写第一篇，意味着还有第二篇的内容，这个也是自己今天偶然发现的问题。同事之前碰到了一个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配置，暂且启动）
这个问题的方向已经明确，和不规范的配置，不规范的操作有关，但是这个问题的结果还是有些出人意料。后续再来解读。