MySQL DBA系列001-mha4mysql-manager已停更，生产环境你还敢使用吗？_mha是不是已经停止维护了

MySQL DBA系列001-mha4mysql-manager已停更，生产环境你还敢使用吗？

前情摘要

1、由于MHA（mha4mysql-manager）工具在 2018年 已经停止维护更新，且不支持GTID复制模式。
2、目前主流版本MySQL 5.7和8.0的复制模式是基于Gtid，因事务号是唯一的，更改同步复制源不需要知道binlog文件名和position位置点，看来开源的尽头是商业和资本化啊。

所谓MHA-Re-Edition 复刻版简介

MHA-Re-Edition 复刻版简介的相关介绍链接如下。

https://github.com/hcymysql/MHA-Re-Edition
1

MySQL开源高可用方案建议

MySQL主从还是可以做很多文章的。

MySQL主从复制架构

MySQL 配置为主从模式，从库是主库的 backup，同一时间设置其中一台为主服务器，提供读写，另一台服务器作为热备，不提供读写，通过复制与主服务器数据保持一致，二者均开启 binlog。
至于到底是单主单从，还是单主多从，那就看您的实际需求了。

MHA架构（已废弃）

如上所说，已于2018废弃。
MHA（Master High Availability）在 mysql 高可用方面是一个相对成熟的解决方案。在 mysql 故障切换的过程中，MHA 能做到在 0-30 秒之内自动完成数据库的故障切换工作，并且在进行故障切换的过程中，MHA 能在最大程度上保证数据的一致性，已达到真正意义上的高可用，但 GTID 出现后 MHA 功能弱化。

PXC架构

集群架构原理（PXC）：节点接收 sql 请求后，对于 ddl 操作，在 commit 之前，由 wsrep API 调用 galera 库进行集群内广播，所有其他节点验证成功后事务在集群所有节点进行提交，反之 roll back。PXC 保证整个集群所有数据的强一致性，满足：Consistency和Availability。

MySQL集群实现

1. 上层中间调度如 HAproxy
2. 调度到的 Node上进行读写
3. 同步至其他两个节点

MySQL 集群关键技术

同步复制、wsrep 插件技术

MySQL主从复制出现数据不一致的可能原因

1. 主从时钟是否一致
2. 网络通信是否存在延迟
3. 是否和日志类型，数据过大有关
4. 从库性能，有没开启 binlog
5. 从库查询是否优化
6. 主库或者从库压力过大，有较大的事务
7. 磁盘IO或者网络吞吐量受限