《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 ,分析下日志

  - 

4451:X 20 Aug 05:17:27.444 # +monitor master mymaster 127.0.0.1 6380 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 // 发现一个备库

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

// 开始故障恢复 4451:X 20 Aug 05:18: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为节点数量,这样保证一半同意,才会生效。

 

posted @ 2018-08-20 15:31  Zzz哈  Views(124)  Comments(0Edit  收藏  举报