麦克斯仇
Think different
159
文章
36873
阅读
首页
INDEX
文章
ARTICLE
关于
ABOUT
Redis主从复制
创建日期：
2021/05/18
修改日期：
2022/09/27
Linux
Redis
> 本文档整理自教程： 1. Redis官方文档：[Replication](https://redis.io/topics/replication) 2. Redis官方文档：[Redis Sentinel Documentation](https://redis.io/topics/sentinel) 3. 尚硅谷视频：[尚硅谷_Redis6](http://www.atguigu.com/download_detail.shtml?v=323) # 简介 主库数据更新后根据配置和策略，自动同步到从库的`master/slaver`机制，主库以写为主，从库以读为主。 - 优点：**读写分离，性能扩展** - 场景：**读多写少**  # 如何使用 ## 环境准备 准备三台互通的服务器 ``` 192.168.220.101:6379 192.168.220.102:6379 192.168.220.103:6379 ``` 按照教程：[CentOS7/CentOS8安装Redis6.2.3](https://maxqiu.com/article/detail/50)分别安装Redis服务，若设置密码，各个库的密码应当设置相同 安装完成后环境如下：  ## 配置从库 **从库**在配置后原先的数据会被删除。 > 方案1：修改配置文件 修改两个从库`redis.conf`中的如下配置： ```ini # 连接的主库地址与端口 replicaof 192.168.220.101 6379 # 连接的主库密码（如果主库有） masterauth 123 # 连接的主库用户名（如果主库有） masteruser username ``` 修改完成后重启从库 > 方案2：使用命令脚本 分别登录从库并认证，之后使用如下命令进行配置 PS：从`Redis 5.0.0`开始，使用`REPLICAOF host port`代替`SLAVEOF host port` ``` # 设置主库的密码（如果主库有） 127.0.0.1:6379> CONFIG SET masterauth 123 OK # 设置主库的用户名（如果主库有） 127.0.0.1:6379> CONFIG SET masteruser username ok # 配置主库地址 127.0.0.1:6379> REPLICAOF 192.168.220.101 6379 ok ``` > 查看结果 之后登录并使用`INFO replication`查看信息  ## 效果 > 主库写入，从库读取 主库： ```bash 127.0.0.1:6379> SET key1 value1 OK ``` 从库： ```bash 127.0.0.1:6379> KEYS * 1) "key1" 127.0.0.1:6379> GET key1 "value1" ``` > 从库仅读取，无法写入 从库： ```bash 127.0.0.1:6379> SET key2 value2 (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`完整示例文档，本文仅挑重点说 > 监控信息设置 示例： ``` sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 60000 sentinel failover-timeout mymaster 180000 sentinel parallel-syncs mymaster 1 sentinel monitor resque 192.168.1.3 6380 4 sentinel down-after-milliseconds resque 10000 sentinel failover-timeout resque 180000 sentinel parallel-syncs resque 5 ``` 只需要指定要监视的主库，为每个独立的主库(可能有任意数量的从库)指定不同的名称。不需要指定从库，从库是自动发现的。Sentinel将使用关于从库的附加信息自动更新配置(以便在重启时保留这些信息)。在故障转移期间，每次将一个从库提升为主库，以及每次发现一个新的Sentinel，配置都会被重写。上面的示例配置监视两组Redis主从复制实例，每个实例由一个主库和一个未定义数量的从库组成。一组实例称为mymaster，另一组称为resque。 主要设置说明： ```ini 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永远不会启动故障转移。 其他设置说明： 其他选项都是如下格式： ```ini 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`：是否为守护进程 ### 部署架构 > 官方推荐 ```ini +----+ | M1 | | S1 | +----+ | +----+ | +----+ | R2 |----+----| R3 | | S2 | | S3 | +----+ +----+ Configuration: quorum = 2 ``` - 主库：M1，M2，M3，...，Mn。 - 从库：R1，R2，R3，...，Rn。 - 哨兵：S1，S2，S3，...，Sn。 ## 实战步骤 > 步骤1：设置主从关系 按上文步骤进行设置 - 配置时使用**配置文件**方式配置 - 主库也要配置`masterauth,masteruser`信息，防止主库宕机后切换为从库时无法连接其他主库 - 建议**一主多从**模式 > 步骤2：设置配置文件 在所有服务器上新建`sentinel.conf`配置文件，内容如下： ``` # 绑定地址 bind 0.0.0.0 # 关闭保护模式 protected-mode no # 端口 port 26379 # 守护进程模式 daemonize yes # pid文件位置 pidfile "/usr/local/redis/sentinel.pid" # 日志文件 logfile "/usr/local/redis/sentinel.log" # 工作文件位置 dir "/usr/local/redis" # 主库地址 sentinel monitor master 192.168.220.101 6379 2 # Redis访问密码（如果有） sentinel auth-pass master 123 # 访问用户（如果有） # sentinel auth-pass master <password> # Sentinel访问密码（建议设置） requirepass "123" # 其他配置 sentinel down-after-milliseconds master 15000 sentinel failover-timeout master 60000 ``` > 步骤3：启动哨兵 依次在所有的服务器上执行以下命令启动哨兵： ```bash redis-sentinel sentinel.conf ``` 之后就可以测试宕机自动切换了 ## 故障恢复原理 
13
全部评论
