错误“WSREP has not yet prepared node for application use”表明节点已连接但处于non-Primary状态，集群仲裁失败或脑裂；需检查wsrep_cluster_status、grastate.dat中safe_to_bootstrap及seqno，并依情况执行--wsrep-new-cluster或pc.bootstrap=YES应急。
WSREP has not yet prepared node for application use 这个错误不是连接失败，而是连接成功后执行 SQL 时被拒绝——说明节点已启动、MySQL 进程在跑、端口也通，但 Galera 集群状态没就绪，不让你读写。
核心判断：当前节点处于 non-Primary 状态，集群仲裁失败或脑裂了，它不敢自己做主。
查 wsrep_cluster_status 是不是 non-Primary
这是最直接的确认动作。连上 MySQL 后立刻执行：
SHOW STATUS LIKE 'wsrep_cluster_status';
如果返回 non-Primary，基本可以锁定是集群分裂或只剩单节点且未 bootstrap。
- 正常集群中至少要有 2 个节点在线（3 节点更稳），否则一旦网络抖动或某节点异常退出，剩余节点会主动降级为
non-Primary，拒绝服务 -
Primary状态才是可读写状态；non-Primary下所有 DML/DDL 都报ERROR 1047 (08S01) - 注意：
wsrep_ready = ON不代表能用，它只表示 Galera 模块加载成功，和集群状态无关
看 grastate.dat 的 safe_to_bootstrap 值
这个文件在 MySQL 数据目录下（通常是 /var/lib/mysql/grastate.dat），它记录了节点最后一次关闭前的集群位置信息。
用 cat /var/lib/mysql/grastate.dat 查看内容，重点关注：
Node.js 可靠编程技能。避免事件循环阻塞、异步陷阱、ESM 兼容问题和内存泄漏。触发词：Node.js 开发、async/await、流处理、性能优化、安全编码。
-
seqno：最后提交的事务序号，-1 表示非正常关闭（比如kill -9） -
safe_to_bootstrap: 1表示该节点是最后一个正常关闭的，可以作为新集群起点 -
safe_to_bootstrap: 0表示不能直接 bootstrap，强行启动会导致数据丢失或冲突
如果只有单节点存活，且它的 safe_to_bootstrap 是 1，就可以用 --wsrep-new-cluster 启动它重建集群；如果是 0，得先用 wsrep_recovery 找出正确 seqno 再手动修复 grastate.dat。
启动时加 --wsrep-new-cluster 的实操要点
这不是随便加个参数就能用的命令，顺序和时机非常关键：
- 必须在**所有其他节点已完全停止**的前提下，只对那个
safe_to_bootstrap = 1的节点执行 - 启动命令要显式指定配置文件和用户，例如：
mysqld --defaults-file=/etc/my.cnf.d/server.cnf --user=mysql --wsrep-new-cluster - 不能用
systemctl start mysqld直接启，它会忽略--wsrep-new-cluster；得先停掉服务，再手动运行 mysqld 进程 - 启动成功后，立刻检查
SHOW STATUS LIKE 'wsrep_cluster_status';是否变成Primary，再检查wsrep_cluster_size是否为 1 - 确认 OK 后，再逐个启动其他节点（此时用普通
systemctl start mysqld即可）
临时救急：让单节点先对外提供服务
生产环境等不及重建集群？可以用这个方式让节点脱离集群模式、单独工作（仅限应急）：
SET GLOBAL wsrep_provider_options='pc.bootstrap=YES';
这条 SQL 会让当前节点强制进入 bootstrap 模式，绕过集群协商逻辑，wsrep_cluster_status 会变成 Primary，SQL 就能执行了。
- 副作用明显：它和其他节点彻底失联，后续再加回集群需全量同步（SST），不是 IST
- 执行后务必记录时间点，后续恢复集群时得清空
galera.cache和grastate.dat，否则可能因 UUID 冲突无法加入 - 别把它当成常态方案——这只是“让系统先活下来”，不是“让集群恢复正常”
真正的难点不在命令怎么敲，而在于你得快速判断：这个节点到底是不是最后那个可靠的？它的 seqno 还有没有参考价值？要不要先翻 wsrep_recovery.log 确认 recovered position？这些细节一漏，重建出来的集群可能刚上线就丢数据。
