navicat能连上galera集群但写操作失败，根本原因是wsrep_ready=off时连接已建立，以及默认启用的连接池与galera事务机制冲突；需确认wsrep_ready=on、关闭连接池、禁用压缩协议，并避免图形界面直写系统表。
navicat 能连上 galera 集群，但默认配置会出问题：连接可能成功，写操作却失败或被拒绝，报错 wsrep has not yet prepared node for application use 或 can't execute the given command because you have active locked tables or an active transaction —— 根本原因不是 navicat 本身限制，而是 galera 启动流程和连接时序没对齐。
Navicat 连接时 wsrep_ready=OFF 导致写入失败
Galera 节点启动后，wsrep_ready 默认为 OFF，直到完成 SST/IST 同步、加入集群并确认状态才变为 ON。Navicat 建立连接时若该值仍为 OFF，多数 DML（如 INSERT、UPDATE）会被拒绝，但 SELECT 可能正常——这容易让人误判“连上了就是通的”。
- 检查方式：
SELECT VARIABLE_VALUE FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME = 'wsrep_ready';，返回ON才真正就绪 - Navicat 连接前务必确认该节点已稳定加入集群：
SHOW STATUS LIKE 'wsrep_%';中wsrep_cluster_size≥ 1 且wsrep_local_state_comment为Synced - 如果用
wsrep_sst_method=rsync（常见于 Docker 或测试环境），同步耗时较长，Navicat 连太快会踩中这个窗口期
Navicat 使用 root 用户连接 Galera 时权限不足
Galera 对系统表写入有特殊限制：虽然 CREATE USER、GRANT 等 DDL 会被复制，但直接 INSERT INTO mysql.user 不同步，且部分管理操作（如 FLUSH PRIVILEGES）在多主下行为不可靠。Navicat 的“用户管理”界面默认走的是这类直写路径，导致操作看似成功实则未生效。
- 避免在 Navicat 图形界面里新建用户或改密码；统一用 SQL 执行
CREATE USER+GRANT - 确保连接用户具备
REPLICATION CLIENT权限（Navicat 某些监控功能依赖它），否则“服务器信息”页签会空白或报错 - 不要勾选 Navicat 连接设置里的 “Use compression protocol”，Galera 节点间通信已加密压缩，客户端启用反而可能触发握手异常
Navicat 连接池与 Galera 的事务冲突
Navicat 默认开启连接池（Connection Pooling），并在后台维持空闲连接。而 Galera 要求每个事务必须显式提交或回滚，长时间空闲的连接若持有隐式锁（如未结束的 SELECT ... FOR UPDATE），再被复用时可能引发 WSREP conflict 或死锁。
- 在 Navicat 连接属性 → “高级”选项卡中，关闭
Enable connection pooling - 将
Auto commit设为True（默认），避免手动事务未提交导致后续语句阻塞 - 如果使用查询窗口执行多条语句，每条 DML 后手动按
Ctrl+Enter提交，别依赖 Navicat 自动分号识别——Galera 对批量语句的解析不如单条稳定
真正麻烦的不是 Navicat 怎么填主机名和端口，而是它背后那些默认开关如何跟 Galera 的同步机制打架。尤其是 wsrep_ready 状态延迟和连接池复用，这两个点不手动关掉，连上也白连。
