mysql gtid复制 临时表为什么是不安全的事务

GTID 对于单源复制还是很方便，但是对于多源复制，这里就需要特别注意：

要先停止所有的从库 stop slave

然后清理本机所有的 GTID，reset master

再进行 SET @@GLOBAL.GTID_PURGED='xxxxx' gtid 设置

这里就会引入一个问题，如果是级联复制的情况下，reset master 的时候，会把本机的所有 binlog 清理掉。如果下一级的从库存在延迟，没有及时的把 binlog 传过去，就会造成主从中断，这里我们该怎么避免呢？看这里：

做 reset master 的时候，先看看下游的从库是否存在很大的延迟。如果存在，把当前的 binlog 和后面未同步的 binlog 全部备份下；

待添加好从库的 channel 后，再把未同步的 binlog 文件手动拷贝到 binlog 目录；

更新下 mysql-bin.index 文件；

注意，binlog 不能同名，需要手动更新下文件。

这是今天要到的一个问题，由朋友 杨长江 提交给我，版本5.7.17。如下：

已知的一个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也会被抛弃掉，这样就产生了大量的空洞。

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

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

---