Galera通过认证复制（Certification-Based Replication）实现多主同步：事务在发起节点生成含主键的写集并广播，各节点并行冲突检测，仅当多数节点认证通过后才原子提交，确保强一致与“写入即可见”。
Galera 实现 MySQL 多主同步，核心在于用认证复制（Certification-Based Replication）替代传统异步主从，让所有节点具备写能力且数据强一致。它不是“多个主库各自为政”，而是通过全局事务序列和写集校验，确保任意节点写入后，其他节点在提交前完成冲突检测与同步确认。
多主同步靠什么机制落地
Galera 不依赖 binlog 重放，而是通过 WSREP API 捕获事务的写集（Write Set），包含表名、主键、变更字段及新值。每个事务被赋予全局唯一 GTID，并广播至集群所有节点：
- 本地执行阶段：事务在发起节点正常执行，生成写集
- 认证阶段：各节点并行比对写集是否与已提交事务冲突（例如同一主键被并发修改）
- 提交阶段：仅当多数节点认证通过，事务才在所有节点原子性提交
这种流程保证了“写入即可见”——客户端收到 COMMIT 成功响应时，数据已在全部在线节点持久化，不存在延迟或不一致窗口。
关键配置不能跳过的几项
配置错误是集群启动失败或脑裂的主因。以下参数必须逐节点核对，且 IP 地址需固定、可解析：
-
wsrep_cluster_address：填所有节点 IP 列表，格式为
gcomm://192.168.1.10,192.168.1.11,192.168.1.12，首节点启动时需显式指定该地址 -
wsrep_node_address：当前节点真实 IP（非 127.0.0.1），建议配合
/etc/hosts做主机名解析 -
wsrep_provider：指向编译或安装后的
libgalera_smm.so绝对路径，路径错误会导致 mysqld 启动失败 -
wsrep_sst_method：推荐
rsync（轻量）或xtrabackup-v2（生产环境，支持增量同步）
启动顺序和状态验证要点
Galera 不支持所有节点同时冷启动。必须严格按顺序操作：
- 先启动第一个节点，命令中加入
--wsrep_cluster_address=gcomm://（空地址表示初始化新集群） - 确认该节点
SHOW STATUS LIKE 'wsrep_%'中wsrep_cluster_size为 1、wsrep_ready为 ON 后，再启动其余节点 - 每加一个节点，检查
wsrep_cluster_size是否递增，wsrep_local_state_comment应为Synced - 写入测试建议用带主键的单行 UPDATE，避免触发复杂冲突；跨节点查询同一张表，结果应实时一致
规避常见风险的实际建议
Galera 强一致的代价是写性能敏感、冲突易发。生产中需主动控制风险：
- 禁用
autocommit=0下的长事务，大事务会阻塞认证队列，拖慢整个集群 - 避免无主键表——Galera 依赖主键生成写集，缺失主键将导致同步中断
- 网络必须稳定低延迟（节点间 ping < 1ms），高延迟会放大认证等待时间，引发超时或节点驱逐
- 三节点集群是最低可用配置；若只有两个节点，需额外部署仲裁器（garbd）防止单点故障引发脑裂
