redis主从复制

redis主从复制

一、redis主从复制介绍

1.Redis复制功能简单介绍

1）使用异步复制。
2）一个主服务器可以有多个从服务器。
3）从服务器也可以有自己的从服务器。
4）复制功能不会阻塞主服务器。
5）可以通过复制功能来让主服务器免于执行持久化操作，由从服务器去执行持久化操作即可。

2.Redis复制功能介绍（重点了解）

1）Redis 使用异步复制。从 Redis2.8开始，从服务器会以每秒一次的频率向主服务器报告复制流（replication stream）的处理进度。

2）一个主服务器可以有多个从服务器。

3）不仅主服务器可以有从服务器，从服务器也可以有自己的从服务器，多个从服务器之间可以构成一个图状结构。

4）复制功能不会阻塞主服务器：即使有一个或多个从服务器正在进行初次同步， 主服务器也可以继续处理命令请求。

5）复制功能也不会阻塞从服务器：只要在 redis.conf 文件中进行了相应的设置， 即使从服务器正在进行初次同步， 服务器也可以使用旧版本的数据集来处理命令查询。

6）在从服务器删除旧版本数据集并载入新版本数据集的那段时间内，连接请求会被阻塞。

7）还可以配置从服务器，让它在与主服务器之间的连接断开时，向客户端发送一个错误。

8）复制功能可以单纯地用于数据冗余（data redundancy），也可以通过让多个从服务器处理只读命令请求来提升扩展性（scalability）： 比如说，繁重的SORT命令可以交给附属节点去运行。

9）可以通过复制功能来让主服务器免于执行持久化操作：只要关闭主服务器的持久化功能，然后由从服务器去执行持久化操作即可。

3.关闭主服务器持久化时，复制功能的数据安全

1.当配置Redis复制功能时，强烈建议打开主服务器的持久化功能。 否则的话，由于延迟等问题，部署的服务应该要避免自动拉起。

2.为了帮助理解主服务器关闭持久化时自动拉起的危险性，参考一下以下会导致主从服务器数据全部丢失的例子：

1）假设节点A为主服务器，并且关闭了持久化。并且节点B和节点C从节点A复制数据

2）节点A崩溃，然后由自动拉起服务重启了节点A. 由于节点A的持久化被关闭了，所以重启之后没有任何数据

3）节点B和节点C将从节点A复制数据，但是A的数据是空的，于是就把自身保存的数据副本删除。

结论：

1）在关闭主服务器上的持久化，并同时开启自动拉起进程的情况下，即便使用Sentinel来实现Redis的高可用性，也是非常危险的。因为主服务器可能拉起得非常快，以至于Sentinel在配置的心跳时间间隔内没有检测到主服务器已被重启，然后还是会执行上面的数据丢失的流程。

2）无论何时，数据安全都是极其重要的，所以应该禁止主服务器关闭持久化的同时自动拉起。

二、主从复制原理

1. 副本库通过slaveof 10.0.0.51 6379命令,连接主库,并发送SYNC给主库 
2. 主库收到SYNC,会立即触发BGSAVE,后台保存RDB,发送给副本库
3. 副本库接收后会应用RDB快照
4. 主库会陆续将中间产生的新的操作,保存并发送给副本库
5. 到此,我们主复制集就正常工作了
6. 再此以后,主库只要发生新的操作,都会以命令传播的形式自动发送给副本库.
7. 所有复制相关信息,从info信息中都可以查到.即使重启任何节点,他的主从关系依然都在.
8. 如果发生主从关系断开时,从库数据没有任何损坏,在下次重连之后,从库发送PSYNC给主库
9. 主库只会将从库缺失部分的数据同步给从库应用,达到快速恢复主从的目的

三、Redis主从复制早期工作机制

1.sync命令执行图

2.sync断线重连图

如果我们仔细地观察整个断线并重连的过程，就会发现：
从服务器在断线之前已经拥有主服务器的绝大部分数据，要让主从服务器重新回到一致状态，从服务器真正需要的是 k10087、k10088和k10089这三个键的数据，而不是主服务器整个数据库的数据。SYNC 命令在处理断线并重连时的做法——将主服务器的整个数据库重新同步给从服务器，是极度浪费的！

3.SYNC与PSYNC

1）在 Redis2.8版本之前，断线之后重连的从服务器总要执行一次完整重同步（fullresynchronization）操作。

2）从 Redis2.8开始，Redis使用PSYNC命令代替SYNC命令。

3）PSYNC比起SYNC的最大改进在于PSYNC实现了部分重同步（partial resync）特性：
在主从服务器断线并且重新连接的时候，只要条件允许，PSYNC可以让主服务器只向从服务器同步断线期间缺失的数据，而不用重新向从服务器同步整个数据库。

注：
PSYNC这个特性需要主服务器为被发送的复制流创建一个内存缓冲区（in-memory backlog）， 并且主服务器和所有从服务器之间都记录一个复制偏移量（replication offset）和一个主服务器 ID（master run id），当出现网络连接断开时，从服务器会重新连接，并且向主服务器请求继续执行原来的复制进程：

1）如果从服务器记录的主服务器ID和当前要连接的主服务器的ID相同，并且从服务器记录的偏移量所指定的数据仍然保存在主服务器的复制流缓冲区里面，那么主服务器会向从服务器发送断线时缺失的那部分数据，然后复制工作可以继续执行。

2）否则的话，从服务器就要执行完整重同步操作。

4.psync处理断线重连图

1）PSYNC只会将从服务器断线期间缺失的数据发送给从服务器。两个例子的情况是相同的，但SYNC 需要发送包含整个数据库的 RDB 文件，而PSYNC 只需要发送三个命令。

2）如果主从服务器所处的网络环境并不那么好的话（经常断线），那么请尽量使用 Redis 2.8 或以上版本：通过使用 PSYNC 而不是 SYNC 来处理断线重连接，可以避免因为重复创建和传输 RDB文件而浪费大量的网络资源、计算资源和内存资源。

四、复制的一致性问题

1）在读写分离环境下，客户端向主服务器发送写命令 SET k10086 v10086，主服务器在执行这个写命令之后，向客户端返回回复，并将这个写命令传播给从服务器。

2）接到回复的客户端继续向从服务器发送读命令 GET k10086 ，并且因为网络状态的原因，客户端的 GET命令比主服务器传播的 SET 命令更快到达了从服务器。

3）因为从服务器键k10086的值还未被更新，所以客户端在从服务器读取到的将是一个错误（过期）的k10086值。

Redis是怎么保证数据安全的呢？

1）主服务器只在有至少N个从服务器的情况下，才执行写操作

2）从Redis 2.8开始，为了保证数据的安全性，可以通过配置，让主服务器只在有至少N个当前已连接从服务器的情况下，才执行写命令。

3）不过，因为 Redis 使用异步复制，所以主服务器发送的写数据并不一定会被从服务器接收到，因此， 数据丢失的可能性仍然是存在的。

4）通过以下两个参数保证数据的安全：

#执行写操作所需的至少从服务器数量
min-slaves-to-write <number of slaves>
#指定网络延迟的最大值
min-slaves-max-lag <number of seconds>

这个特性的运作原理：

1）从服务器以每秒一次的频率 PING 主服务器一次， 并报告复制流的处理情况。主服务器会记录各个从服务器最后一次向它发送 PING 的时间。用户可以通过配置， 指定网络延迟的最大值 min-slaves-max-lag ， 以及执行写操作所需的至少从服务器数量 min-slaves-to-write 。

2）如果至少有 min-slaves-to-write 个从服务器， 并且这些服务器的延迟值都少于 min-slaves-max-lag 秒， 那么主服务器就会执行客户端请求的写操作。你可以将这个特性看作 CAP 理论中的 C 的条件放宽版本： 尽管不能保证写操作的持久性， 但起码丢失数据的窗口会被严格限制在指定的秒数中。

3）另一方面， 如果条件达不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的条件， 那么写操作就不会被执行， 主服务器会向请求执行写操作的客户端返回一个错误。

五、主从复制实战

1.准备从库并开启redis

[root@db01 /opt]# scp redis-3.2.9.tar.gz 10.0.0.52:/opt/

[root@db02 ~]# mkdir /data/redis_6379/ 

[root@db02 ~]# mkdir -p /data/soft
[root@db02 ~]# mkdir -p /opt/redis_6379/{conf,pid,logs}

[root@db02 ~]# yum install gcc -y

[root@db02 ~]# tar zxf redis-3.2.9.tar.gz -C /opt/
[root@db02 ~]# ln -s /opt/redis-3.2.9/ /opt/redis
[root@db02 ~]# cd /opt/redis
[root@db02 ~]# make && make install

[root@db02 ~]# cat /opt/redis_6379/conf/redis_6379.conf 
#以守护进程模式启动
daemonize yes
#绑定的主机地址
bind 127.0.0.1 10.0.0.52
#监听端口
port 6379
#pid文件和log文件的保存地址
pidfile /opt/redis_6379/pid/redis_6379.pid
logfile /opt/redis_6379/logs/redis_6379.log
#本地数据库的目录
dir /data/redis_6379
#指定本地持久化文件的文件名,默认是dump.rdb
dbfilename redis_6379.rdb

save 900 1
save 300 10
save 60 10000

appendfilename "redis_6379.aof"
appendonly yes
appendfsync everysec


[root@db02 ~]# redis-server /opt/redis_6379/conf/redis_6379.conf
[root@db02 ~]# netstat -lntp|grep redis
tcp        0      0 10.0.0.52:6379          0.0.0.0:*               LISTEN      5000/redis-server 1 
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      5000/redis-server 1 

2.开启主从

# 方法1: 临时生效
[root@db-02 ~]# redis-cli
127.0.0.1:6379> SLAVEOF 10.0.0.51 6379

# 方法2: 写入配置文件
[root@db02 ~]# vim /opt/redis_6379/conf/redis_6379.conf
SLAVEOF 10.0.0.51 6379
masterauth 123456

[root@db01 ~]# redis-cli -a 123456
127.0.0.1:6379> keys *
1) "k1"
2) "k4"
3) "k3"
4) "k2"
5) "k5"

[root@db02 ~]# redis-server /opt/redis_6379/conf/redis_6379.conf
[root@db02 ~]# redis-cli
127.0.0.1:6379> auth 123456
127.0.0.1:6379> SET k1 v1
(error) READONLY You can't write against a read only slave.
127.0.0.1:6379> keys *
1) "k2"
2) "k5"
3) "k3"
4) "k4"
5) "k1"

[root@db02 ~]# ll /data/redis_6379/
-rw-r--r-- 1 root root 166 Dec 27 10:34 redis_6379.aof
-rw-r--r-- 1 root root 114 Dec 27 10:34 redis_6379.rdb

3.查看主从状态

db01:
127.0.0.1:6379> info replication
#Replication
role:master
connected_slaves:1
slave0:ip=10.0.0.52,port=6379,state=online,offset=407,lag=0
master_repl_offset:407
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:406


db02:
127.0.0.1:6379> info replication
#Replication
role:slave
master_host:10.0.0.51
master_port:6379
master_link_status:up
master_last_io_seconds_ago:6
master_sync_in_progress:0
slave_repl_offset:477
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

4.切换主从

# 1.停主库
db01:
127.0.0.1:6379> shutdown


# 2.从库查看状态
db02:
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:10.0.0.51
master_port:6379
master_link_status:down     #连接主库的状态是：down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:3263
master_link_down_since_seconds:24
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0


# 3.从库取消主从关系
127.0.0.1:6379> SLAVEOF no one
127.0.0.1:6379> info replication
# Replication
role:master      #此时从库的角色就变成了master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0


# 4.其他库重新指向主

注意!!!

# 1.从节点只读不可写
10.0.0.52:6379> set k1 v1
(error) READONLY You can't write against a read only slave.

# 2.从节点不会自动故障转移,它会一直同步主

# 3.主从复制故障转移需要人工介入
- 修改代码指向REDIS的IP地址
- 从节点需要执行SLAVEOF no one

注意!!!

# 1.从节点会清空自己原有的数据,如果同步的对象写错了,就会导致数据丢失

# 安全的操作:
- 无论是同步,无论是主节点还是从节点
- 先备份一下数据