Yandex Cloud
  • Services
  • Solutions
  • Why Yandex Cloud
  • Pricing
  • Documentation
  • Contact us
Get started
Language / Region
© 2022 Yandex.Cloud LLC
Yandex Managed Service for Redis
  • Getting started
  • Step-by-step instructions
    • All instructions
    • Information about existing clusters
    • Creating clusters
    • Changing cluster and database settings
    • Connecting to a database
      • Preparing for connecting
      • Connecting to a non-sharded cluster
      • Connecting to a sharded cluster
    • Stopping and starting clusters
    • Updating a Redis version
    • Managing hosts in a cluster
    • Managing shards
    • Managing backups
    • Changing the master
    • Monitoring the state of a cluster and hosts
    • Deleting clusters
  • Use cases
    • Storing PHP sessions in Managed Service for Redis
    • Migrating databases to Managed Service for Redis
  • Concepts
    • Relationship between service resources
    • Host classes
    • Network in Managed Service for Redis
    • Sharding
    • Backups
    • Replication and fault tolerance
    • Supported clients
    • Memory management in Managed Service for Redis
    • Limitations of Managed Service for Redis
    • Quotas and limits
    • Storage types
    • Redis settings
  • Access management
  • Pricing policy
    • Current pricing policy
    • Archive
      • Before February 1, 2020
  • API reference
    • Authentication in the API
    • gRPC
      • Overview
      • BackupService
      • ClusterService
      • ResourcePresetService
      • OperationService
    • REST
      • Overview
      • Backup
        • Overview
        • get
        • list
      • Cluster
        • Overview
        • addHosts
        • addShard
        • backup
        • create
        • delete
        • deleteHosts
        • deleteShard
        • get
        • getShard
        • list
        • listBackups
        • listHosts
        • listLogs
        • listOperations
        • listShards
        • move
        • rebalance
        • rescheduleMaintenance
        • restore
        • start
        • startFailover
        • stop
        • streamLogs
        • update
        • updateHosts
      • ResourcePreset
        • Overview
        • get
        • list
      • Operation
        • Overview
        • get
  • Questions and answers
    • General questions
  1. Concepts
  2. Replication and fault tolerance

Replication and fault tolerance

Written by
Yandex.Cloud
  • Replication
  • Fault tolerance
  • Redis persistence settings

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 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.

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.

Redis persistence settings

Managed Service for Redis clusters use fault tolerance (persistence) presets:

  • save ""

    Regular RDB file saving is disabled. Instead, AOF mode is used.

  • appendonly yes

    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.

    Warning

    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.

  • no-appendfsync-on-rewrite yes

    Since the AOF fsync policy 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 BGSAVE or BGREWRITEAOF.

    When you run BGREWRITEAOF, 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.

  • 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 value.

  • auto-aof-rewrite-min-size 64mb

    The minimum size that triggers the AOF file rewrite process is 64 MB.

  • 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 about Redis persistence options, see the DBMS documentation and the redis.conf file description.

Was the article helpful?

Language / Region
© 2022 Yandex.Cloud LLC
In this article:
  • Replication
  • Fault tolerance
  • Redis persistence settings