频繁的全量复制(1)
伴随着系统的运行，master的数据量会越来越大，一旦master重启，runid将发生变化，会导致全部slave的 全量复制操作
内部优化调整方案:
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命令可以查看该信息
作用:
本机保存上次runid，重启后恢复该值，使所有slave认为还是之前的master
频繁的全量复制(2)
问题现象
- 网络环境不佳，出现网络中断，slave不提供服务
问题原因
- 复制缓冲区过小，断网后slave的offset越界，触发全量复制
最终结果
- slave反复进行全量复制
解决方案
- 修改复制缓冲区大小
repl-backlog-size
建议设置如下:
1. 测算从master到slave的重连平均时长second
2. 获取master平均每秒产生写命令数据总量write_size_per_second
3. 最优复制缓冲区空间 = 2 * second * write_size_per_second
频繁的网络中断(1)
问题现象
- master的CPU占用过高 或 slave频繁断开连接
问题原因
- slave每1秒发送REPLCONF ACK命令到master
- 当slave接到了慢查询时(keys * ，hgetall等)，会大量占用CPU性能
- master每1秒调用复制定时函数replicationCron()，比对slave发现长时间没有进行响应
最终结果
- master各种资源(输出缓冲区、带宽、连接等)被严重占用
解决方案
- 通过设置合理的超时时间，确认是否释放slave
repl-timeout
该参数定义了超时时间的阈值(默认60秒)，超过该值，释放slave
频繁的网络中断(2)
问题现象
- slave与master连接断开
问题原因
- master发送ping指令频度较低
- master设定超时时间较短
- ping指令在网络中存在丢包
解决方案
- 提高ping指令发送的频度
repl-ping-slave-period
超时时间repl-time的时间至少是ping指令频度的5到10倍，否则slave很容易判定超时
数据不一致
问题现象
- 多个slave获取相同数据不同步
问题原因
- 网络信息不同步，数据发送有延迟
解决方案
- 优化主从间的网络环境，通常放置在同一个机房部署，如使用阿里云等云服务器时要注意此现象
- 监控主从节点延迟(通过offset)判断，如果slave延迟过大，暂时屏蔽程序对该slave的数据访问
slave-serve-stale-data yes|no
开启后仅响应info、slaveof等少数命令(慎用，除非对数据一致性要求很高)