🐇明明跟你说过：个人主页
🏅个人专栏：《MySQL技术精粹》🏅
🔖行路有良友，便是天堂🔖
目录
一、前言
1、MySQL 8.0 中的高可用方案
2、适用场景
二、环境准备
1、系统环境说明
2、主机规划
3、系统基础配置
三、高可用搭建
1、安装MySQL
2、启动MySQL
3、修改配置文件
4、配置高可用
5、高可用测试
6、集群恢复
一、前言
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
