Replication and fault tolerance
Managed Service for Redis uses standard Redis replication and provides high availability of cluster data using Redis Sentinel.
Replication
Managed Service for Redis clusters use asynchronous replication: the result of a write request is reflected on the master host, which then forwards the data to the cluster replicas. The replication process does not affect the master availability in any way, but it can make replicas temporarily unavailable (for up to a few seconds for large databases) when loading new data into memory.
Because of replication's asynchronous nature, data on replicas may be out of date: while a replica is processing updates from the master, it continues sending existing data in response to requests (replica-serve-stale-data yes flag is set).
Due to limited resources, b1, b2, and b3 class hosts aren't replicated.
For more information about how replication works in Redis, read the DBMS documentation.
Fault tolerance
A master host can be changed both automatically as a result of a failure and manually. Manual master switching is available both for a sharded cluster and an unsharded one.
High data availability in an unsharded cluster is implemented using Redis Sentinel: in a cluster consisting of three or more hosts, Sentinel services automatically manage master selection and replica configurations.
In order to make decisions about cluster performance, the majority of Sentinel services need to be healthy. As a result, it's more cost-efficient to deploy clusters with an odd number of hosts when working with Managed Service for Redis. For example, a cluster with three hosts can lose one host and continue working, while a cluster with four hosts can also lose no more than one host: if a second host is lost, the remaining Sentinel instances will not be enough to select a new master.
A cluster consisting of two hosts does not provide full failover for the same reason: one of the two Sentinel instances will not be enough to assign one host as a master if the other one failed. In this situation, the cluster can only process read operations.
Owners of Managed Service for Redis clusters can't configure Sentinel services, but they can read the information that the services provide. Read more about Sentinel in the DBMS documentation.
Assigning a different host as a master if the primary master fails
If the master host fails, any of the cluster hosts available for replication becomes a new master. If the master assignment priority is set for the cluster hosts, the host with the lowest priority is selected as a new master. The minimum value is 0
and the maximum (default) value is 100
. A host with the 0
priority will never be selected as a master.
Persistence
Managed Service for Redis clusters use data persistence presets. You can disable persistence, if required, to improve server throughput because the DBMS will stop writing updates out to disk.
Warning
Only disable persistence if data integrity is unimportant to your application, for instance when using Managed Service for Redis as cache. This will cause the most recent data captured in Redis to be stored in RAM only and to become lost if a server crashes.
Persistence settings
By default, cluster persistence is enabled and uses the following Redis settings:
-
save ""
Regular RDB file saving is disabled. AOF mode is used instead.
-
appendonly yes
AOF (Append Only File) mode is enabled. In this mode, Redis logs every write operation without changing already written data.
-
no-appendfsync-on-rewrite yes
Since the AOF
fsync
policy is set toeverysec
, the AOF log backgroundBGSAVE
save orBGREWRITEAOF
rewrite processes perform a lot of disk I/O. Redis can blockfsync()
calls for too long in some Linux configurations.The setting prevents calling
fsync()
within the main system process when runningBGSAVE
orBGREWRITEAOF
.When
BGREWRITEAOF
is running,fsync()
is called. Redis writes the shortest sequence of commands required to restore the current dataset to memory. You can control data size using the aof-rewrite-incremental-fsync setting. -
auto-aof-rewrite-percentage 100
The AOF log size must exceed 100% for the AOF file to be automatically rewritten. Depends on the log file's auto-aof-rewrite-min-size setting.
-
auto-aof-rewrite-min-size 64mb
Auto-aof-rewrite-min-size 64mb
-
aof-load-truncated yes
Allows loading a truncated AOF file if the system crashes. A notice of loading the truncated file is logged.
-
aof-rewrite-incremental-fsync yes
Enables AOF file synchronization every time 32 MB of data is generated.
-
aof-use-rdb-preamble yes
Enables using the RDB file as a preamble to the AOF file when rewriting or restoring it.
For more information on Redis persistence mechanisms, refer to the DBMS documentation and the redis.conf config file description.
Disabling persistence
With persistence disabled, the following Redis settings take effect:
-
save ""
Regular RDB file saving is disabled.
-
appendonly no
The AOF (Append Only File) is disabled.