杰霸霸博客

主题

Redis复制(replica) ​

Alt text

1. 介绍 ​

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

2. 用途 ​

读写分离、容灾恢复、数据备份、水平扩容支撑高并发

3. 主丛复制缺点 ​

  1. 复制有延时
    由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
  2. master挂掉导致不可用
    默认情况下，不会在slave节点中自动重选一个master，需要人工干预。

4. 主从复制流程 ​

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

5. 主从搭建 ​

5.1 搭建计划 ​

角色主从
机器mysql01mysql02

5.2 单机搭建 ​

按照redis单机安装笔记分别在mysql01、mysql02上搭建redis。

5.3 配置master ​

  1. 编辑redis.conf文件，添加如下内容：
ini
dbfilename dump_6379.rdb
appendonly yes
appendfilename "appendonly.aof"
appenddirname "data"
  1. 创建主从复制的用户 若主节点开启了ACL, 同步数据需要用户认证
sh
# 同步数据的用户不能是default
acl setuser replica_user on >123456 +info +replconf +psync +sync +ping +config|get ~* +@read
  1. 重启master

5.4 配置slave ​

  1. 编辑redis.conf文件，添加如下内容：
ini
dbfilename dump_6379.rdb
appendonly yes
appendfilename "appendonly.aof"
appenddirname "data"
replicaof 192.168.154.141 6379
masterauth 123456
masteruser replica_user
# 配置从节点只读
replica-read-only yes
  1. 重启slave,观察日志
sh
jack@mysql02:/opt/module/redis-7.2.4$ tail -f -n 300 logs/redis.log
94082:S 27 Apr 2025 18:13:21.758 * Connecting to MASTER 192.168.154.141:6379
94082:S 27 Apr 2025 18:13:21.758 * MASTER <-> REPLICA sync started
94082:S 27 Apr 2025 18:13:21.835 * Non blocking connect for SYNC fired the event.
94082:S 27 Apr 2025 18:13:21.839 * Master replied to PING, replication can continue...
94082:S 27 Apr 2025 18:13:21.842 * Partial resynchronization not possible (no cached master)
94082:S 27 Apr 2025 18:13:26.238 * Full resync from master: 9b2ed0f67ca311aebc1b8c58e5d20f3418a086cd:0
94082:S 27 Apr 2025 18:13:26.238 * MASTER <-> REPLICA sync: receiving streamed RDB from master with EOF to disk
94082:S 27 Apr 2025 18:13:26.252 * MASTER <-> REPLICA sync: Flushing old data
94082:S 27 Apr 2025 18:13:26.252 * MASTER <-> REPLICA sync: Loading DB in memory
94082:S 27 Apr 2025 18:13:26.278 * Loading RDB produced by version 7.2.4
94082:S 27 Apr 2025 18:13:26.278 * RDB age 0 seconds
94082:S 27 Apr 2025 18:13:26.278 * RDB memory usage when created 1.04 Mb
94082:S 27 Apr 2025 18:13:26.278 * Done loading RDB, keys loaded: 2, keys expired: 0.
94082:S 27 Apr 2025 18:13:26.278 * MASTER <-> REPLICA sync: Finished with success
94082:S 27 Apr 2025 18:13:26.278 * Creating AOF incr file temp-appendonly.aof.incr on background rewrite
94082:S 27 Apr 2025 18:13:26.278 * Background append only file rewriting started by pid 94923
94923:C 27 Apr 2025 18:13:26.295 * Successfully created the temporary AOF base file temp-rewriteaof-bg-94923.aof
94923:C 27 Apr 2025 18:13:26.295 * Fork CoW for AOF rewrite: current 0 MB, peak 0 MB, average 0 MB
94082:S 27 Apr 2025 18:13:26.379 * Background AOF rewrite terminated with success
94082:S 27 Apr 2025 18:13:26.379 * Successfully renamed the temporary AOF base file temp-rewriteaof-bg-94923.aof into appendonly.aof.3.base.rdb
94082:S 27 Apr 2025 18:13:26.379 * Successfully renamed the temporary AOF incr file temp-appendonly.aof.incr into appendonly.aof.3.incr.aof
94082:S 27 Apr 2025 18:13:26.411 * Removing the history file appendonly.aof.2.incr.aof in the background
94082:S 27 Apr 2025 18:13:26.411 * Removing the history file appendonly.aof.2.base.rdb in the background
94082:S 27 Apr 2025 18:13:26.445 * Background AOF rewrite finished successfully

可以看到数据先是全量再增量同步到slave数据库中。

5.5 测试主从 ​

在master上0号数据库操作，发现slave上0号数据库已经同步： Alt text

6. 命令配置方式 ​

6.1 修改同步信息 ​

除了在配置文件里设置，还能在运行时使用replicaof命令动态修改从节点的主节点信息。

sh
127.0.0.1:6379> replicaof 192.168.1.100 6379

需要注意的是命令方式只在当次有效，重启redis失效同步信息。

6.2 停止同步 ​

让当前实例不再作为从节点，停止同步数据

sh
127.0.0.1:6379> replicaof no one

7. 主从查看 ​

除了查看日志之外，还可以通过info replication命令查看

sh
127.0.0.1:6379> info replication
NOAUTH Authentication required.
127.0.0.1:6379> auth default 123456
OK
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.154.142,port=6379,state=online,offset=1708,lag=0
master_failover_state:no-failover
master_replid:9b2ed0f67ca311aebc1b8c58e5d20f3418a086cd
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1708
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1708
sh
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:192.168.154.141
master_port:6379
master_link_status:up
master_last_io_seconds_ago:6
master_sync_in_progress:0
slave_read_repl_offset:1540
slave_repl_offset:1540
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:9b2ed0f67ca311aebc1b8c58e5d20f3418a086cd
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1540
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1540

8. 主从同步要点 ​

  1. slave是从头开始复制还是从当前slave启动时间点开始复制? slave是从头开始复制，即使中途停掉，后续再重启也保持数据和master一致。
  2. master停掉后从机是上位还是原地待命？
    从机不动，原地待命，从机数据可以正常使用；等待主机重启动归来。
  3. master停掉后再启动，还是master吗？
    master重启后仍然是master, slave仍能正常同步数据。