Important

Self-managed SingleStore will soon transition from version 9.1 RC to version 10. This new semantic versioning scheme will provide SingleStore with finer control over engine and feature releases that were not possible with the current versioning scheme.

In the interim, SingleStore 9.1 RC can be used to preview, evaluate, and provide feedback on the new and upcoming features in SingleStore 10 prior to its general availability. Ahead of this transition, SingleStore 9.0 is recommended for production workloads, which can later be upgraded to SingleStore 10.

Cluster Management Commands

Node Requirements for SingleStore Commands

SingleStore commands must be run on the appropriate type(s) of node in a SingleStore cluster.

When sync_permissions and enable_query_forwarding are set to ON, all Data Definition Language (DDL) commands can be forwarded from child aggregator to master. This list of requirements reflects this behavior.

For more information about these variables, see the Sync Variables Lists.

X = recommended to run on this type of node
P = possible (but not recommended) to run on this type of node
blank = cannot run on this type of node

SingleStore Command	Master Aggregator	Child Aggregator	Leaf
ADD AGGREGATOR	X	X
AGGREGATOR SET AS MASTER		X
ANALYZE	X	X
ADD LEAF	X
ALTER DATABASE	X	X
ALTER RESOURCE POOL	X	X
ALTER TABLE	X	X	P
ALTER VIEW	X	X	P
ALTER USER	X	X
ATTACH LEAF	X	X
ALTER PIPELINE	X	X
BACKUP DATABASE	X	X
BEGIN	X	X	P
BOOTSTRAP AGGREGATOR	X	X
COMMIT	X	X	P
CONTINUE REPLICATING	P	P	P
CREATE AGGREGATE	X	X
CREATE DATABASE	X	X	P
CREATE FUNCTION	X	X
CREATE GROUP	X	X
CREATE INDEX	X	X	P
CREATE PIPELINE	X	X
CREATE PROCEDURE	X	X
CREATE RESOURCE POOL	X	X
CREATE ROLE	X	X
CREATE TABLE	X	X	P
CREATE USER	X	X
CREATE VIEW	X	X
DELETE	X	X	P
DESCRIBE	X	X	X
DETACH LEAF	X	X
DROP AGGREGATE	X	X
DROP DATABASE	X	X	P
DROP FUNCTION	X	X
DROP GROUP	X	X
DROP INDEX	X	X	P
DROP PIPELINE	X	X
DROP PROCEDURE	X	X
DROP RESOURCE POOL	X	X
DROP ROLE	X	X
DROP TABLE	X	X	P
DROP RESULT TABLE	X	X
DROP USER	X	X	X
DROP VIEW	X	X	P
DROP … FROM PLANCACHE	X	X	P
EXPLAIN	X	X	X
EXTRACT PIPELINE	X	X
FLUSH TABLES	X		P
GRANT	X	X	X
GRANT GROUP	X	X	X
GRANT ROLE	X	X	X
INSERT	X	X	P
KILL CONNECTION	X	X	P
KILLALL QUERIES	X	X	P
LOAD DATA	X	X	P
OPTIMIZE TABLE	X	X	P
PAUSE REPLICATING	P	P	P
PROMOTE AGGREGATOR … TO MASTER	X	X
PROFILE PIPELINE	X	X
REBALANCE PARTITIONS	X	X
REMOVE AGGREGATOR	X	X
REMOVE LEAF	X	X
REPAIR DATABASE	X	X	X
REPLACE	X	X	P
REPLICATE DATABASE	P	P	P
RESTORE DATABASE	X	X
RESTORE REDUNDANCY	X	X
ROLLBACK	X	X	P
REVOKE	X	X
REVOKE GROUP	X	X
REVOKE ROLE	X	X
SELECT	X	X	P
SET GLOBAL	X	X	P
SHOW AGGREGATORS	X	X
SHOW COLUMNS	X	X
SHOW CREATE TABLE	X	X	P
SHOW DATABASES	X	X	P
SHOW GRANTS	X	X	X
SHOW INDEX	X	X	P
SHOW INDEXES	X	X	P
SHOW KEYS	X	X
SHOW LEAVES	X	X
SHOW PLANCACHE	X	X	X
SHOW PROCESSLIST	X	X	X
SHOW REPLICATION STATUS	X	X	X
SHOW SCHEMAS	X	X	P
SHOW GLOBAL STATUS	X	X	X
SHOW GLOBAL VARIABLES	X	X	X
SHOW RESOURCE POOLS	X	X	P
SHOW SESSION STATUS	X	X	X
SHOW SESSION VARIABLES	X	X	X
SHOW STATUS EXTENDED	X	X	X
SHOW TABLE STATUS	X	X	X
SHOW TABLES	X	X	X
SHOW VARIABLES	X	X	X
SHOW WARNINGS	X	X	X
SHOW ERRORS	X	X	X
START PIPELINE	X	X
STOP PIPELINE	X	X
STOP REPLICATING	X	X	X
TRUNCATE	X	X
UNLOCK TABLES	X
UPDATE	X	X	P
USE	X	X	P

Leaf States

Each leaf is in one of the following states:

State	Description
`Unknown`	In this state, a leaf is not part of the cluster. This is the state before you run ADD LEAF to introduce the leaf into the system. A leaf that is unknown will not show up in SHOW LEAVES. The REMOVE LEAF command will transition a leaf into the `unknown` state.
`Online`	This is the default, healthy state of a leaf. In the `online` state, the leaf is an active member of the distributed system and is either currently serving or ready to serve data to the aggregators.
`Offline`	The master aggregator periodically sends a heartbeat (ping) to all the nodes in a cluster to determine if they are responsive and online. A leaf enters the `offline` state if the master aggregator cannot reach it. The heartbeat frequency is based on typical network latencies and node responsiveness. It is set to a default of 150ms which has been empirically determined. If the cluster is in redundancy 2 any partitions on the `offline` node will be failed over to the leaves pair. The master aggregator continues to ping `offline` nodes to detect when they should be moved into the `attaching` state. See How Failover is Triggered in HA for failover cases.
`Recovering`	Not online, and not available for read or write queries. A leaf in `recovering` state has been restarted and is replaying data back into memory.
`Detached`	In this state, the leaf is detached from the cluster. A leaf transitions from `online` to `detached` when DETACH LEAF is run. You can reintroduce the leaf into the `online` state with the ATTACH LEAF command. This command will automatically try to reuse the data present on the leaf; this is especially important in redundancy-1. DETACH LEAF is the same as REMOVE LEAF except that after rebalancing away a leaf’s partitions, it transitions it to `detached` instead of `unknown`.
`Attaching`	A leaf transitions from `offline` to `attaching` when it is once again reachable by heartbeats. The master aggregator will automatically run ATTACH LEAF to attach any partitions on the leaf back into the cluster. While the attach is running the leaf will stay in the `attaching` state. When the attach is finished the leaf will move to the `online` state.

The following diagram summarizes the leaf states and the transitions between them.

Cluster Management Commands

On this page

Node Requirements for SingleStore Commands

Leaf States

In this section

Was this article helpful?

On this page

Was this article helpful?