Redis主从配置

通过 info replication 命令可以看到复制的一些参数信息

从数据库配置

	1) slaveof  < masterip >  < masterport >
		slave实例需要配置该项， 指向master的（  ip, port ） 。
	2) masterauth 
		如果master实例启用了密码保护， 则该配置项需填master的启动密码； 若master未启用密码， 该配置项需要注释掉
	3) slave-serve-stale-data
		指定 slave 与 master 连接中断时的动作。 
		默认为yes， 表明slave会继续应答来自client的请求， 但这些数据可能已经过期（因为连接中断导致无法从 master同步） 。
		若配置为no， 则slave除正常应答"INFO"和"SLAVEOF"命令外， 其余来自客户端的请求命令均会得到" SYNC with master in progress "的应答， 
		直到该 slave 与master 的连接重建成功或该 slave 被提升为 master 。

	4) slave-read-only
		指定slave是否只读， 默认为yes。 
		若配置为no， 这表示slave是可写的， 但写的内容在主从同步完成后会被删掉。
	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 。

主从复制常见问题

读写分离

读写分离，主要是因为要建立一主多从的架构， 才能横向任意扩展 slave node 去支撑更大的读吞吐量。

读写分离产生的问题

• 复制数据延迟
  可以通过 info replication 的 offset 指标进行排查。
  对于无法容忍大量延迟场景， 可以编写外部监控程序监听主从节点的复制偏移量，当延迟较大时触发报警或者通知客户端避免读取延迟过高的从节点。
  同时从节点的 slave-serve-stale-data 参数也与此有关。
• 异步复制导致数据丢失
  因为master->slave的复制是异步， 所以可能有部分还没来得及复制到slave就宕机了， 此时这些部分数据就丢失了。
  这个问题只能降低到可控范围,没办法做到100%不丢失。
  比如下面的配置：
  要求至少有1个slave， 数据复制和同步的延迟不能超过10秒
  如果说一旦所有的slave， 数据复制和同步的延迟都超过了10秒钟， 那么这个时候， master就不会再接收任何请求了。
  有了min-slaves-max-lag这个配置， 就可以确保说， 一旦slave复制数据和ack延时太长， 就认为可能master宕机后损失的数据太多了， 那么就拒绝写请求， 这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低到可控范围内。

	#最少有多少台从机器才能写入
	min-slaves-to-write 1
	#从节点最大延迟时间,延迟小于min-slaves-max-lag秒的slave才认为是健康的slave
	min-slaves-max-lag 10

从节点故障问题

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

配置不一致导致的问题

例如 maxmemory 不一致， 如果主机配置 maxmemory 为8G， 从机 slave 设置为4G， 这个时候是可以用的， 而且还不会报错。
但是如果要做高可用， 让从节点变成主节点的时候， 就会发现数据已经丢失了， 而且无法挽回。

如何规避全量复制

全量复制指的是当 slave 从机断掉并重启后， runid 产生变化而导致需要在 master 主机里拷贝全部数据。
这种拷贝全部数据的过程非常耗资源。
全量复制是不可避免的， 例如第一次的全量复制是不可避免的， 这时我们需要选择小主节点， 且 maxmemory 值不要过大， 这样就会比较快。
同时选择在低峰值的时候做全量复制。

造成全量复制的原因

1. 是主从机的运行 runid 不匹配。 解释一下， 主节点如果重启， runid 将会发生变化。 如果从节点监控到 runid 不是同一个， 它就会认为你的节点不安全。
   当发生故障转移的时候， 如果主节点发生故障， 那么从机就会变成主节点。
2. 复制缓冲区空间不足， 比如默认值1M， 可以部分复制。 但如果缓存区不够大的话， 首先需要网络中断， 部分复制就无法满足。 其次需要增大复制缓冲区配置（relbacklogsize） ， 对网络的缓冲增强。

主节点重启怎么避免全量辅助

在一些场景下， 可能希望对主节点进行重启， 例如主节点内存碎片率过高， 或者希望调整一些只能在启动时调整的参数。
如果使用普通的手段重启主节点， 会使得runid发生变化， 可能导致不必要的全量复制。
为了解决这个问题， Redis提供了debug reload的重启方式： 重启后， 主节点的runid和offset都不受影响， 避免了全量复制。

单机器的复制风暴

当一个主机下面挂了很多个 slave 从机的时候，
主机 master 挂了， 这时 master 主机重启后， 因为runid 发生了变化， 所有的 slave 从机都要做一次全量复制。
这将引起单节点和单机器的复制风暴， 开销会非常大。

树状结构解决：
可以采用树状结构降低多个从节点对主节点的消耗
从节点采用树状树非常有用， 网络开销交给位于中间层的从节点， 而不必消耗顶层的主节点。
但是这种树状结构也带来了运维的复杂性， 增加了手动和自动处理故障转移的难度

主从服务在机器上的分布问题

由于 Redis 的单线程架构， 通常单台机器会部署多个 Redis 实例。
当一台机器（machine） 上同时部署多个主节点 （master） 时，
如果每个 master 主机只有一台 slave 从机， 那么当机器宕机以后， 会产生大量全量复制。
这种情况是非常危险的情况， 带宽马上会被占用， 会导致不可用。
解决：
1、 应该把主节点尽量分散在多台机器上， 避免在单台机器上部署过多的主节点。
2、 当主节点所在机器故障后提供故障转移机制， 避免机器恢复后进行密集的全量复制

主从配置文件

从库

###########从库##############
#设置该数据库为其他数据库的从数据库
slaveof  
#主从复制中， 设置连接master服务器的密码（前提master启用了认证）
masterauth 
slave-serve-stale-data yes
# 当从库同主库失去连接或者复制正在进行， 从库有两种运行方式：
# 1) 如果slave-serve-stale-data设置为yes(默认设置)， 从库会继续相应客户端的请求
# 2) 如果slave-serve-stale-data设置为no， 除了INFO和SLAVOF命令之外的任何请求都会返回一个错误"SYNC with master in progress"
#当主库发生宕机时候， 哨兵会选择优先级最高的一个称为主库， 从库优先级配置默认100， 数值越小优先级越高
slave-priority 100
#从节点是否只读； 默认yes只读， 为了保持数据一致性， 应保持默认
slave-read-only yes

主库

########主库配置##############
#在slave和master同步后（发送psync/sync） ， 后续的同步是否设置成TCP_NODELAY假如设置成yes， 则redis会合并小的TCP包从而节省带宽， 但会增加同步延迟（40ms） ， 造成master与slave数据不一致假如设置成no， 则redis master会立即发送同步数据， 没有延迟
#前者关注性能， 后者关注一致性
repl-disable-tcp-nodelay no
#从库会按照一个时间间隔向主库发送PING命令来判断主服务器是否在线， 默认是10秒
repl-ping-slave-period 10
#复制积压缓冲区大小设置
repl-backlog-size 1mb
#master没有slave一段时间会释放复制缓冲区的内存， repl-backlog-ttl用来设置该时间长度。 单位为秒。
repl-backlog-ttl 3600
#redis提供了可以让master停止写入的方式， 如果配置了min-slaves-to-write， 健康的slave的个数小于N， mater就禁止写入。 
# master最少得有多少个健康的slave存活才能执行写命令。 
# 这个配置虽然不能保证N个slave都一定能接收到master的写操作， 但是能避免没有足够健康的slave的时候， master不能写入来避免数据丢失。 
# 设置为0是关闭该功能。
min-slaves-to-write 3
min-slaves-max-lag 10