【Redis】Redis 主从复制之一

  1. 云栖社区>
  2. 博客>
  3. 正文

【Redis】Redis 主从复制之一

yangyi_dba 2016-05-25 00:28:41 浏览860
展开阅读全文
前言
  和关系型数据库一样,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的持久化 对主从复制有什么影响? 

网友评论

登录后评论
0/500
评论
yangyi_dba
+ 关注