第一篇是发现了问题，这一篇发现了更多有意思的现象。

场景

当我实时观察偏移量的时候（想看什么时候能追上），发现我记录的offset竟然由大变小了，我以为自己看错了，但一段时间后，又复现了！紧张感顿生，大bug？

问题

为什么offset会变小，感觉是循环解析mysql-bin.010672

发现之路

感觉是个大bug，

• 第一怀疑是我存储的时候被截断了。因为明显是存储的offset是变小了，而理论上mysql提供的offset肯定不会变小。看代码，发现是按照字符串存储的sprintf("%s",...)，那么这个存储没问题。
• 那么难道是取值的时候出问题了。翻代码，取的offset是固定的4byte，取法不应该有错。溢出？？？
  • 4字节，能够表示的大小最大是40多亿，再看binlog文件，11G（120亿字节！！！）。那么真的有可能是mysql提供的offset有问题，mysql自己在写入的时候这个offset就被截断了。

验证之路

• 首先，我要确认我取4个字节是对的。翻mysql协议，确认Ok，是4字节。
• 现在，验证binlog文件内的offset确实超过40多亿后，重新开始了。找dba和运维提供binlog文件，（中间几多等待，12G，在不同机房，慢慢等待），然后解析

#171205 16:06:59 server id 2012  end_log_pos 4294934461 CRC32 0x29e814c4     Update_rows: table id 111580
#171205 16:06:59 server id 2012  end_log_pos 4294942639 CRC32 0xc85227c4     Update_rows: table id 111580
#171205 16:06:59 server id 2012  end_log_pos 4294952475 CRC32 0x4bf1a443     Update_rows: table id 111580
#171205 16:06:59 server id 2012  end_log_pos 4294963179 CRC32 0xe3263ec6     Update_rows: table id 111580
#171205 16:06:59 server id 2012  end_log_pos 5775 CRC32 0x0b2c2d31     Update_rows: table id 111580
#171205 16:06:59 server id 2012  end_log_pos 15731 CRC32 0x8d92b8e3     Update_rows: table id 111580
#171205 16:06:59 server id 2012  end_log_pos 25781 CRC32 0x043bc145     Update_rows: table id 111580
#171205 16:06:59 server id 2012  end_log_pos 28567 CRC32 0x7c9e0674     Update_rows: table id 111580
#171205 16:06:59 server id 2012  end_log_pos 39917 CRC32 0xcb431e05     Update_rows: table id 111580
#171205 16:06:59 server id 2012  end_log_pos 49975 CRC32 0x92c1a163     Update_rows: table id 111580

问题确认！ mysql写入的offset确实是被截断了

我看到的所谓循环，其实不是循环，只是offset确实变小了。

影响

这个问题本身这次并没有对业务产生影响，这次主要问题是延迟。但这个问题本身很重要。

• 如果同步中模拟slave断掉，下次拿这个偏移去mysql获取数据的时候，mysql可能无法给出有效数据，因为这个偏移在文件内，可能有多个！
• 如果是主从同步中，真实的slave断掉，也会有一样的问题。//todo
• 除此之外，还有别的问题吗？（mysql写入binog、刷盘、index规则）//todo