DISTRIBUTED_PARTITIONS

This view contains information about partitions.

Column Name	Description
`DATABASE_ID`	The unique `ID` of the related database for a given partition.
`DATABASE_NAME`	The name of the database for the partition.
`ORDINAL`	The ordinal number for a given partition, which decides the order in which data is distributed among partitions.
`HOST`	The hostname or IP address for the related node.
`PORT`	The port number of the related node.
`ROLE`	The role of the related node.
`LOCKED`	Whether a given partition is locked, as part of a partition level lock or higher.
`NODE_ID`	The `ID` of the related node.
`IS_OFFLINE`	Whether a given partition is offline.
`SYNC_DESIRED`	This is `TRUE` if a given partition instance uses synchronous replication. This matches the column `IS_SYNC` from `information_schema.DISTRIBUTED_DATABASES` of the corresponding database.
`STATE`	The current state of a given partition. This can be `EMPTY` (for online masters) or `ASYNC` - data is asynchronously replicated from the master partition. `SYNC` - data is synchronously replicated from the master partition. `READY` - a transition state from async to sync replication used to guarantee that replicas are connected and blocking commits if metadata indicates them as sync. `UNRECOVERABLE` - due to a bug in writing out log records, or a resource issue that replay fails to handle appropriately, for example, disk IO issue, or out of memory (OOM). No user action can be done to bring it back to any other state.
`TERM`	The term of the database, used to uniquely identify which node was the master of a specific database.
`INSTANCE_ID`	Unique `ID` of the partition instance.
`IS_READ_REPLICA`	Whether a given partition is part of a read replica or not.
`SITE_ID`	The ID for the workspace.
`SAFE_TS`	The lower bound of the pre-prepare timestamps of any unresolved 2PC their participants (reference and partition databases) participate or will participate in.
`READ_REPLICA_STATE`	This can be used to determine which instance of a partition on a workspace (where a database is mounted read-only), is actually being used for query execution. Relevant for SingleStore Helios.

Last modified: November 1, 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.

(Optional) Run the following command to view the associated signature files.
Shell
```
curl undefined
```
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.
  Shell
```
curl -O undefined
```

After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

Shell

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