数据库内核月报 - 2014 / 11

MySQL · 捉虫动态 · OPTIMIZE 不存在的表

bug 描述

这是一个和 GTID 相关的Bug,也就是说5.6才会有,并且出现这个 bug 需要满足条件:

做修改性质的表管理操作,如 OPTIMIZE/ANALYZE/REPAIR 可以,CHECK 就不可以 操作对应的表不存在 gtid_next 被设置为一个固定的值,并且 binlog 开启 在同时满足这3种条件下,会发现记录binlog时,对应的 Gtid_log_event 中的UUID会记为 00000000-0000-0000-0000-000000000000,并且这个对应的 gtid 不会记入 Executed_Gtid_Set。

bug影响

从 bug 描述可以看出,这个 bug 的表现特征就是 gtid_event 记错了,因此单实例的话基本不受影响的,因为主备复制时才会用到 gtid,所以主备场景会受到这个bug的影响。下面我们看下主备场景下这个bug是如何影响的:

M<->S : M 和 S 互为主备,都是5.6,以 gtid 协议进行复制,M是主库。

假设我们在主库上执行了 OPTIMIZE TABLE non_exist_table,这时候 gtid_next = ‘AUTOMATIC’,不是一个固定值,所以主库的 gtid 记录还是正常的,假设这时生成的 gtid_log_event 为 f3c1dd3e-395d-11e4-be45-4cb16c8f4abc:5,binlog 传到备库后,SQL 线程在 apply 的时候,会先将 f3c1dd3e-395d-11e4-be45-4cb16c8f4abc:5 设置为 gtid_next,然后同样做 OPTIMIZE TABLE non_exist_table,这个时候就触发了bug,备库的 gtid_log_event 记为00000000-0000-0000-0000-000000000000:5,并且不记入 Executed_Gtid_Set。主库继续接收用户的更新,同时会将备库的 binlog 拉过去应用,当做到 00000000-0000-0000-0000-000000000000:5 时,发现这个不在 Executed_Gtid_Set 中,就会执行,同样触发 bug, gtid_log_event 记为00000000-0000-0000-0000-000000000000:5,并且同样不记入 Executed_Gtid_Set。如此这样循环往复,会发现 OPTIMIZE TABLE non_exist_table 对应的binlog 在主备之前循环,充斥在 binlog 和 relay log 中。

bug 分析

之所以出现这个bug,是因为表管理操作的特殊性,OPTIMIZE/ANALYZE/REPAIR/CHECK TABLE 这些都统一调用 mysql_admin_table 函数进行管理操作,mysql_admin_table 执行失败的时候,执行线程并不报错,而是在 mysql_admin_table 函数结束前,清空线程中的error,将错误信息封装在结果集(result set)中发送给客户端,所以 OPTIMIZE/ANALYZE/REPAIR 虽然执行失败了,但仍然会记 binlog 。 按照这个逻辑来看,出错了仍然记binlog也是没问题,只要记对就行了,但是这里有一个问题,就是 mysql_admin_table 会调用 open_and_lock_tables,因为表不存在,所以 open_and_lock_tables 打开表的时候就出错,然后调用 trans_rollback_stmt ,之后会调到 gtid_rollback,最终调到 thd->variables.gtid_next.set_undefined()。

void set_undefined()
{
if (type == GTID_GROUP)
type= UNDEFINED_GROUP;
}

可以看到,如果是 type == GTID_GROUP,就将 type 设置为 UNDEFINED_GROUP。那么什么情况下gtid_next 的 type 会是 GTID_GROUP,答案是为一个固定值的时候,即类似这种 f3c1dd3e-395d-11e4-be45-4cb16c8f4abc:5。

而在 Gtid_log_event::Gtid_log_event 有这段逻辑,

if (spec.type == GTID_GROUP)
{
global_sid_lock->rdlock();
sid= global_sid_map->sidno_to_sid(spec.gtid.sidno);
global_sid_lock->unlock();
}
else
sid.clear();

我们会发现,这个时候sid会被清掉,clear 操作就是置全0,所以最终写入 binlog 的就是全0。

细心的同学会发现,当 gtid_next = automatic 的时候,也是会被 clear 的(automatic 对应的 group 是 AUTOMATIC_GROUP),其实如果 gtid_next = automatic 的话,只有在 binlog commit 的时候才调用 gtid_before_write_cache 生成 gtid,所以前面的 gtid_rollback 是不会影响 automatic 的。

关于不记 Executed_Gtid_Set 的问题,gtid_rollback 的时候,一方面通过 thd->variables.gtid_next.set_undefined() 把 gtid_next 的type设成UNDEFINED_GROUP,另一方面用 thd->clear_owned_gtids(),把 thd->owned_gtid 的 sidno 设为0,导致最终不会添加到 Executed_Gtid_Set 中。

bug修复

官方已经修复了这个bug,具体可以参见这2个 revno

revno: 5749 revno: 5751 主要是第一个,第二个是post-fix。修复方法是在 THD 中加一个标志 skip_gtid_rollback,在进入 mysql_admin_table 时先根据上下文设置thd->skip_gtid_rollback ,在退出mysql_admin_table 前重置标志,gtid_rollback 在执行clear前会判断下thd->skip_gtid_rollback。