如何通过日志的方式理解Redis主从复制

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版本的删库跑路，那经验增长老长了。