《Redis 主从复制》

万念俱灰，说的就是我现在的心情......

周六下午写了一下午的读书笔记，由于我的 MAC 有点问题，重启了一下......

灰飞烟灭......

读

　　第八章《集群》

总结

1：如何开启主从复制？

　　- Redis.conf 中配置 slaveof 主数据库地址 主数据库端口

　　- 启动一个 Redis 实例 redis-server --port 监听端口 --slaveof 主数据库地址 主数据库端口

2：如何查看主从数据库状态及其节点信息？

　　- INFO replication

3：设置主从后，从库可以写么？

　　- 不可以，如果在从库执行写操作的话，则会报错。

　　- 不过也可以通过修改配置 slave-read-only 使得从库可以执行写操作，不过这会使得主从数据库不一致。通常是禁止的(默认)

4：主从的原理是什么呢？是如何实现的呢？

　　- 当一个从数据库启动时，会向主库发送 PSYNC(Redis 2.8 之后) 命令。

　　- 当主库接到 PSYNC(Redis 2.8) 命令时，会[保存快照(RDB) + 缓存保存快照期间的命令]，当快照完成后，会把快照和缓存命令一块发给从库。

　　- 当从库接到后，会根据RDB快照和缓存命令，进行同步(也叫做复制初始化)。

5：为什么有时候主从数据不一致？

　　- 由于 Redis 采用了乐观复制，既乐观的认为主从数据最终是会同步的。

　　- 当客户端发起请求后，主数据库执行完成会立即返回结果。并将命令异步同步从数据库。

　　- 由于本身是异步，假如网络断开或者其他什么，就会导致主从数据不一致的情况发生。

6：如何解决主从数据不一致问题？

　　- Redis 在配置中提供了解决一致性的方案，合理的配置这两个选项可以降低(注意，不是解决)一致性的问题。

　　- min-slaves-to-write 3      是表示当有3个或者3个以上的从库更新了数据，主库才是可写的,如果不满足的话，会直接报错

　　- min-slaves-max-lag 10    是表示允许从库失去连接的最长时间，当从库超过这个时间时候，我们就认为这个从库已经[挂了]

7：主/从 数据库崩溃的处理办法？

　　- 当从库崩溃时，不会影响其他，当从库重启之后，主库会自动同步数据，所以也没有数据丢失问题。

　　- 主库崩溃后，情况会有一些复杂。

　　　　- 由于为了主库的性能最佳，通常会关闭 AOF/RDB 。

　　　　　　- 如果关闭，一定不要使用 Supervisor 等进程管理工具实现自动重启，因为当自动重启后，主库没有任何数据，当从库连接上之后，同步数据，从库数据也将清空

　　　　- 推荐使用 哨兵 机制来实现 主/从 的切换。

8：哨兵机制的简单实现？

　　- 这里我开了两个 redis-server 实例， 8680 端口作为 master，8681 端口作为 slave。

　　- 配置 哨兵 ，建立配置文件 sentinel.conf

　　　　- sentinel monitor 监控数据库名称 地址 端口 最低通过票数

　　　　- 例如： sentinel monitor mymaster 127.0.0.1 6379 1

　　- 启动监控：redis-sentinel /path/to/sentinel.conf

　　- 这时，我们杀死 master ，分析下日志

　　-

:X  Aug ::27.444 # +monitor master mymaster 127.0.0.1  quorum 1     // 主库
4451:X 20 Aug 05:18:13.972 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380  // 发现一个备库

// 杀死主库进程
:X  Aug ::12.835 # +sdown master mymaster 127.0.0.1 6380  // 主观认为数据库停止了服务
:X  Aug ::12.837 # +odown master mymaster 127.0.0.1  #quorum /1 // 客观认为数据库已停止运行
:X  Aug ::12.838 # +new-epoch 2

// 开始故障恢复
:X  Aug ::12.839 # +try-failover master mymaster 127.0.0.1 6380 // 选择 6380 端口为主库

// 之后就是 6380 为主库，具体的细节一会在详细说

 9：哨兵机制的实现原理？

　　- 当哨兵启动时，会和需要监控的主数据库建立两条连接。

　　　　- 一条是 订阅 __sentinel__::hello 频道，获取其他哨兵节点信息。

　　　　- 另一条需要定期发送 INFO 字段来获取，数据库本身信息。

　　- 当和主数据库建立完成之后，定期执行下列操作

　　　　- 10s/次 会向主数据库发送 INFO 命令

　　　　　　- 获取当前数据库相关信息(节点数量/节点信息/等等)

　　　　- 2s/次 会向主/从数据库的 __sentinel__::hello 频道发送自己的信息

　　　　- 1s/次 向主数据库和其他哨兵节点发送Ping命令

　　- 当主数据库出现问题时候

　　　　- 哨兵向主数据库发送 ping 命令，未回复，则该哨兵认为主数据库 主观下线

　　　　- 这时候会判断 quorum 参数

　　　　　　- 例如  sentinel monitor mymaster 127.0.0.1 6379 3

　　　　　　- 该配置表示，如果有三个哨兵认为主数据库主观下线

　　　　- 才会认为该主数据库 客观下线

　　- 当认为客观下线后，需要进行故障恢复。

　　　　- 这时，会推举领头哨兵进行故障恢复。

　　　　　　- 领头哨兵的选举流程为(Raft算法)

　　　　　　- 发现数据库主观下线的哨兵，向其他人发送命令，要求选自己为 领头哨兵

　　　　　　- 超过半数同意，则该哨兵成为领头哨兵进行故障恢复

10：什么样子的哨兵部署方案比较好？

　　- 建议为每个节点部署(主/从)哨兵。

　　- 保证环境一致。

　　- 设置 quorum 为  N/2 + 1 ,N为节点数量，这样保证一半同意，才会生效。