开发者社区> db匠> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

数据库内核月报 - 2015 / 06-MySQL · 答疑解惑 · binlog event 中的 error code

简介:
+关注继续查看

问题描述

RDS 有个任务叫做恢复到任意时间点,相当于一个数据时光机,可以将数据恢复到过去任意一个时间点,在用户出现误操作需要将数据找回时非常有用。这个功能主要是通过备份集恢复 + binlog回放实现,在用备份集恢复出的实例上应用 binlog 到指定时间点。

然而最近线上重放binlog时遇到了这样一个错误:

Table xxxx already exists

查看对应 binlog 的,发现这是一个 CREATE VIEW 语句,而备份集恢复出来的实例上确实已经有了这个view,再往前翻看binlog,并没有发现 DROP 这个 view 的记录,倒是找到了CREATE 这个 view 的记录,仔细比较2处 CREATE VIEW 的binlog event,会发现后者多了个 error_code=1050,这个是什么错呢:

$perror 1050
MySQL error code 1050 (ER_TABLE_EXISTS_ERROR): Table '%-.192s' already exists

1050 对应的错就是 Table already exists

就是说 CREATE VIEW 失败了,仍然记入 binlog 了,但是当时备库并没有这个错误中断掉。

复现步骤

复现非常简单,连着执行同一个create view语句即可。

mysql> create table t1(id int, name varchar(30)) engine=innodb;
Query OK, 0 rows affected (0.02 sec)

mysql> create view t1_v as select id from t1;
Query OK, 0 rows affected (0.01 sec)

mysql> create view t1_v as select id from t1;
ERROR 1050 (42S01): Table 't1_v' already exists

查看binlog event

#150614 23:15:02 server id 36302  end_log_pos 2651 CRC32 0x8f8b6c61     GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '94cdda9b-a2d0-11e4-ade1-a0d3c1f20ae4:68157343'/*!*/;
# at 2651
#150614 23:15:02 server id 36302  end_log_pos 2856 CRC32 0x703fbe6d     Query   thread_id=21475 exec_time=0     error_code=0
SET TIMESTAMP=1434294902/*!*/;
CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`127.0.0.1` SQL SECURITY DEFINER VIEW `t1_v` AS select id from t1
/*!*/;
# at 2856
#150614 23:15:02 server id 36302  end_log_pos 2904 CRC32 0xfc2ef7cb     GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '94cdda9b-a2d0-11e4-ade1-a0d3c1f20ae4:68157344'/*!*/;
# at 2904
#150614 23:15:02 server id 36302  end_log_pos 3109 CRC32 0x0e807965     Query   thread_id=21475 exec_time=0     error_code=1050
SET TIMESTAMP=1434294902/*!*/;
CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`127.0.0.1` SQL SECURITY DEFINER VIEW `t1_v` AS select id from t1
/*!*/;

可以清楚的看到,第二次 CREATE VIEW 时error_code 为 1050。

分析

查看 binlog 对应的代码,发现 error_code 这个字段是 Query_log_event 的专属,其它的如 row_event、gtid event等都没有这个字段。而备库在执行Query_log_event 时会检查event 的 error_code(存入expected_error),如果非0的话,就和当前SQL线程执行出错(存入actual_error)比较,看是否一致,如果一致的话就算执行成功,如果不一致的话,就再检查这个错是否能够忽略,如配置了 slave_skip_errors,代码片段如下(在Query_log_event::do_apply_event中):

/*
If we expected a non-zero error code, and we don't get the same error
code, and it should be ignored or is related to a concurrency issue.
*/
actual_error= thd->is_error() ? thd->get_stmt_da()->sql_errno() : 0;
DBUG_PRINT("info",("expected_error: %d  sql_errno: %d",
expected_error, actual_error));

if ((expected_error && expected_error != actual_error &&
!concurrency_error_code(expected_error)) &&
!ignored_error_code(actual_error) &&
!ignored_error_code(expected_error))
{
rli->report(ERROR_LEVEL, 0,
"\
Query caused different errors on master and slave.     \
Error on master: message (format)='%s' error code=%d ; \
Error on slave: actual message='%s', error code=%d. \
Default database: '%s'. Query: '%s'",
ER_SAFE(expected_error),
expected_error,
actual_error ? thd->get_stmt_da()->message() : "no error",
actual_error,
print_slave_db_safe(db), query_arg);
thd->is_slave_error= 1;
}

正常的想法应该是执行出错,就不应该记binlog,为什么会有这样的设计呢,主库错,记binlog,然后备库要求同样的错。
因为DDL是不能回滚的,如果DDL执行到一半报错,主库又不能回滚,那么应该如何通知备库它做了一半呢?就是把错记下去,期待备库也报同样的错。

挖一下黑历史,Query_log_event 中的 error_code 字段最早是在这个commit中加入的,目的是将主库上执行出错的信息传给备库,备库执行的时候会检测实际的出错信息和主库传过来的binlog中记录的是否是一样的,不一样就报错。

在此之前,备库对于 Query_log_event 执行出错是这样处理的,先检查SQL线程执行出错是不是因为表不存在,如果是的话,就单独再开个连接,从主库把不存在的表导过来(fetch_nx_table),然后再重试执行失败的event,如果还有不存在的表,就再拉,再重复执行;对于其它的错就直接报错。
现在看起来是不是很奇葩,2000年的时候,MySQL还是很年青的哇 =_=

总结

我们在回放binlog的时候用的是mysql client,不是SQL线程,mysql client中并没有对error_cocd的处理逻辑,因此遇到执行出错就直接报错了。

所以如果脚本或者代码里有这种重放binlog逻辑的,需要注意处理这种场景。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
PolarDB-X内核新版本:将MySQL进行到底
在PolarDB-X最新的内核版本5.4.15中,提供诸多新功能:存储过程,读写分离优化,表级分区管理,密码、审计优化等。
0 0
TDSQL中修复的mysql内核bug
在TDSQL这两年多的开发工作中,我感觉很自豪的一件事是我修复了不少mysql-5.7.17和mariadb-10.1.9的内核bug,这些bug大多已经报告给了MySQL/MariaDB官方开发团队,在每个bug描述中我会贴出来bug报告的连接。本文将大略介绍这些bug的概况,我在将来会写更多文章详细介绍每个bug的具体问题分析以及解决思路。本文列出的所有bug都已经修复,经过验证可以正确工作并解决相关问题。 这里先说一下为什么我要提交代码给mysql/mariadb官方开发团队,主要有一下几个好处: 1. 官方开发者可以review我提交的patch,帮助完善patch,发现和解决之前
0 0
MySQL · 内核特性 · 统计信息的现状和发展
简介我们知道查询优化问题其实是一个搜索问题。基于代价的优化器 ( CBO ) 由三个模块构成:计划空间、搜索算法和代价估计 [1] ,分别负责“看到”最优执行计划和“看准”最优执行计划。如果不能“看准”最优执行计划,那么优化器基本上就是瞎忙活,甚至会产生严重的影响,出现运算量特别大的 SQL ,造成在线业务的抖动甚至崩溃。在上图中,代价估计用一个多项式表示,其系数 c 反应了硬件环境和算子特性,而
0 0
关于MySQL内核,一定要知道的!
近一个多月,写了一些MySQL内核的文字,稍作总结,希望对大家有帮助。1.《InnoDB,为何并发如此之高?》 文章介绍了: (1)什么是并发控制; (2)并发控制的常见方法:锁,数据多版本; (3)redo,undo,回滚段的实践; (4)InnoDB如何利用回滚段实现MVCC,实现快照读。
1897 0
MySQL · 引擎特性 · MySQL内核对读写分离的支持
读写分离的场景应用 随着业务增长,数据越来越大,用户对数据的读取需求也随之越来越多,比如各种AP操作,都需要把数据从数据库中读取出来,用户可以通过开通多个只读实例,将读请求业务直接连接到只读实例上。使用RDS云数据库的读写分离功能,用户只需要一个请求地址,业务不需要做任何修改,由RDS自带的读写分离中间件服务来完成读写请求的路由及根据不同的只读实例规格进行不同的负载均衡,同时当只读实例出现故障时能够主动摘除,减少对用户的影响。
1268 0
MySQL · 引擎特性 · Group Replication内核解析之二
背景 前文已经介绍了MySQL的Group Replication的实现机制和原理,本文就Group Replication的具体实现进行详细的阐述,以更深入的理解Group Replication的机制,在实践中更好的应用Group Replication,提升应用系统的可用性,优化其性能。
1140 0
+关注
db匠
rds内核团队秘密研发的全自动卖萌机. 追加特效: 发数据库内核月报. 月报传送: http://mysql.taobao.org/monthly/
文章
问答
来源圈子
更多
让用户数据永远在线,让数据无缝的自由流动
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
让 MySQL 原生分布式触手可及
立即下载
好的 MySQL 兼容可以做到什么程度
立即下载
云数据库RDS MySQL从入门到高阶
立即下载