如果你还不会搭建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
将其和主库一致才行。
若密码正确,则会显示如下日志
数据同步
在验证完主库的密码后,则真正开始数据主从同步,同步的方式为全量同步+部分同步的方式,这里详细讲解一下,在建立主从复制后,第一次会进行全量复制,而后才会进行增量复制。
全量复制
当主库收到请求后,会在主库执行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
版本的删库跑路,那经验增长老长了。