关于MySQL GTID的一次深刻学习( 三 )_最近因为一个特别的操作需求

其实这是因为在数据库运行过程中确实发生了两次切换导致，也通过这种方式能够清晰的记录下来GTID的变更历史，这本来没什么好说的，在配置反向关系的时候抛出了错误。

Last_IO_Errno: 1236Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1 but the master has purged binary logs containing GTIDs that the slave requires.'

从错误信息来看， Master切换之后， Slave变成了主库，这个时候数据写入就在Slave端了，然后业务再次切换后数据开始在Master写入。这个过程中的切换会导致一部分的binlog写入是在Slave端生成，而这部分的binlog显然随着时间的变化会自动被服务清理掉。如果报出这样的错误，实在是比较尴尬和无奈的事情了，换句话说，我们要关注当前的状态和后续的改变， binlog我们不可能自始至终保留，而且就算保留拿来恢复也不显示，所以在这个过程中一定有什么特别的地方。