这里我们来分析什么场景可能会出现不连续的GTID

并行复制

并行复制的事务处于并行执行状态，GTID集合（Executed_Gtid_Set）出现空洞是正常现象，并且在并行复制完成后会最终一致

人为修改GTID_NEXT

人工的指定GTID_NEXT为具体值时（SET GTID_NEXT=’‘），在Executed_Gtid_Set尾部可能导致正常的GTID空洞
重新执行SET GTID_NEXT=’AUTOMATIC’;后，MySQL会分配一个最小的未使用的GTID，此处就是d9dd8550-1f4c-11e7-a44b-cbca9484dbbd:11，这种情况不需要修复
所以，严格来讲同一个具有server-uuid下的GTID的大小不严格代表了事务执行的先后关系，要以记录到binlog的先后顺序为准
比如：

  • gtid_executed = uuid:1-10
  • SET GTID_NEXT = uuid:15
  • 执行事务T1（uuid:15）
  • SET GTID_NEXT = AUTOMATIC
  • 执行事务T2（uuid:11）

  • 那么，T1的GTID大于T2，但T1早于T2执行

    FILE & POS的故障修复

    在GTID（二）：集群中的数据同步中的【情况2】->【解决方法1】中已详细说明，由于Master删除了部分Slave还没有同步的数据（GTIDs），导致START SLAVE后报错
    【解决方法1】使用传统复制方法来解决，CHANGE MASTER TO … FILE & POS
    那么，例如：
    Master / Slave数据已同步
    — Slave

  • STOP SLAVE

  • Slave gtid_executed = master_uuid: 1 - 10

— Master

  • 当前binlog为master-bin.000005
  • 执行一些事务 …
  • Master gtid_executed = master_uuid: 1 - 20
  • 然后binlog为master-bin.000007
  • PURGE BINARY LOGS TO ‘master-bin.000007’（比如master-bin.000007中的GTIDs为master_uuid: 16 - 20）
  • 此时删除的master-bin.000006包含的全部是Slave没有执行的事务
  • Master gtid_purged = master_uuid：1 - 15

— Slave

— Master

  • SHOW MASTER STATUS：File = master-bin.000007, Pos = 100

— Slave

  • CHANGE MASTER TO, MASTER_LOG_FILE=’master-bin.000007’, MASTER_LOG_POS=100;
  • Slave便会从下一个新的事务（master_uuid: 21）开始复制了
  • Slave gtid_executed = master_uuid: 1 - 10，21 - …