# Redis 入门到精通（九）-- 主从复制（3）

Redis 入门到精通（九）-- 主从复制（3）

一、redis 主从复制-常见问题（1）

1、伴随着 redis 系统的运行，master 的数据量会越来越大，一旦 master 重启，runid 将发生变化，会导致全部 slave 的全量复制操作，这样会引发频繁的全量复制。

2、redis 内部优化调整方案：

1）master 内部创建 master_replid 变量，使用 runid 相同的策略生成，长度41位，并发送给所有 slave。

2）在 master 关闭时执行命令 shutdown save，进行 RDB 持久化,将 runid 与 offset 保存到 RDB 文件中。

java 复制代码

repl-id repl-offset
通过 redis-check-rdb 命令可以查看该信息

3）master 重启后加载 RDB 文件，恢复数据。

重启后，将 RDB 文件中保存的 repl-id 与 repl-offset 加载到内存中。

java 复制代码

master_repl_id = repl 
master_repl_offset = repl-offset
通过 info 命令可以查看该信息

4）作用：

本机保存上次 runid，重启后恢复该值，使所有 slave 认为还是之前的 master。

3、以下问题也会产生频繁的全量复制（2）

1）问题现象

网络环境不佳，出现网络中断，slave不提供服务。

2）问题原因

复制缓冲区过小，断网后slave的offset越界，触发全量复制。

3）最终结果

slave反复进行全量复制。

4）解决方案

修改复制缓冲区大小。

5）建议设置如下：

1. 测算从master到slave的重连平均时长second
1. 获取master平均每秒产生写命令数据总量write_size_per_second
1. 最优复制缓冲区空间 = 2 * second * write_size_per_second

二、redis 主从复制-常见问题（2）

1、redis 主从复制出现频繁的网络中断情况一

1）问题现象

master 的 CPU 占用过高或 slave 频繁断开连接。

2）问题原因

slave 每1秒发送 REPLCONF ACK 命令到 master。
当 slave 接到了慢查询时（keys * ，hgetall等），会大量占用 CPU 性能。
master 每1秒调用复制定时函数 replicationCron()，比对 slave 发现长时间没有进行响应。

3）最终结果

master 各种资源（输出缓冲区、带宽、连接等）被严重占用。

4）解决方案

通过设置合理的超时时间，确认是否释放 slave。
repl-timeout 该参数定义了超时时间的阈值（默认60秒），超过该值，释放 slave。

2、redis 主从复制出现频繁的网络中断情况二

1）问题现象

slave 与 master 连接断开。

2）问题原因

master 发送 ping 指令频度较低。
master 设定超时时间较短。
ping 指令在网络中存在丢包。

3）解决方案

提高ping指令发送的频度。
repl-ping-slave-period 超时时间 repl-time 的时间至少是 ping 指令频度的5到10倍，否则 slave 很容易判定超时。

三、redis 主从复制-常见问题（3）

1、redis 主从复制，数据不同步问题

1）问题现象

多个slave获取相同数据不同步。

2）问题原因

网络信息不同步，数据发送有延迟。

3）解决方案

优化主从间的网络环境，通常放置在同一个机房部署，如使用阿里云等云服务器时要注意此现象。
监控主从节点延迟（通过offset）判断，如果 slave 延迟过大，暂时屏蔽程序对该 slave 的数据访问。

java 复制代码

slave-serve-stale-data yes|no

开启后仅响应 info、slaveof 等少数命令（慎用，除非对数据一致性要求很高）。

2、redis 主从复制内容总结：

1）什么是持久化。

2）RDB ：save, bgsave, 配置。

3）AOF ：持久化写策略。重写。

上一节关联链接请点击：
# Redis 入门到精通（九）-- 主从复制（2）