Redis 7.x 系列【22】主从复制配置项

有道无术，术尚可求，有术无道，止于术。

本系列Redis 版本 7.2.5

源码地址：https://gitee.com/pearl-organization/study-redis-demo

1. 前言

redis.conf 配置文件中，提供了很多个主从复制的配置项（在从节点中配置）：

################################# REPLICATION ################################## Master-Replica replication. Use replicaof to make a Redis instance a copy of
# another Redis server. A few things to understand ASAP about Redis replication.
#
#   +------------------+      +---------------+
#   |      Master      | ---> |    Replica    |
#   | (receive writes) |      |  (exact copy) |
#   +------------------+      +---------------+
#
# 1) Redis replication is asynchronous, but you can configure a master to
#    stop accepting writes if it appears to be not connected with at least
#    a given number of replicas.
# 2) Redis replicas are able to perform a partial resynchronization with the
#    master if the replication link is lost for a relatively small amount of
#    time. You may want to configure the replication backlog size (see the next
#    sections of this file) with a sensible value depending on your needs.
# 3) Replication is automatic and does not need user intervention. After a
#    network partition replicas automatically try to reconnect to masters
#    and resynchronize with them.
#
# replicaof <masterip> <masterport># If the master is password protected (using the "requirepass" configuration
# directive below) it is possible to tell the replica to authenticate before
# starting the replication synchronization process, otherwise the master will
# refuse the replica request.
#
# masterauth <master-password>
#
# However this is not enough if you are using Redis ACLs (for Redis version
# 6 or greater), and the default user is not capable of running the PSYNC
# command and/or other commands needed for replication. In this case it's
# better to configure a special user to use with replication, and specify the
# masteruser configuration as such:
#
# masteruser <username>
#
# When masteruser is specified, the replica will authenticate against its
# master using the new AUTH form: AUTH <username> <password>.# When a replica loses its connection with the master, or when the replication
# is still in progress, the replica can act in two different ways:
#
# 1) if replica-serve-stale-data is set to 'yes' (the default) the replica will
#    still reply to client requests, possibly with out of date data, or the
#    data set may just be empty if this is the first synchronization.
#
# 2) If replica-serve-stale-data is set to 'no' the replica will reply with error
#    "MASTERDOWN Link with MASTER is down and replica-serve-stale-data is set to 'no'"
#    to all data access commands, excluding commands such as:
#    INFO, REPLICAOF, AUTH, SHUTDOWN, REPLCONF, ROLE, CONFIG, SUBSCRIBE,
#    UNSUBSCRIBE, PSUBSCRIBE, PUNSUBSCRIBE, PUBLISH, PUBSUB, COMMAND, POST,
#    HOST and LATENCY.
#
replica-serve-stale-data yes# You can configure a replica instance to accept writes or not. Writing against
# a replica instance may be useful to store some ephemeral data (because data
# written on a replica will be easily deleted after resync with the master) but
# may also cause problems if clients are writing to it because of a
# misconfiguration.
#
# Since Redis 2.6 by default replicas are read-only.
#
# Note: read only replicas are not designed to be exposed to untrusted clients
# on the internet. It's just a protection layer against misuse of the instance.
# Still a read only replica exports by default all the administrative commands
# such as CONFIG, DEBUG, and so forth. To a limited extent you can improve
# security of read only replicas using 'rename-command' to shadow all the
# administrative / dangerous commands.
replica-read-only yes# Replication SYNC strategy: disk or socket.
#
# New replicas and reconnecting replicas that are not able to continue the
# replication process just receiving differences, need to do what is called a
# "full synchronization". An RDB file is transmitted from the master to the
# replicas.
#
# The transmission can happen in two different ways:
#
# 1) Disk-backed: The Redis master creates a new process that writes the RDB
#                 file on disk. Later the file is transferred by the parent
#                 process to the replicas incrementally.
# 2) Diskless: The Redis master creates a new process that directly writes the
#              RDB file to replica sockets, without touching the disk at all.
#
# With disk-backed replication, while the RDB file is generated, more replicas
# can be queued and served with the RDB file as soon as the current child
# producing the RDB file finishes its work. With diskless replication instead
# once the transfer starts, new replicas arriving will be queued and a new
# transfer will start when the current one terminates.
#
# When diskless replication is used, the master waits a configurable amount of
# time (in seconds) before starting the transfer in the hope that multiple
# replicas will arrive and the transfer can be parallelized.
#
# With slow disks and fast (large bandwidth) networks, diskless replication
# works better.
repl-diskless-sync yes# When diskless replication is enabled, it is possible to configure the delay
# the server waits in order to spawn the child that transfers the RDB via socket
# to the replicas.
#
# This is important since once the transfer starts, it is not possible to serve
# new replicas arriving, that will be queued for the next RDB transfer, so the
# server waits a delay in order to let more replicas arrive.
#
# The delay is specified in seconds, and by default is 5 seconds. To disable
# it entirely just set it to 0 seconds and the transfer will start ASAP.
repl-diskless-sync-delay 5# When diskless replication is enabled with a delay, it is possible to let
# the replication start before the maximum delay is reached if the maximum
# number of replicas expected have connected. Default of 0 means that the
# maximum is not defined and Redis will wait the full delay.
repl-diskless-sync-max-replicas 0# -----------------------------------------------------------------------------
# WARNING: Since in this setup the replica does not immediately store an RDB on
# disk, it may cause data loss during failovers. RDB diskless load + Redis
# modules not handling I/O reads may cause Redis to abort in case of I/O errors
# during the initial synchronization stage with the master.
# -----------------------------------------------------------------------------
#
# Replica can load the RDB it reads from the replication link directly from the
# socket, or store the RDB to a file and read that file after it was completely
# received from the master.
#
# In many cases the disk is slower than the network, and storing and loading
# the RDB file may increase replication time (and even increase the master's
# Copy on Write memory and replica buffers).
# However, when parsing the RDB file directly from the socket, in order to avoid
# data loss it's only safe to flush the current dataset when the new dataset is
# fully loaded in memory, resulting in higher memory usage.
# For this reason we have the following options:
#
# "disabled"    - Don't use diskless load (store the rdb file to the disk first)
# "swapdb"      - Keep current db contents in RAM while parsing the data directly
#                 from the socket. Replicas in this mode can keep serving current
#                 dataset while replication is in progress, except for cases where
#                 they can't recognize master as having a data set from same
#                 replication history.
#                 Note that this requires sufficient memory, if you don't have it,
#                 you risk an OOM kill.
# "on-empty-db" - Use diskless load only when current dataset is empty. This is 
#                 safer and avoid having old and new dataset loaded side by side
#                 during replication.
repl-diskless-load disabled# Master send PINGs to its replicas in a predefined interval. It's possible to
# change this interval with the repl_ping_replica_period option. The default
# value is 10 seconds.
#
# repl-ping-replica-period 10# The following option sets the replication timeout for:
#
# 1) Bulk transfer I/O during SYNC, from the point of view of replica.
# 2) Master timeout from the point of view of replicas (data, pings).
# 3) Replica timeout from the point of view of masters (REPLCONF ACK pings).
#
# It is important to make sure that this value is greater than the value
# specified for repl-ping-replica-period otherwise a timeout will be detected
# every time there is low traffic between the master and the replica. The default
# value is 60 seconds.
#
# repl-timeout 60# Disable TCP_NODELAY on the replica socket after SYNC?
#
# If you select "yes" Redis will use a smaller number of TCP packets and
# less bandwidth to send data to replicas. But this can add a delay for
# the data to appear on the replica side, up to 40 milliseconds with
# Linux kernels using a default configuration.
#
# If you select "no" the delay for data to appear on the replica side will
# be reduced but more bandwidth will be used for replication.
#
# By default we optimize for low latency, but in very high traffic conditions
# or when the master and replicas are many hops away, turning this to "yes" may
# be a good idea.
repl-disable-tcp-nodelay no# Set the replication backlog size. The backlog is a buffer that accumulates
# replica data when replicas are disconnected for some time, so that when a
# replica wants to reconnect again, often a full resync is not needed, but a
# partial resync is enough, just passing the portion of data the replica
# missed while disconnected.
#
# The bigger the replication backlog, the longer the replica can endure the
# disconnect and later be able to perform a partial resynchronization.
#
# The backlog is only allocated if there is at least one replica connected.
#
# repl-backlog-size 1mb# After a master has no connected replicas for some time, the backlog will be
# freed. The following option configures the amount of seconds that need to
# elapse, starting from the time the last replica disconnected, for the backlog
# buffer to be freed.
#
# Note that replicas never free the backlog for timeout, since they may be
# promoted to masters later, and should be able to correctly "partially
# resynchronize" with other replicas: hence they should always accumulate backlog.
#
# A value of 0 means to never release the backlog.
#
# repl-backlog-ttl 3600# The replica priority is an integer number published by Redis in the INFO
# output. It is used by Redis Sentinel in order to select a replica to promote
# into a master if the master is no longer working correctly.
#
# A replica with a low priority number is considered better for promotion, so
# for instance if there are three replicas with priority 10, 100, 25 Sentinel
# will pick the one with priority 10, that is the lowest.
#
# However a special priority of 0 marks the replica as not able to perform the
# role of master, so a replica with priority of 0 will never be selected by
# Redis Sentinel for promotion.
#
# By default the priority is 100.
replica-priority 100# The propagation error behavior controls how Redis will behave when it is
# unable to handle a command being processed in the replication stream from a master
# or processed while reading from an AOF file. Errors that occur during propagation
# are unexpected, and can cause data inconsistency. However, there are edge cases
# in earlier versions of Redis where it was possible for the server to replicate or persist
# commands that would fail on future versions. For this reason the default behavior
# is to ignore such errors and continue processing commands.
#
# If an application wants to ensure there is no data divergence, this configuration
# should be set to 'panic' instead. The value can also be set to 'panic-on-replicas'
# to only panic when a replica encounters an error on the replication stream. One of
# these two panic values will become the default value in the future once there are
# sufficient safety mechanisms in place to prevent false positive crashes.
#
# propagation-error-behavior ignore# Replica ignore disk write errors controls the behavior of a replica when it is
# unable to persist a write command received from its master to disk. By default,
# this configuration is set to 'no' and will crash the replica in this condition.
# It is not recommended to change this default, however in order to be compatible
# with older versions of Redis this config can be toggled to 'yes' which will just
# log a warning and execute the write command it got from the master.
#
# replica-ignore-disk-write-errors no# -----------------------------------------------------------------------------
# By default, Redis Sentinel includes all replicas in its reports. A replica
# can be excluded from Redis Sentinel's announcements. An unannounced replica
# will be ignored by the 'sentinel replicas <master>' command and won't be
# exposed to Redis Sentinel's clients.
#
# This option does not change the behavior of replica-priority. Even with
# replica-announced set to 'no', the replica can be promoted to master. To
# prevent this behavior, set replica-priority to 0.
#
# replica-announced yes# It is possible for a master to stop accepting writes if there are less than
# N replicas connected, having a lag less or equal than M seconds.
#
# The N replicas need to be in "online" state.
#
# The lag in seconds, that must be <= the specified value, is calculated from
# the last ping received from the replica, that is usually sent every second.
#
# This option does not GUARANTEE that N replicas will accept the write, but
# will limit the window of exposure for lost writes in case not enough replicas
# are available, to the specified number of seconds.
#
# For example to require at least 3 replicas with a lag <= 10 seconds use:
#
# min-replicas-to-write 3
# min-replicas-max-lag 10
#
# Setting one or the other to 0 disables the feature.
#
# By default min-replicas-to-write is set to 0 (feature disabled) and
# min-replicas-max-lag is set to 10.# A Redis master is able to list the address and port of the attached
# replicas in different ways. For example the "INFO replication" section
# offers this information, which is used, among other tools, by
# Redis Sentinel in order to discover replica instances.
# Another place where this info is available is in the output of the
# "ROLE" command of a master.
#
# The listed IP address and port normally reported by a replica is
# obtained in the following way:
#
#   IP: The address is auto detected by checking the peer address
#   of the socket used by the replica to connect with the master.
#
#   Port: The port is communicated by the replica during the replication
#   handshake, and is normally the port that the replica is using to
#   listen for connections.
#
# However when port forwarding or Network Address Translation (NAT) is
# used, the replica may actually be reachable via different IP and port
# pairs. The following two options can be used by a replica in order to
# report to its master a specific set of IP and port, so that both INFO
# and ROLE will report those values.
#
# There is no need to use both the options if you need to override just
# the port or the IP address.
#
# replica-announce-ip 5.5.5.5
# replica-announce-port 1234

2. 配置说明

2.1 replicaof

replicaof 参数用于在从节点中配置主节点的IP、端口：

# replicaof <masterip> <masterport>

2.2 masterauth

masterauth 参数用于配置主节点的密码，如果主节点设置了密码保护，可以在开始复制同步过程之前告知从节点进行身份验证，否则主节点将拒绝从节点的请求。

# masterauth <master-password>

2.3 masteruser

masteruser 参数用于配置主节点的用户名，Redis ACL（适用于 Redis 6 或更高版本）中，可以配置一个专用用户用于复制：

# masteruser <username>

2.4 replica-serve-stale-data

replica-serve-stale-data 用于配置从节点与主节点失去连接，或者正在进行时，从节点如何响应客户端的读请求。

replica-serve-stale-data yes

设置为 yes（默认）时，从节点仍然会响应客户端请求，可能会返回过期的数据，如果是第一次同步，则数据集可能为空。

设置为 no 时，当主节点连接中断，从节点将对所有访问命令回复错误消息：“MASTERDOWN Link with MASTER is down and replica-serve-stale-data is set to 'no'”。INFO、REPLICAOF、AUTH、SHUTDOWN、REPLCONF、ROLE、CONFIG、SUBSCRIBE、UNSUBSCRIBE、PSUBSCRIBE、PUNSUBSCRIBE、PUBLISH、PUBSUB、COMMAND、POST、HOST 和 LATENCY 等命令除外。

2.5 replica-read-only

replica-read-only 用于设置从节点是否允许进行写操作。

replica-read-only yes

设置为 yes（默认）时，从节点是只读的，即不允许客户端发送写命令。这是为了避免从节点上的数据和主节点的数据发生冲突，确保数据一致性和主从复制的正确性。

设置为 no 时，从节点将允许接受客户端发送的写命令。这种设置一般用于特殊需求或者特定场景下，例如需要在从节点执行某些数据修改操作。

2.6 repl-diskless-sync

repl-diskless-sync 用于配置在全量复制时，是否使用无盘复制。

repl-diskless-sync yes

设置为 yes（默认）时，表示使用无盘复制模式，主节点在生成 RDB 快照后，不会立即将其写入磁盘，而是直接将其内容通过网络发送给从节点。这样，就避免了磁盘 I/O 的开销，从而提高了复制的效率。但是由于 RDB 快照内容保存在内存中，可能会增加主节点的内存压力。

设置为 no 时，主节点在生成 RDB 快照，并将其写入磁盘。然后，主节点会将这个 RDB 文件发送给从节点。这个过程中，磁盘 I/O 可能会成为了性能瓶颈之一。

2.7 repl-diskless-sync-delay

repl-diskless-sync-delay 用于配置在无盘复制过程中，主节点在开始实际传输 RDB 数据之前需要等待的时间。延迟的目的是希望在这段时间内，更多的从节点能够连接到主节点，以便主节点可以并行地将 RDB 数据发送给这些从节点，从而提高复制的效率。

repl-diskless-sync-delay 5

延迟以秒为单位指定，默认为5秒。要完全禁用延迟，只需将其设置为0秒，传输将尽快开始。

2.8 repl-diskless-sync-max-replicas

repl-diskless-sync-max-replicas 用于配置在无盘复制过程中，如果已连接的从节点达到预期的最大数量，可以在达到最大延迟（repl-diskless-sync-delay）之前开始复制。

repl-diskless-sync-max-replicas 0

默认值为0意味着最大值未定义，Redis会等待完整的延迟时间。

2.9 repl-diskless-load

repl-diskless-load 用于配置在无盘复制过程中，从节点在接收到 RDB 数据时的处理方式。

repl-diskless-load disabled

支持的配置项：

• disabled：默认值，从节点在接收到 RDB 数据时，不会立即加载到内存中，而是会先将数据写入磁盘，然后再从磁盘中加载到内存中。这种方式更加保守，可以确保数据的持久性和安全性，但在某些情况下可能会增加磁盘 I/O 的开销。
• on-empty-db：当从节点的数据库为空时，才直接从内存中加载 RDB 数据，而不是先写入磁盘。这种方式可以在一定程度上减少磁盘 I/O，但在从节点已经包含数据的情况下仍然会先写入磁盘。这是更安全的方式，避免在复制过程中同时加载旧数据集和新数据集。
• swapdb：从节点在接收到 RDB 数据时，在内存中先创建一个数据库的拷贝，然后将接收到的 RDB 数据解析并加载到这个拷贝中。如果解析成功，则替换掉原有的数据库；如果失败，则恢复原有的数据库。注意，这需要足够的内存，如果内存不足，可能会面临OOM（内存耗尽）风险。

2.10 repl-ping-replica-period

repl-ping-replica-period 用于配置主节点向其从节点发送PING命令的时间间隔，默认值为 10 秒。

# repl-ping-replica-period 10

2.11 repl-timeout

repl-ping-replica-period 用于配置主从节点之间在复制过程中的超时时间，默认值为60秒。

# repl-timeout 60

在复制的过程中，如果超过了时间，主从节点之间还没有任何数据交换，则认为复制连接可能出现问题。此时会采取一些措施来尝试恢复复制连接，如关闭当前的复制连接并尝试重新建立连接。

从主节点角度来说，在 repl-timeout 时间内，没有收到从节点发送的 REPLCONF ACK 确认信息，则认定超时。

从节点角度来说，在 repl-timeout 时间内，没有收到主节点发送 RDB 快照数据、PING命令，则认定超时。

2.12 repl-disable-tcp-nodelay

repl-disable-tcp-nodelay用于配置在主从节点同步后，是否禁用 TCP_NODELAY。

repl-disable-tcp-nodelay no

TCP_NODELAY 是 TCP/IP 协议栈中的一个套接字选项，用于控制 TCP 连接的 Nagle 算法。Nagle 算法是一种旨在减少网络拥塞的算法，它通过合并小的 TCP 数据包成更大的数据包来发送，从而减少网络上的小数据包数量，但可能会增加数据的延迟。

设置为 no 时（默认），Redis 会立即发送同步数据，没有延迟。这样做可以确保数据的一致性，但可能会增加网络带宽的消耗。

设置为 yes 时，Redis 会合并小的 TCP 数据包，从而节省带宽，但这样做会增加数据同步的延迟，可能会达到 40 毫秒或更多。这可能会导致主从节点之间的数据在短时间内出现不一致的情况。

2.13 repl-backlog-size

repl-backlog-size 用于配置复制积压缓冲区（repl_backlog_buffer）的大小，默认为 1MB 。

epl-backlog-size 1mb

2.14 repl-backlog-ttl

repl-backlog-ttl 用于配置复制积压缓冲区中数据的存活时长，默认为3600 秒，为0表示永久存活。

# repl-backlog-ttl 3600

改配置确保了即使从节点长时间离线，只要在这个时间范围内重新连接，就有可能通过部分同步来恢复数据一致性。

2.15 replica-priority

replica-priority 用于配置在主节点故障时，从节点将被选为新的主节点的优先级（哨兵模式）。

replica-priority 100

默认情况下，优先级为100。值越小，表示优先级越高。例如，如果有三个副本的优先级分别为10、100和25，哨兵模式会选择优先级为10的节点。优先级为 0 表示用不会被升级为主节点。

2.16 propagation-error-behavior

propagation-error-behavior 用于配置在命令传播过程中，发生错误的处理方式。

# propagation-error-behavior ignore

命令传播过程中发生错误，可能会导致数据不一致性，默认是忽略此类错误并继续处理命令。

2.17 replica-ignore-disk-write-errors no

replica-ignore-disk-write-errors 用于配置从节点在遇到磁盘写入错误时的处理方式。

# replica-ignore-disk-write-errors no

可选配置项：

• no：这是默认值，表示从节点不会忽略磁盘写入错误。如果发生磁盘写入错误，从节点将停止处理数据复制，将会停止接收数据并报告错误给客户端和或日志系统。因为它无法可靠地保证数据的一致性。这有助于防止数据损坏，但也可能导致服务中断。

2.18 replica-announced

replica-announced 用于配置从节点是否应该被Sentinel公告或暴露给Sentinel的客户端。

# replica-announced yes

在哨兵模式中，默认情况下，所有的从节点都会被包含在 Sentinel 的公告中。可以配置 Sentinel 忽略某些从节点，这种未公告的从节点会被 sentinel replicas <master> 命令忽略，并且不会被暴露给 Redis Sentinel 的客户端。

此配置不会改变优先级的行为。即使将 replica-announced 设置为 ‘no’，该节点仍然可以被提升为主节点。

2.19 min-replicas-to-write、min-replicas-max-lag

min-replicas-to-write 和 min-replicas-max-lag 用于配置在连接的从节点数量少于 N 个，并且这些从节点的延迟时间不超过 M 秒的情况下停止接受写操作。

例如，要求至少有 3 个从节点，且延迟时间不超过 10 秒，可以使用以下配置：

min-replicas-to-write 3  
min-replicas-max-lag 10

将其中一个或两个值设置为 0 可以禁用此功能。默认情况下，min-replicas-to-write 被设置为 0（功能禁用），而 min-replicas-max-lag 被设置为 10。

2.20 replica-announce-ip、replica-announce-port

replica-announce-ip 和 replica-announce-port 允许从节点在连接到主节点时，宣布一个与自身实际 IP 地址和端口不同的 IP 地址和端口。这在某些特定的网络配置或部署场景中非常有用，比如当从节点位于 NAT 后面或使用了容器/虚拟化技术时。

# replica-announce-ip 5.5.5.5
# replica-announce-port 1234

从节点需要上报自己的地址信息给主节点，当使用端口转发或网络地址转换（NAT），或者使用了容器/虚拟化技术时， IP 地址和端口信息可能不正确，可以使用以上配置进行指定。