Important

The SingleStore 9.1 release candidate (RC) gives you the opportunity to preview, evaluate, and provide feedback on new and upcoming features prior to their general availability. In the interim, SingleStore 9.0 is recommended for production workloads, which can later be upgraded to SingleStore 9.1.

REMOVE LEAF

Removes a leaf node from a cluster without deleting its data.

This command rebalances the leaf node’s partitions into the remaining leaves on the cluster and removes the specified leaf node from the Master Aggregator. Consequently, the leaf node will be removed from the SHOW LEAVES command. A leaf node that has been removed can be added back to the cluster, without any loss of data, by using the ADD LEAF command.

While the cluster will no longer know about this leaf node, Toolbox will still know that memsqlctl recognizes that there is a running memsql process which is now in the unknown state.

Syntax

REMOVE LEAF 'host':port [FORCE] [KILL] [ENSURE_PARTITION_SAFETY]

FORCE

REMOVE LEAF is designed to keep the database online while you remove a leaf from the cluster. However, if you want to remove a leaf node without keeping the database online (for example, during maintenance operations), then use the FORCE option to disable automatic rebalancing. When specified, it disables the rebalancing behavior of REMOVE LEAF.

During some operational workflows, when leaf_failure_detection is OFF, a leaf may be marked as online even when it is unreachable, presumably due to connection errors. To remove such leaves, enable remove_leaf_force_remove_online_leaf and run the REMOVE LEAF command with the FORCE option. In this configuration, the REMOVE LEAF command ignores any connection errors and treats the leaf as offline for the duration of the command. Refer to List of Engine Variables for more information on the respective engine variables.

KILL

KILL prevents persistent long running write queries from blocking a clustering option for an arbitrarily long time (for example, a scale up or scale down or even an upgrade). Auto-rebalances automatically use the KILL mode if the auto-rebalance fails to run after three attempts.

ENSURE_PARTITION_SAFETY

ENSURE_PARTITION_SAFETY prevents a leaf (or leaves) from being removed if it contains the last online instance of a partition.

Remarks

  • The default port is 3306.

  • If the leaf does not have a pair, SingleStore will rebalance its partitions onto the remaining leaves before removing it. After this rebalance process is over, the databases partition that were moved are no longer present on the node.

  • You must use the ADD LEAF command if you want to reintroduce the removed leaf into the cluster.

  • Refer to sdb-admin delete-node to delete a leaf node and its data.

  • This command can be run on the master aggregator node, or a child aggregator node (refer to Node Requirements for SingleStore Commands ).

  • If MemSQL Ops is not enabled for manual cluster control, then a REMOVE LEAF can result in the leaf being added back without user intervention.

  • This command causes implicit commits. Refer to COMMIT for more information.

  • Refer to the Permission Matrix for the required permissions.

Example

REMOVE LEAF '192.168.1.110':3306;

REMOVE LEAVES

Removes all leaf nodes without removing the data.

Refer to the REMOVE LEAF section for more information.

Note

REMOVE LEAVES is an all-or-nothing command, either all the leaves will be removed, or none of them will.

Syntax

REMOVE LEAVES [IF EXISTS] ('host_1':port_1, ..., 'host_n':port_n) [FORCE] [ENSURE_PARTITION_SAFETY]

Example

REMOVE LEAVES ('192.168.1.110':3306, '192.168.1.111':3306, '192.168.1.112':3306);

Last modified: March 10, 2026

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined
  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined
  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
    cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
    --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
    --bundle undefined \
    --new-bundle-format -
    Verified OK

Try Out This Notebook to See What’s Possible in SingleStore

Get access to other groundbreaking datasets and engage with our community for expert advice.