【Redis】Redis 主从复制之一

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
简介: 前言   和关系型数据库一样,Redis也有自己的高可用属性,主从复制,相比而言 redis的主从复制的搭建过程更为简单。一 redis 主从复制的特点 1 同一个master可以拥有多个slaves。
前言
  和关系型数据库一样,Redis也有自己的高可用属性,主从复制,相比而言 redis的主从复制的搭建过程更为简单。
一 redis 主从复制的特点
1 同一个master可以拥有多个slaves。
2 master下的Slave还可以接受同一架构中其它slave的链接与同步请求,实现数据的级联复制,即master->slave->Sslave模式;
3 master以非阻塞的方式同步数据至slave,这将意味着master会继续处理一个或多个slave的读写请求;
4 slave端同步数据也可以修改为非阻塞是的方式,当slave在执行新的同步时,它仍可以用旧的数据信息来提供查询;否则,当slave与master失去联系时,slave会返回一个错误给客户端;
5 redis的主从复制具有可扩展性,即多个slave专门提供只读查询与数据的冗余,master端专门提供写操作,实现读写分离,负载均衡;
6通过配置禁用Master数据持久化机制,将其数据持久化操作交给Slaves完成,避免在Master中要有独立的进程来完成此操作。

二 redis 复制的原理以及注意事项
 我们可以从slave redis 的log中查看redis 复制的主要过程
  1. [3308] 24 May 23:09:44.133 * Connecting to MASTER 10.0.2.8:6379
  2. [3308] 24 May 23:09:44.134 * MASTER <-> SLAVE sync started
  3. [3308] 24 May 23:09:44.134 * Non blocking connect for SYNC fired the event.
  4. [3308] 24 May 23:09:44.136 * Master replied to PING, replication can continue...
  5. [3308] 24 May 23:09:44.137 * Partial resynchronization not possible (no cached master)
  6. [3308] 24 May 23:09:44.137 * Full resync from master: 295a0c0dbf70e9b372ebdf6d14b0cae90072ac89:1
  7. [3308] 24 May 23:09:44.143 * MASTER <-> SLAVE sync: receiving 40 bytes from master
  8. [3308] 24 May 23:09:44.144 * MASTER <-> SLAVE sync: Flushing old data
  9. [3308] 24 May 23:09:44.144 * MASTER <-> SLAVE sync: Loading DB in memory
  10. [3308] 24 May 23:09:44.144 * MASTER <-> SLAVE sync: Finished with success
  11. [3308] 24 May 23:24:44.033 * 1 changes in 900 seconds. Saving...
  12. [3308] 24 May 23:24:44.034 * Background saving started by pid 3385
  13. [3385] 24 May 23:24:44.037 * DB saved on disk
  14. [3385] 24 May 23:24:44.038 * RDB: 0 MB of memory used by copy-on-write
  15. [3308] 24 May 23:24:44.134 * Background saving terminated with success
结合redis 主从同步的日志和官方文档,我们总结一下redis的同步过程原理:
1 当一个redis 实例加上slaveof master_ip port 方式启动时,无论是第一次连接还是重连,它会主向master发送一个SYNC command,请求同步连接。
2 当master 收到SYNC 命令之后,发送一个PING 命令给slave ,且在后台执行bgsave命令,将数据快照保存到数据文件中,同时会记录所有修改数据的命令并缓存在数据文件。
3 master后台进程把数据持久化到磁盘之后,就发送数据库文件给slave。
4 slave端将数据文件保存到硬盘上,然后将其在加载到内存中,完成第一次全量同步操作。
5 master会将之前收集到的修改数据的操作和新的修改数据的操作发送给Slave端。
6 slave 收到这些命令之后会在本地执行,类似于MySQL的sql_thread操作。从而达到主从数据最终一致。
7 如果master和slave之间的链接出现断连,slave可以自动重连master。根据版本的不同,断连后同步的方式也不同:
    2.8之前:重连成功之后,一次全量同步操作将被自动执行.
    2.8之后:重连成功之后,进行部分同步操作.
Master持久化功能关闭时Replication的安全性
当我们部署redis主从复制的时候,一般都会强烈建议把master的持久化开关打开。即使为了避免持久化带来的延迟影响,不把持久化开关打开,那么也应该把master配置为不会自动启动的。因为master异常crash后再重启是非常危险的,会导致slave中的数据会被清空。
假设我们有一个redis节点A,设置为master,并且关闭持久化功能,另外两个节点B和C是它的slave,并从A复制数据。
如果A节点崩溃了导致所有的数据都丢失了,它会有重启系统来重启进程。但是由于持久化功能被关闭了,所以即使它重启了,它的数据集是空的。
而B和C依然会通过replication机制从A复制数据,所以B和C会从A那里复制到一份空的数据集,并用这份空的数据集将自己本身的非空的数据集替换掉。于是就相当于丢失了所有的数据。
即使使用一些HA工具,比如说sentinel来监控master-slaves集群,也会发生上述的情形,因为master可能崩溃后迅速恢复。速度太快而导致sentinel无法察觉到一个failure的发生。
部分同步(partial resynchronization )
这个特殊将会使用PSYNC 命令,注意该命令在2.8之后才支持PSYNC如果一个salve使用的是老的版本仅支持SYNC命令,那么将会用SYNC来同步
无磁盘的复制
通常一个同步需要在磁盘上创建一个RDB文件,然后再重新加载这个文件来进行与slave数据同步
由于磁盘的读写是非常慢的,这对于redis master是一个非常有压力的操作,在2.8.18之后的第一个版来尝试使用无磁盘的复制,在这个设置里了进程直接把RDB 发送到slaves,而不需要使用磁盘来做中间的存储。
需要注意的是 不过这个功能目前处于实验阶段,还未正式发布。
三  部署主从复制
环境 :
rac4 主库 10.0.2.8:6379
rac3 从库 10.0.2.6:6379
1 在两台机器上或者同一台机器起不同的端口,具体步骤请参考《redis 初探》
2 修改rac3 的redis.cnf 添加配置 ,指向rac4
  slaveof 10.0.2.8 6379 
  也可以在rac3上启动redis之后执行
  slaveof 10.0.2.8 6379 
  不过一旦slave重启之后 主从关系就消失了。建议在redis.cnf 配置
3 启动主库和从库
  /usr/local/bin/redis-server /etc/redis/redis.conf
至此 搭建一个以rac4为主库 ,rac3为从库的redis 复制系统。
四 应用案例
主库

  1. root@rac4:~# >redis-cli
  2. 127.0.0.1:6379> select 0
  3. OK
  4. 127.0.0.1:6379> set name yangyi
  5. OK
  6. 127.0.0.1:6379> get name
  7. "yangyi"
  8. 127.0.0.1:6379>
从库
  1. root@rac3:~# >redis-cli
  2. 127.0.0.1:6379> select 0
  3. OK
  4. 127.0.0.1:6379> get name
  5. "yangyi"
  6. 127.0.0.1:6379>
五 推荐文章
    文章篇幅和时间有限,本文并未完整的介绍Redis的高可用特性,后续研究之后会陆续补充完整。 推荐《 redis replication官方介绍》,留一个(小白的)问题 ,redis主从复制过程和持久化的方式之间有什么关系吗 ,基于rdb 或者 aof的持久化 对主从复制有什么影响? 
相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
目录
相关文章
|
11月前
|
存储 负载均衡 NoSQL
Redis之主从复制
【1月更文挑战第8天】主从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(masterleader),后者称为从节点(slave/follower);数据的复制是单向的,只能由主节点到从节点。Master以写为主,Slave以读为主。 默认情况下,每台Redis服务器都是主节点; 且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点。
244 13
|
11月前
|
NoSQL 关系型数据库 MySQL
Redis高可用之主从复制架构(第一部分)
Redis高可用之主从复制架构(第一部分)
|
11月前
|
监控 NoSQL 容灾
【Redis】主从复制
【Redis】主从复制
|
9月前
|
存储 缓存 NoSQL
Redis常见面试题(二):redis分布式锁、redisson、主从一致性、Redlock红锁;Redis集群、主从复制,哨兵模式,分片集群;Redis为什么这么快,I/O多路复用模型
redis分布式锁、redisson、可重入、主从一致性、WatchDog、Redlock红锁、zookeeper;Redis集群、主从复制,全量同步、增量同步;哨兵,分片集群,Redis为什么这么快,I/O多路复用模型——用户空间和内核空间、阻塞IO、非阻塞IO、IO多路复用,Redis网络模型
Redis常见面试题(二):redis分布式锁、redisson、主从一致性、Redlock红锁;Redis集群、主从复制,哨兵模式,分片集群;Redis为什么这么快,I/O多路复用模型
|
4月前
|
NoSQL 关系型数据库 Redis
《docker高级篇(大厂进阶):1.Docker复杂安装详说》包括:安装mysql主从复制、安装redis集群
《docker高级篇(大厂进阶):1.Docker复杂安装详说》包括:安装mysql主从复制、安装redis集群
167 14
|
11月前
|
存储 监控 负载均衡
redis 集群 (主从复制 哨兵模式 cluster)
redis 集群 (主从复制 哨兵模式 cluster)
|
6月前
|
存储 NoSQL 大数据
大数据-51 Redis 高可用方案CAP-AP 主从复制 一主一从 全量和增量同步 哨兵模式 docker-compose测试
大数据-51 Redis 高可用方案CAP-AP 主从复制 一主一从 全量和增量同步 哨兵模式 docker-compose测试
83 3
|
7月前
|
NoSQL 网络协议 Redis
Redis的主从复制和哨兵模式
本文详细介绍了Redis的主从复制配置、原理(包括全量复制和增量复制)以及如何搭建一主二从的Redis集群,同时还探讨了Redis哨兵模式的概念、配置文件、以及如何配置一主二从三哨兵的Redis哨兵模式,以实现高可用性。
|
8月前
|
消息中间件 存储 缓存
深入理解Redis集群主从复制原理
该文章主要探讨了Redis集群中的主从复制原理,包括为何需要主从复制、配置方法、复制流程以及一些高级特性。
深入理解Redis集群主从复制原理
|
9月前
|
NoSQL Redis
Redis 主从复制架构配置及原理
Redis 主从复制架构配置及原理
105 5