MySQL支持复制到一个更高版本的slave，这允许我们通过升级从机和指向应用程序来轻松地将MySQL设置升级到一个新版本。但如果不支持或者是应用程序在旧版本的MySQL上表现得更好，我们就需要通过降级来提升slave性能。

MySQL手册表示基于行的复制可以用于复制到较低版本，前提是没有复制的DDL与从服务器不兼容。其中有一个不兼容命令是MySQL 5.7中的新特性，5.6上版本不可用：

ALTER USER 'testuser'@'localhost' IDENTIFIED BY 'testuser';

执行该命令会中断复制。这里是一个在非GTID复制中被破坏的奴隶的例子：

跳过该语句不会恢复复制：

mysql> STOP SLAVE;Query OK, 0 rows affected (0.02 sec)mysql> SET GLOBAL sql_slave_skip_counter=1;Query OK, 0 rows affected (0.00 sec)mysql> START SLAVE;Query OK, 0 rows affected (0.01 sec)mysql> SHOW SLAVE STATUS\G

修复非GTID复制

当检查从机状态时，复制仍然未修复。要修复它，必须手动跳转到下一个二进制日志位置。当前执行的二进制日志(Relay_Master_Log_File)和位置(Exec_Master_Log_Pos)分别是mysql-bin.000002和36174373。我们可以在主机上使用MySqLBiLoSQL来确定下一个位置：

基于上述输出，下一个二进制日志位置为36174621。修复slave，运行：

STOP SLAVE;CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=36174621;START SLAVE;

验证从属线程现在是否正在执行：SHOW SLAVE STATUS\G

为了使主从一致，对从属执行兼容查询。

SET SESSION sql_log_bin = 0;GRANT USAGE ON *.* TO 'testuser'@'localhost' IDENTIFIED BY 'testuser';

GTID复制

对于GTID复制，除了为冒犯语句注入空事务之外，还需要使用上面提供的非GTID解决方案跳过它。一旦运行，将其翻转回到GTID。

下面是一个中断的GTID slave的例子：

由于执行的最后一个位置是7403，所以需要为违规序列7404创建一个空事务。

STOP SLAVE;SET GTID_NEXT='00005723-0000-0000-0000-000000005723:7404';BEGIN;COMMIT;SET GTID_NEXT=AUTOMATIC;START SLAVE;

注意：如果您启用了MTS，您也可以从显示Last_SQL_Error of SHOW SLAVE STATUS\G获得违反GTID坐标。

下一步是找到下一个二进制日志位置。当前执行的二进制日志(Relay_Master_Log_File)和位置(Exec_Master_Log_Pos)分别是mysql-bin.000003和12468343。我们可以再次在主机上使用MySqLBiLoSQL来确定下一个位置：

下一个二进制日志位置是36174621。修复从站，运行

STOP SLAVE;CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=12468591, MASTER_AUTO_POSITION=0;START SLAVE;

注意，我在上面添加MaskAutoPosil=0，现在禁用GTID复制。您可以运行SHOW SLAVE STATUS\G以确定MySQL运行良好：

因为运行良好，现在可以恢复GTID复制：

STOP SLAVE;CHANGE MASTER TO MASTER_AUTO_POSITION=1;START SLAVE;

最后，为了使主从一致，对从属执行兼容查询。

SET SESSION sql_log_bin = 0;GRANT USAGE ON *.* TO 'testuser'@'localhost' IDENTIFIED BY 'testuser';

在本文中，我分享了如何修复由于向从属复制不兼容的命令而导致复制中断时的复制。如果有其它不兼容的命令，欢迎大家在下方评论。