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 slave 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.
Redis on Flash 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 Redis on Flash 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.
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