各位观众老爷，大家好！我是今天的主讲人，江湖人称“数据库老司机”，今天咱们聊聊MySQL高可用架构的那些事儿，重点是MGR（MySQL Group Replication）和PXC（Percona XtraDB Cluster）。都是扛把子的选手，但特性、优缺点各异，选哪个，得根据你的实际情况。
咱们直接上干货！
一、高可用架构的必要性：别等到“宕机”才后悔
先问大家一个问题：你的数据值多少钱？你的业务中断一分钟，损失多少？
别跟我说不值钱，现在这个时代，数据就是金钱！单点故障的MySQL服务器就像一个随时可能爆炸的定时炸弹，别侥幸，炸一次，你就知道啥叫“欲哭无泪”了。
高可用架构，就是通过冗余和故障转移机制，保证数据库持续可用。即使一台服务器挂了，另一台也能顶上，业务照常运行，老板照常发工资（当然，如果老板也挂了，那就…）。
二、MGR：MySQL官方的“亲儿子”，强一致性的代表
MGR，MySQL Group Replication，是MySQL官方提供的基于Paxos协议的分布式一致性方案。简单来说，就是一群MySQL节点组成一个组，每个事务都要经过组内多数节点的同意才能提交。
-
MGR的核心原理：Paxos协议的变种
Paxos协议太复杂？没关系，记住核心思想：提案（Proposal）、接受（Accept）、提交（Commit）。
- 提案：主节点（Primary，虽然MGR可以自动选主，但概念上还是有主节点）发起一个事务提案。
- 接受：组内其他节点收到提案后，如果没问题（没有冲突），就接受这个提案。
- 提交：当超过半数的节点接受了提案，主节点就提交这个事务。
这就保证了数据在多个节点上的一致性。
-
MGR的模式：单主模式（Single-Primary）和多主模式（Multi-Primary）
- 单主模式：只有一个节点可以写数据，其他节点只读。优点是简单，避免写冲突；缺点是写性能受主节点限制。
- 多主模式：所有节点都可以写数据。优点是写性能高；缺点是容易产生写冲突，需要冲突检测机制。
一般情况下，推荐使用单主模式，除非你的应用场景对写性能要求极高，且能容忍一定的冲突风险。
-
MGR的优点：
- 强一致性：数据一致性是MGR最大的优势，保证了数据不会丢失或错乱。
- 自动故障转移：主节点挂了，会自动选出新的主节点，无需人工干预。
- MySQL官方支持：是MySQL官方提供的解决方案，兼容性好，文档齐全。
- 易于管理：相比其他方案，MGR的配置和管理相对简单。
-
MGR的缺点：
- 性能开销：为了保证一致性，每个事务都需要经过多轮通信，性能会有一定损耗。
- 对网络要求高：网络延迟会影响事务提交速度，对网络环境要求较高。
- 脑裂问题：虽然MGR有内置的脑裂防护机制，但极端情况下仍可能发生脑裂，需要额外监控和处理。
-
MGR的配置示例（基于MySQL 8.0）：
假设我们有三个节点：node1 (192.168.1.101)，node2 (192.168.1.102)，node3 (192.168.1.103)。
-
通用配置（所有节点）：
# 编辑 MySQL 配置文件 (my.cnf 或 my.ini) [mysqld] server-id=1 # 每个节点的 server-id 必须唯一 gtid_mode=ON enforce_gtid_consistency=ON log_slave_updates=ON binlog_checksum=NONE binlog_format=ROW transaction_write_set_extraction=XXHASH64 loose-group_replication_group_name="aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee" # 所有节点必须相同 loose-group_replication_start_on_boot=ON loose-group_replication_bootstrap_group=OFF # 只有第一个节点启动时需要设置为 ON loose-group_replication_local_address="192.168.1.101:33061" # 每个节点的地址和端口 loose-group_replication_group_seeds="192.168.1.101:33061,192.168.1.102:33061,192.168.1.103:33061" # 所有节点地址和端口 plugin_load_add = group_replication.so # 加载插件解释：
server-id：每个节点的唯一标识，必须不同。gtid_mode=ON：开启 GTID (Global Transaction Identifier)，用于全局事务标识。enforce_gtid_consistency=ON：强制 GTID 一致性。log_slave_updates=ON：从节点也要记录 binlog，用于数据同步。binlog_format=ROW：使用 ROW 格式的 binlog，保证数据一致性。transaction_write_set_extraction=XXHASH64：使用 XXHASH64 算法提取事务的 write set，用于冲突检测。loose-group_replication_group_name：MGR 组的唯一标识，所有节点必须相同。loose-group_replication_start_on_boot：开机自动启动 MGR。loose-group_replication_group_seeds：MGR 组的成员列表，所有节点都要能访问到。loose-group_replication_local_address：本节点的 MGR 地址和端口。
-
初始化第一个节点 (node1)：
# 登录 MySQL mysql -u root -p # 设置 group_replication_bootstrap_group=ON SET GLOBAL group_replication_bootstrap_group=ON; # 启动 MGR START GROUP_REPLICATION; # 设置 group_replication_bootstrap_group=OFF SET GLOBAL group_replication_bootstrap_group=OFF; # 修改 root 密码 (重要！) ALTER USER 'root'@'localhost' IDENTIFIED BY 'YourNewPassword'; ALTER USER 'root'@'%' IDENTIFIED BY 'YourNewPassword';解释：
SET GLOBAL group_replication_bootstrap_group=ON：只有第一个节点启动时需要设置，用于初始化 MGR 组。START GROUP_REPLICATION：启动 MGR。SET GLOBAL group_replication_bootstrap_group=OFF：初始化完成后，需要关闭这个选项。
-
加入其他节点 (node2 和 node3)：
# 登录 MySQL mysql -u root -p # 启动 MGR START GROUP_REPLICATION; # 修改 root 密码 (重要！) ALTER USER 'root'@'localhost' IDENTIFIED BY 'YourNewPassword'; ALTER USER 'root'@'%' IDENTIFIED BY 'YourNewPassword';解释：
- 直接启动 MGR 即可，会自动加入现有组。
-
验证 MGR 状态：
# 登录任何一个节点 mysql -u root -p # 查看 MGR 状态 SELECT * FROM performance_schema.replication_group_members; # 查看 MGR 拓扑 SELECT * FROM performance_schema.replication_group_member_stats;如果看到所有节点的状态都是
ONLINE，恭喜你，MGR 集群搭建成功！
-
三、PXC：Percona XtraDB Cluster，基于Galera的“开源明星”
PXC，Percona XtraDB Cluster，是Percona公司基于Galera Cluster技术开发的MySQL高可用解决方案。Galera Cluster是一个同步复制的集群方案，保证所有节点上的数据完全一致。
-
PXC的核心原理：Galera Cluster的同步复制
Galera Cluster采用同步复制，每个事务在提交之前，都会同步到所有节点。只有所有节点都成功写入，事务才能提交。
- Write-Set复制：Galera Cluster复制的是事务的Write-Set，而不是整个binlog。Write-Set包含了事务修改的数据和元数据。
- 认证（Certification）：在提交事务之前，Galera Cluster会对Write-Set进行认证，检查是否存在冲突。如果存在冲突，事务将被回滚。
- 流控（Flow Control）：Galera Cluster使用流控机制来防止节点之间的数据差异过大。如果某个节点落后太多，会被暂停写入，直到追上其他节点。
-
PXC的优点：
- 真正的多主架构：所有节点都可以读写，没有主从之分。
- 近乎同步复制：数据一致性非常高，延迟很低。
- 自动节点加入：新节点加入集群时，会自动从现有节点复制数据。
- 开源免费：PXC是开源的，可以免费使用。
-
PXC的缺点：
- 对网络要求极高：同步复制对网络延迟非常敏感，网络不稳定会导致性能下降。
- 写冲突处理：虽然有冲突检测机制，但仍可能发生写冲突，需要应用层处理。
- 事务大小限制：为了保证性能，Galera Cluster对事务大小有限制。
- 复杂性较高：PXC的配置和管理相对复杂，需要一定的经验。
-
PXC的配置示例（基于Percona XtraDB Cluster 8.0）：
假设我们有三个节点：node1 (192.168.1.101)，node2 (192.168.1.102)，node3 (192.168.1.103)。
-
通用配置（所有节点）：
# 编辑 MySQL 配置文件 (my.cnf 或 my.ini) [mysqld] server-id=1 # 每个节点 server-id 必须唯一 binlog_format=ROW default_storage_engine=InnoDB innodb_autoinc_lock_mode=2 query_cache_size=0 query_cache_type=0 bind-address=0.0.0.0 # 监听所有地址 # Galera 配置 wsrep_on=ON wsrep_cluster_name="my_pxc_cluster" # 集群名称，所有节点必须相同 wsrep_cluster_address="gcomm://192.168.1.101,192.168.1.102,192.168.1.103" # 集群节点地址 wsrep_node_name="node1" # 节点名称，每个节点必须唯一 wsrep_node_address="192.168.1.101" # 节点地址 wsrep_provider=/usr/lib64/galera4/libgalera_smm.so # Galera 库文件路径 wsrep_sst_method=xtrabackup-v2 # SST 方法，用于节点加入时的全量数据复制 wsrep_sst_auth="sstuser:YourSSTPassword" # SST 用户名和密码解释：
server-id：每个节点的唯一标识，必须不同。binlog_format=ROW：使用 ROW 格式的 binlog，保证数据一致性。wsrep_on=ON：开启 Galera 集群。wsrep_cluster_name：PXC 集群名称，所有节点必须相同。wsrep_cluster_address：PXC 集群节点地址，用逗号分隔。wsrep_node_name：节点名称，每个节点必须唯一。wsrep_node_address：节点地址。wsrep_provider：Galera 库文件路径，根据实际情况修改。wsrep_sst_method：SST (State Snapshot Transfer) 方法，用于节点加入时的全量数据复制。wsrep_sst_auth：SST 用户名和密码，用于数据复制的身份验证。
-
创建 SST 用户：
# 登录 MySQL mysql -u root -p # 创建 SST 用户 CREATE USER 'sstuser'@'%' IDENTIFIED BY 'YourSSTPassword'; GRANT REPLICATION CLIENT, PROCESS ON *.* TO 'sstuser'@'%'; GRANT SELECT ON performance_schema.* TO 'sstuser'@'%'; FLUSH PRIVILEGES; # 修改 root 密码 (重要！) ALTER USER 'root'@'localhost' IDENTIFIED BY 'YourNewPassword'; ALTER USER 'root'@'%' IDENTIFIED BY 'YourNewPassword';解释：
CREATE USER 'sstuser'@'%' IDENTIFIED BY 'YourSSTPassword'：创建 SST 用户。GRANT REPLICATION CLIENT, PROCESS ON *.* TO 'sstuser'@'%'：授权 SST 用户复制权限。GRANT SELECT ON performance_schema.* TO 'sstuser'@'%'：授权 SST 用户访问 performance_schema。
-
初始化第一个节点 (node1)：
# 停止 MySQL 服务 systemctl stop mysql # 以安全模式启动 MySQL mysqld_safe --wsrep-new-cluster & # 等待几分钟，直到 MySQL 启动完成解释：
mysqld_safe --wsrep-new-cluster：以安全模式启动 MySQL，并初始化 PXC 集群。
-
启动其他节点 (node2 和 node3)：
# 启动 MySQL 服务 systemctl start mysql解释：
- 直接启动 MySQL 服务，会自动加入现有集群。
-
验证 PXC 状态：
# 登录任何一个节点 mysql -u root -p # 查看 PXC 状态 SHOW STATUS LIKE 'wsrep%';关键指标：
wsrep_cluster_size：集群节点数量。wsrep_cluster_status：集群状态，Primary表示正常。wsrep_ready：节点状态，ON表示就绪。
如果看到
wsrep_cluster_size等于 3，wsrep_cluster_status是Primary，wsrep_ready是ON，恭喜你，PXC 集群搭建成功！
-
四、MGR vs PXC：如何选择？
| 特性 | MGR | PXC |
|---|---|---|
| 一致性 | 强一致性 | 近乎同步复制 |
| 架构 | 单主/多主 | 多主 |
| 性能 | 相对较低 | 较高 |
| 网络要求 | 较高 | 极高 |
| 冲突处理 | 较少冲突，自动处理 | 可能发生写冲突，需要应用层处理 |
| 事务大小限制 | 无限制 | 有限制 |
| 复杂性 | 相对简单 | 较高 |
| 官方支持 | MySQL官方提供 | Percona公司提供 |
| 适用场景 | 对数据一致性要求极高，对性能要求不高 | 对性能要求高，对数据一致性要求较高 |
总结：
- 选择MGR： 如果你的业务对数据一致性要求是“宁可慢，也要准”，且网络环境一般，那就选择MGR。比如：金融交易、支付系统等。
- 选择PXC： 如果你的业务对性能要求很高，可以容忍一定的冲突风险，且网络环境非常好，那就选择PXC。比如：高并发的Web应用、游戏服务器等。
五、高可用架构的注意事项：别只顾着“搭积木”
- 监控是关键：无论选择哪种架构，都需要完善的监控系统，实时监控集群状态、性能指标、错误日志等。
- 备份与恢复：定期备份数据，并测试恢复流程，确保在灾难发生时可以快速恢复。
- 容量规划：根据业务增长预测数据量和访问量，提前规划集群容量，避免出现瓶颈。
- 版本升级：及时升级MySQL版本，获取最新的安全补丁和性能优化。
- 安全加固：加强数据库的安全防护，防止未经授权的访问和攻击。
六、结语：高可用，永无止境
高可用架构不是一蹴而就的，需要不断学习、实践、优化。没有最好的方案，只有最适合你的方案。希望今天的讲座能帮助你更好地理解MGR和PXC，并为你的业务选择合适的高可用架构。
感谢各位的观看！下次再见！