docker重启mysql数据丢失_故障分析 | 记一次 MySQL 主从双写导致的数据丢失问题

本文探讨了一次由于在互为主从的MySQL服务器上同时进行写入导致的数据丢失问题。在Row格式的RelayLog重放过程中,由于没有主键或唯一键,可能导致数据不一致。在没有合适索引时,MySQL使用Hash Scan重放记录,即使数据已改变,也可能执行Binlog中的更新,从而覆盖原有数据。此外,文章讨论了binlog_row_image和slave_rows_search_algorithms参数对数据一致性和性能的影响。
摘要由CSDN通过智能技术生成

作者:戴骏贤

网易游戏 技术部资深数据库系统工程师。

本文来源:原创投稿

*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。


一、问题起源

不久前用户反馈部门的 MySQL 数据库发生了数据更新丢失。为了解决这个问题,当时对用户使用的场景进行了分析。发现可能是因为用户在两台互为主从的机器上都进行了写入导致的数据丢失。

f98df5c65093e2f7ef73a5fe7aa91ae8.png

如图所示,是正常和异常情况下应用写入数据库的示例。随后在更加深入调查问题的过程中,DBA 发现了故障引起数据丢失的原因:

b16dc49cb64e56302101681f76ca71e0.png

如图 1-2 所示为故障具体过程的还原。从图中可以看出在第 3 步 DP 上的写入操作,在恢复 DA 到 DP 的同步之后,覆盖了第 4 步 DA 上的写入。因此导致了最终两台机器数据不一致,并且有一部分数据更新丢失。

在这里相信读者都会有一个疑问, 在第 4 步之后数据变成了(id : 1 ,name : name4),那么第 3 步操作的时候写入的语句是 update t20200709 set name = 'name3' where id =1 and name='name2',在第 5 步恢复同步的时候这条语句在 DA 上重放应该不会被成功执行,毕竟 Where 条件都不匹配了。而且在 DP 产生的 Binlog 中,确实也记录了 SQL 语句的 Where 条件,无论从哪个角度上来看第 3 步的 SQL 语句都不应该被重放成功。

### UPDATE `test`.`t20200709`### WHERE###   @1=1 /* INT meta=0 nullable=0 is_null=0 */###   @2='name2' /* VARSTRING(255) meta=255 nullable=1 is_null=0 */### SET###   @1=1 /* INT meta=0 nullable=0 is_null=0 */###   @2='name3' /* VARSTRING(255) meta=255 nullable=1 is_null=0 */# at 684315240

那么这个问题难道是 MySQL 自身的 Bug,抑或是 MySQL 在某些特殊参数或者条件下的正常表现?对于这个问题,本文将可能的给出这个问题的详细解释和分析。

二、Row 格式下 RelayLog 的重放

2.1 BEFOR IMAGE && AFTER IMAGE && binlog_row_image 参数

在最后解释本文最初提出的问题前,需要先来看下 RelayLog 是怎么被重放的。一般情况下,当有 DML 语句变更数据库中的数据的时候,Binlog 会记录下事件描述信息、BEFORE IMAGE 和 AFTER IMAGE 等信息。在这里有一个概念 BEFORE IMAGE 和 AFTER IMAGE 需要先介绍下:

1. BEFORE IMAGE : 前镜像,既数据修改前的样子。

2. AFTER IMAGE : 后镜像,既数据修改后的样子。

为了方便理解,这里贴一个 Binlog 的例子。假设当前有表 t20200709,然后表中数据如下:

mysql> select * from t20200709 ;+----+-------+| id | name  |+----+-------+|  1 | name4 |+----+-------+1 rows in set (0.00 sec)

之后执行 SQL 语句 update t20200709 set name =1 where id = 1;

mysql> update t20200709 set name =1 where id = 1;Query OK, 1 row affected (0.00 sec)Rows matched: 1  Changed: 1  Warnings: 0

然后来看下 Binlog 中的记录:

#200715 17:28:28 server id 15218  end_log_pos 400 CRC32 0xe4dedec0     Update_rows: table id 4034114356 flags: STMT_END_F### UPDATE `test`.`t20200709`### WHERE###   @1=1 /* INT meta=0 nullable=0 is_null=0 */###   @2='name4' /* VARSTRING(255) meta=255 nullable=1 is_null=0 */### SET###   @1=1 /* INT meta=0 nullable=0 is_null=0 */###   @2='1' /* VARSTRING(255) meta=255 nullable=1 is_null=0 */# at 400

可以见得,在修改之前 name 字段的值是 name4,在 Binlog 中用 Where 条件 @2='name4' 来指明,而修改后的 name 的值是 '1',在 Binlog 中就是 @2='1' 来指明。因此 BEFORE IMAGE 就是 Binlog 中 WHERE 到 SET 的部分。而 AFTER IMAGE 就是 SET 之后的部分。

bc189675ca8488035d3385379c92fdb3.png

那么 DELETE,UPDATE 和 INSERT 语句被记录在 Binlog 中的时候,是否都有 BEFORE IMAGE 和 AFTER IMAGE?其实不是所有的 DML 事件类型都拥有两个 IMAGE 的,参见图 2-2 可知只有 UPDATE 语句,会同时拥有 BEFORE IMAGE 和 AFTER IMAGE。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值