单机模式

1. master_replid是每次重启redis产生一个40位的ID
2. 主要用于主从复制.识别增量的一个标识.

# 从的info
master_replid:4ec57b08245df967ec04c8042886f476f77549e5
master_replid2:0000000000000000000000000000000000000000

image.png

主从模式

• master replication信息

# master自己生成的40位ID
master_replid:d920f01828cd7b6ba8ab93de03f75d26e688d496
master_replid2:0000000000000000000000000000000000000000

image.png

• slave replication信息

1. slave与master成功建立主从关系后
2. 会将master的master_replid存储在自己的master_replid上

# 与master的master_replid相同
master_replid:d920f01828cd7b6ba8ab93de03f75d26e688d496
master_replid2:0000000000000000000000000000000000000000

image.png

主从断开后

127.0.0.1:6379> replicaof no one

master_replid:2d5f15f52f96113d5805cef6895e7d8405c0e502
master_replid2:d920f01828cd7b6ba8ab93de03f75d26e688d496

1. 与master断开后, slave的role变成master,自己又产生一个新的master_replid
2. 见第二张图, 设置第二个replication ID和offset 5839.然后new Replication ID

3. 为什么要保存上次主replication ID呢?

   
   slave info信息
   slave logfile日志信息

主从恢复后

# 从的info
master_replid:d920f01828cd7b6ba8ab93de03f75d26e688d496
master_replid2:0000000000000000000000000000000000000000

• 恢复主从关系时, 从会尝试使用master_replid(2d5f15f52f96113d5805cef6895e7d8405c0e502)和offset去请求master部分数据恢复,其实在这里有个疑问, 上次保存了master Replication ID,而这次使用自身的一个master Replication ID请求, 必定匹配上. 这个ID是新产生的, 主服务跟本不知道, 这里应该使用master_replication2(d920f01828cd7b6ba8ab93de03f75d26e688d496)+offset去请求服务太对. 感觉这是一个BUG
  

  slave日志

• slave使用master_replid+offset请求master, master收到后进行匹配, 匹配不成功,使用全量(bgsave)复制, 这里其实是永远不会匹配成功的.

• master_replication2 什么时候使用?
  

  master日志

自我解答

就刚才那个问题,如果出现网络延时, 假设延时5分钟, 同时master与slave都没有下线, 所以他们的ID不会变, 恢复时slave会带上master_replid+offset去请求master, master匹配成功后,就不会触发全量复制,而是走增量复制. 应该是这样意思吧.但是master_replication2 还是没有找到相关资料, 等进一步研究好了,再来解答吧.