9.redis主从复制

什么是主从复制

主库数据更新后根据配置和策略，自动同步到从库（备份机）的master/slaver机制，master（主库）以写为主，slave（从库）以读为主。

主从复制作用

• 读写分离：master以写为主，slave以读为主。
• 容灾恢复：由于slaves的数据是master的副本，无论master还是slaves宕机了都能让数据得到有效的恢复。

环境准备

1. 拷贝三个redis.conf配置文件，并分别重命名为redis6379.conf，redis6380.conf和redis6381.conf
2. 三个配置文件都配置 daemonize yes
3. 端口分别配置为port 6379，port 6380和port 6381
4. pid文件路径分别配置为pidfile /var/run/redis_6379.pid，pidfile /var/run/redis_6380.pid和pidfile /var/run/redis_6381.pid
5. log名称分别配置为logfile "6379.log"，logfile "6380.log"和logfile "6381.log"
6. db文件名称分别配置为dbfilename dump6379.rdb，dbfilename dump6380.rdb和dbfilename dump6381.rdb

当然以上配置都非必须的，只是为了在同一台虚拟机上演示更好的区分开来

分别使用redis6379.conf，redis6380.conf和redis6381.conf配置文件来启动三个不同的redis服务，并通过ps -ef|grep redis命令来查看服务状态。 使用三个命令行窗口分别连接redis服务。 以79端口的redis服务为例，输入命令 info replication查看主从复制信息。

# Replication
#master表示为主库，slave表示为从库
role:master
#连接该主库的从库数量
connected_slaves:0
master_replid:07e5ec5474ccf8c60e1471309b47e2592f38aeb1
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

主从复制模式

1. 一主二从：一台主库（master），两台或多台从库（slaves）

假设以79端口服务为主库，其他为从库。 79服务分别造几条数据，如下： 命令slaveof <host> <port>表示以host地址的port端口的redis服务为主库，自己为从库。假设80和81都以79为主库，如下：

80和81分别以79为主库后，主库79的数据被复制到了从库，又由于主库79先新增数据，80和81后以79为主库，由此可见从库和主库刚连接时为全量复制（后续主库有新增数据，从库为增量复制）。

以从库80为例，输入info replication查看从库主从复制信息。感兴趣的同学可以通过此命令尝试查看主库此时的主从复制信息。

# Replication
#当前状态为从库
role:slave
#主库ip地址
master_host:127.0.0.1
#主库端口
master_port:6379
#与主库的连通状态，up表示连通，down不连通
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:882
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:02c33749f6cd663e01bf7442a4a80e03d25a0cda
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:882
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:393
repl_backlog_histlen:490

主库可以写，从库只能读，即：主写从读，读写分离

假如通过shutdown命令演示主库79宕机了，问题：从库80和81是原地待命等待与主库重新连接还是从库咸鱼翻身由从变主？ 主库重新连接后。

结论：主库宕机后，从库原地待命等待与主库重新连接，只是从库与主库的连通状态由up变为down。

以从库80为例，从库宕机后，重新连接后，问题：从库80仍然是以79为主库的从库，还是与主库79断开主从关系，自己变为主库？

结论：从库宕机后重新连接，与原有主库断开主从关系，但保存有原来主库的数据。

注：slaveof命令确定的主从关系只是临时的，从库重新启动就断开了，若要永久配置主从关系需要写进配置文件。

假设80为master时，80以79为主库后，从库80原有的数据与主库79合并还是79主库的数据完全覆盖从库80数据？

答案：从库的数据被主库完全覆盖，同学们可以自己尝试尝试。

2. 薪火相传 80作为79的slave，并拥有79的数据副本，同时80也是81的master，81拥有80的数据副本（也是79的副本），数据从79传输到80，又由80传输到81，脉脉相传。80即作为master，同时也是slave。 80的master是79，81的master是80，此时80既是master也是slave，使用info replication命令重点查看80的信息如下： 由于role只能显示master或者slave，所以80是master&slave也只是理论上的一说，此时80执行set等修改命令仍然执行报错。

按照如图数字所示的顺序执行命令，可知数据由79同步到了80，再由80同步到了81。 当主库宕机，或者从库宕机之后几种情况理论分析和一主二从情况相同，此处不再赘述。

3. 反客为主

由一主二从可知，当master宕机之后，slaves原地待命等待master恢复，但不可一日无主。反客为主即为当master宕机后，从众多的从库中选择一个作为master，其他从库以其为新的master。

slaveof no one：使当前数据库与其他数据库的附属关系，使其成为主数据库。

在一主二从的基础上，当79宕机后，slaveof no one使80断开与79的主从关系，slaveof 127.0.0.1 6380让81的新master为80。

重新连接79后，查看79和80的主从复制信息，如下：

由此可知，即使79重新连接后，但江山早已易主。

4. 哨兵模式（sentinel）

反客为主的自动版，由反客为主可知，当主库宕机之后，需要手动重新选择新的master，并且重新修改slave的主库指向。哨兵模式即能够在后台监控主库如果出现故障，则根据投票自动从从库中选择新的主库，并且其他从库以新的主库为master。

和反客为主不同之处在于当旧的master重新连接后，旧的master也会成为新的master的slave。

sentinel monitor 被监控数据库名称（自定义） 被监控数据库ip地址 被监控数据库端口号 票数，表示当被监控的数据库出现故障后，自动从从库中投票，从库达到指定票数后则变成其他从库的新主库。

新建sentinel.conf文件。 编辑sentinel.conf文件，写入sentinel monitor host6479 127.0.0.1 6379 1。

分别启动79，80和81数据库，79分别为80和81的主库（一主二从）

新的窗口用redis-sentinel /myredis/sentinel.conf 以sentinel的方式启动redis监控服务。

由日志可知79的从库分别是80和81。

用shutdown演示79宕机后，由日志可知，后台正通过投票从从库中选择新的主库。 通过投票后新的master为81。

当79重新连接服务后，江山易主，权利变更，79成为81的从库。

复制的原理

1. slave启动成功连接到master后会发送一个sync命令；

2. master接到命令启动后的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，以完成一次完全同步（全量复制）；

3. 全量复制：slave服务在接受到数据库文件数据后，将其存盘并加载到内存中；

4. 增量复制：master继续将新的所有收集到的修改命令依次传给slave，完成同步，但是只要是重新连接master，一次完全同步（全量复制）将被自动执行。

复制的缺点

由于所有的操作都是现在master上操作，然后同步更新到slaves上，所以从master同步到slaves机器有一定的延迟。当系统繁忙的时候延迟问题更加严重，slaves机器数量的增加也会是这个问题更严重。特别是薪火相传模式时，master同步到slaveA，slaveA同步完后再同步到slaveB，slaveB同步完后再同步到slaveC... ... 上一个slave同步完后下一个slave才能同步，更加延长了同步的时间。