Percona XtraDB Cluster（PXC)集群

单机 MySQL 撑得住读多写少的业务，一旦碰上写并发上来、主库宕机要人工切、或者跨机房还要保证数据不丢，问题就露出来了。PXC 属于那种「平时用不上，出事时救命」的东西：它把 Galera 的同步复制塞进 Percona Server，做成一个多主可写的 MySQL 集群。这门课要解决的就是这个能力缺口——你不需要先成为 MySQL 内核专家，但得把 PXC 的复制语义、节点行为和故障处理搞清楚，否则配出来也是个不敢上线的实验环境。

先搞清它和主从复制不是一回事

很多人带着「主从 + 读写分离」的直觉来学 PXC，第一步就栽了。PXC 用的是认证式复制（certification-based replication）：事务在本地节点执行，提交前把写集广播给所有节点做冲突检测，通过才真正 commit。这意味着节点之间理论上没有延迟窗口，但代价是写性能受最慢节点拖累，且大事务、热点行更新会频繁触发冲突回滚。课程里要把这些机制掰开讲，你才能判断：自己的业务是适合多主写入，还是只把它当高可用用、写仍然压在一个节点上。

课上会反复碰到的几个硬骨头

PXC 的坑大多集中在几个固定位置，课程围绕它们展开：

• 节点引导：集群不是「先起一个再起剩下」，第一个节点要用引导模式启动，安全引导、集群地址、节点名配错一个就起不来。
• SST / IST：新节点加入时是全量还是增量同步，选 xtrabackup 还是 rsync，大库全量同步期间对现有节点的压力从哪来。
• 节点状态：synced、donor、joiner、disconnected 各自的含义和处置方式，别看到不 synced 就重启。
• 写冲突与死锁：多主下同一行并发更新的报错长什么样，业务层要怎么改。
• 脑裂与仲裁：节点数为什么建议奇数、权重怎么设、网络分区时该牺牲哪一边。
• 和 ProxySQL / HAProxy 的配合：前端怎么感知节点状态，把流量从不可用节点上摘掉。

配套练习建议怎么做

光看不动手，PXC 等于没学。建议至少用三台虚机（或容器）走一遍完整流程：先按标准步骤把三节点集群拉起来，然后人为做几个破坏性实验——主动 kill 一个节点的 MySQL 进程、模拟网络延迟、写入一条大事务看集群反应、把某个节点数据目录清掉再让它重新加入。每次实验后记录节点状态变化和错误日志，这些日志就是面试和排障时最有说服力的材料。课程里的章节笔记适合课后对照复盘，但别拿它替代你自己的实验记录，你踩过的坑和你查到的原因，才是真正留下来的东西。

看完应该能回答这些问题

• PXC 的同步复制和 MySQL 半同步复制，语义差别到底在哪？
• 一个写事务从本地执行到所有节点可见，中间经历了哪些步骤？
• 三个节点挂掉一个，集群还能不能写入？挂掉两个呢？
• SST 过程中 donor 节点为什么可能变得很慢，怎么缓解？
• 业务报 1213 死锁或写冲突时，第一反应应该查什么？
• 什么场景下你会选 PXC，什么场景下 MGR 或传统主从更合适？

如果这些问题你现在答不上来一半，这门课就是给你补的。带着具体问题去学，比从头顺一遍目录效率高得多。