Redis复制之一主二从

是什么

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

img

能干嘛

  1. 读写分离
  2. 容灾恢复
  3. 数据备份
  4. 水平扩容支撑高并发

案例

基本命令

  1. info replication
    可以查看复制节点的主从关系和配置信息
  2. replicaof 主库IP 主库端口
    一般写入进redis.conf配置文件内
  3. slaveof 主库IP 主库端口
    每次与master断开之后,都需要重新连接,除非你配置进redis.conf文件
    在运行期间修改slave节点的信息,如果该数据库已经是某个主数据库的从数据库,那么会停止和原主数据库的同步关系转而和新的主数据库同步,重新拜码头
  4. slaveof no one
    使当前数据库停止与其他数据库的同步,转成主数据库,自立为王

架构说明

一个master两个salve:3台虚机,每台都安装redis,三边网络要相互ping通且注意防火墙配置
img

三大命令

  1. 主从复制
replicaof 主库IP 主库端口

配从(库)不配主(库)
2. 改换门庭

slaveof 新主库IP 新主库端口
  1. 自立为王
slaveof no one

案例1:一主二从

方案一:配置文件固定写死

配置文件细节操作

以redis6379.conf为例

  1. 开启 daemonize yes
daemonize yes
  1. 注释掉bind 127.0.0.1
# bind 127.0.0.1 ::1 
  1. protected-mode no
protected-mode no
  1. 指定端口
port 6379
  1. 指定当前工作目录,dir
dir /myredis
  1. pid文件名字,pidfile
pidfile /var/run/redis_6379.pid
  1. log文件名字,logfile
logfile "/myredis/6379.log"
  1. requirepass
requirepass 111111
  1. dump.rdb名字
dbfilename dump6379.rdb
  1. aof文件,appendfilename(本步骤可选,非必须)
appendonly yes
appendfilename "appendonly.aof"
  1. 从机访问主机的通行密码masterauth(从机设置即可,主机不需要设置)
replicaof 172.139.20.96 6379
masterauth 111111
  1. 启动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. 主从关系查看
    (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

  1. 测试,在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:命令操作手动指定

  1. 从机停机去掉配置文件中的配置项,3台目前都是主机状态,各不从属
# replicaof 172.139.20.96 6379
  1. 预设的从机上执行命令
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:薪火相传

img

上一个slave可以是下一个slave的master,slave同样可以接收其他slaves的连接和同步请求,那么该slave作为了链条中下一个的master,可以有效减轻主master的写压力
中途变更转向:会清除之前的数据,重新建立拷贝最新的

slaveof 新主库IP 新主库端口

案例3:反客为主

slaveof no one

复制原理和工作流程

  1. slave启动,同步初请
  • slave启动成功连接到master后会发送一个sync命令
  • slave首次全新连接master,一次完全同步(全量复制)将被自动执行,slave自身原有数据会被master数据覆盖清除
  1. 首次连接,全量复制
  • master节点收到sync命令后会开始在后台保存快照(即RDB持久化,主从复制时会触发RDB),master将rdb快照文件和所有缓存的命令发送到所有slave,以完成一次完全同步
  • 而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中,从而完成复制初始化
  1. 心跳持续,保持通信
    master发出PING包的周期,默认是10秒
  2. 进入平稳,增量复制
    master继续将新的所有收集到的修改命令自动依次传给slave,完成同步
  3. 从机下线,重连续传
    master会检查backlog里面的offset,master和slave都会保存一个复制的offset还有一个masterID,offset是保存在backlog中的。master只会把已经复制的offset后面的数据复制给slave,类似断点续传

复制的缺点

img

  1. 复制延时,信号衰减
    由于所有的写操作都是现在master上操作,然后同步更新到slave上,所以master同步到slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,slave机器数量的增加也会使这个问题更加严重
  2. master挂了,默认情况下,不会在slave节点中自动重选一个master,需要人工干预
posted @ 2025-03-07 16:15  小肚腩吖  阅读(12)  评论(0)    收藏  举报