Redis优化基础[004]生产环境当中主从复制的常见问题

数据库主从配置

从数据库配置

1. slaveof
   slave实例需要配置该项, 指向master的(IP, PORT)
2. masterauth
   如果master实例启用了密码保护, 则该配置项需要填写密码;
   若master实例为已用密码, 该配置项要注释掉;
3. slave-serve-stale-data
   指定slave与master连接中断时的动作;
   默认yes:
   表示slave会继续应答来自client的请求, 但这些数据可能已经过期(连接中断等原因);
   若配置为no:
   则slave除正常应答"info"和"slaveof"命令外;
   其余来自客户端的请求命令均会得到"SYNC with master in progress"的应答;
   知道该slave与master的链接重建成功或该slave被提成为master;
4. slave-read-only
   指定slave是否只读 yes no
5. repl-disable-tcp-nodelay
   指定向slave同步数据时, 是否禁用socket的NO_DELAY选项.
   若配置为yes:
   则禁用NO_DELAY, 则TCP协议栈会合并小包统一发送;
   这样可以减少主从节点间的包数量并节省带宽, 但会增加数据同步到slave的时间;
   若配置为no:
   表名启用NO_DELAY, 则TCP协议栈不会延迟小包发送时机;
   这样数据同步延时会减少, 但需要更大的带宽;
   通常应该配置为no以降低同步延迟, 但主从间网络负载很高时可以配置为yes.
6. slave-priority
   指定slave的优先级. 在不只1个slave存在的部署环境下, 当master宕机时, Redis Sentinel会将priority值最小的slave提升为master.
   需要注意的是, 若该配置项为0, 则对应的slave永远不会被Redis Sentinel自动提升为master.

从节点故障问题
对于从节点的故障问题, 需要在客户端维护一个可用从节点列表, 当从节点故障时, 立刻切换到其他从节点或主节点, redis Cluser可以解决这个问题.

主从配置不一致
maxmemory不一致, 从节点4GB主节点8GB, 当从节点变成主节点的时候, 就会发现数据已经丢失, 而且无法挽回.

解决主节点重启后runid不一致, 导致的全量复制问题
Redis提供了, debug reload的重启方式: 重启后, 主节点的runid和offset都不受影响, 避免全量复制.

复制缓冲区不足
配置缓冲区, relbacklogsize

复制风暴
当一个主节点下挂载了很多个slave的时候, master挂了, 重启后, 因为runid发生变化, 所有的slave都要做一次全量复制, 这将引起单节点和单机器的复制风暴.
解决:
可以采用树状结构降低多个节点对主几点的消耗
解决:
应该把主节点尽量分散在多台机器上, 避免在单台机器上部署过多的主节点.

只有N个从节点连接的时候才允许写入
Redis2.8以后, 可以设置主节点只有N台从节点连接的时候可以写入请求.
然而, 因为Redis使用的是异步复制, 所以没有办法保证从节点确实收到的给定的写入请求;
所以存在一个窗口期的数据都是的可能性.
这是一个比较极端的做法
主机配置两个参数
min-slaves-to-write # 大约n台slave才能写入
min-slaves-max-lag