proxysql + mysql 8.0 mgr 读写分离可行,但需强制使用 mysql_native_password 插件、依赖 mysql_server_group_replication_checker 自动分组、配置 select for update 路由规则及启用 replication_lag 检测。

直接上结论:ProxySQL + MySQL 8.0 MGR 集群读写分离能跑通,但必须绕开 caching_sha2_password 认证兼容性陷阱,并严格依赖 mysql_server_group_replication_checker 自动分组,否则路由错位、连接被拒、写请求打到只读节点都是常态。
MySQL 8.0 用户认证必须显式指定插件
MySQL 8.0 默认用 caching_sha2_password,而 ProxySQL 2.3.x 及更早版本只认 mysql_native_password。不处理就会报 Access denied for user 'rw'@'192.168.x.x' (using password: YES),哪怕密码完全正确。
- 创建应用用户时强制指定插件:
CREATE USER 'rw'@'%' IDENTIFIED WITH mysql_native_password BY '123456'; - 监控用户也要一致:
CREATE USER 'monitor'@'%' IDENTIFIED WITH mysql_native_password BY 'monpass'; - 切勿改
default_authentication_plugin—— ProxySQL 不读这个变量,只查mysql.user.plugin字段 - 若用 ProxySQL 2.4+(如 2.6.3),可支持
caching_sha2_password,但需确保monitor用户也用同种插件,否则mysql-monitor_username登录失败会导致节点状态无法识别
hostgroup 分组必须靠 MGR 状态自动同步,不能手动 INSERT
手动把所有节点塞进 reader_hostgroup = 30 是高危操作。MGR 中只有 PRIMARY 节点可写,其余 SECONDARY 是只读;ProxySQL 依赖 sys.gr_member_routing_candidate_status 视图判断角色,跳过这步就等于放弃自动故障转移能力。
FastAPI + Flask 混合部署最佳实践,解决路由定义、API 代理等常见问题,适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 初始插入全部进
offline_hostgroup = 40:INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (40, '192.168.1.1', 3306); - 执行
LOAD MYSQL SERVERS TO RUNTIME触发mysql_server_group_replication_checker自动探测 - 确认 MySQL 已安装 SYS schema(8.0 默认自带),且
monitor用户有权限:GRANT SELECT ON sys.* TO 'monitor'@'%'; - 检查结果:
SELECT hostgroup_id, hostname, status FROM mysql_servers;—— 正常应看到 PRIMARY 落入writer_hostgroup = 10,SECONDARY 自动归入reader_hostgroup = 30
读写规则要避开隐式事务和 SELECT FOR UPDATE
ProxySQL 默认按语句前缀(SELECT/INSERT)路由,但 SELECT FOR UPDATE 或事务中后续的 SELECT 实际是写上下文,必须强制走写组,否则会卡死或报错。
- 加一条明确规则优先匹配:
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup, apply) VALUES (1, 1, '^SELECT.*FOR UPDATE$', 10, 1); - 启用
transaction_persistent = 1(在mysql_users表里设),保证同一事务内所有语句都路由到同一 hostgroup - 避免用
^((?!SELECT).)*$这类负向断言规则 —— 性能差、易漏匹配,优先用match_digest精确匹配^INSERT、^UPDATE、^DELETE - 如果业务大量使用隐式事务(如 JDBC auto-commit=false 后连续执行
UPDATE+SELECT),仅靠语句前缀不够,得结合username或schemaname做二级路由
最易被忽略的是 replication_lag 检测没开,或者 mysql-monitor_enabled 关着 —— 这会让 ProxySQL 对从库延迟毫无感知,延迟几十秒的节点照常接读请求,查到旧数据还不报错。










