Sign inTry Free

SHOW REPLICATION STATUS

Warning

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

On this page

Shows the list of all connections between the replication master and secondary databases.

Syntax

SHOW REPLICATION STATUS

Remarks

  • The URI identifies the database as <host>:<port>/<dbName>.

  • Log position is the position in the transactional log formatted as <LogFileId>:<ByteOffsetInLogFile>.

  • Each database in replicating mode has two background threads (SecondaryNetwork and SecondaryReplay). The state and position of both threads are displayed per-database. The SecondaryNetwork thread downloads the necessary snapshot files and transaction logs from the primary database and the SecondaryReplay thread reads transactions from these files and commits them to memory.

  • A row in the result table represents a replication. It could be a replication from:

    master aggregator to child aggregator

    master partition to a replica partition in cluster

    a primary cluster to a secondary cluster

    It also depends on the node where a user runs this command. If this command is run on a leaf node, replications from one partition to another will be reported. If it is run in a master aggregator, then the db replications and cluster-db replications will be reported.

  • This command can be run on any SingleStore node (see Cluster Management Commands).

  • If a sync replica is out of sync it will not appear in the output.

  • This command does not display DR clusters and the primary databases that do not have replicas.

  • The output of this command depends on the number of leaves in a cluster as explained Replication Distribution Tree.

  • Refer to the Permission Matrix for the required permission.

Output

Column

Explanation

Role

The replication role of the local database copy. Possible values are async replica, sync replica, and master.

Database

The name of the database being replicated. The database name is the same on the primary and secondary clusters, except for the sharding database which is called sharding_[hash] on the secondary cluster.

MasterURI

The URI for the primary database instance. The format is host:port/database_name.

Master_State

The state of the primary database instance. Commonly, the master state is online but differs during transition periods/errors. See Database States for details.

Master_CommitLSN

Position in the log before which all pages have been committed. All content is committed in the pages that are in the log before this log sequence number (LSN).

Master_HardenedLSN

Position in the log before which all pages have been written to the disk.

Master_ReplayLSN

Position in the log before which all pages have been replayed into memory.

Master_TailLSN

Position in the log before which all pages have been reserved for transactions. The next transaction to reserve space from the log will start writing at this LSN.

MasterCommits

The number of transactions committed on the primary database instance.

Connected

The current state of the connection between master and replica instances of the database. Possible values are yes and no.

ReplicaURI

The URI for the secondary database instance. The format is host:port/database_name.

ReplicaState

The state of the secondary database instance. Possible values are replicating and replication paused.

Replica_CommitLSN

Position in the log before which all pages have been committed. It is replicated from the master, and thus is expected to be behind Master_CommitLSN.

Replica_HardenedLSN

Position in the log before which all pages have been written to the disk.

Replica_ReplayLSN

Position in the log before which all pages have been replayed into memory. It is always less than or equal to CommitLSN (in an active workload, it is expected to lag behind CommitLSN by few LSN).

Replica_TailLSN

All pages that have been received from the master is below this LSN.

ReplicaCommits

The number of transactions committed on the secondary database instance.

Note

This SingleStore feature is only available in SingleStore Enterprise Edition. SingleStore Enterprise Edition includes 24x7 support and several enterprise-only features for critical deployments. For more information about SingleStore Developer and SingleStore Enterprise, see the SingleStore Editions page.

Example

SHOW REPLICATION STATUS;
+--------+----------+------------+--------------+------------------+--------------------+------------------+----------------+----------------+-----------+------------+--------------------------+---------------+-------------------+---------------------+-------------------+-----------------+-----------------+
| Role   | Database | Master_URI | Master_State | Master_CommitLSN | Master_HardenedLSN | Master_ReplayLSN | Master_TailLSN | Master_Commits | Connected | Throttling | Replica_URI              | Replica_State | Replica_CommitLSN | Replica_HardenedLSN | Replica_ReplayLSN | Replica_TailLSN | Replica_Commits |
+--------+----------+------------+--------------+------------------+--------------------+------------------+----------------+----------------+-----------+------------+--------------------------+---------------+-------------------+---------------------+-------------------+-----------------+-----------------+
| master | cluster  | NULL       | online       | 0:239            | 0:239              | 0:233            | 0:239          |             32 | yes       | no         | 127.0.0.1:3307/cluster   | replicating   | 0:238             | 0:239               | 0:238             | 0:239           |              30 |
| master | trades   | NULL       | online       | 0:4294967341     | 0:4294967341       | 0:4294967339     | 0:4294967341   |             39 | yes       | no         | 127.0.0.1:3307/trades    | replicating   | 0:4294967340      | 0:4294967341        | 0:4294967340      | 0:4294967341    |              38 |
+--------+----------+------------+--------------+------------------+--------------------+------------------+----------------+----------------+-----------+------------+--------------------------+---------------+-------------------+---------------------+-------------------+-----------------+-----------------+

Last modified: August 4, 2023

Was this article helpful?

On this page

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