Workspace Management Commands

Node Requirements for SingleStore Helios Commands

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

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.

  • 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 Helios Command

Master Aggregator

Child Aggregator

Leaf

ANALYZE

X

X

ALTER DATABASE

X

X

ALTER RESOURCE POOL

X

X

ALTER TABLE

X

X

P

ALTER VIEW

X

X

P

ALTER USER

X

X

ALTER PIPELINE

X

X

BACKUP DATABASE

X

X

BEGIN

X

X

P

COMMIT

X

X

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

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 USER

X

X

X

DROP VIEW

X

X

P

DROP … FROM PLANCACHE

X

X

P

EXPLAIN

X

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

PROFILE PIPELINE

X

X

REPAIR DATABASE

X

X

X

REPLACE

X

X

P

RESTORE DATABASE

X

X

ROLLBACK

X

X

P

REVOKE

X

X

REVOKE GROUP

X

X

REVOKE ROLE

X

X

SELECT

X

X

P

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 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

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 workspace.

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 workspace 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 workspace 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.

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 workspace.

Attaching

A leaf transitions from offline to attaching when it is once again reachable by heartbeats.

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

In this section

Last modified: September 11, 2024

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