我按照此page上的步骤进行操作
STOP SLAVE;
SET GTID_NEXT="[THE GTID SET]";
BEGIN; COMMIT;
SET GTID_NEXT="AUTOMATIC";
START SLAVE;
恢复奴隶。但就我而言，gtid_set是
Retrieved_Gtid_Set: 8b6d4795-5ad3-11e6-a31f-00259077c77a:2369-2377
Executed_Gtid_Set: 8b6d4795-5ad3-11e6-a31f-00259077c77a:1-2372:2374,8be5b0ba-5ad3-11e6-a31f-0cc47a50d072:1-12
当我尝试向从服务器注入空事务并重新启动从服务器时，“ slave_SQL_Running”仍然为“ No”。
STOP SLAVE;
SET GTID_NEXT="8b6d4795-5ad3-11e6-a31f-00259077c77a:2377";
BEGIN; COMMIT;
SET GTID_NEXT=AUTOMATIC;
START SLAVE;
它变成
Retrieved_Gtid_Set: 8b6d4795-5ad3-11e6-a31f-00259077c77a:2369-2377
Executed_Gtid_Set: 8b6d4795-5ad3-11e6-a31f-00259077c77a:1-2372:2374:2377,8be5b0ba-5ad3-11e6-a31f-0cc47a50d072:1-12
当新数据插入到主服务器后，从服务器仍无法与主服务器同步。
状态变为：
Retrieved_Gtid_Set: 8b6d4795-5ad3-11e6-a31f-00259077c77a:2369-2378
Executed_Gtid_Set: 8b6d4795-5ad3-11e6-a31f-00259077c77a:1-2372:2374:2377,8be5b0ba-5ad3-11e6-a31f-0cc47a50d072:1-12
我该如何工作？
我不想进行完全转储，因为有很多数据，而完全转储需要很多时间。
最佳答案
请检查下面的博客文章。
https://www.abhinavbit.com/2019/05/gtid-replication-skip-transaction-using.html
在您的情况下，您应该运行以下命令来跳过sql线程错误。
STOP SLAVE;
SET GTID_NEXT="8b6d4795-5ad3-11e6-a31f-00259077c77a:2375";
BEGIN; COMMIT;
SET GTID_NEXT=AUTOMATIC;
START SLAVE;
关于mysql - 注入(inject)空事务以修复MySQL 5.6 GTID复制不起作用，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/38970375/