Sign inTry Free

Replication

On this page

The replication process forms an essential part of a disaster recovery (DR) plan.

SingleStore replicates data in the following situations.

Synchronous and Asynchronous Replication

Synchronous Replication Debugging Flow

The diagram below shows what happens when an async alert is raised at the partition level. The replica refers to the leaf node that has the replica partition and the master is the master partition instance, which fails if the leaf node where it hosted goes offline, or is unable to communicate with the master aggregator (for example. due to network issues).

High availability, Redundancy-2 mode

With high availability redundancy-2 replication, you can specify, using the CREATE DATABASE, RESTORE DATABASE and ALTER DATABASE commands, whether replication from primary to replica partitions is synchronous or asynchronous. By default, synchronous replication is used. Synchronous replication from the primary partitions will complete on all replicas before the commit of the transaction is acknowledged to the client application.

Synchronous replication is usually no more than ten to twenty percent slower than asynchronous replication. However, SingleStore recommends using synchronous replication; it provides much stronger data consistency guarantees as compared to asynchronous replication.

If a database is using synchronous replication and its replica partition fails to respond within five seconds, the replica partition switches to asynchronous replication; this allows the replica partition to not block the current and future replication transactions. The replica partition does not resume failover until both of the following are true:

  • The replica partition becomes responsive.

  • The primary partition becomes responsive, if it was previously unresponsive.

When the replica partition resumes failover, it switches to synchronous replication.

Replica Log Replay and Partition Promotion during HA Failover.

  • Replica log pages are received/hardened on one path; applying them into memory (replay) runs asynchronously and can lag.

  • Before a replica partition becomes master, the engine waits until replay has applied all locally committed log (online failover also syncs promote targets first).

  • While a partition is in promote-to-master transition, new reads and writes to that partition are blocked until promotion completes (or fails/times out). Writes against a steady-state replica partition fail; reads may see stale data.

  • This process is separate from sync vs async replication (whether the master waits for replica ack before acknowledging commit to the client).

  • The master_promote_timeout and master_promote_kill_timeout_seconds timeout variables for bounded waits during online failover.

REPLICATE DATABASE

When you use the REPLICATE DATABASE command, you can only replicate asynchronously.

Last modified:

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

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