升级MaxScale至2.1版本后客户端认证及复制用户授权失败

从你的描述来看，这个问题大概率是MaxScale 2.0.x到2.1.x版本之间用户权限处理逻辑的变更导致的——毕竟降级回2.0.1就能正常工作，且直接连接主库权限有效、缓存文件也已加载权限。下面给你几个针对性的排查和解决步骤：

1. 强制刷新MaxScale用户权限缓存 #

你提到清空了缓存目录，但2.1.x版本可能需要主动触发权限重载才能让新缓存生效，而非仅删除缓存文件。登录MaxScale服务器，执行以下命令：

maxadmin reload users

执行完成后重启MaxScale服务，再测试复制用户的连接。

2. 检查MaxScale服务配置的权限规则 #

2.1.x版本对复制用户的权限检查更严格，尤其是使用readwritesplit或binlogrouter服务时，需确保配置未限制复制用户权限：

• 若使用readwritesplit，检查配置中是否添加了allow_replication=yes（该参数控制是否允许复制连接通过此服务）
• 确认服务配置的user参数包含你的复制用户，且未被deny_users规则排除
• 若使用binlogrouter服务，需确保复制用户通过该服务连接，而非普通读写分离服务——复制连接需要走专门的binlog路由服务才能正确处理权限

3. 查看MaxScale日志定位具体错误 #

前往MaxScale日志目录（通常为/var/log/maxscale/），搜索复制用户名或access denied关键字，找到授权失败的具体报错：

• 若日志提示missing REPLICATION SLAVE privilege，需确认复制用户确实拥有该权限（直接连接主库执行SHOW GRANTS FOR 'repl_user'@'%';验证）
• 若日志提示user not found in dbusers，说明权限缓存未正确加载，可再次执行maxadmin reload users并检查缓存文件是否更新

4. 验证MaxScale版本兼容性问题 #

MaxScale 2.1.13可能存在已知的权限缓存bug，你可以尝试：

• 升级到2.1.x系列的最新补丁版本（如2.1.20+，若条件允许），确认是否修复该问题
• 梳理官方版本变更记录，查看2.1.x是否对复制用户权限处理做了特殊变更，比如新增了需配置的参数

如果以上步骤无效，可在MaxScale配置文件中添加auth_debug=yes开启权限调试日志，通过详细的授权过程日志进一步定位问题。

内容的提问来源于stack exchange，提问作者Ethan Shrago