🚀 博主介绍：大家好，我是无休居士！一枚任职于一线Top3互联网大厂的Java开发工程师！ 🚀
🌟 在这里，你将找到通往Java技术大门的钥匙。作为一个爱敲代码技术人，我不仅热衷于探索一些框架源码和算法技巧奥秘，还乐于分享这些宝贵的知识和经验。
💡 无论你是刚刚踏入编程世界的新人，还是希望进一步提升自己的资深开发者，在这里都能找到适合你的内容。我们共同探讨技术难题，一起进步，携手度过互联网行业的每一个挑战。
📣 如果你觉得我的文章对你有帮助，请不要吝啬你的点赞👍分享💕和评论哦！ 让我们一起打造一个充满正能量的技术社区吧！
目录标题
- MySQL 主从复制中的问题
- GTID
- GTID和Binlog的关系
- 总结
MySQL 数据库集群主要有两部分组成，分别是 Master 节点和 Worker 节点。其中，Master 节点主要负责写的工作，Worker 节点主要负责读的工作。
这时我们很容易就能想象到，如果某个 Worker 节点宕机也就意味着少了一个读节点，对于整个 MySQL 数据库集群来讲影响有限；但是如果是一个 Master 节点宕机的话，对于整个 MySQL 集群来讲是毁灭性的，因为此时的 MySQL 整个集群完全处于可读状态。
那么今天我们就来聊一聊，如果 MySQL 集群的主节点出现问题时，那么整个 MySQL 集群该如何调整。
MySQL 主从复制中的问题
在 MySQL 5.6 之前，MySQL 主从复制主要是通过 binlog 日志的偏移量来实现的主从复制。
假设现在有 A、B 和 C 三台 MySQL 数据库，A 为 B 和 C 的主库的话，一般需要在 B 和 C 节点上执行如下命令：
[root@slave1 ~]# mysql -uroot -p123456 # 登录然后执行
change master to
master_host='A服务器的IP'
