Redis的复制(Master/Slave)
Posted 开心ever
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Redis的复制(Master/Slave)相关的知识,希望对你有一定的参考价值。
是什么
复制
在 Redis 复制的基础上,使用和配置主从复制非常简单,能使得从 Redis 服务器(下文称 slave)能精确得复制主 Redis 服务器(下文称 master)的内容。每次当 slave 和 master 之间的连接断开时, slave 会自动重连到 master 上,并且无论这期间 master 发生了什么, slave 都将尝试让自身成为 master 的精确副本。
这个系统的运行依靠三个主要的机制:
-
当一个 master 实例和一个 slave 实例连接正常时, master 会发送一连串的命令流来保持对 slave 的更新,以便于将自身数据集的改变复制给 slave , :包括客户端的写入、key 的过期或被逐出等等。
-
当 master 和 slave 之间的连接断开之后,因为网络问题、或者是主从意识到连接超时, slave 重新连接上 master 并会尝试进行部分重同步:这意味着它会尝试只获取在断开连接期间内丢失的命令流。
-
当无法进行部分重同步时, slave 会请求进行全量重同步。这会涉及到一个更复杂的过程,例如 master 需要创建所有数据的快照,将之发送给 slave ,之后在数据集更改时持续发送命令流到 slave 。
Redis使用默认的异步复制,其特点是低延迟和高性能,是绝大多数 Redis 用例的自然复制模式。但是,从 Redis 服务器会异步地确认其从主 Redis 服务器周期接收到的数据量。
客户端可以使用 WAIT 命令来请求同步复制某些特定的数据。但是,WAIT 命令只能确保在其他 Redis 实例中有指定数量的已确认的副本:在故障转移期间,由于不同原因的故障转移或是由于 Redis 持久性的实际配置,故障转移期间确认的写入操作可能仍然会丢失。你可以查看 Sentinel 或 Redis 集群文档,了解关于高可用性和故障转移的更多信息。本文的其余部分主要描述 Redis 基本复制功能的基本特性。
接下来的是一些关于 Redis 复制的非常重要的事实:
-
Redis 使用异步复制,slave 和 master 之间异步地确认处理的数据量
-
一个 master 可以拥有多个 slave
-
slave 可以接受其他 slave 的连接。除了多个 slave 可以连接到同一个 master 之外, slave 之间也可以像层叠状的结构(cascading-like structure)连接到其他 slave 。自 Redis 4.0 起,所有的 sub-slave 将会从 master 收到完全一样的复制流。
-
Redis 复制在 master 侧是非阻塞的。这意味着 master 在一个或多个 slave 进行初次同步或者是部分重同步时,可以继续处理查询请求。
-
复制在 slave 侧大部分也是非阻塞的。当 slave 进行初次同步时,它可以使用旧数据集处理查询请求,假设你在 redis.conf 中配置了让 Redis 这样做的话。否则,你可以配置如果复制流断开, Redis slave 会返回一个 error 给客户端。但是,在初次同步之后,旧数据集必须被删除,同时加载新的数据集。 slave 在这个短暂的时间窗口内(如果数据集很大,会持续较长时间),会阻塞到来的连接请求。自 Redis 4.0 开始,可以配置 Redis 使删除旧数据集的操作在另一个不同的线程中进行,但是,加载新数据集的操作依然需要在主线程中进行并且会阻塞 slave 。
-
复制既可以被用在可伸缩性,以便只读查询可以有多个 slave 进行(例如 O(N) 复杂度的慢操作可以被下放到 slave ),或者仅用于数据安全。
-
可以使用复制来避免 master 将全部数据集写入磁盘造成的开销:一种典型的技术是配置你的 master Redis.conf 以避免对磁盘进行持久化,然后连接一个 slave ,其配置为不定期保存或是启用 AOF。但是,这个设置必须小心处理,因为重新启动的 master 程序将从一个空数据集开始:如果一个 slave 试图与它同步,那么这个 slave 也会被清空。
以上摘自官网
行话:也就是我们所说的主从复制,主机数据更新后根据配置和策略,自动同步到备机的master/slaver机制,Master以写为主,Slave以读为主
能干嘛
- 读写分离
- 容灾恢复
操作/案例
-
配从(库)不配主(库)
-
从库配置:slaveof 主库IP 主库端口
- 每次与master断开之后,都需要重新连接,除非你配置进redis.conf文件
- Info replication
-
修改配置文件细节操作
- 拷贝多个redis.conf文件
[root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# ls -l total 272 -rw-rw-r-- 1 root root 106874 May 16 2019 00-RELEASENOTES -rw-rw-r-- 1 root root 53 May 16 2019 BUGS -rw-rw-r-- 1 root root 2381 May 16 2019 CONTRIBUTING -rw-rw-r-- 1 root root 1487 May 16 2019 COPYING drwxrwxr-x 6 root root 4096 Jul 10 16:30 deps -rw-r--r-- 1 root root 162 Jul 14 15:50 dump.rdb -rw-rw-r-- 1 root root 11 May 16 2019 INSTALL -rw-rw-r-- 1 root root 151 May 16 2019 Makefile -rw-rw-r-- 1 root root 6888 May 16 2019 MANIFESTO -rw-rw-r-- 1 root root 20555 May 16 2019 README.md -rw-rw-r-- 1 root root 61797 May 16 2019 redis.conf -rwxrwxr-x 1 root root 275 May 16 2019 runtest -rwxrwxr-x 1 root root 280 May 16 2019 runtest-cluster -rwxrwxr-x 1 root root 341 May 16 2019 runtest-moduleapi -rwxrwxr-x 1 root root 281 May 16 2019 runtest-sentinel -rw-rw-r-- 1 root root 9710 May 16 2019 sentinel.conf drwxrwxr-x 3 root root 4096 Jul 10 16:31 src drwxrwxr-x 11 root root 4096 May 16 2019 tests drwxrwxr-x 8 root root 4096 May 16 2019 utils [root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# pwd /root/redis-5.0.5 [root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# cp redis.conf /r root/ run/ [root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# cp redis.conf /root/re readme.txt redis-5.0.5/ redis-5.0.5.tar.gz [root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# cp redis.conf /root/re readme.txt redis-5.0.5/ redis-5.0.5.tar.gz [root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# cp redis.conf /root/redis-5.0.5/redis6379.conf [root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# cp redis.conf /root/redis-5.0.5/redis6380.conf [root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# cp redis.conf /root/redis-5.0.5/redis6381.conf [root@izuf6hmkcpexishpa3id8xz redis-5.0.5]# ls -l total 464 -rw-rw-r-- 1 root root 106874 May 16 2019 00-RELEASENOTES -rw-rw-r-- 1 root root 53 May 16 2019 BUGS -rw-rw-r-- 1 root root 2381 May 16 2019 CONTRIBUTING -rw-rw-r-- 1 root root 1487 May 16 2019 COPYING drwxrwxr-x 6 root root 4096 Jul 10 16:30 deps -rw-r--r-- 1 root root 162 Jul 14 15:50 dump.rdb -rw-rw-r-- 1 root root 11 May 16 2019 INSTALL -rw-rw-r-- 1 root root 151 May 16 2019 Makefile -rw-rw-r-- 1 root root 6888 May 16 2019 MANIFESTO -rw-rw-r-- 1 root root 20555 May 16 2019 README.md -rw-r--r-- 1 root root 61797 Jul 14 16:39 redis6379.conf -rw-r--r-- 1 root root 61797 Jul 14 16:40 redis6380.conf -rw-r--r-- 1 root root 61797 Jul 14 16:40 redis6381.conf -rw-rw-r-- 1 root root 61797 May 16 2019 redis.conf -rwxrwxr-x 1 root root 275 May 16 2019 runtest -rwxrwxr-x 1 root root 280 May 16 2019 runtest-cluster -rwxrwxr-x 1 root root 341 May 16 2019 runtest-moduleapi -rwxrwxr-x 1 root root 281 May 16 2019 runtest-sentinel -rw-rw-r-- 1 root root 9710 May 16 2019 sentinel.conf drwxrwxr-x 3 root root 4096 Jul 10 16:31 src drwxrwxr-x 11 root root 4096 May 16 2019 tests drwxrwxr-x 8 root root 4096 May 16 2019 utils [root@izuf6hmkcpexishpa3id8xz redis-5.0.5]#
-
- 开启daemonize yes
-
- Pid文件名字
- 指定端口
- Log文件名字
-
- Dump.rdb名字
-
常用3招
- 一主二仆
- Init
2.一个Master两个Slave
3.日志查看
主机日志
备机日志
info replication
4.主从问题演示
1 切入点问题?slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来,那之前的123是否也可以复制 2 从机是否可以写?set可否? 3 主机shutdown后情况如何?从机是上位还是原地待命 4 主机又回来了后,主机新增记录,从机还能否顺利复制? 5 其中一台从机down后情况如何?依照原有它能跟上大部队吗?
-
- 薪火相传
-
上一个Slave可以是下一个slave的Master,Slave同样可以接收其他
slaves的连接和同步请求,那么该slave作为了链条中下一个的master,
可以有效减轻master的写压力 - 中途变更转向:会清除之前的数据,重新建立拷贝最新的
- Slaveof 新主库IP 新主库端口
-
- 反客为主(SLAVEOF no one)
- 使当前数据库停止与其他数据库的同步,转成主数据库
- 薪火相传
-
复制原理
- Slave启动成功连接到master后会发送一个sync命令
-
Master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,
在后台进程执行完毕之后,master将传送整个数据文件到slave,以完成一次完全同步 - 全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
- 增量复制:Master继续将新的所有收集到的修改命令依次传给slave,完成同步
- 但是只要是重新连接master,一次完全同步(全量复制)将被自动执行
-
哨兵模式(sentinel)
- 是什么
- 反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库
- 使用步骤
- 调整结构,6379带着80、81
- 自定义的/myredis目录下新建sentinel.conf文件,名字绝不能错
- 配置哨兵,填写内容
- 是什么
1. sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1
2.上面最后一个数字1,表示主机挂掉后salve投票看让谁接替成为主机,得票数多少后成为主机
-
-
- 启动哨兵
-
1.Redis-sentinel /myredis/sentinel.conf
2.上述目录依照各自的实际情况配置,可能目录不同
-
-
- 原有的master挂了
-
-
-
- 投票新选
-
-
-
- 重新主从继续开工,info replication查查看
-
-
-
- 问题:如果之前的master重启回来,会不会
-
-
-
- 一组sentinel能同时监控多个Master
-
复制的缺点
-
-
- 复制延时
-
1.由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重。
以上是关于Redis的复制(Master/Slave)的主要内容,如果未能解决你的问题,请参考以下文章
try redis -- master -slave 主从复制