Sign inTry Free

Important

New database features are no longer connected to engine versions; features are now enabled independently during scheduled update windows, and “major” and “minor” releases no longer exist in Helios. Please visit the release notes to view the latest features available in your database clusters.

MV_REPLICATION_MANAGEMENT_REF_DB_STATE

This view shows the state of the reference database replica on the node.

This view is also available as an LMV (local view per node) view.

Column Name

Description

NODE_ID

The node ID for the node that originated this replication management row.

ID

Internal ID for replication management. Useful for cross-referencing with tracelogs.

DISTRIBUTED_DATABASE_ID

The ID of this distributed database, in the sharded database table of cluster database metadata.

INSTANCE_NODE_ID

The ID of the node that hosts this reference database replica. Will be the same value as NODE_ID.

METADATA_ROLE

The role of this instance in cluster metadata. Possible values: Master, Async Replica, Unrecoverable, Paused Replica.

LOCAL_ROLE

The role of this instance locally on the node where it exists. Possible values: Master, Replica, Transitioning, Dropping or Reprovisioning, Unrecoverable, Recovering, Missing (disconnected).

DR_STATUS

Whether the database is a DR replica or not, and if so whether it is paused or not. Possible values: Not DR, Active DR, Paused DR.

MASTER_METADATA_TERM

Term uniquely identifies a period during which an instance of a database is a master. This holds the term of the master in metadata - it will always match LOCAL_TERM if this instance’s METADATA_ROLE is Master.

LOCAL_TERM

Term uniquely identifies a period during which an instance of a database is a master.

UPDATE_ITERATION

The last iteration counter on which this state was updated. Used to cross-check with the other replication management tables.

DATABASE_NAME

Name of the database.

RUNTIME_STATE_UPDATE_RESULT

Records whether the runtime state for this reference database was successfully updated or not (this includes partition boundaries, for example). This is not used to take an action, but is only used to determine whether an iteration of the replication management thread succeeded or not.

Last modified:

Was this article helpful?

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.

Sign UpLog In