Modes of replication

Describes the asynchronous and synchronous modes of table replication.

You can replicate table data in one of two replication modes. You specify the mode per source-replica pair.

Asynchronous replication

In this replication mode, MapR Database confirms to client applications that operations are complete after the operations are performed on source tables. Updates are replicated in the background. Therefore, the latency of updates from client applications is not affected by the time required for the network round trip between the source cluster and the destination cluster.

This type of replication is well-suited for clusters that are geographically separated in wide-area networks.

MapR Database can throttle the replication stream to minimize the impact of the replication process on incoming operations during periods of heavy load. Throttling distributes disk reads and CPU usage more evenly over time, so that incoming operations on a source table can be completed faster. Throttling is disabled by default.

Asynchronous replication is the default replication mode.

Synchronous replication

In this replication mode, MapR Database confirms to client applications that changes have been applied to a source table only when these two conditions are true:

  • The change was sent to all of the container copies in the local cluster.
  • The change was sent to a gateway in the destination cluster. This operation takes place only after the first. Puts are not sent to gateways until after they are sent to all container copies in the cluster where the source table is located.

If a gateway fails, the source detects this and resends operations to the gateway when it is restarted or a new gateway is brought online.

Due to the confirmations that MapR Database receives on source clusters, synchronous replication is especially well-suited for creating a backup of your data for disaster recovery.

When the latency of a replication stream is high, MapR Database switches to asynchronous replication temporarily so that client applications are not blocked indefinitely. After the latency is sufficiently reduced, MapR Database switches back to synchronous replication. The same switching occurs when a gateway fails, and MapR Database does not resume synchronous replication until a new gateway is established or the failed gateway is restarted.