一 什么是主从复制
机器故障;容量瓶颈;QPS瓶颈
一主一从,一主多从
做读写分离
做数据副本
扩展数据性能
一个maskter可以有多个slave
一个slave只能有一个master
数据流向是单向的,从master到slave
1.1 原理
1 2 3 4 5 6 7 8 9
|
1. 副本库通过slaveof 127.0.0.1 6379命令,连接主库,并发送SYNC给主库 2. 主库收到SYNC,会立即触发BGSAVE,后台保存RDB,发送给副本库 3. 副本库接收后会应用RDB快照 4. 主库会陆续将中间产生的新的操作,保存并发送给副本库 5. 到此,我们主复制集就正常工作了 6. 再此以后,主库只要发生新的操作,都会以命令传播的形式自动发送给副本库. 7. 所有复制相关信息,从info信息中都可以查到.即使重启任何节点,他的主从关系依然都在. 8. 如果发生主从关系断开时,从库数据没有任何损坏,在下次重连之后,从库发送PSYNC给主库 9. 主库只会将从库缺失部分的数据同步给从库应用,达到快速恢复主从的目的
|
1.2 主库是否要开启持久化
1
|
如果不开有可能,主库重启操作,造成所有主从数据丢失!
|
1.3 辅助配置(主从数据一致性配置)
1 2 3
|
min-slaves-to-write 1 min-slaves-max-lag 3
|
二 复制的 配置
2.1 slave 命令
1 2 3 4 5 6
|
6380是从,6379是主
在6380上执行(去从库配置,配置主库)
slaveof 127.0.0.1 6379 slaveof no one
|
2.2 配置文件
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
|
slaveof ip port slave-read-only yes
''' mkdir -p redis1/conf redis1/data redis2/conf redis2/data redis3/conf redis3/data vim redis.conf
daemonize no pidfile redis.pid bind 0.0.0.0 protected-mode no port 6379 timeout 0 logfile redis.log dbfilename dump.rdb dir /data slaveof 10.0.0.101 6379 slave-read-only yes
cp redis.conf /home/redis2/conf/
docker run -p 6379:6379 --name redis_6379 -v /home/redis1/conf/redis.conf:/etc/redis/redis.conf -v /home/redis1/data:/data -d redis redis-server /etc/redis/redis.conf
docker run -p 6378:6379 --name redis_6378 -v /home/redis2/conf/redis.conf:/etc/redis/redis.conf -v /home/redis2/data:/data -d redis redis-server /etc/redis/redis.conf
docker run -p 6377:6379 --name redis_6377 -v /home/redis3/conf/redis.conf:/etc/redis/redis.conf -v /home/redis3/data:/data -d redis redis-server /etc/redis/redis.conf
info replication
'''
|
四 故障处理
slave故障
master故障
五 复制常见问题
1 读写分离
读流量分摊到从节点
可能遇到问题:复制数据延迟,读到过期数据,从节点故障
2 主从配置不一致
maxmemory不一致:丢失数据
数据结构优化参数:主节点做了优化,从节点没有设置优化,会出现一些问题
3 规避全量复制
第一次全量复制,不可避免:小主节点,低峰(夜间)
节点运行id不匹配:主节点重启(运行id变化)
复制挤压缓冲区不足:增大复制缓冲区大小,rel_backlog_size
4 规避复制风暴
单主节点复制风暴,主节点重启,所有从节点复制
每天逼着自己写点东西,终有一天会为自己的变化感动的。这是一个潜移默化的过程,每天坚持编编故事,自己不知不觉就会拥有故事人物的特质的。 Explicit is better than implicit.(清楚优于含糊)