Redis的主从复制+哨兵模式的详细配置+讲解

Redis的主从复制+哨兵模式

为什么要使用主从复制？为了解决单机版的Redis挂掉的问题，和读并发量大的问题。
所谓的主从复制，就是一个作为主机的Redis有两个从机跟随，这两个从机只能执行读的操作。

详细配置

1.配从不配主。只对两个从机进行配置。看一下自己的 Redis安装目录。

这里root/myredis目录下的dump.rad文件是为了保持持久化的文件，每次redis启动会读取里面的内容保持和上次关闭的内容一致，/usr/local/redis/bin目录下的
redis-check-aof是检测aof（也是持久化的，这里默认的是没有开启）文件，redis-check-rdb是检测刚才的rdb文件，redis-sentinel是哨兵模式的启动，redis-cli是启动redis的文件，redis-server是链接redis文件。

2.启动Redis。

3.看完这些目录后需要对配置文件redis.conf复制，每一个从机也需要各自的.conf文件，因为redis默认的端口号是6379，那么我们把6379当做是主机，做两个从机的端口是6380和6381。复制后编辑里面的内容。

4.编辑.conf内容，执行:set nu,显示行号，把92行的端口号，（如果136行的守护进程没有开启要记得开启），158行的pid，253行的rdb文件改成自己从机的端口号，例如下面的6380，6381从机也是如此。esc+:+wq保存并退出。



5.在主机启动另外两个从机。
启动6380.

启动6381.

6.配置从机，两个端口都要这么配置，这给出了6381的，6380也一样。

7.查看信息，Info replication可以查看信息。

可见，6379是身份是master主机，6380和6381是从机slave，这样我们就配置好了。

问题来了：

1切入点问题? slave1、slave2是从头开始复制还是从切入开始复制?比如从k4进来,那之前的123是否也可以复制？

答：是从开始进行复制。之前的123也是可以复制的。因为Slave启动成功连接到master后会发送一个sync命令
Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整 个数据文件到slave,以完成一次完全同步
全量复制:而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制: Master继续将新的所有收集到的修改命令依次传给slave,完成同步
但是只要是重新连接master,一次完全同步(全量复制)将被自动执行

2从机是否可以写? set可否?

答：从机是不可写的，只能读。

3主机shutdown后情况如何?从机是上位还是原地待命

答：主机shutdown后，从机会原地待命，等待主机上线。

4主机又回来了后，主机新增记录,从机还能否顺利复制?

答：可以顺利复制。

5其中一台从机down后情况如何?依照原有它能跟上大部队吗?

答：会跟上以前的部队。

SLAVEOF no one可以使从机变成主机，执行了这个命令的从机，使当前数据库停止与其他数据库的同步，会脱离以前的部队，这一般是解决主机挂掉的情况，但是有没有自动监控主机挂掉的呢，这个就涉及到哨兵模式。

哨兵模式

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

详细步骤：

1.在/root/myredis这个目录下创建配置文件（目录里面有什么文件上面已经给出根据自己的情况决定写在哪个目录），注意文件名字不要错。

2.编辑文件内容为：
sentinel monitor 被监控主机名字(自己起名字) 127.0.0.1 6379 1 例如： sentinel monitor host6379 127.0.0.1 6379 1

  上面最后一个数字1，表示主机挂掉后salve互相投票看让谁接替成为主机，得票数为1的成为主机

3.启动哨兵。

执行流程图：

一台主机可以配置多个哨兵进行监视，配置哨兵的方法和以上相同，在复制一份sentinel.conf文件在按照步骤进行配置即可。

问题来了

当主机挂掉时候，从机会进行投票选出主机，那么，当主机回来的时候，该主机是否会变成主机？

答案是不会，这就好比是你的领导走了，你被晋升为领导，但如果你的领导又想回来工作，你会把他安排成领导吗？可想而知，不会！经过验证如下：

总结：

虽然做到了读写分离，但是还是有一定的问题，由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。我们放弃了主从复制，采用了集群的方式来解决。

本文地址：https://blog.csdn.net/CTRLKK/article/details/107310436