写第一篇，意味着还有第二篇的内容，这个也是自己今天偶然发现的问题。同事之前碰到了一个MySQL服务不断重启的问题，究其原因，其实倒还合理，今天的这个问题比较纠结，看起来好像没有直接的联系，问题算是比较诡异。

我简单复现下这个问题，我在5.7.19的版本中做了测试，可以复现。

首先搭建一主两从的测试环境，使用sandbox或者是我自己写的shell版本也可以，具体可以参考:https://github.com/jeanron100/mysql_slaves

我配置的环境如下，端口分别为10010和10020

10010 n1 Y

10020 n2 N

运行脚本init.sh大概也就一分钟就会搭建好了，参数文件的设置如下，GTID是开启的。

datadir=/U01/mysql_5.7_repl/n1

basedir=/usr/local/mysql_5.7

port=10010

socket=/U01/mysql_5.7_repl/n1/n1.sock

server_id=10010

gtid_mode=ON

enforce_gtid_consistency=ON

master_info_repository=TABLE

relay_log_info_repository=TABLE

binlog_checksum=NONE

log_slave_updates=ON

log_bin=binlog

binlog_format=ROW

主从的配置是差不多的，复制关系没有问题。

然后我们停止从库，把从库的GTID设置从配置文件删除,即删除参数。

gtid_mode=ON

enforce_gtid_consistency=ON

然后启动之后，MySQL服务竟然能够正常启动，在5.7.16的版本中测试时会出现不断重启的问题。当然启动之后，slave的线程是无法启动的。

mysql> start slave;

ERROR 3112 (HY000): The replication receiver thread for channel '' cannot start in AUTO_POSITION mode: this server uses @@GLOBAL.GTID_MODE = OFF.

提示很明显，是GTID的问题。

这个时候主库端已经没有了从库的连接，因为IO_Thread还没有建立关联。

我们这个时候保留主库GTID的配置，保留从库的服务，停止主库，使用mysqladmin shutdown 的方式。主库的操作命令就会hang住了。

mysqld的服务没了踪影，但是mysqladmin的命令卡在了那里。

魔性的一点是mysqld的服务已经停止了，我重启还是能够正常启动，但是mysqladmin的进程一直挂在那里。这个就有些不太合理了。

而问题的解决方法有两个，一个是删除主库的GTID配置，另外一个是停止从库（或者保留从库GTID配置，暂且启动）

这个问题的方向已经明确，和不规范的配置，不规范的操作有关，但是这个问题的结果还是有些出人意料。后续再来解读。