maxscale启动失败主因是模块名变更或版本不匹配：23.08+需将mariadbmon改为mysqlmon；读写分离失效多因路由未绑定、监听器指向错误或slave状态异常；认证失败源于用户映射缺失；连接延迟高常因max_connections、connection_timeout等参数未调优。
MaxScale 启动失败：提示 Failed to load module 'mariadbmon'
模块加载失败通常是因为 MaxScale 版本与后端 MySQL/MariaDB 协议不匹配，或配置中指定了不存在的监控模块名。较新版本（23.08+）已将 mariadbmon 重命名为 mysqlmon，但文档和旧配置仍大量沿用旧名。
- 检查 MaxScale 版本：
maxscale --version，若 ≥23.08，把配置里所有type=mariadbmon改成type=mysqlmon -
mysqlmon默认要求主从节点开启log_bin和server_id，且复制用户需有REPLICATION CLIENT权限 - 若使用 MySQL 8.0+，注意默认认证插件是
caching_sha2_password，MaxScale 22.x 及更早版本不支持，需在复制用户上执行：ALTER USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx';
读写分离没生效：所有请求都打到 master
最常见原因是路由规则未命中，或服务监听了错误端口。MaxScale 不会自动按 SQL 类型拆分流量，必须显式定义 readwritesplit 路由并绑定到监听器。
- 确认监听器（
[RW Listener]）的service指向的是Read-Write-Service，而不是Splitter Service这类无效名称 -
readwritesplit路由默认只将SELECT发往 slave，但带FOR UPDATE或出现在事务中时仍走 master —— 这是设计行为，不是 bug - 用
maxctrl list servers确认 slave 状态为Running，而非Down或Maint；状态异常会导致所有流量 fallback 到 master
客户端连上 MaxScale 后报错 Access denied for user ''@'localhost'
这是 MaxScale 认证转发失败的典型表现，本质是它尝试用空用户连接后端，说明没有正确配置「客户端认证映射」或后端用户缺失。
- MaxScale 不代理用户密码，它需要在自己的配置中为每个前端用户声明对应的后端凭据，通过
[user_mapping]段或在 service 中设auth_all_servers=true+ 后端存在同名用户 - 更稳妥的做法：在所有 MySQL 节点上创建与客户端同名用户，并确保密码哈希一致（用
SELECT PASSWORD('xxx')检查），然后在 service 配置中加auth_all_servers=true - 如果用 MySQL 8.0+，避免用
PASSWORD()函数，改用SELECT SHA2('xxx', 256)手动比对认证字符串
延迟高、连接数暴涨：maxscale.cnf 里哪些参数最关键
MaxScale 的连接池和超时控制全靠配置驱动，开箱即用的默认值在生产环境极易引发雪崩。
-
max_connections=200是全局上限，但每个 service 还有独立限制，如Read-Write-Service默认仅允许 25 个并发连接，需手动调大 -
connection_timeout=30太短，网络抖动时频繁断连重连；建议设为300（5 分钟），配合应用层健康检查 -
router_options=strict_sp_calls=false必须显式关闭，否则调用存储过程时会被误判为写操作，全部路由到 master - 不要盲目开启
optimistic_trx=true，它依赖 GTID 且在主从延迟 >1s 时可能返回过期数据
