有道無術，術尚可求，有術無道，止于術。

本系列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 地址和端口信息可能不正確，可以使用以上配置進行指定。