Replication and fault tolerance
Managed Service for Redis uses standard Redis replication and provides high availability of cluster data using Redis Sentinel.
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 the asynchronous nature of replication, data on replicas might become stale: while a replica is processing updates received from the master, it continues responding to requests using the available data (the replica-serve-stale-data yes parameter is set).
Due to limited resources, b1.nano and b1.small class hosts aren't replicated.
For more information about how replication works in Redis, see the DBMS documentation.
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.
Redis persistence settings
Managed Service for Redis clusters use fault tolerance (persistence) presets:
Regular RDB file saving is disabled. Instead, AOF mode is used.
AOF (Append Only File) mode is enabled. In this mode, Redis logs every write operation without changing already written data.
The AOF mode ensures data integrity in the event of cluster or Redis process emergency shutdown. Its use creates additional load on the hard drive, so you can disable this setting to save resources.
Disable AOF only if data integrity is unimportant for your application, for example, when using Managed Service for Redis as your cache. If this is the case, the most recent data captured in Redis will only be stored in RAM and will be lost if a server crashes.
Since the AOF
fsyncpolicy is set to
everysec, the AOF log's background save (
BGSAVE) or rewrite (
BGREWRITEAOF) process performs many disk I/O operations. Redis may block calling
fsync()for too long in some Linux configurations.
The setting prevents calling
fsync()within the main system process when running
When you run
fsync()is in progress. Redis writes the shortest sequence of commands needed to rebuild the current dataset in memory. You can adjust the data size using the aof-rewrite-incremental-fsync setting.
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 value.
The minimum size that triggers the AOF file rewrite process is 64 MB.
Allows loading a truncated AOF file if the system crashes. A notice of loading the truncated file is logged.
Enables AOF file synchronization every time 32 MB of data is generated.
Enables using the RDB file as a preamble to the AOF file when rewriting or restoring it.