MySQL 5.6 OCP 1Z0-883：解决 Slave 错误与重置GTID策略

在MySQL 5.6的OCP考试题库1Z0-883中，一个关于简单主从复制场景的问题被提出。题目背景是，当前存在一个主从复制配置，但出现了`Duplicate entry '8' for key 'PRIMARY'`的错误，这是在尝试插入数据时由于主键冲突导致的。具体情境是在slave上，查询表`mytable`时，发现该表的结构与主库的结构不符，主库的`mytable`表定义有一个`ID`字段为主键，而slave上的表没有这个约束。 问题的关键点在于如何解决这个问题，以便能够重新启动slave以执行后续的SQL语句。以下是对每个选项的详细解释： A) `SETGLOBAL SQL_SKIP_SLAVE_COUNTER=1` 此选项设置的是跳过复制计数器，但并不能解决主键冲突问题，而是可能导致数据丢失，因此不是正确选择。 B) `SET GTID_NEXT="CONSISTENCY"; BEGIN; COMMIT; SET GTID_NEXT="AUTOMATIC"` 这两个连续的语句是用于设置GTID（Global Transaction Identifier）模式的，用于协调跨多个数据库的事务。在这种情况下，它们无助于处理当前的主键冲突，所以不合适。 C) `SETGLOBAL enforce_gtid_consistency=ON` 这个设置强制启用全局事务一致性检查，对于解决主键冲突没有直接帮助，它主要用于确保事务在分布式环境中的一致性，不是针对这个特定错误的解决方案。 D) `SETGTID_EXECUTED="38f32e23480a7-32a1-c323f78067fd37821:9"` 这个选项试图设置已经执行过的GTID范围，但这同样无法解决主键冲突问题，因为它是针对已经完成的事务的。 E) `SETGTID_NEXT="38f32e23480a7-32a1-c323f78067fd37821:9"; BEGIN; COMMIT; SETGTID_NEXT="AUTOMATIC"` 这个选项序列与B选项类似，先设置了GTID模式，然后开始并提交了一个事务，最后切换到自动模式。然而，这些操作不能直接处理主键冲突，且事务在此场景下并不适用。 正确的步骤应该是先修复slave上表的结构，使其与主库一致，即添加`ID`字段的主键约束，然后再恢复复制。然而，由于提供的选项中没有明确的修复表结构的选项，我们可能需要回到主库执行相应的ALTER TABLE语句来添加主键，或者在slave上创建一个新的表并导入数据，然后手动删除或忽略引发错误的插入语句。 因此，没有直接的选项可以解决问题，但实际操作中可能需要手动干预。如果答案中包括了修复表结构的选项，那么可能是D或E选项后跟一个修复表的命令，比如： 正确答案可能会是： F) `ALTER TABLE mytable ADD COLUMN ID INT(11) NOT NULL DEFAULT 0 PRIMARY KEY;` (假设在主库上执行) 然后在修复了表结构后，可以执行其中一个GTID相关的语句（如E选项），接着再执行`START SLAVE`来继续复制。 总结来说，这道题目主要考察考生对MySQL主从复制、事务处理以及解决主键冲突的理解，同时测试他们在实际问题中的问题解决能力。