主从的架构:
一主多从,级联
主从复制
1.s初次链接到m,发送sync命令,会触发一次全量复制。
2.m新开后台线程,生成一份RDB快照,同时将客户端发来的写命令,缓存在内存中
3.RDB生成后,发送给s,s收到后先写入磁盘,再加载到内存中。
4.m还会将缓存中的写命令,异步发送给s。
同步是由s发起
初次同步和部分重同步期间,m是非阻塞的,也就是还能提供对外服务。
部分重同步依赖一个偏移量,同时存在于m和s,再次连接上,s会向m发送偏移量,m进行比较,然后把偏移量后的命令发送给s。(特例:断开连接时间过长、偏移量已被覆盖<偏移量存在于m的复制积压缓冲区,默认1MB>,此时启动RDB全量同步)
常见问题
故障转移的策略:优先级最高(数越小)-偏移量最大-runid最小的从服务
全量复制问题:首次同步不可避免,后面尽量避免
1)m发生故障时,可能会导致runid变化,s会认为是一个全新的m。所以用哨兵、集群的方式来避免
2)复制积压缓冲区不足,也会导致。调大即可
3)复制风暴:主节点重启,大量s开启复制。通过树状级联的复制结构减轻压力。
----------
生成RDB日志的流程:https://blog.csdn.net/sj15814963053/article/details/124422938?spm=1001.2014.3001.5502
fork子进程进行,采用Copy-On-Write技术,同时正常处理读写
在复制时正好有个修改操作(修改已有数据A),A被复制一份A ^,子进程复制的是A,而修改操作的是A^
(开启RDB持久化后,当达到持久化的阈值,redis会fork一个新的进程来做持久化,采用了操作系统的copy-on-wirte写时复制策略,子进程与父进程共享Page。如果父进程的Page(每页4K)有修改,父进程自己创建那个Page的副本,不会影响到子进程;)
所以下面这个案例内存分析部分,有80% * 2G=1.6G
AOF重写:单写一个文件,合并命令,目的是减小AOF文件大小
AOF日志由主线程写入。是先执行数据写入命令,然后再写日志;但是AOF重写是后台子进程来写。
- 自动触发: 根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。其中auto-aof-rewrite-min-size表示运行AOF重写时文件最小体积,默认为64MB。auto-aof-rewrite-percentage表示当前AOF文件大小(aof_current_size)和上一次重写后AOF文件大小(aof_base_size)的比值(新的增量达到了上次重写后文件大小的百分比)。自动触发时机为 aof_current_size > auto-aof-rewrite-min-size &&(aof_current_size - aof_base_size)/aof_base_size> = auto-aof-rewrite-percentage
https://blog.csdn.net/sj15814963053?type=blog
标签:aof,AOF,auto,rewrite,Redis,复制,size From: https://www.cnblogs.com/xyang/p/16708488.html