Redis主从复制

2021-05-18  Linux  Redis

本文档整理自教程：

主库数据更新后根据配置和策略，自动同步到从库的master/slaver机制，主库以写为主，从库以读为主。

• 优点：读写分离，性能扩展
• 场景：读多写少

准备三台互通的服务器

1. 192.168.220.101:6379
2. 192.168.220.102:6379
3. 192.168.220.103:6379

按照教程：CentOS7/CentOS8安装Redis6.2.3分别安装Redis服务，若设置密码，各个库的密码应当设置相同

安装完成后环境如下：

从库在配置后原先的数据会被删除。

方案1：修改配置文件

修改两个从库redis.conf中的如下配置：

1. # 连接的主库地址与端口
2. replicaof 192.168.220.101 6379
3. # 连接的主库密码（如果主库有）
4. masterauth 123
5. # 连接的主库用户名（如果主库有）
6. masteruser username

修改完成后重启从库

方案2：使用命令脚本

分别登录从库并认证，之后使用如下命令进行配置

PS：从Redis 5.0.0开始，使用REPLICAOF host port代替SLAVEOF host port

1. # 设置主库的密码（如果主库有）
2. 127.0.0.1:6379> CONFIG SET masterauth 123
3. OK
4. # 设置主库的用户名（如果主库有）
5. 127.0.0.1:6379> CONFIG SET masteruser username
6. ok
7. # 配置主库地址
8. 127.0.0.1:6379> REPLICAOF 192.168.220.101 6379
9. ok

之后登录并使用INFO replication查看信息

主库写入，从库读取

1. 127.0.0.1:6379> SET key1 value1
2. OK

1. 127.0.0.1:6379> KEYS *
2. 1) "key1"
3. 127.0.0.1:6379> GET key1
4. "value1"

从库仅读取，无法写入

1. 127.0.0.1:6379> SET key2 value2
2. (error) READONLY You can't write against a read only replica.

• 从库启动成功且连接到主库后会发送一个sync命令
• 主库接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，主库将传送整个数据文件到从库以完成一次完全同步
  1. 先全量复制：从库接收到数据库文件数据后，将其存盘并加载到内存中。
  2. 后增量复制：主库继续将新的所有收集到的修改命令依次传给从库，完成同步
• 但是只要是从库重新连接主库，一次完全同步将被自动执行

所有从库都直连主库。当新增一台从库时，会自动执行一次数据同步。

• 主库宕机：从库原地待命，仅读取，不可写入。
• 主库恢复：从库自动重新连接。
• 从库宕机：仅宕机的从库不可访问，其他正常。
• 从库恢复：
  • 配置文件式：自动重新连接并同步数据。
  • 命令配置式：需要重新执行配置命令，连接后同步数据。

上一个从库可以是下一个从库的主库，从库同样可以接收其他从库的连接和同步请求，那么该从库作为了链条中下一个的主库, 可以有效减轻主库的写压力，去中心化降低风险。

• 主库宕机：从库原地待命，仅读取，不可写入。主库恢复后从库自动重新连接
• 从库宕机：中间从库宕机，后面的从库均不会有新数据产生。

反客为主（手动解决宕机问题）

当一个主库宕机后，后面的从库执行REPLICAOF no one可以升为主库，一主多从模式下其他的从库需要执行REPLICAOF host port更换主库，薪火相传模式后面的从库不用做任何修改。

☆ Redis Sentinel 哨兵模式（自动解决宕机问题）

反客为主的自动版，能够后台监控主机是否故障，发生故障后根据投票数自动将从库转换为主库

• 监控：Sentinel会不断检查主实例和副本实例是否按预期工作。
• 通知：Sentinel可以通过API通知系统管理员或其他计算机程序，其中一个受监视的Redis实例出了问题。
• 自动故障转移：如果主服务器未按预期工作，则Sentinel可以启动故障转移过程，在该过程中，将副本升级为主服务器，将其他附加副本重新配置为使用新的主服务器，并通知使用Redis服务器的应用程序连接时要使用的新地址。
• 配置提供程序：Sentinel充当客户端服务发现的授权来源：客户端连接到Sentinels，以询问负责给定服务的当前Redis主服务器的地址。如果发生故障转移，Sentinels将报告新地址。

Sentinel的分布式性质

Redis Sentinel是一个分布式系统：Sentinel本身被设计为在多个Sentinel进程协同工作的配置中运行。让多个Sentinel进程协同工作的好处如下:

1. 当多个哨兵一致认为某一主子不再可用时，会执行失败检测。这降低了误报的概率。
2. 即使不是所有的Sentinel进程都在工作，Sentinel也可以工作，这使得系统能够健壮地抵御故障。毕竟，故障转移系统本身就是一个单点故障，这一点也不好玩。

sentinel.conf 配置文件

Sentinel在启动时需要一份sentinel.conf配置文件，在Redis的源码包内有一份sentinel.conf完整示例文档，本文仅挑重点说

监控信息设置

1. sentinel monitor mymaster 127.0.0.1 6379 2
2. sentinel down-after-milliseconds mymaster 60000
3. sentinel failover-timeout mymaster 180000
4. sentinel parallel-syncs mymaster 1
5. sentinel monitor resque 192.168.1.3 6380 4
6. sentinel down-after-milliseconds resque 10000
7. sentinel failover-timeout resque 180000
8. sentinel parallel-syncs resque 5

只需要指定要监视的主库，为每个独立的主库(可能有任意数量的从库)指定不同的名称。不需要指定从库，从库是自动发现的。Sentinel将使用关于从库的附加信息自动更新配置(以便在重启时保留这些信息)。在故障转移期间，每次将一个从库提升为主库，以及每次发现一个新的Sentinel，配置都会被重写。上面的示例配置监视两组Redis主从复制实例，每个实例由一个主库和一个未定义数量的从库组成。一组实例称为mymaster，另一组称为resque。

主要设置说明：

1. sentinel monitor <master-group-name> <ip> <port> <quorum>

第一行用来告诉Redis监视一个名为mymaster的主机，它的地址是127.0.0.1，端口是6379，仲裁人数是2。

• quorum是指哨兵的数量，他们需要就主机不可达的事实达成一致，以便真正标记主机故障，并在可能的情况下最终启动故障转移程序。
• 然而，仲裁仅用于检测故障。为了真正执行故障转移，其中一个哨兵需要被选举为故障转移的领导者并被授权进行。这只有在Sentinel进程的大多数投票时才会发生。

例如，如果你有5个Sentinel进程，并且给定master的quorum值为2，就会发生这样的情况：

• 如果两个哨兵同时同意主节点不可达，其中一个将尝试启动故障切换。
• 如果至少有三个哨兵可到达，故障转移将被授权，并将真正开始。

在实践中，这意味着在故障发生期间，如果大多数Sentinel进程无法交谈(也就是在少数分区中没有故障转移)，那么Sentinel永远不会启动故障转移。

其他设置说明：

其他选项都是如下格式：

1. sentinel <option_name> <master_name> <option_value>

常用设置如下：

• sentinel down-after-milliseconds <master-name> <milliseconds>：Sentinel检测Redis的超时时间（以毫秒为单位）默认30秒
• sentinel parallel-syncs <master-name> <numreplicas>：故障转移时，同时有多少个副本执行同步，建议1
• sentinel auth-pass <master-name> <password>：Sentinel：连接主机的密码（如果有）
• sentinel auth-user <master-name> <username>：Sentinel：连接主机的用户名（如果有）
• sentinel failover-timeout <master-name> <milliseconds>：故障转移超时时间（默认3分钟）
• sentinel notification-script <master-name> <script-path>：发生故障时需要执行的通知脚本

其他信息设置

• port 26379：Sentinel的端口
• requirepass <password>：Sentinel的密码（若设置了密码，则所有的Sentinel密码都要相同）
• daemonize no：是否为守护进程

1. +----+
2. | M1 |
3. | S1 |
4. +----+
5. |
6. +----+ | +----+
7. | R2 |----+----| R3 |
8. | S2 | | S3 |
9. +----+ +----+
10. Configuration: quorum = 2

• 主库：M1，M2，M3，…，Mn。
• 从库：R1，R2，R3，…，Rn。
• 哨兵：S1，S2，S3，…，Sn。

步骤1：设置主从关系

按上文步骤进行设置

• 配置时使用配置文件方式配置
• 主库也要配置masterauth,masteruser信息，防止主库宕机后切换为从库时无法连接其他主库
• 建议一主多从模式

步骤2：设置配置文件

在所有服务器上新建sentinel.conf配置文件，内容如下：

1. # 绑定地址
2. bind 0.0.0.0
3. # 关闭保护模式
4. protected-mode no
5. # 端口
6. port 26379
7. # 守护进程模式
8. daemonize yes
9. # pid文件位置
10. pidfile "/usr/local/redis/sentinel.pid"
11. # 日志文件
12. logfile "/usr/local/redis/sentinel.log"
13. # 工作文件位置
14. dir "/usr/local/redis"
15. # 主库地址
16. sentinel monitor master 192.168.220.101 6379 2
17. # Redis访问密码（如果有）
18. sentinel auth-pass master 123
19. # 访问用户（如果有）
20. # sentinel auth-pass master <password>
21. # Sentinel访问密码（建议设置）
22. requirepass "123"
23. # 其他配置
24. sentinel down-after-milliseconds master 15000
25. sentinel failover-timeout master 60000

步骤3：启动哨兵

依次在所有的服务器上执行以下命令启动哨兵：

1. redis-sentinel sentinel.conf

之后就可以测试宕机自动切换了

故障恢复原理