CentOS Stream 9 中部署 MySQL 8.0 MGR（MySQL Group Replication）一主两从高可用集群
🐇明明跟你说过：个人主页
🏅个人专栏：《MySQL技术精粹》🏅
🔖行路有良友，便是天堂🔖
目录
一、前言
1、MySQL 8.0 中的高可用方案
当你上线一个数据库服务时，最怕的是什么？当然是——挂了！⛔
所以，我们需要让数据库 高可用（High Availability），简单说就是：
“就算有节点崩了，服务也不能停！”
那 MySQL 有哪些高可用的方案呢？我们来一一介绍。
1️⃣ 主从复制（经典老搭档）👥
📝 原理：一个主库（Master）负责写，多个从库（Slave）负责读，通过 二进制日志（binlog）同步数据。
📌 优点：
- 架构简单，上手快
- 性能可接受，读写分离效果好
⚠️ 缺点：
- 没有自动故障转移（主挂了就得手动切）
- 延迟不可避免（主从延迟问题）
💬 通俗说法：
“老大干活，小弟抄笔记📓。老大病倒了，小弟要等人吩咐才能接手。”
2️⃣ MySQL InnoDB Cluster（基于 MGR）🔗
📝 原理：MySQL 8.0 官方推出的高可用方案，基于 Group Replication（MGR），多个节点之间通过组协议互相复制，保持一致性。
📌 优点：
- 官方支持，紧跟版本
- 支持自动故障转移（Single Primary 模式）
- 数据强一致性（保证写入顺序）
⚠️ 缺点：
- 写入冲突需要处理（多主模式下尤为严重）
- 对网络延迟敏感
- 配置复杂度高于主从
💬 通俗说法：
“兄弟三人轮流做老大👑，有规则决定谁上。兄弟有事，其他人自动接班，不用吩咐👌。”
3️⃣ MHA（MySQL High Availability）🛠️
📝 原理：由 Perl 脚本组成的主从复制管理器，能自动检测主库是否宕机，并迅速提升某个从库为新主。
📌 优点：
- 成熟稳定，广泛使用
- 可自动主从切换
⚠️ 缺点：
- 依赖外部监控与管理节点
- 依然是主从架构，存在数据延迟风险
- 项目已停止更新❌（社区维护中）
💬 通俗说法：
“一个看门人👀不停盯着老大，一旦倒下，赶紧推个新老大上位。”
4️⃣ Galera Cluster（三强联盟）🔄
📝 原理：多主同步复制（multi-master synchronous replication），所有节点都可以读写，数据写入同步确认。
📌 优点：
- 每个节点都能写（真正多主）
- 同步复制，强一致性
⚠️ 缺点：
- 网络要求高，对时延非常敏感
- 复杂度高，不适合大批量写入业务
💬 通俗说法：
“三个老大同时写作业📄，但必须每次都核对答案✅，才能交上去。”
5️⃣ ProxySQL + MGR / 主从（代理接力棒）🧠
📝 原理：通过 ProxySQL 把数据库访问做中间层代理，实现读写分离、故障转移等功能。
📌 优点：
- 灵活控制流量
- 可以和多种架构组合
- 支持连接池、SQL 规则分发
⚠️ 缺点：
- 需要额外组件维护
- 配置略复杂
💬 通俗说法：
“在你和数据库之间加个智商超高的中间人🧑⚖️，谁有能力他就安排谁来处理。”
2、适用场景
1️⃣ 主从复制（经典老将）👥
适用场景：
- 🧾 内容管理系统、博客、论坛等中小型网站
- 📊 对写入要求不高，读多写少
- 🧰 开发测试环境，数据可容忍一定延迟
2️⃣ MGR（MySQL Group Replication）📦【官方推荐】
适用场景：
- 🏦 银行、支付、电商等核心系统
- 🛡️ 不能丢数据、强一致性要求
- 🚨 需要自动故障转移、无需人工干预
3️⃣ MHA（MySQL High Availability）🛠️【经典成熟方案】
适用场景：
- 🏢 传统企业系统
- ✅ 使用已有主从架构，想补上自动故障转移
- 💼 中小型业务但需要保障主库稳定运行
4️⃣ Galera Cluster（真正多主）🌀
适用场景：
- 🌍 跨地域写入需求
- 👩💻 同步数据共享协作系统（如 CRM、OA）
- 💾 高并发小事务业务（例如即时通信、IoT 数据采集）
5️⃣ MyS
