一本书2024-11-21 来自湖北“如果备库本身存在延迟，那么备库上生成的 binlog 的时间戳和真实的业务时间可能存在偏差”，老师，针对这句话我有一些疑问，备库的 binlog 时间戳是binlog在备库中应用的时间点还是与主库保持一致？如果是跟主库保持一致，那就和真实的业务时间应该是一样的吧？gpt说备库的 binlog 时间戳通常与主库保持一致。 如果选择主备之前存在1分钟延迟，要备份12点的数据，而11：59到12点的数据没应用到备库上，备库的binlog也就没有这部分数据，从而用备库恢复会丢失这部分数据，所以达不到业务上的恢复目标，我猜测是老师想说的是这个意思？作者回复: 是的，文章里这个地方可能写得不够清楚。 文章里，判断一个binlog文件的时间，用了binlog文件头的时间戳，这个时间是Binlog的创建时间。 至于从主库上复制过来的Binlog，记录到备库的Binlog中时，时间是不会变的。 如果复制有延迟，就可能会存下面在这样的情况。 备库上Binlog N的开始时间是 10点整，Binlog N+1的开始时间是11点整。 但由于备库延迟，Binlog N+1里实际上还有主库上10点多生成的Binlog。如果需要把数据恢复到10:30，只应用到Binlog N，就会缺少Binlog N+1中的一些事务。
牧野静风2024-11-20 来自广东有个问题，在使用binlog恢复过程中，这个库只能作为从库了吧，主库要切走之后才好操作，如果是主库，应用连着在写入，这块怎么处理，并且后续正常写入呢