mysql备份恢复实例丢失事务解析
发布时间：2022-03-29 08:30:47 所属栏目：MySql教程 来源：互联网
导读：看到了一篇server id导致mysql备份恢复的时候丢失事务的文章，特此重现一下。 主备开启了GTID，实验过程如下： 1.主库执行： create database test1; create database test2; 2.主从没有延迟后备份，利用从库备份，物理或者逻辑都可以： mysqldump -uroot
|
看到了一篇server id导致mysql备份恢复的时候丢失事务的文章，特此重现一下。 主备开启了GTID，实验过程如下： 1.主库执行： create database test1; create database test2; 2.主从没有延迟后备份，利用从库备份，物理或者逻辑都可以： mysqldump -uroot -poracle --single-transaction --master-data=2 --all-databases > dump.sql 3.主库执行： create database test3; 4.将主库干掉 5.从库提升为主库，并且： create database test4; 6.利用从库的备份恢复老的主库，并指向新主 这个时候会发现，恢复出来的从库丢失了一个事务test3： mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | ming | | mysql | | performance_schema | | sakila | | sys | | test1 | | test2 | | test4 | | tt | | world | +--------------------+ 11 rows in set (0.00 sec) 文章说是因为server_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， 此时该条记录就会被过滤掉。就不会传递到老主那边去。 # at 836 #200328 11:23:25 server id 1573854809 end_log_pos 901 CRC32 0x23ffdc70 GTID last_committed=4 sequence_number=5 rbr_only=no SET @@SESSION.GTID_NEXT= '6f5b02b9-1f08-11ea-9853-000c2970dcdf:5'/*!*/; # at 901 #200328 11:23:25 server id 1573854809 end_log_pos 998 CRC32 0x2f611a1d Query thread_id=2 exec_time=4290974348 error_code=0 SET TIMESTAMP=1585365805/*!*/; create database test3 /*!*/; 那么为什么test4会被传递到老主被应用呢？因为该事务在新主master-bin log中如下，server id 1051295是新主的， 就不会被IO thread过滤. # at 998 #200211 6:19:19 server id 1051295 end_log_pos 1063 CRC32 0xec9c6a1e GTID last_committed=5 sequence_number=6 rbr_only=no SET @@SESSION.GTID_NEXT= '4c312339-ab38-11e9-86a8-000c29050245:1'/*!*/; # at 1063 #200211 6:19:19 server id 1051295 end_log_pos 1160 CRC32 0xaccb28ab Query thread_id=2 exec_time=0 error_code=0 SET TIMESTAMP=1581373159/*!*/; SET @@session.sql_mode=1151336480/*!*/; create database test4 /*!*/; 那么为什么两条记录不一致呢？这是因为test3事务是老主传递过来的，那么在relay log中，master-bin log中， 以及向后传递到其它从库中的时候，server id是会一直被带下去的。test4事务是新主自己的事务， 那么从他自己的master-bin log，以及向后传递的从库的relay log和应用后生成的master-bin log中都会是新主的server id。 所以test3会被过滤，test4会被应用。 老的主库此时： mysql> show master statusG *************************** 1. row *************************** File: mysql-bin.000002 Position: 1443 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 1508afe9-70a7-11ea-8d70-000c2970dcdf:1-3, --自己库里执行的事务 4c312339-ab38-11e9-86a8-000c29050245:1,--主从传递下来的事务 6f5b02b9-1f08-11ea-9853-000c2970dcdf:1-4--自己作为主的时候执行的事务 1 row in set (0.00 sec) 新的主库： mysql> show master statusG *************************** 1. row *************************** File: mysql-bin.000002 Position: 1322 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 4c312339-ab38-11e9-86a8-000c29050245:1-2, 6f5b02b9-1f08-11ea-9853-000c2970dcdf:1-5 1 row in set (0.00 sec)  （编辑：源码门户网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐