# 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 文件中。
repl-id repl-offset
通过 redis-check-rdb 命令可以查看该信息
3）master 重启后加载 RDB 文件，恢复数据。
重启后，将 RDB 文件中保存的 repl-id 与 repl-offset 加载到内存中。
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）建议设置如下：
-
- 测算从master到slave的重连平均时长second
-
- 获取master平均每秒产生写命令数据总量write_size_per_second
-
- 最优复制缓冲区空间 = 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 的数据访问。
slave-serve-stale-data yes|no
开启后仅响应 info、slaveof 等少数命令（慎用，除非对数据一致性要求很高）。
2、redis 主从复制内容总结：
1）什么是持久化。
2）RDB ：save, bgsave, 配置。
3）AOF ：持久化写策略。重写。
上一节关联链接请点击：
# Redis 入门到精通（九）-- 主从复制（2）
原文地址：https://blog.csdn.net/qfyh_djh/article/details/140591940
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！