MHA作为MySQL5.7版本下传统复制下的高可用霸主，依旧在MySQL5.7的高可用架构中占据主流地位。
且MHA在MYSQL5.7版本后已经不再更新，这意味着继续使用MHA搭建MySQL8.0的高可用性架构存在不稳定性和不确定性，虽然有人依旧在这么干。
在GTID环境下，MHA随着MySQL8.0版本的推出，慢慢走向没落；
大家开始选择replication-manager或者orchestrator等高可用解决方案。
不足及风险点：
1、failover依赖于外部脚本，比如VIP切换需要自己编写脚本实现
2、MHA启动后只检测主库是否正常，并不检查从库状态及主从延迟
3、需要基于SSH免认证配置，存在一定的安全隐患
4、没有提供从服务器的读负载均衡功能
5、从节点出现宕机等异常并没有能力处理，即没有从库故障转移能力
6、在高可用切换期间，某些场景下可能出现数据丢失的情况，并不保证数据0丢失
7、无法控制RTO恢复时间
【摘文链接】
https://www.modb.pro/db/12071
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
