gcache.size过小会导致新节点加入时ist失败而触发sst，推荐设为2–4gb并结合离线时间、写入量、磁盘空间和版本一致性综合评估；应使用xtrabackup-v2避免锁表，监控缓存状态，禁用自动fallback，并注意预分配导致的磁盘占用。
gcache.size 不够大，新节点加入时直接触发 SST 而非 IST
IST（Incremental State Transfer）能复用 gcache 中的写集，跳过全量拷贝；但前提是新节点缺失的事务日志还“躺在” gcache 里。一旦 gcache.size 太小、或老节点运行太久、或写入太猛，gcache 就会被滚动覆盖——这时新节点一连上来，发现自己要的 GTID 范围已丢失，只能退回到 SST（全量同步），拖慢上线速度，还压垮磁盘和网络。
实操建议：
-
gcache.size推荐从 1GB 起步，生产环境常见设为 2–4GB；不是越大越好，但低于 512MB 在中等写入下极易丢日志 - 用
SHOW STATUS LIKE 'wsrep_local_cached_downto';查看当前缓存起始位置，再对比新节点的wsrep_last_committed，差值过大就说明 IST 概率低 - 别只看单次写入量，要考虑最长可能的节点离线时间：比如运维升级停机 30 分钟，这期间产生的写集必须能被
gcache容纳住
IST 失败后没关 SST 的自动 fallback，导致意外锁表和主库压力飙升
Percona XtraDB Cluster 默认开启 wsrep_sst_method=rsync 或 mysqldump 时，若 IST 不可用，会静默切换到 SST——而 rsync 类 SST 在源节点上会加全局读锁（FLUSH TABLES WITH READ LOCK），哪怕只是几秒，对高并发写业务也是雪崩起点。
实操建议：
- 显式配置
wsrep_sst_method=xtrabackup-v2，它支持无锁热备，且能并行压缩传输，是目前最稳妥的 SST 方案 - 禁用自动 fallback：设置
wsrep_provider_options="gcache.recover=yes; ist.recv_timeout=30;"，并监控wsrep_local_state_comment状态，发现卡在Joining或Donor/Desynced就人工干预 - 不要依赖
wsrep_sst_auth密码明文写进配置文件，改用 MySQL 8.0+ 的mysql.session账号或 Vault 动态注入
gcache 文件实际占用远超配置值，磁盘突然爆满
gcache.size 是逻辑大小上限，但 Percona 实际分配的是固定块（默认 128MB），且采用预分配 + 循环覆盖策略。当配置 gcache.size = 1G，它可能一次性创建 8 个 128MB 文件（即 1024MB），即使当前只用了 200MB，磁盘也立刻少了 1GB 空间——尤其在容器或云盘空间紧张的环境，容易触发 OOM 或写失败。
实操建议：
- 用
ls -lh /var/lib/mysql/gc*查看真实文件体积，别只信配置值 - 避免在
/tmp或/var/tmp这类 tmpfs 挂载点放gcache，内存不够时会导致 mysqld 启动失败 - 如果磁盘确实吃紧，可调小
gcache.page_size（如设为 64M），减少单次预分配粒度，但会略微增加元数据管理开销
跨版本升级或混合部署时，gcache 兼容性被忽略，IST 直接失败
Percona XtraDB Cluster 8.0.32 和 5.7.42 使用的 gcache 格式不兼容，即使 gcache.size 足够、GTID 范围匹配，节点之间也无法解析彼此的写集。现象是 donor 日志出现 "Failed to apply IST: invalid gcache page"，然后强制走 SST。
实操建议：
- 集群内所有节点必须使用完全相同的 PXC 版本号（包括小版本），不能只看主版本
- 滚动升级前，在测试环境用
wsrep_provider_options="gcache.debug=1"开启调试日志，确认 IST 流程能跑通 - 备份
gcache文件本身没意义——它无法跨节点、跨版本复用，别把它当成 WAL 归档来管理
真正难的不是算出该配多大 gcache.size，而是把写入节奏、节点生命周期、升级窗口和磁盘水位这四件事串起来看；漏掉任意一个，IST 就可能在半夜三点悄悄变成 SST。
