通过日志的方式理解Redis主从复制
携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第21天，点击查看活动详情
如果你还不会搭建
Redis主从复制，请参考主从复制搭文档: juejin.cn/post/713470…文章采用的
Redis版本为: 3.2.12
Redis主从复制概要
之前我们介绍了如何构建主从复制，其中在总结处提及的，做主从的时候，一定要谨慎，因为在执行主从复制时，会清理掉从库所有的数据，所以说，今天我们来看下，我们从库在执行SLAVEOF的时候，执行的步骤。
建立连接
当我们在从库执行slaveof，指定主节点的地址和端口后，从库和主库会进行连接，等待复制，这时，可以查看日志得到信息，我们新建一个主从，我们查看日志可知：
[root@pdudo 6380]# grep -i connecting redis.log -A 1
* Connecting to MASTER 127.0.0.1:6379
* MASTER <-> SLAVE sync started
[root@pdudo 6380]#
如上日志显示，从库将向主库建立链接，且建立成功，主从开始复制。
检查主库是否存活
再建立链接后，为确保服务器存活，从库会向主库发送ping命令，若收到返回pong，则开始复制。
通过日志显示如下
* Master replied to PING, replication can continue...
如果发送ping未被返回pong，会抛出如下错误，并且间隔数秒，会再次尝试建立连接。
# Error condition on socket for SYNC: Connection refused
此时我们则应当检查主库是否可用。
权限校验
当从库ping主库得到正常返回时，这个时候，就需要开启鉴权了，所谓的鉴权，若主库设置了requirepass，则从库在连接主库进行复制前，就需要指定masterauth才行，否则会重复建立连接步骤。
若密码错误，会显示如下日志
# Unable to AUTH to MASTER: -ERR invalid password
如上就是主库requirepass和从库masterauth不一致所引起的，此时从库会回到建立连接步骤重新开始，周而复始，此时我们应该检查主库的密码是否和masterauth一致，若不一致，需要修改masterauth将其和主库一致才行。
若密码正确，则会显示如下日志
* Partial resynchronization not possible (no cached master)
数据同步
在验证完主库的密码后，则真正开始数据主从同步，同步的方式为全量同步+部分同步的方式，这里详细讲解一下，在建立主从复制后，第一次会进行全量复制，而后才会进行增量复制。
全量复制
当主库收到请求后，会在主库执行bgsave开始后台备份，备份完成后，会直接将备份后的rdb发送至从库。从库在收到主库rdb文件后， 会释放到从库中。 通过主库的日志可以看到详细信息。
* Full resync requested by slave 127.0.0.1:6380
* Starting BGSAVE for SYNC with target: disk
* Background saving started by pid 44841
* DB saved on disk
* Background saving terminated with success
* Synchronization with slave 127.0.0.1:6380 succeeded
在从库收到后，可以看到日志
* Full resync from master: 250ee58e7c7fb1e6c57c05cbfb099cb0013674d9:1
* MASTER <-> SLAVE sync: receiving 77 bytes from master
* MASTER <-> SLAVE sync: Flushing old data
* MASTER <-> SLAVE sync: Loading DB in memory
* MASTER <-> SLAVE sync: Finished with success
而后，当主库有新增数据后，会通过增量复制的方式发送至从库进行执行，至此，我们主从复制逻辑介绍完毕。
总结
自此，还有我们了解了大概的主从复制流程，其实还有亿点点细节没有提及，例如数据同步的时候，我们在执行全量复制的时候，这时候来了新命令，应该放到哪里？ 等等。由于有点复杂，所以不准备持续阐述了，这里总结几个小坑，我们在做主从复制的时候，尽量选择业务量小的时候操作，为什么呢？ 因为业务量大的时候，我们在后台做bgsave的时候，当检测到达到多少key有变化了，它就会认为目前的备份版本太老了，会重新进行备份，然而又进入了循环，始终都备份不完。其次在重申一点，在做主从复制的时候，一定要认真看好机器，不要将其他正在线上使用的Redis作为从库来执行slaveof了，我们有过类似的案例，Redis版本的删库跑路，那经验增长老长了。
