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.


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

Last modified: September 8, 2022

Was this article helpful?