05: redis master-slave replication

 

redis master-slave replication

 

 

 

 

principle:

1. sent from the server to the master SYNC command.

2. received the SYNC command master server calls BGSAVE command to create a RDB file, and use all the write command buffer recording executed next.

3. When the primary server after executing BGSAVE command, it sends to the server from the RDB file, the file will be received and loaded from the server.

4. All the write command stored in the buffer to the master server sent from the server to execute.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Detailed process:

 

 

 

 

Common master-slave architecture:

A plurality of master server from the server.

From the server can also have its own from the server.

Copy function does not block the main server.

 

 

 

From the master data consistency guarantees:

min-slaves-to-write 1

min-slaves-max-lag

 

 

Principle of operation of this feature:

A second frequency from the server to the PING master once, and report the case of copy processing flow.

Master server logs each time it is sent from the server to the last PING time.

 

Users can configure, specify the maximum network delay min-max-LAG-slaves ,

 

And performing a write operation is required at least from the number of servers min-to-Write-slaves .

 

如果至少有 min-slaves-to-write 个从服务器, 并且这些服务器的延迟值都少于 min-slaves-max-lag秒,

 

那么主服务器就会执行客户端请求的写操作。

 

你可以将这个特性看作 CAP 理论中的 C 的条件放宽版本: 尽管不能保证写操作的持久性,

但起码丢失数据的窗口会被严格限制在指定的秒数中。

 

另一方面, 如果条件达不到 min-slaves-to-write min-slaves-max-lag 所指定的条件, 那么写操作就不会被执行

主服务器会向请求执行写操作的客户端返回一个错误。

 

 

---------------------

主库是否要开启持久化?

如果不开有可能,主库重启操作,造成所有主从数据丢失!

 

主从服务器数据全部丢失的例子:

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

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

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

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

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

 

 

 

 

---------------------

主从复制实现:

 

1、环境:

准备两个或两个以上redis实例

 

mkdir /nosql/638{0..2}

 

配置文件示例:

vim   /nosql/6380/redis.conf

port 6380

daemonize yes

pidfile /nosql/6380/redis.pid

loglevel notice

logfile "/nosql/6380/redis.log"

dbfilename dump.rdb

dir /nosql/6380

protected-mode no

 

 

vim   /nosql/6381/redis.conf

port 6381

daemonize yes

pidfile /nosql/6381/redis.pid

loglevel notice

logfile "/nosql/6381/redis.log"

dbfilename dump.rdb

dir /nosql/6381

protected-mode no

 

 

 

vim   /nosql/6382/redis.conf

port 6382

daemonize yes

pidfile /nosql/6382/redis.pid

loglevel notice

logfile "/nosql/6382/redis.log"

dbfilename dump.rdb

dir /nosql/6382

protected-mode no

 

启动:

redis-server /nosql/6380/redis.conf

redis-server /nosql/6381/redis.conf

redis-server /nosql/6382/redis.conf

 

 

主节点:6380

从节点:63816382

 

 

2、开启主从:

6381/6382命令行:

 

redis-cli -p 6381

SLAVEOF 127.0.0.1 6380

 

redis-cli -p 6382

SLAVEOF 127.0.0.1 6380

 

 

3、查询主从状态

 

从库:

127.0.0.1:6382> info replication

 

主库:

127.0.0.1:6380> info replication

 

 

4、从库切为主库

 

模拟主库故障

 

redis-cli -p 6380

shutdown

 

redis-cli -p 6381

info replication

slaveof no one

 

 

 

6382连接到6381

[root@db03 ~]# redis-cli -p 6382

127.0.0.1:6382> SLAVEOF no one

127.0.0.1:6382> SLAVEOF 127.0.0.1 6381

 

Guess you like

Origin www.cnblogs.com/jim-xu/p/11671637.html