Redis第1️⃣8️⃣课 主从复制原理及优化
2019-05-15 本文已影响2人
小超_8b2f
一、什么是主从复制
1. 单机有什么问题❓
1）机器故障
2）内存容量瓶颈
3）QPS瓶颈
（1 是高可用问题，2、3 是分布式问题，本节主要讲高可用问题）
2. 主从复制的作用
1）数据副本
2） 扩展读性能
3. 简单总结
1）一个master可以有多个slave
2）一个slave只能有1个master
3） 数据流向是单向的，master到slave
一主多从，读写分离，流量分流
二、主从复制配置
方式一：从节点执行slaveof命令
- 老版本命令
slaveof host port #从主节点上复制
slaveof no one # 老子不想成为任何人的从节点了。
- 新版本命令
#起始版本：5.0.0
replicaof host port
replicaof no one
方式二：修改从节点配置文件(从节点中配置)
1）老版本配置文件：
slaveof ip port
slave-read-only yes
2）新版本配置文件：
replicaof <masterip> <masterport>
masterauth <master-password>
replica-serve-stale-data yes
replica-read-only yes
repl-diskless-sync no
repl-timeout 60
太无奈！Redis 作者被迫修改 master-slave 架构的描述
方式一 VS 方式二
| 方式 | 优点 | 缺点 |
|---|---|---|
| 命令 | 无需重启 | 不便于管理 |
| 配置 | 统一配置 | 需要重启 |
相关操作
3）主节点查看主从信息：
127.0.0.1:6379> info Replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=353,lag=1
master_replid:e6bef3844d495a0574691d7993fd25311836f53a
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:353 #主节点偏移量
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:353
4）从节点查看主从信息：
localhost:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:521
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:e6bef3844d495a0574691d7993fd25311836f53a
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:521 ##从节点偏移量（）
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:521
localhost:6380>
5）主节点被从节点同步的log文件记录：
675:M 16 May 2019 09:24:51.898 # Server initialized
675:M 16 May 2019 09:24:51.899 * Reading RDB preamble from AOF file...
675:M 16 May 2019 09:24:51.900 * Reading the remaining AOF tail...
675:M 16 May 2019 09:24:51.900 * DB loaded from append only file: 0.001 seconds
675:M 16 May 2019 09:24:51.901 * Ready to accept connections
675:M 16 May 2019 09:26:33.537 * Replica 127.0.0.1:6380 asks for synchronization ###
675:M 16 May 2019 09:26:33.537 * Full resync requested by replica 127.0.0.1:6380 ###
675:M 16 May 2019 09:26:33.538 * Starting BGSAVE for SYNC with target: disk ###生成RDB快照
675:M 16 May 2019 09:26:33.540 * Background saving started by pid 682
682:C 16 May 2019 09:26:33.542 * DB saved on disk
675:M 16 May 2019 09:26:33.573 * Background saving terminated with success
675:M 16 May 2019 09:26:33.573 * Synchronization with replica 127.0.0.1:6380 succeeded ###
6）从节点同步主节点的日志信息：
681:S 16 May 2019 09:26:33.534 * Ready to accept connections
681:S 16 May 2019 09:26:33.535 * Connecting to MASTER 127.0.0.1:6379
681:S 16 May 2019 09:26:33.535 * MASTER <-> REPLICA sync started
681:S 16 May 2019 09:26:33.535 * Non blocking connect for SYNC fired the event.
681:S 16 May 2019 09:26:33.535 * Master replied to PING, replication can continue...
681:S 16 May 2019 09:26:33.536 * Partial resynchronization not possible (no cached master)
#runid，每个redis-server的唯一标识: 可以在info命令的结果中查找到
681:S 16 May 2019 09:26:33.541 * Full resync from master: e6bef3844d495a0574691d7993fd25311836f53a:0
681:S 16 May 2019 09:26:33.573 * MASTER <-> REPLICA sync: receiving 294 bytes from master
681:S 16 May 2019 09:26:33.574 * MASTER <-> REPLICA sync: Flushing old data
681:S 16 May 2019 09:26:33.574 * MASTER <-> REPLICA sync: Loading DB in memory
681:S 16 May 2019 09:26:33.575 * MASTER <-> REPLICA sync: Finished with success
681:S 16 May 2019 09:26:33.575 * Background append only file rewriting started by pid 683
681:S 16 May 2019 09:26:33.602 * AOF rewrite child asks to stop sending diffs.
683:C 16 May 2019 09:26:33.602 * Parent agreed to stop sending diffs. Finalizing AOF...
683:C 16 May 2019 09:26:33.603 * Concatenating 0.00 MB of AOF diff received from parent.
683:C 16 May 2019 09:26:33.604 * SYNC append only file rewrite performed
681:S 16 May 2019 09:26:33.637 * Background AOF rewrite terminated with success
681:S 16 May 2019 09:26:33.637 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
681:S 16 May 2019 09:26:33.639 * Background AOF rewrite finished successfully
7.实战操作
#6380 非主从
slaveof no one
#6379
mset a b c d e f g h
#6380
dbsize
>0
#6380
set key1 value1
#6380
slaveof 127.0.0.1 6379
get key
>(nil) #证明是完全复制并替换本地的DB
查看runid的命令
redis-cli -p 6379 info server | grep run
run_id:b3130f2f3a410bf42327dabfbd94ce0d54b1a99a
三、全量复制 & 部分复制
全量复制流程图
四、故障处理
slave宕机
master宕掉1
master宕机2
可以写脚本文件实现上述功能，但是其并没有实现故障自动转移
主从复制故障转移问题？
五、开发运维常见问题
1. 读写分离：读流量分摊到从节点
1）数据复制延迟，发生数据不一致问题
2）读到过期数据。(在Redis3.2中已经解决此问题)
过期数据删除策略：
（1）lazy策略，第一次使用时查看是否过期，是的话则删除
（2）定时任务：由定时任务采样一些key，当采样速度跟不上产生过期数据的速度，则造成很多过期数据没有被删除。slave节点不能删除过期数据
3）从节点故障
2. 主从配置不一致：
1） maxmemory不一致：丢失数据
2）例如数据结构优化参数（hash-max-ziplist-entries）:主改从未改，内存不一致
3. 规避全量复制（开销大）
1）第一次全量复制
（1）第一次不可避免
（2）小主节点（设置max_memory）,低峰时复制（半夜）
2）节点运行ID不匹配
（1）主节点重启（运行id发生变化）
（2）故障转移，例如哨兵或集群
3）复制积压缓冲区不足
（1）网络中断，部分复制无法满足
（2）增大复制缓冲区配置rel_backlog_size ,增强网络 （1M ——> 10M）
4. 规避复制风暴
规避复制风暴
