If your MemSQL workload changes over time, MemSQL Ops makes it easy to efficiently scale cluster size to meet increasing performance and sizing demands. You can add more leaf or child aggregator nodes to your MemSQL cluster by following the steps below.
Once a database has been created, you cannot change the number of partitions the database was originally created with.
This means to maintain the current number of database partitions per leaf, you must export all data, delete the database, recreate the database and all tables, and load data back into the database’s tables.
Also, to maintain an equal number of partitions per leaf, the new total number of leaves must be divisible by the total number of partitions. For example, a four leaf cluster has four partitions per leaf and 16 partitions total. If only two leaf nodes are added that totals to 6 leaves; however, 16 / 6 is not an integer, meaning there cannot be an equal number of partitions on each leaf. This will cause data skew. If four leaves are added, 16 / 8, then there can be an equal number of partitions on each leaf (two).
If you keep the existing number of partitions, then you don’t have to do any reloading; only rebalancing would be required.
Follow the steps below to add more nodes to your cluster:
-
Match and confirm that the
memsql.cnf
configuration files for new nodes are the same as existing nodes.- Sizing (RAM, Cores)
- Configuration Best Practices (ulimit settings, THP settings, process limits, vm settings)
-
Generate Cluster Report prior to adding nodes. This will be useful for troubleshooting in case any issues arise during the cluster expansion process.
-
Check
memsql-ops version
on all existing hosts (upgrade optional) to ensure you are installing the correct memsql-ops version on the new hosts. You can get the memsql-ops version across all hosts by running:memsql-ops agent-list
-
Un-compress the ops tar file and run the install.sh script on each new node. View the Installation Guide for installation options.
sudo ./install.sh
-
Check and compare the settings.cnf file on a new host (that will become a leaf or aggregator) and an old host (that is an existing leaf or aggregator) to make sure they are the same.
-
From each new host, set each new host to follow the primary ops agent. View the FOLLOW topic for more information.
memsql-ops follow -h PRIMARY_AGENT_HOST
- Check to see if the new leaves are correctly following the master. You should see the new hosts when running
memsql-ops agent-list
.
- Check to see if the new leaves are correctly following the master. You should see the new hosts when running
-
Deploy MemSQL from Master Aggregator
- When deploying from the Master Aggregator, you must specify the Agent ID of the host you want to deploy a MemSQL node on. To get the Agent ID of all hosts, use the agent-list command from step 3.
- If the default port 3306 is already being used by a MemSQL node, you must specify another port with
-P PORT
. - If you are adding leaf nodes, and are running in high availability, (i.e. your Master Aggregator is set to
--redundancy-level 2
), you must specify an availability group for your new leaf nodes,--availability-group {1,2}
. - For more information, see the MEMSQL-DEPLOY documentation.
memsql-ops memsql-deploy -a AGENT_ID -r {leaf,aggregator,master}
- After adding all new nodes, they should now all be visible when running
memsql-ops memsql-list
.
-
Run
memsql-list
on any host to identify the new nodes and pass theMEMSQL_ID
value for those nodes intomemsql-restart
. You must restart each new node to allow thememsql.cnf
configuration settings to take effect.
memsql-ops memsql-list
memsql-ops memsql-restart MEMSQL_ID
-
Update the root password from Master so all new nodes have a root password.
- Use the node’s
MEMSQL_ID
frommemsql-ops memsql-list
. - See the MEMSQL-UPDATE-ROOT-PASSWORD topic for more information.
memsql-ops memsql-update-root-password -p PASSWORD MEMSQL_ID
Note: This operation will remove and re-add the leaf to the cluster. This will cause certain connections to fail and should be considered an offline operation.
- Use the node’s
-
Skip this step if you are on MemSQL v6 or higher. On a new node, connect to the database and run
SHOW USERS;
. You should see two anonymous users,''@'localhost'
and''@'127.0.0.1'
. You will want to drop these users to prevent someone logging into your database anonymously by running:DROP USER ''@'localhost'; DROP USER ''@'127.0.0.1'; DROP USER 'root'@'localhost'; DROP USER 'dashboard'@'%'; DROP USER 'dashboard'@'localhost';
- Run
SHOW USERS;
again to check if the anonymous users have been successfully removed. - See Configuring MemSQL User Accounts for more detail.
- Run
-
To confirm all nodes are properly added:
- If you added leaves, connect to any aggregator and run
SHOW LEAVES;
- If you added aggregators, connect to any aggregator and run
SHOW AGGREGATORS;
- If you added leaves, connect to any aggregator and run
-
On any host, run
memsql-ops memsql-list
to make sure all new leaves and aggregators are Ops aware. You should be able to see all new aggregator or leaf nodes added. -
If you added leaf nodes, enter the SQL interface on the Master Aggregator and run
REBALANCE PARTITIONS;
on all databases. You do not need to perform this step if you added aggregators. -
Check memory and disk usage in the MemSQL Ops user interface.
-
If you added leaves, enter the SQL interface on any aggregator and output
SHOW CLUSTER STATUS
into a file you can examine to make sure partitions are evenly distributed. If you added aggregators, run a simple test query on the new aggregator to confirm the aggregator is functioning. -
If you added leaf nodes, check for data skew by running the following query on any aggregator:
SELECT
DATABASE_NAME,
TABLE_NAME,
FLOOR(AVG(ROWS)) AS avg_rows,
ROUND(STDDEV(ROWS)/AVG(ROWS),3) * 100 AS row_skew,
FLOOR(AVG(MEMORY_USE)) AS avg_memory,
ROUND(STDDEV(MEMORY_USE)/AVG(MEMORY_USE),3) * 100 AS memory_skew
FROM INFORMATION_SCHEMA.TABLE_STATISTICS
GROUP BY 1, 2
HAVING SUM(ROWS) > 10000
ORDER BY row_skew DESC;