Database replication

Database replication helps ensure high availability. When replication is enabled, your dataset is replicated to a replica shard, which is constantly synchronized with the primary shard. If the primary shard fails, an automatic failover happens and the replica shard is promoted. That is, it becomes the new primary shard.

When the old primary shard recovers, it becomes the replica shard of the new primary shard. This auto-failover mechanism guarantees that data is served with minimal interruption.

You can tune your high availability configuration with:

  • Rack/Zone Awareness - When rack-zone awareness is used additional logic ensures that master and replica shards never share the same rack, thus ensuring availability even under loss of an entire rack.
  • High Availability for Replica Shards - When high availability for replica shards is used, the replica shard is automatically migrated on node failover to maintain high availability.
Warning:
Enabling replication has implications for the total database size, as explained in Database memory limits.

Auto Tiering replication considerations

We recommend that you set the sequential replication feature using rladmin. This is due to the potential for relatively slow replication times that can occur with Auto Tiering enabled databases. In some cases, if sequential replication is not set up, you may run out of memory.

While it does not cause data loss on the primary shards, the replication to replica shards may not succeed as long as there is high write-rate traffic on the primary and multiple replications at the same time.

The following rladmin command sets the number of primary shards eligible to be replicated from the same cluster node, as well as the number of replica shards on the same cluster node that can run the replication process at any given time.

The recommended sequential replication configuration is two, i.e.:

rladmin tune cluster max_redis_forks 1 max_slave_full_syncs 1
Note:
This means that at any given time, only one primary and one replica can be part of a full sync replication process.

Database replication backlog

Redis databases that use replication for high availability maintain a replication backlog (per shard) to synchronize the primary and replica shards of a database. By default, the replication backlog is set to one percent (1%) of the database size divided by the database number of shards and ranges between 1MB to 250MB per shard. Use the rladmin and the crdb-cli utilities to control the size of the replication backlog. You can set it to auto or set a specific size.

The syntax varies between regular and Active-Active databases.

For a regular Redis database:

rladmin tune db <db:id | name> repl_backlog <Backlog size in MB | 'auto'>

For an Active-Active database:

crdb-cli crdb update --crdb-guid <crdb_guid> --default-db-config "{\"repl_backlog_size\": <size in MB | 'auto'>}"

Active-Active replication backlog

In addition to the database replication backlog, Active-Active databases maintain a backlog (per shard) to synchronize the database instances between clusters. By default, the Active-Active replication backlog is set to one percent (1%) of the database size divided by the database number of shards, and ranges between 1MB to 250MB per shard. Use the crdb-cli utility to control the size of the CRDT replication backlog. You can set it to auto or set a specific size:

crdb-cli crdb update --crdb-guid <crdb_guid> --default-db-config "{\"crdt_repl_backlog_size\": <size in MB | 'auto'>}"

For Redis Software versions earlier than 6.0.20: The replication backlog and the CRDT replication backlog defaults are set to 1MB and cannot be set dynamically with 'auto' mode. To control the size of the replication log, use rladmin to tune the local database instance in each cluster.

rladmin tune db <db:id | name> repl_backlog <Backlog size in MB (or if ending with bytes, KB or GB, in the respective unit)>
RATE THIS PAGE
Back to top ↑