ADD LEAF
Add a leaf node to a cluster.
Syntax
ADD LEAF user[:'password']@'host':port [INTO GROUP {1|2}]
Remarks
user
specifies the user other nodes in the cluster will use to connect to the leaf. This user should have super privileges as it will be used to run all queries and cluster management commands on the leaf.password
(default "") is optional. The password needed to log in to the leaf. This password can’t be changed once the leaf is added without first removing the leaf.port
value is 3306.[INTO GROUP {1|2}]
specifies the availability group, if applicable, to which you want to add the leaf. See Managing High Availability for more information. If you do not explicitly specify a group, SingleStoreDB will automatically add the leaf into the smallest group less than or equal toredundancy_level
.If you run
ADD LEAF
on a host/port pair that already exists inSHOW LEAVES
, SingleStoreDB will return an error.This command can be run on the master aggregator node, or a child aggregator node (see Node Requirements for SingleStoreDB Commands ).
ADD LEAF
doesn’t automatically runREBALANCE PARTITIONS
to move new data onto the leaf.REBALANCE
needs to be run manually to move data. If you plan to add multiple leaves its most efficient to add them all first and run a singleREBALANCE
to move data onto the new leaves.If the leaf was previously a part of the cluster any partitions still on the leaf when its added will be reattached as part of
ADD LEAF
.This command causes implicit commits. See COMMIT for more information.
See the Permission Matrix for the required permission.
Warning
Addresses used when running ADD LEAF
should be stable addresses for optimal function and to avoid a split cluster situation.
If a leaf has a different IP when it is started from the one passed to ADD LEAF
, then the master aggregator will not know how to connect to it. The recommended course of action in such a situation is to scrap the leaf node, configure it anew and add it to the cluster. Be careful to use a stable address.
It is also recommended to reconfigure the master aggregator with a stable address during BOOTSTRAP AGGREGATOR, otherwise, you might hit the same issue with the master.
If you need to change the address of a node, you need to remove it from the cluster and re-add it. Make sure to always have an available master aggregator, otherwise, you could end up losing the database.
Example
ADD LEAF 'root'@'192.168.1.110':3306; Query OK, 1 row affected (0.00 sec)
Related Topics