Redis从主从复制到Sentinel双机热备

最新推荐文章于 2023-02-16 06:30:00 发布
最新推荐文章于 2023-02-16 06:30:00 发布
阅读量686 收藏 5
点赞数 2
分类专栏： redis 文章标签： redis
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/clearlxj/article/details/115380029
版权

安装redis安装包

到 http://download.redis.io/releases/ 选择需要的redis版本进行下载。

下载之后将安装包传到用来做实验的两台服务器10.10.10.44以及10.10.10.102，均为CenterOs7。

解压安装包（此处个人选择的是redis-4.0.9.tar.gz的安装包）并进行编译

# 解压安装包
tar -xvf redis-4.0.9.tar.gz
# 进入到对应目录
cd redis-4.0.9
# 编译
make

在解压目录下找到redis.conf下进行如下修改

# 注释掉bind，不注释只能本机访问
# bind 127.0.0.1

# 开启后台启动，默认为no
daemonize yes

# 新增密码，此处设置123456
requirepass 123456

现在来安装和后台启动redis

cd src
# 安装redis
make install
# 通过配置文件启动redis，因为我们配置了后台启动，所以本次启动为后台启动
redis-server ../redis.conf

看到一下信息说明启动成功

30633:C 01 Apr 14:46:42.510 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
30633:C 01 Apr 14:46:42.510 # Redis version=4.0.9, bits=64, commit=00000000, modified=0, pid=30633, just started
30633:C 01 Apr 14:46:42.510 # Configuration loaded

lxj@lxj:~$ redis-cli -h 10.10.10.44
10.10.10.44:6379> AUTH 123456
OK
10.10.10.44:6379> set test44 test44
OK
10.10.10.44:6379> get test44
"test44"

lxj@lxj:~$ redis-cli -h 10.10.10.102
10.10.10.102:6379> AUTH 123456
OK
10.10.10.102:6379> set test102 test102
OK
10.10.10.102:6379> get test102
"test102"

安装过程中的一些问题

注意编译的服务器需要提前安装好gcc及对应的依赖包

yum install -y gcc

如果安装过程出现以下错误，原因是因为gcc版本过低，yum安装的gcc是4.8.5的。

make[1]: *** [server.o] Error 1
make[1]: Leaving directory `/home/tmp/redis-test/redis-6.0.9/src'
make: *** [all] Error 2

可以选择升级gcc，升级过程如下：

yum -y install centos-release-scl
yum -y install devtoolset-9-gcc devtoolset-9-gcc-c++ devtoolset-9-binutils
scl enable devtoolset-9 bash
echo "source /opt/rh/devtoolset-9/enable" >> /etc/profile
gcc -v

或者选择减低redis的版本。

主从复制

复制特点

  1. 同一个Master可以同步多个Slaves。
  2. Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。
  3. Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。
  4. Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据。
  5. 为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成。

复制原理

​ 在Slave启动并连接到Master之后，它将主动发送一个SYNC命令。此后Master将启动后台存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后，Master将传送整个数据库文件到Slave，以完成一次完全同步。而Slave服务器在接收到数据库文件数据之后将其存盘并加载到内存中。此后，Master继续将所有已经收集到的修改命令，和新的修改命令依次传送给Slaves，Slave将在本次执行这些数据修改命令，从而达到最终的数据同步。
​ 如果Master和Slave之间的链接出现断连现象，Slave可以自动重连Master，但是在连接成功之后，一次完全同步将被自动执行。

配置

我们以10.10.10.44为主，以10.10.10.102为从，那么我们需要为102进行配置

修改102的redis.conf中进行以下配置

# 在末尾加上一下信息，使其成为10.10.10.44的slave，会自动保持和master的数据保持一致
slaveof 10.10.10.44 6379
# 为了保证数据的一致性，从节点不提供写功能，配置文件中要添加一项`slave-read-only yes`，一般默认配置项会有，不需要更改
slave-read-only yes
# 如果设置了密码的话，需要进行主节点密码认证
masterauth 123456

修改44的redis.conf配置

# 如果设置了密码的话，需要进行主节点密码认证
masterauth 123456

如果redis有设置密码的话，所有的节点密码配置一样，不一样不能够正常切换，因为sentinel要配置主节点密码，主节点也要配置masterauth，因为当前主节点在经历故障和恢复后可能会被切换成从节点。

配置完成之后我们重启102的redis服务

# 关闭redis服务的命令
## redis-cli 连接之后 shutdown
10.10.10.102:6379> SHUTDOWN
## 或者 使用kill命令

重启102redis服务之后，我们可以通过info replication命令查看redis的主从服务信息。

# 44
10.10.10.44:6379> info replication
# Replication
role:master
connected_slaves:0
master_replid:f2090459b0541896cb4345bcc7555a4a582aea4e
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
10.10.10.44:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=10.10.10.102,port=6379,state=online,offset=14,lag=0
master_replid:eb0cc05a2d9557019d6e7ede0f351bfa0979791c
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:14
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:14

# 102
10.10.10.102:6379> info replication
# Replication
role:slave
master_host:10.10.10.44
master_port:6379
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:14
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:eb0cc05a2d9557019d6e7ede0f351bfa0979791c
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:14
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:14

通过主从节点的信息可以看出主从节点配置成功。

测试主从复制

我们在44上进行set然后查看两个redis对应的数据是否一致

# 未设置前查看
10.10.10.44:6379> get slavetest
(nil)

10.10.10.102:6379> get slavetest
(nil)

# 在主服务器进行设置
10.10.10.44:6379> set slavetest 123
OK

# 设置之后查看
10.10.10.44:6379> get slavetest
"123"

10.10.10.102:6379> get slavetest
"123"

可以看出主节点的数据能够同步到从节点上。

配置sentinel

当主服务器挂了之后，从服务器立马切换为主服务器继续工作，当原先主服务器修复完善启动后，会自动充当从服务器的角色继续工作。这样就很好的避免了，由于一台主机出现故障，系统挂点的现象出现。

Sentinel(哨兵)是用于监控redis集群中Master状态的工具，已经集成在redis官方版本中，可以直接配置使用。

修改sentinel.conf（与redis.conf同一个目录）

修改内容如下

# 检查主redis节点的地址和端口信息，2代表至少两个个sentinel节点认为主节点宕机才算宕机
sentinel monitor mymaster 10.10.10.44 6379 2

# 主节点失联30秒后，认为主节点不可达，默认30s
sentinel down-after-milliseconds mymaster 5000

# 主节点的密码，如有的话
sentinel auth-pass mymaster 123456

# sentinel后台运行
daemonize yes

# 解决哨兵之间不能通信，不能进行主结节客观下线的判断，以及failover
protected-mode no

# sentinel的端口，默认26379
# port 26379

# 切换新的主节点后，从节点要从新的主节点同步数据。默认1，表示开启
# sentinel parallel-syncs master 1

重启已经redis，启动sentinel

# 启动sentinel
./src/redis-sentinel sentinel.conf

连接到其中一个sentinel可以看到

lxj@lxj:~$ redis-cli -h 10.10.10.44 -p 26379
10.10.10.44:26379> info
## 此处被省略
## ....

# 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=10.10.10.44:6379,slaves=1,sentinels=2
# 以上可以看出sentinel监控状态ok,master节点的ip,端口。并且能够显示从节点的数量和sentinel节点的数量

主从切换测试

因为要查看sentinel的日志，所以其中一个sentinel不配置后台运行；将44down之后，查看sentinel的日志可以看到，当有两个sentinel发现44down之后，将102设置为主redis，并将44设置为从redis

20330:X 01 Apr 17:28:05.274 # +sdown master mymaster 10.10.10.44 6379
20330:X 01 Apr 17:28:05.336 # +odown master mymaster 10.10.10.44 6379 #quorum 2/2
20330:X 01 Apr 17:28:05.336 # +new-epoch 1
20330:X 01 Apr 17:28:05.336 # +try-failover master mymaster 10.10.10.44 6379
20330:X 01 Apr 17:28:05.375 # +vote-for-leader 1718193d4bb0c5b2837ba6e71da4e8031346cd81 1
20330:X 01 Apr 17:28:05.444 # ce235e51cbc258d94e2ea0a539f1482b3f2515e7 voted for 1718193d4bb0c5b2837ba6e71da4e8031346cd81 1
20330:X 01 Apr 17:28:05.446 # +elected-leader master mymaster 10.10.10.44 6379
20330:X 01 Apr 17:28:05.446 # +failover-state-select-slave master mymaster 10.10.10.44 6379
20330:X 01 Apr 17:28:05.508 # +selected-slave slave 10.10.10.102:6379 10.10.10.102 6379 @ mymaster 10.10.10.44 6379
20330:X 01 Apr 17:28:05.508 * +failover-state-send-slaveof-noone slave 10.10.10.102:6379 10.10.10.102 6379 @ mymaster 10.10.10.44 6379
20330:X 01 Apr 17:28:05.599 * +failover-state-wait-promotion slave 10.10.10.102:6379 10.10.10.102 6379 @ mymaster 10.10.10.44 6379
20330:X 01 Apr 17:28:06.276 # +promoted-slave slave 10.10.10.102:6379 10.10.10.102 6379 @ mymaster 10.10.10.44 6379
20330:X 01 Apr 17:28:06.276 # +failover-state-reconf-slaves master mymaster 10.10.10.44 6379
20330:X 01 Apr 17:28:06.320 # +failover-end master mymaster 10.10.10.44 6379
20330:X 01 Apr 17:28:06.320 # +switch-master mymaster 10.10.10.44 6379 10.10.10.102 6379
20330:X 01 Apr 17:28:06.320 * +slave slave 10.10.10.44:6379 10.10.10.44 6379 @ mymaster 10.10.10.102 6379
20330:X 01 Apr 17:28:11.323 # +sdown slave 10.10.10.44:6379 10.10.10.44 6379 @ mymaster 10.10.10.102 6379

我们也可以去102查看主从情况

10.10.10.102:6379> info replication
# Replication
role:master
connected_slaves:0
master_replid:064dbdf5121bd5f79a71455091f0a5d44120a532
master_replid2:ae6c075dc960a03586c6db68e4bfe6b297410f7f
master_repl_offset:72771
second_repl_offset:46434
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:72771

说明主从切换成功了，并且我们可以查看102的redis.conf配置文件，可以发现我们配置了slaveof 10.10.10.44 6379已经被删除了 。

我们将44的redis重新恢复之后，通过cli发现44已经变成了102的从服务器，说明主服务器宕机之后重新恢复的话会以从服务器的身份接入。

# 102
10.10.10.102:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=10.10.10.44,port=6379,state=online,offset=109261,lag=1
master_replid:064dbdf5121bd5f79a71455091f0a5d44120a532
master_replid2:ae6c075dc960a03586c6db68e4bfe6b297410f7f
master_repl_offset:109538
second_repl_offset:46434
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:109538

# 44
10.10.10.44:6379> info replication
# Replication
role:slave
master_host:10.10.10.102
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:108430
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:064dbdf5121bd5f79a71455091f0a5d44120a532
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:108430
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:105319
repl_backlog_histlen:3112

再测试一下主从复制情况

10.10.10.102:6379> get test
(nil)
10.10.10.44:6379> get test
(nil)


10.10.10.102:6379> set test test
OK


10.10.10.102:6379> get test
10.10.10.44:6379> get test
"test"

说明主从复制正常进行，并且查看44的redis.conf会发现，在配置文件最后加上了slaveof 10.10.10.102 6379。

经过以上测试说明redis双机热备成功。

将redis制作成系统服务，并自启动

魔笛Love
关注
  • 2
    点赞
  • 踩
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Redis双机热备
宿久
02-04 6186
      双机热备特指基于高可用系统中的两台服务器的热备（或高可用），因两机高可用在国内使用较多，故得名双机热备，双机高可用按工作中的切换方式分为：主-备方式（Active-Standby方式）和双主机方式（Active-Active方式），主-备方式即指的是一台服务器处于某种业务的激活状态（即Active状态），另一台服务器处于该业务的备用状态（即Standby状态)。而双主机方式即指两种不同...
keepalive+nginx+redis实现双机热备加redis主从高可用
最新发布
qq_36797902的博客
09-07 393
script "/usr/local/keepalived/scripts/redis/redis_check.sh winning.2019 " ###监控脚本。script "/usr/local/keepalived/scripts/redis/redis_check.sh winning.2019 " ###监控脚本。输入命令：vim/winning/winmid/redis/conf/common.conf。三、建立文件夹：/usr/local/keepalived/scripts。
Redis(带认证)+keepalived双机热备部署方案
qq_36811981的博客
09-10 2425
1. 前言 目前Redis主流的高可用方案主要是Master+Slave+Sentinel（即主从+哨兵）的模式，主要原理是：通过Sentinel（哨兵）集群来检测集群各节点Redis服务的存活状态及完成Redis集群的主从切换。切换完成后，Sentinel调用notification-script参数指定的配置文件，通知DNS服务更改DNS配置，完成Redis master节点的切换。 然而我们现在的应用不支持Sentinel模式，并且代码改起来改动较大，风险也比较大。所以只好舍弃了Master+Slav
keepalived + redis 实现双机热备
04-23
NULL 博文链接：https://xticfc.iteye.com/blog/2181407
Redis主从复制(Replication)和哨兵模式(Sentinel)
weixin_40964170的博客
01-07 744
概念 1、redis的复制功能是支持多个数据库之间的数据同步。一类是主数据库（master）一类是从数据库（slave），主数据库可以进行读写操作，当发生写操作的时候自动将数据同步到从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据，一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。 2、通过redis的复制功能可以很好的实现数据库的读写分离，提高服务器的负载能力。主数据库主要进行写操作，而从数据库负责读操作。 主从复制，读写分离，大部分情况下都是在进行读操作，减缓服务器的压力
SpringBoot项目中利用Redis实现系统双活_双机热备
06-13
总的来说，SpringBoot项目中利用Redis实现系统双活和双机热备是一个涉及多个层面的技术实践，包括Redis的主从配置、应用的无状态设计、故障切换策略以及监控报警机制等。通过这些措施，可以显著提升系统的稳定性和...
redis主从备份双机热备集群简洁配置方式
01-08
redis主从备份双机热备集群简洁配置方式，主要配置redis.conf文件和sentinel.conf文件，可以实现主从自动切换，宕机也不怕
高可用Redis：主从复制、sentinel哨兵、漂移VIP故障转移.pdf
04-02
高可用Redis：主从复制、sentinel哨兵、漂移VIP故障转移
redis-sentinel集群及双机热备
03-17
Redis Sentinel集群和双机热备是 Redis 高可用性（High Availability, HA）的重要组成部分，它们确保了在主节点故障时能够快速切换到备份节点，从而维持服务的连续性。以下将详细介绍这两个概念以及相关配置和操作。...
一步步实现redis+sentinel双机热备
weixin_34400525的博客
10-09 578
2019独角兽企业重金招聘Python工程师标准>>> ...
redis双机热备方案
03-07
redis 双机 热备 方案,自动切换 keepaline
keepalived+redis主从双机热备部署
酷狗蛋的博客
06-04 2643
keepalived+redis主从双机热备部署@[TOC](keepalived+redis主从双机热备部署) 最近的项目上遇到了这样的需求，客户要求做应用与数据库的分离。客户给了4台服务器。1、安装部署Redis2、安装部署keepalived 最近的项目上遇到了这样的需求，客户要求做应用与数据库的分离。客户给了4台服务器。 1、安装部署Redis 准备环境 1.两台服务器 192.168.0.55 master 192.168.0.56 slave 192.168.
亲自动手实践Redis主从复制、Sentinel主从切换、Cluster分片的操作，看完还学不会就安心当条咸鱼吧
守夜人爱吃兔子的博客
05-17 260
前言 我们在开发测试环境中，一般搭建Redis的单实例来应对开发测试需求，但是如果在生产环境中对可靠性、可用性的要求较高，这时候就需要引入Redis的集群方案。而Redis 提供的Redis Sentinel主从切换和Redis Cluster分片技术，则有效实现了 Redis 的高可用、高性能、高可伸缩性，本文对以上技术进行亲自动手实践。 简介 1. Redis Cluster分片 通过一致性 hash 的方式，将数据分散到多个服务器节点：设计了 16384 个哈希槽，并分配到多台 redi.
Redis + Keepalived 实现双机主从互备【互为主从、主从自动切换】
liuqw231的专栏
02-16 3682
实际生产中，系统压力不大且仅两台物理服务器；实际一个Redis服务完全够用，但为了高可用及容灾备份，又不够哨兵模式的三台，所以做此实现方案。
基于docker实现redis哨兵模式（双机热备）
方糖先生的博客
10-10 1246
基于docker实现redis双机热备 redis的双机热备，是由redis主从+sentinel（哨兵）来实现的，至于使不使用docker差别不是特别大，我之所以选择基于docker主要出于方便。 我这里基于两台服务器进行讲解，主从设置上，一主一从或者一主多从都可以，但是哨兵模式上，官方的建议是2n+1（n>=1）台服务器的，不过出于资源有限，以及我们是基于一主一从的模式，所以，我们这里...
redis 高阶（七）哨兵模式
java_shm的专栏
08-24 371
一.哨兵简介 1. 哨兵概念 哨兵(sentinel) 是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的 master并将所有slave连接到新的master。 2.哨兵的作用 监控 不断的检查master和slave是否正常运行。 master存活检测、master与slave运行情况检测 通知（提醒） 当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知。 自动故障转移 断开master与slave连接，选取一个slave作为m
Redis 哨兵模式（Sentinel）的配置使用
小树苗
04-17 681
哨兵模式 两台服务器分别为CentOS7.6系统： master：10.24.45.12 slave：10.24.45.15 全部完成下面操作： 先关闭防火墙和selinux systemctl stop firewalld systemctl disable firewalld vim /etc/selinux/config SELINUX=disabled 重启：re...
Redis服务搭建及使用Keepalived实现主从双机热备
mingjie1212的博客
01-09 2522
Redis服务器服务搭建及主从架构实现 1.  简述 本文档根据互联网上博客参考，并在测试环境搭建成功，记录测试环境中Redis缓存服务器的搭建过程及实现主从双机热备架构的过程。 2.  测试环境 系统：Centos6.5 软件：redis-2.8.24.tar.gz  Keepalived v1.2.13 主IP： 192.168.3.3 从IP：192.168.3.4 VI
搭建高可用Redis：主从复制、Sentinel哨兵与VIP故障转移详解
Redis的主从复制是通过在一台主服务器（master）上执行写操作，同时将这些操作同步到从服务器（slave）上实现的。这确保了数据的一致性和冗余。在文中提到的示例中，配置了两台从服务器（192.168.33.80 和 192.168....
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值