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

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

本系列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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314

2. 配置说明

2.1 replicaof

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

# replicaof <masterip> <masterport>
1

2.2 masterauth

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

# masterauth <master-password>
1

2.3 masteruser

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

# masteruser <username>
1

2.4 replica-serve-stale-data

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

replica-serve-stale-data yes
1

设置为 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
1

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

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

2.6 repl-diskless-sync

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

repl-diskless-sync yes
1

设置为 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
1

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

2.8 repl-diskless-sync-max-replicas

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

repl-diskless-sync-max-replicas 0
1

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

2.9 repl-diskless-load

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

repl-diskless-load disabled
1

支持的配置项：

• 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
1

2.11 repl-timeout

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

# repl-timeout 60
1

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

从主节点角度来说，在 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
1

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
1

2.14 repl-backlog-ttl

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

# repl-backlog-ttl 3600
1

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

2.15 replica-priority

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

replica-priority 100
1

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

2.16 propagation-error-behavior

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

# propagation-error-behavior ignore
1

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

2.17 replica-ignore-disk-write-errors no

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

# replica-ignore-disk-write-errors no
1

可选配置项：

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

2.18 replica-announced

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

# replica-announced yes
1

在哨兵模式中，默认情况下，所有的从节点都会被包含在 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
1
2

将其中一个或两个值设置为 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
1
2

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