详解Redis主从复制（自动同步到备机的master/slaver机制）

[全站通告] 想快速节省您的时间并可接受付费的朋友，可扫右边二维码加博主微信-非诚勿扰！

概念：

主从复制就是主机数据更新后，根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主。

配置：

（1）“一主二仆”策略

准备三台redis服务器：主服务器A，从服务器B1、从服务器B2。服务器B1、B2同步A数据，A1负责写操作，B1、B2负责读操作。

A服务器IP：168.7.5.74，端口6379

B1服务器IP：168.7.5.75，端口6379

B2服务器IP：168.7.5.76，端口6379

• 使用命令

　　在服务器B1、B2上分别执行如下命令，成为A服务器的从库：

slaveof 168.7.5.74 6379

　　使用命令可查看当前库role、master_host、manter_port、connected_slaves相关配置信息：

　info replication

　　注意：

a、当主库宕机后，从库仍是slave角色，仍负责接受读操作；

b、当主库恢复服务后，从库B1、B2继续同步主库A的数据，服务照旧；

c、当从库与master断开连接后，如果使用的是命令配置，需要重新使用命令才能连接到主库；

d、当从库连接master后，master会先一次性将当前数据全量同步到salve上，后续增量同步。

从库复制原理：

Slave 启动成功后连接到 master 后，将发送一条sync命令，master接收到命令后，在后台启动存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后，master将传送整个数据文件到slave，以完成一次全量同步。只要重新连接master，将自动执行一次全量复制（完全同步）。

• 使用配置文件

　　  在需要成为从库的redis配置文件中添加配置"replicaof 10.7.5.74 6379"即可。与命令配置不同的是，从库重启服务后将自动同步主库，无需额外操作。

（2）“薪火相传”策略

　　准备三台redis服务器：服务器A，服务器B、服务器C。将服务器B设置为服务器A的从库，将服务器C设置为服务器B的从库：masterA <-- slaverB <-- slaverC。

A服务器IP：168.7.5.74，端口6379

B服务器IP：168.7.5.75，端口6379

C服务器IP：168.7.5.76，端口6379

执行如下命令进行该策略配置：

在服务器B上执行：slaveof 168.7.5.74 6379

在服务器C上执行：slaveof 168.7.5.75 6379

　　注意：

　　　　a、服务器A的角色为 master，服务器B和C的角色为 slaver；

b、当主库A宕机后，在从库B上执行命令 slaverof no one 将从库B角色变为 salve ，从库C无需操作，将继续使用同步B；

c、当A重启服务器后，与BC库组成的体系毫无关系，需重新执行命令加入；

d、salverof no one ：是当前数据库停止与其他数据库的同步，并转换为主数据库。

优点：去除“一主二仆”策略的中心化，减轻master库写的压力。

缺点：从库存在备份延迟

（3）哨兵模式

　　原理：在后台自动监控主机是否故障，如果故障了，根据投票自动将从库转为主库。

　　 配置：

　　 a、创建哨兵模式配置文件。在redis.conf目录下创建文件 sentinel.conf (名称固定)，内容如下：

sentinel monitor hostname 127.0.0.1 6379 1  

hostname 127.0.0.1 6379 ：分别是被监控主机的主机名、IP及端口号

1指定策略：主机宕机后，slave投票决定谁接替主机

b、启动哨兵模式

　　　　 redis-sentinel /usr/redis/sentinel.conf

　　注意：

　　　　a、若当前master宕机后，服务将在从库中选出新的master；

b、若旧master重启后，它将自动成为新的master的slave；

c、一个哨兵(sentinel)可以监控多个master。

应用：

读写分离、容灾备份

主从复制的缺点：

复制的延迟，写操作都在master上，然后同步到slave上，所以会有一定的延迟，同时slave机器数量的增加也会使延迟问题更加严重。

问题未解决？付费解决问题加Q或微信 2589053300 (即Q号又微信号)右上方扫一扫可加博主微信

所写所说，是心之所感，思之所悟，行之所得；文当无敷衍，落笔求简洁。 以所舍，求所获；有所依，方所成！