MySQL 5.6 create table like 同步异常问题分析与总结

我们都知道，mysql5.6版本如果设置了enforce-gtid-consistency=true，则mysql禁止执行create table ... select ...语句，原因是这条语句在mysql内部会被分解成一个dml事务和一个ddl事务，但这两个事务用同一个gtid，binlog同步到从库后，第二个dml语句因为相同gtid的事务已经执行过而被丢弃，造成数据不一致（详见MySQL官方说明：http://dev.mysql.com/doc/refman/5.6/en/replication-features-create-select.html）。凑巧，前几天遇到到一个线上环境主从同步失败的问题，当时因为mysql 5.6 有对create table ... select ...语句的限制，怀疑是一位同事之前做了create table ... like ... 操作导致数据同步失败，于是就研究了一下复制参数对于create table ... like ... 的影响，如下：

 先说一下结论：
1. binlog 格式为行模式（row）时，ddl在binlog中实际以语句的形式存在。
2. 行模式下，replicate-wild_ignore_table=test.%，对于create table like 语句，只要目标表所在的库或参照表所在的库为test，则salve将忽略这条事务（event）。
3. 行模式下，当前库是否是test库，对slave确定是否忽略本条事务不起作用。

 线上对create table ... like ... 有影响的复制参数如下：
replicate_wild_ignore_table=information_schema.%
replicate-wild_ignore_table=performance_schema.%
replicate-wild_ignore_table=test.%

enforce-gtid-consistency=true

说明：上面三条复制过滤规则中，只有replicate-wild_ignore_table=test.%是实际生效的，其余因为实际上是系统视图，没有基表，无效。

首先在主库上执行上述对照组：

 test@20:39:55> create table test.test_d like test.t_store;
Query OK, 0 rows affected (0.04 sec)

执行完后看主库上的8张表都被成功创建,如下：
test@21:03:35> show tables;
+------------------------+
| Tables_in_test        |
+------------------------+
| b_goods_promotion      |
| b_goods_promotion_rela |
| binlog_test            |
| t_store                |
| t_user_merchant        |
| test                  |
| test_a                |
| test_b                |
| test_c                |
| test_d                |
| user_merchant          |
+------------------------+
11 rows in set (0.00 sec)

 Database changed
test@20:40:58> show tables;
+----------------+
| Tables_in_test |
+----------------+
| tmp_1126      |
+----------------+
1 row in set (0.00 sec)

 test@20:41:00>