Redis 5.0.3 配置文件详解(易读-白话翻译)-主从

2021年11月21日 阅读数:13
这篇文章主要向大家介绍Redis 5.0.3 配置文件详解(易读-白话翻译)-主从,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

整个系列的目录: Redis 5.0.3 配置文件详解(易读-白话翻译)-目录    node

################################# REPLICATION 主从 #################################

# Master-Replica replication. Use replicaof to make a Redis instance a copy of
# another Redis server. A few things to understand ASAP(as soon as possible) about Redis replication.
# Redis的主从复制,使用"replicaof"从一个Redis Server复制到另一个去,下面有几个要点须要理解
#   +------------------+      +---------------+
#   |      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.
#    主从复制虽然是异步进行的,可是能够经过配置(min-replicas-to-write)让从节点小于特定值时,主节点不接受"write"请求
#
# 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.
#    Redis的老版本没有复制重同步,可是从2.8开始支持部分同步(使用复制挤压缓冲区实现),解决了断线后老版本"彻底同步"低效、阻塞、循环同步的问题
#    若是从节点与主节点断开联系一小段时间,则会发起部分同步,可是复制挤压缓冲区也有大小,能够设置缓冲区的大小来减小彻底同步出现
#
# 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.
#    复制时自动进行的,且不须要人工介入。在出现网络分区后,从节点会自动尝试去重连主节点,链接成功以后发起部分同步,若是复制积压缓冲区中的数据丢失了,则会发起彻底同步
# 
# 这段英文解释若是是入门学习Redis,可能不会太看得懂,推荐先看看Redis设计与实现这本书,会对这段描述有比较深入的认识
# replicaof <masterip> <masterport>
# replicaof 主节点IP  主节点端口,注意必定要保证主从节点网络是通的,检查本机防火墙和第三方防火墙

# 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.
# 若是主节点设置了密码,那么在从节点的redis.conf中要设置masterauth配置项,将密码写在这里,若是没有
# 设置,那么主节点会拒绝从节点的复制请求
#
# masterauth <master-password>
# masterauth 主节点密码

# 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.
#	 若是"replica-serve-stale-data"设置为"yes",这也是默认设置,那么从节点将会回复客户端的请求,可是获得的数据可能出现下面两种状况
#     1.若是是与主节点失去链接,那么获得的数据多是过期的
#     2.若是是第一次从主节点同步数据,那么获得的数据集会是空的
#
# 2) if replica-serve-stale-data is set to 'no' the replica will reply with
#    an error "SYNC with master in progress" to all the kind of commands
#    but to INFO, replicaOF, AUTH, PING, SHUTDOWN, REPLCONF, ROLE, CONFIG,
#    SUBSCRIBE, UNSUBSCRIBE, PSUBSCRIBE, PUNSUBSCRIBE, PUBLISH, PUBSUB,
#    COMMAND, POST, HOST: and LATENCY.
#    若是"replica-serve-stale-data"设置为"no",从节点将回复客户端"SYNC with master in progress"错误
#    可是INFO, replicaOF, AUTH, PING, SHUTDOWN, REPLCONF, ROLE, CONFIG等命令是能够成功执行并获得相应结果
#
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.
# 咱们能够配置从节点是否能够接受write请求,很是不建议将从节点设置为可接受write请求,由于同步可能会致使数据丢失
# 所以从Redis2.6就将"replica-read-only"默认设置为"yes"了
#
# 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.
# 从节点(只读)在架构时建议不要设计为暴露给互联网上的不可信任客户端,它能够起到滥用实例的保护做用
# 从节点依然支持全部的管理命令,好比CONFI,DEBUG等等,为了提升从节点的安全性,可使用"rename-command"来屏蔽全部的"管理命令"
replica-read-only yes

# Replication SYNC strategy: disk or socket.
# 同步策略:经过磁盘(Disk-backed)或者经过SOCKET(Diskless)
#
# -------------------------------------------------------
# WARNING: DISKLESS REPLICATION IS EXPERIMENTAL CURRENTLY
# -------------------------------------------------------
# 很遗憾经过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:
# 新的从节点和重链接的从节点(从节点的最新偏移量不在主节点的复制积压缓冲区中),则会执行"full synchronization"操做,一个RDB文件会采用如下两种方式中的一种传输给从节点:
#
# 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.
#                 主节点fork一个子进程出来将RDB文件生成到磁盘上,而后父进程将RDB文件逐渐发给从节点
# 2) Diskless: The Redis master creates a new process that directly writes the
#              RDB file to replica sockets, without touching the disk at all.
#              主节点fork一个子进程,而后建立一个和从节点的SOCKET链接,直接将数据发送给从节点,而不借助磁盘
#
# 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.
# 若是使用磁盘(disk-backed),当子进程生成RDB文件后,多个从节点当即就可使用RDB文件进行复制操做
# 若是使用SOCKET(diskless),一旦复制开始,当新的节点复制请求必须等已开始复制完成以后才能进行。
#
# 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.
# 当使用SOCKET(diskless)时,主节点能够等一段时间(可配置),这段时间内过来的复制请求能够并行开始
#
# With slow disks and fast (large bandwidth) networks, diskless replication
# works better.
# 若是磁盘效率低,而网络速度快且带宽也大的状况下,Diskless方式完复制效果更好
repl-diskless-sync no

# 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.
# 若是"repl-diskless-sync"设置为yes,就须要配置"repl-diskless-sync-delay"让主节点等待更多的复制请求过来,并让他们并发复制
#
# 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.
# 延迟时间单位是"秒",默认值是5秒。能够将"repl-diskless-sync-delay"设置为0,这样复制就会当即执行
repl-diskless-sync-delay 5

# Replicas send PINGs to server 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"指定的时长(单位:秒)按期发送"pings"给主节点,经过这个操做能够检测从节点是否和主节点失联。该值默认是10秒
#
# repl-ping-replica-period 10

# The following option sets the replication timeout for:
# "repl-timeout"会影响复制过程当中一下三种状况的超时时间
#
# 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.
# 必定要确保"repl-timeout"的值大于"repl-ping-replica-period"的值,不然当主从节点之间通讯量很低时,每次判断超时都是成功的,默认值是60秒
#
# 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.
# 若是将"repl-disable-tcp-nodelay"设置为"yes",那么主节点会使用更小的TCP packet和更少的带宽发送数据到从节点
# 可是这会让从节点的数据延迟40毫秒(LINUX默认配置,也许能够经过tcp_delack_min修改),关于tcp-nodelay能够看博客:https://blog.csdn.net/bytxl/article/details/17677495
#
# 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.
# 若是将"repl-disable-tcp-nodelay"设置为no,那么从节点接收数据的延迟会减小,可是要求更多的带宽来完成复制工做
#
# 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,可是在很是高的通讯量状况下或者从主节点到从节点会通过不少次转发,将"repl-disable-tcp-nodelay"设置为yes是多是更好的选择
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.
# backlog设置复制积压缓冲区的大小,用以存放从节点与主节点断开链接后这段时间的write等命令,当从节点从新链接上来时,一般不须要作"彻底同步",只须要作部分同步(要求从节点偏移量在复制挤压缓冲区能够找到,表示数据可使用偏移量后的命令进行恢复),将偏移量后面的命令发送给从节点执行
#
# The bigger the replication backlog, the longer the time the replica can be
# disconnected and later be able to perform a partial resynchronization.
# 更大的backlog意味着从节点能够断开链接更长时间,而后才能够执行部分同步
#
# The backlog is only allocated once there is at least a replica connected.
# 一旦有从节点链接到主节点,复制积压缓冲区就会建立,此时并无数据。
#
# 这个值到底设置多少,有一个计算公式:2*平均断线时间*每秒写入数据大小,所以和业务量强相关
# repl-backlog-size 1mb

# After a master has no longer 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.
# 当主节点在最后一个从节点断线以后的一段时间后(repl-backlog-ttl设置),会将复制积压缓冲区释放
#
# 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 the replicas: hence they should always accumulate backlog.
# 从节点永远都不会释放,由于它必须保存本身接收的最新偏移量,当出现断线重连时将这个偏移量发给主节点,主节点决定使用彻底同步仍是部分同步
#
# A value of 0 means to never release the backlog.
# 若是设置为0,表示永不释放复制积压缓冲区
#
# 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.
# "replica-priority"是一个整数值,在哨兵的集群模式下,当"主事哨兵"被选举(选举采用过半原则)出来以后,由它决定挂掉主节点下的某一个从节点做为新的主节点,当其余条件都相同的状况下,"replica-priority"值越小的从节点会被选中做为新的主节点
#
# 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.
# 若是将"replica-priority"设置为0,则该从节点永远都不会被选择为新的主节点,根本就不参与选举。能够减小选举过程当中过多的网络通讯,加快选举过程
# 我还只是一个理论派,没实战经验,我的感受若是机器硬件够好,且机器所在的网络质量够好,能够将其优先级设置得高一些
#
# By default the priority is 100.
# 默认值是100
replica-priority 100

# 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.
# 若是链接的从节点小于N且它们的滞后时间小于或者等于M秒,那么主节点可能会中止接收写操做
# 网上说这两个条件中一个不知足就可能致使主节点不能接收写操做,是很准确,必须是两个条件同时知足才会触发
#
# The N replicas need to be in "online" state.
# 要求这N个从节点是"online"状态,还有在哨兵和Cluster模式下节点还有主观下线和客观下线状态
#
# 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.
# 滞后时间的秒数必须小于指定值,滞后时间=当前时间-最后一次接收到的从replica发过来的ping时间
#
# 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.
# 这个选项并不能保证N个从节点接收写操做,可是能够将丢失的数据限制在指定秒数内
#
# 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.
# 若是将这两个选项中的任何一个设置为0,表示禁用这个特征
#
# By default min-replicas-to-write is set to 0 (feature disabled) and
# min-replicas-max-lag is set to 10.
# 默认"min-replicas-to-write"被设置为0,即禁止了这个特征,"min-replicas-max-lag"默认值为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 and address 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 be actually 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.
# 总结起来讲:在主节点中使用info replication能够列出全部从节点的IP+PORT,原本主节点可使用SOCKET拿到从节点的IP+PORT,但若是使用端口转发(docker,k8s)和NAT或者由于使用了代理,从节点不能直接经过IP+PORT到达,下面这两个从节点选项才有用,它能够将设置的IP和PORT报告给主节点,INFO和ROLE命令会显示设置的值
#
# replica-announce-ip 5.5.5.5
# replica-announce-port 1234