Redis 主从复制和哨兵模式

最新推荐文章于 2024-07-16 18:30:27 发布
最新推荐文章于 2024-07-16 18:30:27 发布
阅读量4.2k 收藏 1
点赞数
文章标签： redis
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_50854537/article/details/111356076
版权

文章目录

主从复制

主从复制概念

Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。为了分担读压力，Redis支持主从复制，保证主数据库的数据内容和从数据库的内容完全一致。Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。

在这里插入图片描述

全量同步
Redis.全量复制一般发生在Slave初始化阶段,这时Slave需要将Master上的所有数据都复制一份。具体步骤如下:

  1. 从服务器连接主服务器，发送SYNC命令

  2. 主服务器接收到SYNC命名后,开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令

  3. 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令

  4. 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照

  5. 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令

  6. 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令;增量同步

在这里插入图片描述

Redis增量复制

是指Slave 初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令,从服务器接收并执行收到的写命令。

Redis主从同步策略

主从刚刚连接的时候，进行全量同步;全同步结束后，进行增量同步。当然，如果有需要，slave在任何时候都可以发起全量同步。redis策略是,无论如何,首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

部署主从模式

实验环境

  • 20.0.0.10 主
  • 20.0.0.11 从1
  • 20.0.0.12 从2

实验过程

1：解压缩Redis软件包，三台服务器同步操作

[root@master ~]# tar zxvf redis-5.0.4.tar.gz

2：安装，三台服务器同步操作

[root@master ~]# cd redis-5.0.4/
[root@master redis-5.0.4]# make
[root@master redis-5.0.4]# make PREFIX=/usr/local/redis install

3：创建链接，三台服务器同步操作

[root@master ~]# ln -s /usr/local/redis/bin/* /usr/local/bin/

4：安装脚本，三台服务器同步操作

[root@master ~]# cd redis-5.0.4/utils/
[root@master utils]# ./install_server.sh

5：查看启动状态，三台服务器同步操作

[root@master utils]# netstat -anptu | grep redis
tcp        0      0 127.0.0.1:6379     0.0.0.0:*     LISTEN      59586/redis-server

6：修改主、从服务器配置文件
主

[root@master utils]# cd
[root@master ~]# vi /etc/redis/6379.conf 
bind 0.0.0.0                    
appendonly yes

从1、从2

[root@slave1 ~]# vi /etc/redis/6379.conf
bind 0.0.0.0
appendonly yes
# replicaof <masterip> <masterport>  修改   replicaof 20.0.0.10 6379

7：重启三台服务器，三台服务器同步操作

[root@master ~]# /etc/init.d/redis_6379 restart

实验效果

日志查看

  • 主
[root@master ~]# tail -f /var/log/redis_6379.log 
59775:M 19 Dec 2020 20:21:58.664 * Background saving terminated with success
59775:M 19 Dec 2020 20:21:58.664 * Synchronization with replica 20.0.0.11:6379 succeeded
59775:M 19 Dec 2020 20:22:03.044 * Replica 20.0.0.12:6379 asks for synchronization
59775:M 19 Dec 2020 20:22:03.044 * Full resync requested by replica 20.0.0.12:6379
59775:M 19 Dec 2020 20:22:03.044 * Starting BGSAVE for SYNC with target: disk
59775:M 19 Dec 2020 20:22:03.044 * Background saving started by pid 59788
59788:C 19 Dec 2020 20:22:03.044 * DB saved on disk
59788:C 19 Dec 2020 20:22:03.045 * RDB: 0 MB of memory used by copy-on-write
59775:M 19 Dec 2020 20:22:03.062 * Background saving terminated with success
59775:M 19 Dec 2020 20:22:03.062 * Synchronization with replica 20.0.0.12:6379 succeeded
  • 从1、从2
[root@slave1 ~]# tail -f /var/log/redis_6379.log 
57462:S 19 Dec 2020 20:21:58.664 * MASTER <-> REPLICA sync: Finished with success
57462:S 19 Dec 2020 20:21:58.664 * Background append only file rewriting started by pid 57466
57462:S 19 Dec 2020 20:21:58.743 * AOF rewrite child asks to stop sending diffs.
57466:C 19 Dec 2020 20:21:58.743 * Parent agreed to stop sending diffs. Finalizing AOF...
57466:C 19 Dec 2020 20:21:58.744 * Concatenating 0.00 MB of AOF diff received from parent.
57466:C 19 Dec 2020 20:21:58.744 * SYNC append only file rewrite performed
57466:C 19 Dec 2020 20:21:58.744 * AOF rewrite: 0 MB of memory used by copy-on-write
57462:S 19 Dec 2020 20:21:58.810 * Background AOF rewrite terminated with success
57462:S 19 Dec 2020 20:21:58.810 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
57462:S 19 Dec 2020 20:21:58.810 * Background AOF rewrite finished successfully
[root@slave2 ~]# tail -f /var/log/redis_6379.log 
57283:S 27 Oct 2020 19:21:25.410 * MASTER <-> REPLICA sync: Finished with success
57283:S 27 Oct 2020 19:21:25.410 * Background append only file rewriting started by pid 57287
57283:S 27 Oct 2020 19:21:25.490 * AOF rewrite child asks to stop sending diffs.
57287:C 27 Oct 2020 19:21:25.490 * Parent agreed to stop sending diffs. Finalizing AOF...
57287:C 27 Oct 2020 19:21:25.490 * Concatenating 0.00 MB of AOF diff received from parent.
57287:C 27 Oct 2020 19:21:25.490 * SYNC append only file rewrite performed
57287:C 27 Oct 2020 19:21:25.491 * AOF rewrite: 0 MB of memory used by copy-on-write
57283:S 27 Oct 2020 19:21:25.590 * Background AOF rewrite terminated with success
57283:S 27 Oct 2020 19:21:25.590 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
57283:S 27 Oct 2020 19:21:25.590 * Background AOF rewrite finished successfully

连接数据库查看

[root@master ~]# redis-cli
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=20.0.0.11,port=6379,state=online,offset=616,lag=1
slave1:ip=20.0.0.12,port=6379,state=online,offset=616,lag=1
master_replid:be8b41328bd2e5cfcae64b6e6c46071d41768ac1
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:616
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:616

验证数据效果
主服务器添加数据，查看从服务器是否有

  • 主
[root@master ~]# redis-cli
127.0.0.1:6379> set aaa 111
OK
127.0.0.1:6379> get aaa
"111"
  • 从
[root@slave1 ~]# redis-cli
127.0.0.1:6379> get aaa
"111"

将主服务器宕掉之后查看信息

[root@master ~]# /etc/init.d/redis_6379 stop
Stopping ...
Waiting for Redis to shutdown ...
Redis stopped
  • 从查看信息
[root@slave1 ~]# redis-cli
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:20.0.0.10            
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:1482
master_link_down_since_seconds:63
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:be8b41328bd2e5cfcae64b6e6c46071d41768ac1
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1482
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1482

实验结论

主服务器宕掉之后主从复制的主不会自动切换，信息会从主服务器上进行复制，不影响数据读取，但无法写入。需要架构哨兵模式，可以让主失效的时候，从可以接替主的工作

哨兵模式

哨兵模式原理

哨兵(sentinel) 是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master。所以整个运行哨兵的集群的数量不得少于3个节点。

哨兵模式的作用

1：监控

  • 不断的检查master和slave是否正常运行
  • master存活检测、master与slave运行情况检测

2：通知（提醒）

  • 当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知

3：自动故障转移

  • 断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址

注释：哨兵也是一台redis服务器，只是不提供数据服务

哨兵的启动依赖于主从模式，所以须把主从模式安装好的情况下再去做哨兵模式，所有节点上都需要部署哨兵模式，哨兵模式会监控所有的redis工作节点是否正常，当master出现问题的时候，因为其他节点与主节点失去联系，因此会投票，投票过半就认为这个master的确出现问题，然后会通知哨兵间，然后从slaves中选取一个作为新的master

部署哨兵模式

接着上面的实验，让所有服务器保持开启状态

1：修改配置文件

三个服务器都需要修改

[root@master ~]# vi redis-5.0.4/sentinel.conf
protected-mode no                                #17  关闭保护模式
daemonize yes                                    #26  开启守护进程
logfile /var/log/sentinel.log                    #36  设置哨兵的日志文件
dir /var/lib/redis/6379                          #65  数据保存路径
sentinel monitor mymaster 20.0.0.10  6379 2      #84 
sentinel down-after-milliseconds mymaster 3000   #113  主宕机超时时间
sentinel failover-timeout mymaster 100000        #146  主自动切换失效时间

将主服务器修改的配置文件复制发送给其余服务器

[root@master ~]# scp redis-5.0.4/sentinel.conf root@20.0.0.11:/root/redis-5.0.4
[root@master ~]# scp redis-5.0.4/sentinel.conf root@20.0.0.12:/root/redis-5.0.4

2：启动哨兵

[root@master ~]# redis-sentinel redis-5.0.4/sentinel.conf &
[1] 60381
[root@slave1 ~]# redis-sentinel redis-5.0.4/sentinel.conf &
[1] 57970
[root@slave2 ~]# redis-sentinel redis-5.0.4/sentinel.conf &
[1] 57811

3：查看日志情况

[root@master ~]# tail -f /var/log/sentinel.log 
59960:X 19 Dec 2020 22:02:39.568 # Configuration loaded
59961:X 19 Dec 2020 22:02:39.570 * Increased maximum number of open files to 10032 (it was originally set to 1024).
59961:X 19 Dec 2020 22:02:39.571 * Running mode=sentinel, port=26379.
59961:X 19 Dec 2020 22:02:39.571 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
59961:X 19 Dec 2020 22:02:39.572 # Sentinel ID is 6df982de009d407ac882b63c29be3c670c43a207
59961:X 19 Dec 2020 22:02:39.572 # +monitor master mymaster 20.0.0.10 6379 quorum 2
59961:X 19 Dec 2020 22:02:39.572 * +slave slave 20.0.0.11:6379 20.0.0.11 6379 @ mymaster 20.0.0.10 6379
59961:X 19 Dec 2020 22:02:39.573 * +slave slave 20.0.0.12:6379 20.0.0.12 6379 @ mymaster 20.0.0.10 6379
59961:X 19 Dec 2020 22:02:45.082 * +sentinel sentinel 6c994c4303173699b8ef61c15e258f1822a55853 20.0.0.11 26379 @ mymaster 20.0.0.10 6379
59961:X 19 Dec 2020 22:02:48.453 * +sentinel sentinel 091ae562082aaad90fe4deb3ab87b18bedbddcf0 20.0.0.12 26379 @ mymaster 20.0.0.10 6379

4：查看进程信息

[root@master ~]# ps aux | grep sentinel
root  59961  0.2  0.2 153836  4680 ?Ssl 22:02 0:00 redis-sentinel *:26379 [sentinel]
root  60054  0.0  0.0 112676   984 pts/1 S+ 22:05 0:00 grep --color=auto sentinel

5：查看哨兵信息

[root@master ~]# redis-cli -h 20.0.0.10 -p 26379 info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=20.0.0.12:6379,slaves=2,sentinels=3

3：验证哨兵模式

1：停止主服务器

[root@master ~]# /etc/init.d/redis_6379 stop
Stopping ...
Waiting for Redis to shutdown ...
Redis stopped

2：查看日志验证效果

[root@slave1 ~]# tail -f /var/log/sentinel.log 
19133:X 19 Dec 2020 22:03:07.189 # +failover-state-reconf-slaves master mymaster 20.0.0.10 6379
19133:X 19 Dec 2020 22:03:07.241 * +slave-reconf-sent slave 20.0.0.11:6379 20.0.0.11 6379 @ mymaster 20.0.0.10 6379
19133:X 19 Dec 2020 22:03:08.236 * +slave-reconf-inprog slave 20.0.0.11:6379 20.0.0.11 6379 @ mymaster 20.0.0.10 6379
19133:X 19 Dec 2020 22:03:08.236 * +slave-reconf-done slave 20.0.0.11:6379 20.0.0.11 6379 @ mymaster 20.0.0.10 6379
19133:X 19 Dec 2020 22:03:08.295 # -odown master mymaster 20.0.0.10 6379
19133:X 19 Dec 2020 22:03:08.295 # +failover-end master mymaster 20.0.0.10 6379
19133:X 19 Dec 2020 22:03:08.295 # +switch-master mymaster 20.0.0.10 6379 20.0.0.12 6379
19133:X 19 Dec 2020 22:03:08.296 * +slave slave 20.0.0.11:6379 20.0.0.11 6379 @ mymaster 20.0.0.12 6379
19133:X 19 Dec 2020 22:03:08.296 * +slave slave 20.0.0.10:6379 20.0.0.10 6379 @ mymaster 20.0.0.12 6379
19133:X 19 Dec 2020 22:12:51.605 # +sdown slave 20.0.0.10:6379 20.0.0.10 6379 @ mymaster 20.0.0.12 6379

查看哨兵信息

[root@slave1 ~]# redis-cli -h 20.0.0.11 -p 26379 info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=20.0.0.12:6379,slaves=2,sentinels=3
主服务器已变成：20.0.0.12
m0_50854537
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
redis主从复制与哨兵模式
weixin_43992845的博客
08-10 328
1.集群环境搭建（默认情况下每台redis服务器都是主节点） 127.0.0.1:6379> info replication //查看当前库的信息 role:master //当前角色 connected_slaves:0 //没有从机 master_replid:d4fa5da90deabc682540ad21321c246e2b0adcfa master_replid2:0000000000000000000000000000000000000000 master_repl_offset:0
Redis主从复制和哨兵模式介绍
HB199753的博客
11-12 2468
目录 前言 一、redis群集 1、模式 2、作用 2.1 主从复制 2.2哨兵 2.3集群 二、redis主从复制 1、概述 2、redis结构分类 3、主从复制原理 4、redis全量同步 5、redis增量复制 6、redis主从同步策略 三、搭建Redis主从复制 1、项目环境 2、关闭防火墙，安装环境 3、解压并安装 4、创建链接文件，并启动服务 5、修改配置文件 5.1 主服务器上 5.2 备选服务器上，先开启和主服务器一样的功能，再进行...
Hacker_Kid-v1.0.1靶机
weixin_45691672的博客
06-16 794
实验主机：Hacker_Kid-v1.0.1靶机一台/Kali linux攻击机一台Hacker_Kid-v1.0.1靶机 IP：192.168.3.225Kali linux攻击机 IP：192.168.3.32实验网络：桥接模式实验目标：获取靶机的Root权限。
redis集群篇一：主从复制以及哨兵
小浪与艳花
07-14 481
redis集群搭建redis集群相关了解背景一、集群知识背景了解二、单机redis的局限三、redis集群：主从复制操练主机故障需要人为干预维护注意事项搭建过程遇到问题小结四、redis哨兵 redis集群相关了解背景 一、集群知识背景了解 cap规则：只能满足其中两个（ca,cp,ap），不可能同时三个都满足（c 一致性，a 可用性，p 分区容错性），想全面了解可以查下百度：cap 理论 二、单机redis的局限 单点故障 容量有限 连接数压力 为了解决以上问题，可通过akf的拆分思想 解决或缓解re
redis错误排查
热门推荐
rongge2008的专栏
12-07 3万+
日志集中式监控平台上线已经有一段时间，但是大部分情况下只是作为发布或者出问题时查看日志的便利工具使用。平时大家都不怎么主动上去看看。于是前几天把应用的错误日志也加上邮件、Hi和短信报警，马上就收到很多错误报警，引起了大家的重视。其中有一个Redis报错： Push notify error: => redis.clients.jedis.exceptions.JedisConnectionExc
redis启动提示vm.overcommit_memory、somaxconn警告错误
爱代码也爱生活
09-04 9711
1、WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 2、WARNING overcommit_memory is set to 0! Background save may fail u
redis主从连接不成功错误
wzq的博客
03-22 2万+
安装完redis后，设置主从，在从服务器上运行 127.0.0.1:6379> slaveof 192.168.159.131 6379 slaveof 然后回到主服务器上，运行info replication 显示如下： 127.0.0.1:6379> info replication # Replication role:master connected_slaves:0
redis主从模式与哨兵模式例子
07-27
redis主从模式与哨兵模式例子 # 当前Sentinel服务运行的端口 port 26378 # 哨兵监听的主服务器 sentinel myid 09a71e001825114de399e0b6214c4b6f5449ab3a # 3秒内mymaster没响应，则认为mymaster宕机 sentinel deny...
Redis集群-Redis安装、Redis主从复制、哨兵、Redis集群
12-25
Redis集群是Redis的一种高可用性解决方案，通过主从复制、哨兵和集群三大技术模块来实现高可用性和可扩展性。本文将对Redis集群进行详细的介绍，包括Redis安装、主从复制、哨兵和集群的配置和实现。 一、Redis安装 ...
Redis主从复制+哨兵配置手册.docx
12-30
Redis 主从复制和哨兵配置手册 Redis 主从复制是一种高可用性解决方案，可以确保数据的安全和可靠性。在这个手册中，我们将详细介绍 Redis 主从复制的配置和哨兵的配置。 环境准备 在开始配置 Redis 主从复制之前...
redis 的主从复制，哨兵模式
04-15
综上所述，Redis 的主从复制提供了基本的数据备份和故障恢复能力，而哨兵模式进一步增强了系统的高可用性，自动处理故障切换，降低了运维复杂度。在实际生产环境中，结合主从复制和哨兵模式，可以构建出稳定、可靠的...
redis主从配置以及哨兵模式配置
03-30
详细的描述了redis的配置，以及哨兵sentinel模式的配置以及使用，很实用！
Redis故障转移日志分析
gumengkai的博客
07-02 1728
一. 测试环境 二. 操作步骤 [root@orcl19c redis]# ps -ef|grep redis root 28166 1 0 09:38 ? 00:00:03 redis-server *:6379 root 28173 1 0 09:39 ? 00:00:03 redis-server *:6380...
Redis开发与运维读书笔记-第五章-持久化
enjoycoding悦码
09-17 810
Redis支持RDB和AOF两种持久化机制，持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复. 一.RDB RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。1　触发机制手动触发采用bgsave命令： ·bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子 进程负责，...
Redis集群的三种配置方式案例
学习学习学习
09-19 1万+
Redis有三种集群模式：主从复制、哨兵(Sentinel)、集群(Cluster)，本文介绍了此三种方法以及连接boot的使用案例
Redis——Redis集群详解
weixin_57323780的博客
04-06 996
Redis 集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。Redis 集群通过分区（partition）来提供一定程度的可用性即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。edis ACL是Access Control List（访问控制列表）的缩写，该功能允许根据可以执行的命令和可以访问的键来限制某些连接。在Redis 5版本之前，Redis 安全规则只有密码控制还有通过rename。
Redis集群配置
qq_41720578的博客
08-01 1903
BOOTPROTO="static"#修改为staticONBOOT="yes"#修改为yesIPADDR=192.168.1.70#修改本地Ip网段下ip不能与本地ip相同GATEWAY=192.168.1.1#修改为本地网关NETMASK=255.255.255.0#修改为本地子网掩码。
Redis三种集群模式介绍及搭建
QHJJHQ的博客
02-05 8095
redis集群 redis集群就是多个redis节点一起工作的模式。它没有代理节点和中心节点，各个节点平等。 redis集群提供了以下两个好处 1、将数据自动切分(split)到多个节点 2、当集群中的某一个节点故障时，redis还可以继续处理客户端的请求。 集群中的主从复制 集群中的每个节点都有1个至N个复制品，其中一个为主节点，其余的为从节点，如果主节点下线了，集群就会把这个主节点的一个从节点设置为新的主节点，继续工作。这样集群就不会因为一个主节点的下线而无法正常工作。 注意： 1、如果
redis登录缓存
最新发布
weixin_53515812的博客
07-16 189
2.将登录成功的token存储到redis中。4.当密码更新成功时，需重新登录，删除旧令牌。1.pom.xml中引入redis依赖。3. 在登录拦截器中进行令牌验证。
redis主从复制和哨兵模式玩为什么要一起用
06-02
Redis主从复制和哨兵模式通常被一起使用，是为了实现高可用性和容错性。 Redis主从复制可以实现数据的备份和读写分离，在主节点上进行写操作，从节点可以进行读操作，从而提高Redis的性能。同时，当主节点出现故障...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值