ProxySQL通过动态路由控制实现MySQL主从滚动升级零中断：先将待升级从库设为offline_hostgroup并热加载，升级完成后再按同步延迟逐步恢复权重；主库升级前暂停写规则并配合VIP切流，再将新主库加入writer_hostgroup；严禁手动改hostgroup_id以防被健康检查覆盖；需启用max_replication_lag防脏读，并确保认证插件与MySQL 8.0兼容，同时开启transaction_persistent=1保障事务一致性。
ProxySQL 本身不升级 MySQL，但它能让你在 MySQL 升级过程中不中断业务——核心是靠流量调度能力把写请求切走、把读请求逐步迁移，让旧库“安静下线”，新库“无感上线”。
MySQL 主从滚动升级时，ProxySQL 怎么接管路由？
主从架构下升级，必须避免写请求打到正在停机升级的节点。ProxySQL 不是被动转发，而是主动控制流向：
- 先将待升级的从库
hostgroup_id临时设为offline_hostgroup（比如 40），再执行LOAD MYSQL SERVERS TO RUNTIME，它立刻停止向该节点发任何请求 - 升级完成后，把节点加回
reader_hostgroup（如 30），但初始weight=10，等同步延迟Seconds_Behind_Master = 0后再逐步调高 - 主库升级前，用
UPDATE mysql_query_rules SET active=0 WHERE rule_id=1暂停默认写规则，配合应用层切流或 VIP 切换，确保写请求只发给新主库 - 切完后，再在 ProxySQL 中把新主库加入
writer_hostgroup = 10，并激活写规则
为什么不能直接改 mysql_servers 表里的 hostgroup_id 来“手动切主”？
手动 UPDATE mysql_servers.hostgroup_id 是最常见也最危险的操作。ProxySQL 的健康检查和自动分组机制会立刻覆盖你的修改，尤其当启用了 mysql_server_group_replication_checker 时：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- MGR 集群中，PRIMARY 节点必须落在
writer_hostgroup，否则写入会触发ERROR 1290 (HY000): The MySQL server is running with the --read-only option - ProxySQL 每 5 秒轮询
sys.gr_member_routing_candidate_status，一旦发现角色变化，就强制重置hostgroup_id - 你手改的值会在下次检查后被清空，导致路由错乱、连接堆积、甚至事务卡死
- 正确做法是：先用
INSERT INTO mysql_servers把所有节点统一塞进offline_hostgroup，再靠自动探测收敛
升级期间读请求怎么避免脏读？
从库升级前后必然存在同步延迟，而 ProxySQL 默认按语句类型路由，不会感知延迟值。如果直接把读请求导过去，SELECT 可能返回过期数据：
- 必须启用
replication_lag检测：在mysql_servers表里为每个从库设置max_replication_lag = 1（单位秒） - ProxySQL 会定期执行
SHOW SLAVE STATUS，一旦Seconds_Behind_Master > max_replication_lag，自动把该节点状态改为SHUNNED，不再参与负载均衡 - 对强一致性读（如订单详情、账户余额），不要依赖路由规则，应在应用层显式连接
writer_hostgroup端口（如 6033 写入口） - 监控项要加一条：
SELECT hostname, status, replication_lag FROM monitor.mysql_server_replication_lag_log ORDER BY time_start_us DESC LIMIT 5
ProxySQL 自身版本和 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' - 方案二（长期维护）：升级 ProxySQL 至 2.4+（如 2.6.3），但注意
monitor用户也必须用同种插件，否则mysql-monitor_username登录失败会导致整个mysql_servers状态无法刷新 -
default_authentication_plugin全局变量对 ProxySQL 无效——它只读取每个用户的plugin字段，不继承全局设置
真正容易被忽略的是：ProxySQL 的 transaction_persistent = 1 必须开启。否则事务中的后续 SELECT 可能被路由到从库，哪怕前面刚执行过 UPDATE——这不是 bug，是设计行为，但生产环境必须关掉这个“优化”。
