在MySQL 5.7下采用多源复制方式，从5.6复制数据过来，会有问题吗？
Q群里有位朋友想尝鲜5.7的多源复制，于是用MySQL 5.7版本作为slave，把MySQL 5.6作为master，想要将数据进行汇总，发现此路不通。
他在my.cnf中设置了2个选项，开启并发复制：
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 4
启动复制线程后，结果在错误日志中不断有类似下面的信息：
Transaction is tagged with inconsistent logical timestamps: sequence_number (823267087) <= last_committed (1301275374434324336)
执行 SHOW SLAVE STATUS\G 查看状态：
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
…
Last_Errno: 1756
Last_Error: … The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details).
…
Last_SQL_Errno: 1756
Last_SQL_Error: … The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details).
…
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp: 160523 18:49:05
…
*************************** 2. row ***************************
Slave_IO_State: Waiting for master to send event
…
Last_Errno: 1756
Last_Error: … The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details).
Skip_Counter: 0
…
Last_SQL_Errno: 1756
Last_SQL_Error: … The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details).
…
上面这些错误提示可以看到，主要原因是：slave端采用了基于 LOGICAL_CLOCK 类型的并行复制，但master端的binlog格式并不支持这种方式，所以slave端无法正确读取binlog并行apply。
虽然仍旧可以采用MySQL 5.7作为slave，但就无法开启基于 LOGICAL_CLOCK 类型的并行复制了。需要改回传统模式就可以了：
slave_parallel_type = DATABASE
此外，在MySQL复制方案中，强烈建议不要让主从大版本不一样，很容易出现各种各样的问题。
关于MySQL的方方面面大家想了解什么，可以直接留言回复，我会从中选择一些热门话题进行分享。 同时希望大家多多转发，多一些阅读量是老叶继续努力分享的绝佳助力，谢谢大家 :)
最后打个广告，运维圈人士专属铁观音茶叶微店上线了，访问：http://yejinrong.com 直达