Redis主从复制以及哨兵模式

 

主从复制

  官网:https://redis.io/topics/replication

 是什么:

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

  目的：读写分离,容灾恢复

 怎么做：

•  拷贝多个redis.conf文件                     //cp redis.conf redis6379.conf
•  开启daemonize yes
•  Pid文件名字
•  指定端口
•  Log文件名字
•  Dump.rdb名字

[root@C2_SW_5748F_1 copy]# cp redis.conf redis6379.conf
[root@C2_SW_5748F_1 copy]# ls
appendonly.aof  redis6379.conf   redis-cli   redis-server
dump.rdb        redis-check-aof  redis.conf
[root@C2_SW_5748F_1 copy]# cp redis.conf redis6380.conf
[root@C2_SW_5748F_1 copy]# cp redis.conf redis6381.conf
[root@C2_SW_5748F_1 copy]# ls
appendonly.aof  dump.rdb  redis6379.conf  redis6380.conf  redis6381.conf  redis-check-aof  redis-cli  redis.conf  redis-server

   vim编译时：快捷键使用"/"输入对应的关键字，按n寻找下一个出现的位置，:wq保存并退出

   需要把redis6379.conf、 redis6380.conf、redis6381.conf分别配置一下

   redis6380.conf如下：

//开启daemonize yes启动时为守护线程
# By default Redis does not run as a daemon. Use 'yes' if you need it.
# Note that Redis will write a pid file in /var/run/redis.pid when daemonized.
daemonize yes


//指定端口号
# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
port 6380


//进程管道路径
# Creating a pid file is best effort: if Redis is not able to create it
# nothing bad happens, the server will start and run normally.
pidfile /var/run/redis6380.pid


//log文件名称
# Specify the log file name. Also the empty string can be used to force
# Redis to log on the standard output. Note that if you use standard
# output for logging but daemonize, logs will be sent to /dev/null
logfile "6380.log"


//dump.rdb名称
# The filename where to dump the DB
dbfilename dump6380.rdb

 把所有的文件配置一下，非常详细关于redis安装和redis配置文件可以看这些文章《Linux下Redis的安装》《Redis配置文件详解》

 这里模拟的是一台虚拟机上有多个redis，正常工作一定是把主服务器和辅服务器分开的，要不然这台虚拟机挂了，主服务器和辅服务器会一起挂，就凉凉了

 

 分别开启连接：redis6379.conf redis6380.conf  redis6381.conf

[root@C2_SW_5748F_1 copy]# redis-server redis6380.conf
[root@C2_SW_5748F_1 copy]# redis-cli -p 6380

  看查进程：

[root@C2_SW_5748F_1 copy]# ps -ef|grep redis
root       3201      1  0 4月03 ?       00:00:00 redis-server 127.0.0.1:6380
root       3214   2361  0 00:00 pts/2    00:00:00 redis-cli -p 6380
root       3219      1  0 00:00 ?        00:00:00 redis-server 127.0.0.1:6381
root       3245   2313  0 00:01 pts/1    00:00:00 redis-cli -p 6381
root       3285      1  0 00:05 ?        00:00:00 redis-server 127.0.0.1:6379
root       3289   2263  0 00:05 pts/0    00:00:00 redis-cli -p 6379
root       3512   3399  0 00:23 pts/3    00:00:00 grep --color=auto redis
[root@C2_SW_5748F_1 copy]# 

看查： 

模式一：一主二仆

前面的环境已经布置好了，开始进行主从复制，以6379为主机，6380和6381为辅机

看查

 redis6380和redis6381信息基本一样，辅机只有读取数据的权利

 辅机的权限：只读取

如果主机宕机，辅机会怎么样？

可以看到，主机挂掉以后，辅机仍然可以读取到以前的数据，主机的状态从up变成了down

 主机再次连接上，是否还是老大的权利？

 答案是可以的

如果辅机宕机了，需要重新连接才行，否则不能当6379的辅机，除非在redis.conf里面配置才行。

 

模式二：薪火相传

上一个Slave可以是下一个slave的Master, Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master,可以有效减轻master的写压力
中途变更转向:会清除之前的数据，重新建立拷贝最新的
Slaveof新主库IP新主库端口
开始：

但是6380仍然不能写

模式三：反客为主

这个模式其实就是简单的示例，就是刚开始6380和6381都是6379的辅机，但是6379突然间挂掉了，6380自己摆脱了6379自己成为了主机，6381也愿意成为6380的辅机，当6379重新回来的时候，发现自己一个辅机也没有了，6380成为了赢家

主从复制原理：

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

缺点：

     由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一 定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

哨兵模式：

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

 

使用步骤：

 1、6379为主机，6380和6381分别为6379的辅机

2、在启动目录下创建sentinel.conf文件

[root@C2_SW_5748F_1 copy]# ls
6379.log  6380.log  6381.log  appendonly.aof  dump6379.rdb  dump6380.rdb  dump6381.rdb  dump.rdb  redis6379.conf  redis6380.conf  redis6381.conf  redis-check-aof  redis-cli  redis.conf  redis-server
[root@C2_SW_5748F_1 copy]# touch sentinel.conf
[root@C2_SW_5748F_1 copy]# ls
6379.log  6381.log        dump6379.rdb  dump6381.rdb  redis6379.conf  redis6381.conf   redis-cli   redis-server
6380.log  appendonly.aof  dump6380.rdb  dump.rdb      redis6380.conf  redis-check-aof  redis.conf  sentinel.conf
[root@C2_SW_5748F_1 copy]# 

3、sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1     1表示sentinel通过投票后认为mater宕机的数量，此处为至少1个

  sentinel.conf文件详解：

#配置端口
port 26379
#以守护进程模式启动
daemonize yes
#日志文件名
logfile "sentinel_26379.log"
#存放备份文件以及日志等文件的目录
dir "/opt/redis/data"
#监控的IP 端口号 名称 sentinel通过投票后认为mater宕机的数量，此处为至少2个
sentinel monitor mymaster 192.168.14.101 6379 2
#30秒ping不通主节点的信息，主观认为master宕机
sentinel down-after-milliseconds mymaster 30000
#故障转移后重新主从复制，1表示串行，>1并行
sentinel parallel-syncs mymaster 1
#故障转移开始，三分钟内没有完成，则认为转移失败
sentinel failover-timeout mymaster 180000

 我们就简单配置一下：

[root@C2_SW_5748F_1 copy]# vim sentinel.conf

#配置端口
port 26379
#以守护进程模式启动   设置为no时可以看到哨兵的运行过程，如果第一次用，建议设置为no
daemonize yes        
#日志文件名
logfile "sentinel_26379.log"
#存放备份文件以及日志等文件的目录
dir "/lhl/copy"
#监控的IP 端口号 名称 sentinel通过投票后认为mater宕机的数量，此处为至少2个
sentinel monitor host6379 127.0.0.1 6379 2                                    

 :wq保存并退出

4、启动哨兵

[root@C2_SW_5748F_1 redis-4.0.1]# cd src
[root@C2_SW_5748F_1 src]# mv redis-sentinel /lhl/copy/
[root@C2_SW_5748F_1 src]# cd /lhl/copy/
[root@C2_SW_5748F_1 copy]# ls
6379.log  6381.log        dump6379.rdb  dump6381.rdb  redis6379.conf  redis6381.conf   redis-cli   redis-sentinel  sentinel.conf
6380.log  appendonly.aof  dump6380.rdb  dump.rdb      redis6380.conf  redis-check-aof  redis.conf  redis-server
[root@C2_SW_5748F_1 copy]# redis-sentinel sentinel.conf

5、看一下哨兵日志，可以看到master为6379，辅机为6380和6381

[root@C2_SW_5748F_1 copy]# vim sentinel_26379.log

3373:X 04 Apr 06:22:19.687 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
3373:X 04 Apr 06:22:19.687 # Redis version=4.0.1, bits=64, commit=00000000, modified=0, pid=3373, just started
3373:X 04 Apr 06:22:19.687 # Configuration loaded
3374:X 04 Apr 06:22:19.690 * Increased maximum number of open files to 10032 (it was originally set to 1024).
3374:X 04 Apr 06:22:19.691 * Running mode=sentinel, port=26379.
3374:X 04 Apr 06:22:19.692 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
3374:X 04 Apr 06:22:19.693 # Sentinel ID is a14f03ba90918091d2a1a3884fa1af78227f92a7
3374:X 04 Apr 06:22:19.693 # +monitor master host6379 127.0.0.1 6379 quorum 1
3374:X 04 Apr 06:22:19.695 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ host6379 127.0.0.1 6379
3374:X 04 Apr 06:22:19.695 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ host6379 127.0.0.1 6379

6、让6379宕机

 再次看查日志：

[root@C2_SW_5748F_1 copy]# vim sentinel_26379.log

3373:X 04 Apr 06:22:19.687 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
3373:X 04 Apr 06:22:19.687 # Redis version=4.0.1, bits=64, commit=00000000, modified=0, pid=3373, just started
3373:X 04 Apr 06:22:19.687 # Configuration loaded
3374:X 04 Apr 06:22:19.690 * Increased maximum number of open files to 10032 (it was originally set to 1024).
3374:X 04 Apr 06:22:19.691 * Running mode=sentinel, port=26379.
3374:X 04 Apr 06:22:19.692 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
3374:X 04 Apr 06:22:19.693 # Sentinel ID is a14f03ba90918091d2a1a3884fa1af78227f92a7
3374:X 04 Apr 06:22:19.693 # +monitor master host6379 127.0.0.1 6379 quorum 1
3374:X 04 Apr 06:22:19.695 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ host6379 127.0.0.1 6379
3374:X 04 Apr 06:22:19.695 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ host6379 127.0.0.1 6379
3374:X 04 Apr 06:29:22.293 # +sdown master host6379 127.0.0.1 6379
3374:X 04 Apr 06:29:22.293 # +odown master host6379 127.0.0.1 6379 #quorum 1/1
3374:X 04 Apr 06:29:22.293 # +new-epoch 1
3374:X 04 Apr 06:29:22.293 # +try-failover master host6379 127.0.0.1 6379
3374:X 04 Apr 06:29:22.293 # +vote-for-leader a14f03ba90918091d2a1a3884fa1af78227f92a7 1
3374:X 04 Apr 06:29:22.293 # +elected-leader master host6379 127.0.0.1 6379
3374:X 04 Apr 06:29:22.293 # +failover-state-select-slave master host6379 127.0.0.1 6379
3374:X 04 Apr 06:29:22.376 # +selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ host6379 127.0.0.1 6379
3374:X 04 Apr 06:29:22.376 * +failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ host6379 127.0.0.1 6379
3374:X 04 Apr 06:29:22.448 * +failover-state-wait-promotion slave 127.0.0.1:6380 127.0.0.1 6380 @ host6379 127.0.0.1 6379
3374:X 04 Apr 06:29:23.351 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ host6379 127.0.0.1 6379
3374:X 04 Apr 06:29:23.351 # +failover-state-reconf-slaves master host6379 127.0.0.1 6379

7、发现6380成为了主机：

8、如果6379重新上线怎么办，哨兵会让6379成为6380（新的主机）的辅机