Redis复制之一主二从
是什么
就是主从复制,master以写为主,slave以读为主
当master数据变化的时候,自动将新的数据异步同步到其它slave数据库

能干嘛
- 读写分离
- 容灾恢复
- 数据备份
- 水平扩容支撑高并发
案例
基本命令
- info replication
可以查看复制节点的主从关系和配置信息 - replicaof 主库IP 主库端口
一般写入进redis.conf配置文件内 - slaveof 主库IP 主库端口
每次与master断开之后,都需要重新连接,除非你配置进redis.conf文件
在运行期间修改slave节点的信息,如果该数据库已经是某个主数据库的从数据库,那么会停止和原主数据库的同步关系转而和新的主数据库同步,重新拜码头 - slaveof no one
使当前数据库停止与其他数据库的同步,转成主数据库,自立为王
架构说明
一个master两个salve:3台虚机,每台都安装redis,三边网络要相互ping通且注意防火墙配置

三大命令
- 主从复制
replicaof 主库IP 主库端口
配从(库)不配主(库)
2. 改换门庭
slaveof 新主库IP 新主库端口
- 自立为王
slaveof no one
案例1:一主二从
方案一:配置文件固定写死
配置文件细节操作
以redis6379.conf为例
- 开启 daemonize yes
daemonize yes
- 注释掉bind 127.0.0.1
# bind 127.0.0.1 ::1
- protected-mode no
protected-mode no
- 指定端口
port 6379
- 指定当前工作目录,dir
dir /myredis
- pid文件名字,pidfile
pidfile /var/run/redis_6379.pid
- log文件名字,logfile
logfile "/myredis/6379.log"
- requirepass
requirepass 111111
- dump.rdb名字
dbfilename dump6379.rdb
- aof文件,appendfilename(本步骤可选,非必须)
appendonly yes
appendfilename "appendonly.aof"
- 从机访问主机的通行密码masterauth(从机设置即可,主机不需要设置)
replicaof 172.139.20.96 6379
masterauth 111111
- 启动Redis,先启动master再启动slave
- master
[ops@master2 ~]$ redis-server /myredis/redis6379.conf
[ops@master2 ~]$ redis-cli -a 111111
- slave1
[ops@slave1 ~]$ redis-server /myredis/redis6380.conf
[ops@slave1 ~]$ redis-cli -a 111111 -p 6380
- slave2
[ops@slave2 ~]$ redis-server /myredis/redis6381.conf
[ops@slave2 ~]$ redis-cli -a 111111 -p 6381
- 主从关系查看
(1)日志
- 主机日志
[ops@master2 /myredis]$ tail 6379.log
5456:M 18 Mar 2025 10:04:32.105 * Replica 172.139.20.115:6381 asks for synchronization
5456:M 18 Mar 2025 10:04:32.106 * Full resync requested by replica 172.139.20.115:6381
5456:M 18 Mar 2025 10:04:32.106 * Delay next BGSAVE for diskless SYNC
5456:M 18 Mar 2025 10:04:37.914 * Starting BGSAVE for SYNC with target: replicas sockets
5456:M 18 Mar 2025 10:04:37.915 * Background RDB transfer started by pid 6769
6769:C 18 Mar 2025 10:04:37.919 * Fork CoW for RDB: current 2 MB, peak 2 MB, average 2 MB
5456:M 18 Mar 2025 10:04:37.919 # Diskless rdb transfer, done reading from pipe, 1 replicas still up.
5456:M 18 Mar 2025 10:04:37.930 * Background RDB transfer terminated with success
5456:M 18 Mar 2025 10:04:37.930 * Streamed RDB transfer with replica 172.139.20.115:6381 succeeded (socket). Waiting for REPLCONF ACK from slave to enable streaming
5456:M 18 Mar 2025 10:04:37.930 * Synchronization with replica 172.139.20.115:6381 succeeded
- 备机日志
slave1
[ops@slave1 /myredis]$ tail 6380.log
1037:S 18 Mar 2025 10:03:41.604 * RDB memory usage when created 0.65 Mb
1037:S 18 Mar 2025 10:03:41.604 * Done loading RDB, keys loaded: 0, keys expired: 0.
1037:S 18 Mar 2025 10:03:41.604 * MASTER <-> REPLICA sync: Finished with success
1037:S 18 Mar 2025 10:03:41.606 * Background append only file rewriting started by pid 1042
1042:C 18 Mar 2025 10:03:41.614 * SYNC append only file rewrite performed
1042:C 18 Mar 2025 10:03:41.615 * Fork CoW for AOF rewrite: current 4 MB, peak 4 MB, average 4 MB
1037:S 18 Mar 2025 10:03:41.628 * Background AOF rewrite terminated with success
1037:S 18 Mar 2025 10:03:41.633 * Removing the history file appendonly.aof.3.incr.aof in the background
1037:S 18 Mar 2025 10:03:41.633 * Removing the history file appendonly.aof.3.base.rdb in the background
1037:S 18 Mar 2025 10:03:41.637 * Background AOF rewrite finished successfully
slave2
[ops@slave2 /myredis]$ tail 6381.log
1130:S 18 Mar 2025 10:04:37.928 * RDB memory usage when created 0.69 Mb
1130:S 18 Mar 2025 10:04:37.928 * Done loading RDB, keys loaded: 0, keys expired: 0.
1130:S 18 Mar 2025 10:04:37.928 * MASTER <-> REPLICA sync: Finished with success
1130:S 18 Mar 2025 10:04:37.929 * Background append only file rewriting started by pid 1135
1135:C 18 Mar 2025 10:04:37.937 * SYNC append only file rewrite performed
1135:C 18 Mar 2025 10:04:37.938 * Fork CoW for AOF rewrite: current 4 MB, peak 4 MB, average 4 MB
1130:S 18 Mar 2025 10:04:38.036 * Background AOF rewrite terminated with success
1130:S 18 Mar 2025 10:04:38.043 * Removing the history file appendonly.aof.3.incr.aof in the background
1130:S 18 Mar 2025 10:04:38.043 * Removing the history file appendonly.aof.3.base.rdb in the background
1130:S 18 Mar 2025 10:04:38.048 * Background AOF rewrite finished successfully
(2)命令
info replication
master
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=172.139.20.119,port=6380,state=online,offset=2058,lag=1
slave1:ip=172.139.20.115,port=6381,state=online,offset=2058,lag=0
master_failover_state:no-failover
master_replid:f7056ecedaf0bbdfda2815942432e3c940169b9f
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:2058
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:2058
slave1
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:172.139.20.96
master_port:6379
master_link_status:up
master_last_io_seconds_ago:5
master_sync_in_progress:0
slave_read_repl_offset:2128
slave_repl_offset:2128
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:f7056ecedaf0bbdfda2815942432e3c940169b9f
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:2128
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:2128
slave2
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:172.139.20.96
master_port:6379
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_read_repl_offset:2422
slave_repl_offset:2422
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:f7056ecedaf0bbdfda2815942432e3c940169b9f
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:2422
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:85
repl_backlog_histlen:2338
- 测试,在mater写入数据,在slave看
- master
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> get k1
"v1"
- slave1
127.0.0.1:6380> get k1
"v1"
- slave2
127.0.0.1:6381> get k1
"v1"
方案2:命令操作手动指定
- 从机停机去掉配置文件中的配置项,3台目前都是主机状态,各不从属
# replicaof 172.139.20.96 6379
- 预设的从机上执行命令
slaveof 主库IP 主库端口
127.0.0.1:6380> slaveof 172.139.20.96 6379
OK
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:172.139.20.96
master_port:6379
案例2:薪火相传

上一个slave可以是下一个slave的master,slave同样可以接收其他slaves的连接和同步请求,那么该slave作为了链条中下一个的master,可以有效减轻主master的写压力
中途变更转向:会清除之前的数据,重新建立拷贝最新的
slaveof 新主库IP 新主库端口
案例3:反客为主
slaveof no one
复制原理和工作流程
- slave启动,同步初请
- slave启动成功连接到master后会发送一个sync命令
- slave首次全新连接master,一次完全同步(全量复制)将被自动执行,slave自身原有数据会被master数据覆盖清除
- 首次连接,全量复制
- master节点收到sync命令后会开始在后台保存快照(即RDB持久化,主从复制时会触发RDB),master将rdb快照文件和所有缓存的命令发送到所有slave,以完成一次完全同步
- 而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中,从而完成复制初始化
- 心跳持续,保持通信
master发出PING包的周期,默认是10秒 - 进入平稳,增量复制
master继续将新的所有收集到的修改命令自动依次传给slave,完成同步 - 从机下线,重连续传
master会检查backlog里面的offset,master和slave都会保存一个复制的offset还有一个masterID,offset是保存在backlog中的。master只会把已经复制的offset后面的数据复制给slave,类似断点续传
复制的缺点

- 复制延时,信号衰减
由于所有的写操作都是现在master上操作,然后同步更新到slave上,所以master同步到slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,slave机器数量的增加也会使这个问题更加严重 - master挂了,默认情况下,不会在slave节点中自动重选一个master,需要人工干预

浙公网安备 33010602011771号