转自：MySQL：主从复制从库GTID大量空洞的问题

一、问题来源

这是今天要到的一个问题，由朋友杨长江提交给我，版本5.7.17。如下：
MySQL：主从复制从库GTID大量空洞的问题 - 图1这里只是部分截屏，GTID SET已经分成了无数段。正常情况下我们的从库GTID SET应该是不会出现这种大量的空洞的，并且每次都丢失了一个GTID。我相信遇到这个问题的朋友也不在少数。如果这个时候从库从库，那么回根据GTID的下限去主库拿GTID信息，但是主库先然已经清理了这些GTID信息必然会导致报错。

二、相关BUG

已知的一个BUG是skip-slave-error参数设置问题，而且这个BUG再8.0.25依旧存在，参考如下：

而拿到朋友的参数文件后，发现并没有设置skip-slave-error参数，那么是其他什么BUG导致的呢？实际上这个BUG是5.7.23以下的版本，并且设置了replicate_wild_do_table等过滤规则会后对CREATE DATABASE/ALTER DATABASE/DROP DATABASE会过滤掉操作，并且从库的GTID也会被抛弃掉，这样就产生了大量的空洞。

  1. When ever a statement is getting filtered out due the filter
  2. rule, server adds the gtid of the filtered transaction to GTID_EXECUTED_SET
  3. by executing an empty transaction on the slave. So that the same transaction will be replicated again in case of
  4. re connections and also GTID_EXECUTED_SET will not have any GAPS.
  5. But this is *not* happening in case of three statements that are
  6. mentioned in problem description (CREATE/ALTER/DROP DATABASE).
  7. Code has re factored to make sure that an empty transaction
  8. will be executed for these three statements (CREATE/ALTER/DROP DATABASE)
  9.     also.

稍微浏览修改，如BUG描述增加对database操作的判定。 

  1. +  if (db_ok &&
  2. +      (rpl_filter->get_do_db()->is_empty() &&
  3. +       rpl_filter->get_ignore_db()->is_empty()))
  4. +  {
  5. +    switch (sql_cmd) //下面是DB相关的操作
  6. +    {
  7. +    case SQLCOM_CREATE_DB:
  8. +    case SQLCOM_ALTER_DB:
  9. +    case SQLCOM_ALTER_DB_UPGRADE:
  10. +    case SQLCOM_DROP_DB:
  11. +      db_ok= rpl_filter->db_ok_with_wild_table(db);
  12. +    default:
  13. +      break;
  14. +    }
  15. +  }

如果使用较老的版本应该注意这个奇特的问题。