mariadb在linux上真正能落地的高可用方案只有galera cluster（多主同步）和replication+proxysql（主从+代理），其他如纯主从、keepalived虚拟ip等仅属故障转移，存在写入单点、脑裂风险或复制延迟等问题。
直接说结论：MariaDB 集群在 Linux 上真正能落地的高可用方案只有 Galera Cluster（多主同步）和 Replication + ProxySQL（主从+代理），其他如纯主从、Keepalived 虚拟 IP 等都只是“故障转移”而非“高可用”，写入单点、脑裂风险、复制延迟等问题无法回避。
Galera Cluster 启动失败最常见的 3 个原因
很多用户卡在 systemctl start mariadb 后服务立即退出，journalctl -u mariadb -n 50 显示 WSREP: Failed to prepare for 'xtrabackup-v2' SST 或 Can't open and lock privilege tables —— 这不是配置写错了，而是环境没理干净：
- 防火墙没关：
systemctl stop firewalld或ufw disable（Ubuntu），Galera 节点间必须开放4567（gcomm）、4568（SST）、4444（IST）端口，iptables规则残留比 firewalld 更难排查 -
wsrep_cluster_address写成gcomm://后跟本机 IP（比如gcomm://192.168.200.80）—— 正确写法是所有节点 IP 列表，且**第一个节点启动时必须用gcomm://（空地址）**，否则它等不到其他节点就超时退出 -
/var/lib/mysql目录非空且含旧数据（比如之前装过单机 MariaDB），Galera 启动时拒绝覆盖；必须清空并重运行mariadb-install-db --auth-root-authentication-method=normal（MariaDB 11.4+ 必须用这个，mysql_install_db已废弃）
Replication 主从配置中 MASTER_LOG_POS 容易填错
执行 CHANGE MASTER TO ... MASTER_LOG_POS=107 时填错位置，会导致从库 IO 线程报 Got fatal error 1236，日志里反复出现 Could not find first log file name in binary log index file。这不是命令写错，而是你没注意主库 SHOW MASTER STATUS 输出的 Position 值是动态的：
- 主库执行
FLUSH TABLES WITH READ LOCK后再查SHOW MASTER STATUS，拿到File和Position，立刻记下，别切窗口 - 从库
CHANGE MASTER TO必须用这组值，不能用之前备份时的、也不能用几秒后主库新生成的 binlog 位置 - 如果主库已写入新数据，而你用的是旧
Position，从库会跳过中间事务，造成数据不一致；此时只能重做从库（mysqldump+RESET SLAVE）
ProxySQL 读写分离规则必须匹配实际 SQL 类型
很多人配完 ProxySQL，发现 SELECT 还是打到主库，或者事务里 UPDATE 被路由到只读从库报错。根本原因是 mysql_query_rules 的 match_digest 或 match_pattern 没覆盖真实流量：
- 简单 SELECT 不一定走读池：如果语句带
FOR UPDATE、LOCK IN SHARE MODE、或出现在事务中（BEGIN后未COMMIT），ProxySQL 默认仍发给主库——这是对的，但容易被忽略 -
match_digest是哈希匹配，不区分大小写和空格，但会把SELECT * FROM users和SELECT id,name FROM users当作不同 digest；线上建议先用stats_mysql_query_digest表看真实高频语句，再针对性加规则 - 不要只靠
active = 1开启规则，还要检查destination_hostgroup是否指向正确的hostgroup_id（比如读池是20，但规则写了10）
Galera 的 wsrep_sst_method 选 xtrabackup-v2 要求主节点提前装好 Percona XtraBackup，且 wsrep_sst_auth 用户必须有 RELOAD, LOCK TABLES, REPLICATION CLIENT 权限；这些细节不提前验证，集群第一次加节点就会卡住，而不是报错——它只是静默等待超时。
