主从复制详解
大约 2 分钟
主从复制详解
主从复制如何执行
replicaof 192.168.0.1 6379主动复制原理
RDB + buffer
slave send psync
master send FULLRESYNC{runID,offset}
master bgsave create RDB && create buffer
master send RDB
slave clear data & load RDB
master send replication buffer (after RDB write operation)
slave load replication buffer调优思路
- 避免从服务器失联后全量复制 repl_backlog_buffer 缓冲区大小设置
频率
- Redis 主节点默认每隔 10 秒对从节点发送 ping 命令判断从节点存活
- 从节点每隔 1 秒发送 replconf ack{offset} 命令给主节点上报自身当前的复制偏移量
从服务器不会自己做（过期删除或内存淘汰），主服务器内存淘汰后会生成del命令发给从服务器
关键术语
- replication buffer
- repl_backlog_buffer
- 全量复制
- 增量复制
- 基于长连接的命令传播
repl_backlog_buffer
从库断开之后，如何找到主从差异数据而设计的环形缓冲区
如果缓冲区被主库的写命令覆盖了，从库会重新进行全量复制
repl_backlog_buffer配置尽量大一些，可以降低主从断开后全量复制的概率replication buffer
主从库增量复制用的buffer存储写命令用的网络断开，从库再次连接，是全量还是增量
1. 从库的slave_repl_offset会通过psync命令发送给主库，主库根据复制进度决定
2. 主库repl_backlog_buffer的slave_repl_offset位置上的数据已经被覆盖掉，会全量复制强烈建议主服务器开启持久化，也应该禁止自动重启
如果未开启持久化，且支持自动重启，在很短时间内主节点重启且空了数据集，Redis Sentinel甚至没检测到主节点的失败未切换主节点，从库的所有数据也会被清空为什么主从复制使用RDB而不是用AOF
AOF重放命令耗时
RDB数据重载快
RDB压缩的二进制数据所以文件小、主从网络带宽占据小
AOF选择刷盘策略，选择不当容易影响Redis性能命令repl-diskless-sync开启无磁盘复制模式
RDB不存储磁盘而是直接发送主库生成 RDB 文件和传输 RDB 文件压力大，所以有从库的从库的设计
主从复制的命令传播异步，延迟与数据的不一致不可避免
1. 加配置扩展写和读负载
2. 监控主从节点延迟（通过offset）判断，如果从节点延迟过大，通知应用不再通过该从节点读取数据