Linux中部署Redis主从复制，主从复制原理

在上一篇文章中谈了单机的 Redis 部署，你觉得单机部署的架构有什么问题吗？主从复制能够解决全部问题吗？

前文：Linux 安装 Redis 单机，详细图解

后文：Linux安装Redis（三）哨兵模式，分析流程和原理，详细图解

但我们还是回到本文的内容吧

本文谈到的内容主要是以下几点：

1. 如何部署Redis主从复制（一主二从）
2. 一些关于主从的问题模拟和思考
3. 主从复制原理和工作流程

前文

所谓主从复制，就是以其中一台机器作为 master，并且以写为主，其他从服务器（Slave）则是以读为主，达到读写分离的效果，以来提高系统性能。从服务器的数据全部从主服务中复制同步而来。

当 master 数据变化的时候，自动将新的数据异步同步到其他Slave数据库

redis 官方文档：redis.io

主从复制它解决了什么问题？

其实这很好说吗，读写分离、容灾备份、数据备份、水平扩容支撑高并发等等，其实也蛮多的，但是也有一些不足之处，后面就知道啦

一、相关命令

其实主从分离是真的很简单，就改几个配置项就完事啦，和单机的没啥区别

也就这一句话，配置从库，不配置主库，从库变更一下配置文件，或者是输入几行命令就可以，主库则不需要动，和单机一样。

关于权限：

1. 如果主库设置了密码，则从机需要验证密码
2. master 如果配置了 requirepass 参数，需要密码登陆
3. 那么slave就要配置masterauth 来设置校验密码，否则的话，master会拒绝slave的访问请求

基本操作命令

1. info replication : 可以查看复制节点的主从关系和配置信息
2. replicaof 主库IP 主库端口 ：一般写入redis.conf配置文件内
3. slaveof 主库IP 主库端口：每次与 master 断开之后，都需要重新连接，除非你配置进redis.conf 文件。
4. 在运行期间修改slave节点的信息，如果该数据库已经是某个主数据库的从数据库，那么会停止和原主数据的同步关系转而和新的主数据库库同步，重新建立联系。
5. slaveof no one：使当前数据库停止与其他数据库的同步，转为主数据库.

二、部署架构

我有三台虚拟机，分别是

192.168.208.128

192.168.208.129

192.168.208.130

准备部署的架构图为：

三、开始部署

1、前期准备：

三台虚拟机上都已经安装完Redis服务，这点不会可以去考古-->

三台虚拟机能够相互ping通，且开放相关的 redis 服务使用的端口或者是关闭防火墙。

关闭防火墙：

systemctl stop firewalld #三台都要关 或者开发相关的端口

配置主从复制，我们只需要修改从库的配置，不需要修改主机的配置。

replicaof 主库IP 主库端口 ：一般写入redis.conf配置文件内
slaveof 主库IP 主库端口：每次与 master 断开之后，都需要重新连接，除非你配置进redis.conf 文件。
在运行期间修改slave节点的信息，如果该数据库已经是某个主数据库的从数据库，那么会停止和原主数据的同步关系转而和新的主数据库库同步，重新建立联系。
slaveof no one：使当前数据库停止与其他数据库的同步，转为主数据库，自立为王。

2、修改配置文件：

我们重新cp 一份未动过的配置文件，一步一步来看，到底那些要进行配置

补充：从机就比主机多了第十步的一个操作，其余均相同，其他更详细的配置还是需要大家在生产环境中配置，例如aof的开启和关闭，同步时间是多长等等

大致步骤：

1、修改 daemonize 为yes

2、注释掉 bind 127.0.0.1

3、修改 protected-mode 为 no

4、指定 port 端口

其实很多时候在线的 redis 服务并不会开放默认的端口，而是会换成其他不常用的端口，来求得一定的安全性

5、指定工作目录

6、指定 pidfile 文件的名称

可改可不改，知道存在，万一要看了，知道在哪里可以看到

7、指定 logfile 文件名称

我这里指定的是我的地址哈~

8、指定 dump.rdb 文件名称（dbfilename）

9、requirepass 设置密码

主机配到这里就可以啦，下面的这个是从机才需要配置的。

10、配置访问主机的密码 masterauth 、 masterip、masterport

修改完后就是如下：

第二台从机也是一样的配置。

四、启动测试

先启动master，再陆续启动两台slave.

确定主机和从机都起来之后。

我们在主机上set 一个值，我们看有没有复制过去

另外也可以看一下从机的log日志，这边的主机我忘记配了，就没啦~ 感兴趣的话，自己去看一下主机的日志

查看服务器状态：

五、思考问题

你觉得上述这样的架构还存有一些什么问题吗？

1、当主机宕机之后，从机会自动变成主机吗？

• 答案是不会，这里木有人来操作啊~

2、从机宕机之后，再启动是从机还是主机？

• 如果是写入配置的方式，从机宕机后重启还是从机，如果是使用命令的方式，来建立主从服务的话，重启后则是主机。

3、主机宕机之后，从机可不可以成为另一台机器的从机？

• 可以，但需要人工干预，来输入相关命令，让该从机成为其他机器的从机。

4、主机宕机之后，我们可以让剩下的其中一台成为主机吗？

• 可以，但需要人工干预，在客户端执行slave no one命令

六、薪火相传

如下图部署方式：

是什么意思呢？

就是当主机宕机的时候，192.168.208.129这台从机，在人工干预的情况下可以立马升级为主机，它下面跟随着两台从机，也可以继续提供读服务，而无需重新改向新的主机。

如果是按照之前的方式部署，如果主机宕机了，那么两台从机都只能提供读服务，需要人工干预将其中一台从机升级为主机，再手动将另外一台的从机改从向新的主机进行复制。（注意：如果要改变跟随的主机，是需要将slave的数据全部清除掉，然后再从新跟随的主机，重新开始复制，数据量比较大的情况，需要一定的时间）

配置是一样的，就是一台跟着一台，只是把跟随的主机变更了。

七、反客为主

我们之前就谈到了，如果主机宕机了，我们是可以手动让从机变更为主服务的，发送slave no one即可。

八、主从复制原理和工作流程

借鉴的一张图： 来源 Redis主从复制原理

1. slave 第一次启动成功连接到 master 后会发送一个 sync 命令，首次全新连接 master，会自动进行一次完全同步（全量复制），slave自身原有数据会被 master 数据覆盖清除。
   
2. master 节点收到 sync 命令后会开始在后台保存快照（即RDB持久化，主从复制时会触发RDB）同时收集所有接收到的用于修改数据集命令缓存起来，master 节点执行RDB持久化完后，master将rdb快照文件和所有缓存的命令发送到所有slave，以完成一次完全同步。
   
3. 而slave服务在接收到数据库文件数据之后，将其存盘并加载到内存中，从而完成复制初始化。
   
4. 在正常运行的过程中，主从双方要保持通信，主机会向从机发送心跳检测，心跳检测的默认时间为10秒，repl-ping-replica-period 10
   
5. 增量复制，除去第一次连接是全量复制以外，之后 master 继续将新的所有收集到的修改命令自动依次传给slave，完成同步。
   
6. 从机下线，重连续传；
   master会检查backlog里面的offset，master和slave都会保存一个复制的offset还有一个masterId,
   offset是保存在backlog中的。master只会把已经复制的offset后面的数据复制给slave，类似断点续传。
   

缺点

1、复制具有延时性，并且因为所有的写操作都是现在Master 上操作，然后同步更新到 Slave 上，所以从 Master 同步到 Slave 机器上有一定的延迟，当系统很繁忙的时候，延迟问题会更严重，另外就是当 Slave 机器数量变多，复制次数变多也会使这个问题更加严重。

2、当 master 挂了的时候，并不会在 slave 节点中自动选举一个节点成为Master节点，从而导致redis服务只能读而不能写。

同时也意味着出现事故的时候，必须要有人工干预。

后文

如果仔细想想，主从复制的架构其实还是有很多问题的，比如不能够自动的进行故障转移，必须要人工干预，又或者是复制的延迟性等。

但不得不说，部署是极为简单的，机器资源要求也不高，在很多时候还是非常实用的，比如做容灾备份，数据备份等。

对啦，想不如做，看也不如做，感兴趣的话，我还是建议可以抽空试一试~