MySQL + Xenon

https://blog.csdn.net/qq_35029061/article/details/128466929

在 MySQL（5.5 及以下）传统复制的时代，MHA（Master High Availability）在 MySQL高可用应用中非常成熟。在 MySQL（5.6）及 GTID 时代开启以后，MHA 却没有与新的 MySQL 一起顺应时潮。

MHA 由日本DeNA 公司youshimaton 开发，他认为在 GTID 环境下 MHA 存在的价值不大，MHA 最近一次发版是 2018 年。现如今使用 MySQL 已离不开 GTID ，无论是从功能、性能角度，还是从维护角度，GTID 能具备更优异的表现，针对数据业务要求不高场景，常用GTID+ROW+Semi-Sync方案。

基于MHA和GTID发展现状，为适应 MySQL 版本更新的高可用业务场景，于是就有了可替代 MHA 的高可用方案：MySQL + Xenon。
一、全局事务标识符（GTID）
1、GTID 简介

GTID(Global Transaction ID)是对于一个已提交事务的编号，并且是一个全局唯一的编号。GTID实际上是由UUID+TID组成的。其中UUID是一个MySQL实例的唯一标识，保存在mysql数据目录下的auto.cnf文件里。TID代表了该实例上已经提交的事务数量，并且随着事务提交单调递增。

GTID的复制方式是从MySQL5.6.5开始的。通过GTID保证了每个在主库上提交的事务在集群中有一个唯一的ID。这种方式强化了数据库的主备一致性，故障恢复以及容错能力。相比传统的复制，GTID复制对于运维更加友好，根据GTID可以知道事务最初是在哪个实例上提交的，产生多少事物等，都可以非常直接的标识出来。
2、GTID工作原理

大致分为如下几个步骤：

master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。
slave端的i/o线程将变更的binlog，写入到本地的relay log中。
sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。
如果有记录，说明该GTID的事务已经执行，slave会忽略。
如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。

————————————————
版权声明：本文为CSDN博主「wespten」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_35029061/article/details/128466929