文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

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

2024-04-02 19:55

关注

看到了一篇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 status\G
*************************** 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 status\G
*************************** 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)
阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-数据库
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯