mysql备份恢复实例丢失事务分析

看到了一篇server id导致mysql备份恢复的时候丢失事务的文章，特此重现一下。
主备开启了GTID，实验过程如下：
文章说是因为ser开发云主机域名ver_id的缘故。
server id一个很大的作用是避免数据回环。所以事务中记录的sever id会是持久不变的，就像我们的身份证一样，
走到哪儿都不变。

老主库因为是利用从库的备份集还原出来的，执行过的事务是 6f5b02b9-1f08-11ea-9853-000c2970dcdf:1-4，
那么就要去向新主请求6f5b02b9-1f08-11ea-9853-000c2970dcdf:5事务。
新主的master-bin log文件中该事务如下：server id是1573854809 。而该server id正好是老主的server id，
此时该条记录就会被过滤掉。就不会传递到老主那边去。
那么为什么test4会被传递到老主被应用呢？因为该事务在新主master-bin log中如下，server id 1051295是新主的，
就不会被IO thread过滤.
那么为什么两条记录不一致呢？这是因为test3事务是老主传递过来的，那么在relay log中，master-bin log中，
以及向后传递到其它从库中的时候，server id是会一直被带下去的。test4事务是新主自己的事务，
那么从他自己的master-bin log，以及向后传递的从库的relay log和应用后生成的master-bin log中都会是新主的server id。
所以test3会被过滤，test4会被应用。
老的主库此时：
新的主库：

相关推荐: 【Mysql】MySQL查询计划key_len全知道

本文首先介绍了MySQL的查询计划中ken_len的含义；然后介绍了key_len的计算方法；最后通过一个伪造的例子,来说明如何通过key_len来查看联合索引有多少列被使用开发云主机域名。 在MySQL中,可以通过explain查看SQL语句所走的路径,如下…