尧图网页设计 
后端数据库负载均衡【免费下载链接】proxysqlHigh-performance proxy for MySQL and PostgreSQL项目地址https://gitcode.com/gh_mirrors/pr/proxysql点击查看免费下载本文围绕 ProxySQL 官方 FAQ 展开系统讲解为什么改了用户名密码不生效重启后配置丢失怎么办ProxySQL 能否做自动故障转移这三个高频问题并结合本仓库源码lib/ProxySQL_Admin.cpp、lib/Admin_Handler.cpp、lib/MySQL_Monitor.cpp、include/ProxySQL_Admin_Tables_Definitions.h剖析其底层实现。读完你不仅能照做完整的改账号→验证→持久化流程还能理解 ProxySQL 多层配置架构、SQLite3 磁盘存储以及基于read_only监控的路由与故障转移原理。一、问题背景为什么改密码不生效很多初次接触 ProxySQL 的运维都会遇到同一个困惑明明修改了配置甚至重启了服务但改动就是不生效——用户连不上、端口没变、密码还是旧的。这并非 ProxySQL 的 Bug而是因为它采用了一套从路由器借鉴而来的三层3-tiered配置系统配置文件disk只是起点真正生效的是内存memory与运行时runtime中的状态。一句话总结 FAQ 给出的结论配置文件只会在第一次启动 ProxySQL 时被加载以及当你手动执行--initial参数强制重置所有设置、重新从配置文件加载时才再次被读取。--initial在源码中的语义是Rename/empty database file重命名/清空数据库文件见 lib/ProxySQL_GloVars.cpp即启动时清空并重建配置数据库从而让proxysql.cnf的内容重新灌入。因此日常变更账号、端口、路由规则等都不应该依赖重启服务或改配置文件而是通过Admin 接口6032 端口在线完成内存层 → 运行时层 → 磁盘层的流转。二、三层配置体系Disk / Memory / RuntimeProxySQL 的配置在每个子系统admin 变量、mysql 变量、mysql 服务器、mysql 用户、查询规则等上都存在三层层级名称说明Disk磁盘层持久化在 SQLite3 二进制格式数据库文件中重启不丢失Memory内存层通过 Admin 接口INSERT/UPDATE/DELETE修改的暂存区相当于一个可编辑的草稿Runtime运行时层真正被 ProxySQL 线程读取、立即生效的配置相当于线上环境三层的流转由一组LOAD / SAVE命令驱动。以 admin 变量为例源码中定义了完整的一组等价命令见 lib/ProxySQL_Admin.cpp 与 lib/Admin_Handler.cppLOAD ADMIN VARIABLES TO MEMORY等价于LOAD ADMIN VARIABLES TO MEM/LOAD ADMIN VARIABLES FROM DISK把磁盘上的配置读入内存层SAVE ADMIN VARIABLES TO DISK等价于SAVE ADMIN VARIABLES FROM MEMORY/SAVE ADMIN VARIABLES FROM MEM把内存层写回磁盘LOAD ADMIN VARIABLES TO RUNTIME等价于LOAD ADMIN VARIABLES TO RUN/LOAD ADMIN VARIABLES FROM MEMORY/LOAD ADMIN VARIABLES FROM MEM把内存层推向运行时层立即生效SAVE ADMIN VARIABLES TO MEMORY等价于SAVE ADMIN VARIABLES FROM RUNTIME把当前运行时配置抓取回内存层便于在此基础上继续编辑。同样的命令模式对MYSQL SERVERS、MYSQL USERS、MYSQL VARIABLES、PGSQL *等子系统全部成立。这套设计使得你可以先把一系列改动都放进内存层确认无误后再一次性推送到运行时实现无停机的事务式配置变更。三、实战一修改 Admin 管理员账号与监听地址3.1 连接默认管理端口ProxySQL 默认的 Admin 端口是6032默认管理员账号为admin:admin。先使用 MySQL 客户端连接$ mysql -u admin -padmin -h 127.0.0.1 -P6032登录成功后查看与管理员相关的两个全局变量admin-admin_credentials管理员账号密码与admin-mysql_ifacesAdmin 接口监听地址/端口/Unix Socketmysql SELECT * FROM global_variables WHERE variable_name IN (admin-admin_credentials,admin-mysql_ifaces); ----------------------------------------- | variable_name | variable_value | ----------------------------------------- | admin-admin_credentials | admin:admin | | admin-mysql_ifaces | 127.0.0.1:6032 | ----------------------------------------- 2 rows in set (0.00 sec)3.2 在内存层修改在 Admin 接口中执行的UPDATE只作用于内存层。把管理员密码改为test:test同时把 Admin 监听改为127.0.0.1:6034并追加一个 Unix Socket/tmp/proxysql_admin.sockmysql UPDATE global_variables SET variable_valuetest:test WHERE variable_nameadmin-admin_credentials; Query OK, 1 row affected (0.00 sec) mysql UPDATE global_variables SET variable_value127.0.0.1:6034;/tmp/proxysql_admin.sock WHERE variable_nameadmin-mysql_ifaces; Query OK, 1 row affected (0.00 sec) mysql SELECT * FROM global_variables WHERE variable_name IN (admin-admin_credentials,admin-mysql_ifaces); ------------------------------------------------------------------ | variable_name | variable_value | ------------------------------------------------------------------ | admin-admin_credentials | test:test | | admin-mysql_ifaces | 127.0.0.1:6034;/tmp/proxysql_admin.sock | ------------------------------------------------------------------ 2 rows in set (0.00 sec)注意此时改动尚未生效如果你立刻用新端口连接会失败。3.3 推送到运行时并验证执行LOAD ADMIN VARIABLES TO RUNTIME;将内存层改动一次性推送到运行时mysql LOAD ADMIN VARIABLES TO RUNTIME; Query OK, 0 rows affected (0.00 sec) mysql quit随后验证旧端口6032已不可用新端口6034配合新密码test:test可以正常登录$ mysql -u admin -padmin -h 127.0.0.1 -P6032 ERROR 2003 (HY000): Cant connect to MySQL server on 127.0.0.1 (111) $ mysql -u test -ptest -h 127.0.0.1 -P6034 Welcome to the MySQL monitor. Commands end with ; or \g. mysql提示admin-mysql_ifaces支持用分号分隔多个监听地址例如127.0.0.1:6034;/tmp/proxysql_admin.sock即同时监听 TCP 端口与 Unix Socket。源码层面admin-admin_credentials与admin-mysql_ifaces在 lib/Admin_Handler.cpp 等位置被识别为需要特殊处理的管理员变量。3.4 让修改跨重启生效上面两步只完成了内存 → 运行时。若不做任何持久化重启后一切回到旧值。需要把内存层内容写回磁盘mysql SAVE ADMIN VARIABLES TO DISK;至此完整的改 Admin 账号标准流程为UPDATE内存→ LOAD ADMIN VARIABLES TO RUNTIME运行时→ SAVE ADMIN VARIABLES TO DISK磁盘。四、实战二为后端服务器创建连接用户4.1 后端用户存放在 mysql_users 而非 admin 变量FAQ 特别强调连接后端服务器的(username, password)组合存放在另一个位置即mysql_users表而不是 admin 变量。每个 hostgroup一组被分组管理的后端服务器集合中一个(user, password)组合对应一份凭据新建用户默认落入 hostgroup 0。在 include/ProxySQL_Admin_Tables_Definitions.h 中可以看到当前版本mysql_users的表结构除username、password外还包含大量可调字段例如字段默认值说明active1是否启用0/1use_ssl0是否要求 SSL 连接0/1default_hostgroup0该用户默认路由到的 hostgroupdefault_schemaNULL默认 schematransaction_persistent1事务是否固定在初始 hostgroupfast_forward0是否启用 fast_forward 直通max_connections10000该用户允许的最大前端连接数4.2 插入新用户并验证$ mysql -u admin -padmin -h 127.0.0.1 -P6032 mysql INSERT INTO mysql_users (username, password) VALUES (user1, 123456);由于多层配置系统的存在该用户此刻只存在于内存层。现在可以通过 ProxySQL 的前端端口默认6033用该用户连接$ mysql -u user1 -p123456 -h 127.0.0.1 -P6033 mysqlFAQ 特别提醒成功连接到 ProxySQL 并不代表已经连接到后端服务器——后端连接的建立可能延后到你执行第一条查询时具体取决于代理当时的内部状态连接池按需建连。若要让该用户被代理真正使用还需要mysql LOAD MYSQL USERS TO RUNTIME;若需要跨重启保留该用户再执行mysql SAVE MYSQL USERS TO DISK;五、实战三重启后配置丢失为什么5.1 设计初衷ProxySQL 本就不该频繁重启FAQ 明确说明默认情况下改动不会持久化到磁盘因此重启后全部丢失。同时强调 ProxySQL 从设计上就不应该被频繁重启常见的重启场景只有几种修改了无法在运行时变更的 admin 变量如线程栈大小 thread stack sizeFAQ 指出理论上这种变量也可以实现动态修改但实现非常复杂作者选择不做升级到新版本软件项目更偏好低频但更稳定的发布节奏内部崩溃例如运行 nightly 构建等不稳定版本时。5.2 必须显式持久化SAVE ... TO DISK 家族要在重启后保留配置必须知道你想持久化哪一部分配置并显式执行对应的 SAVE 命令SAVE MYSQL USERS TO DISK; SAVE MYSQL SERVERS TO DISK; SAVE MYSQL QUERY RULES TO DISK; SAVE MYSQL VARIABLES TO DISK; SAVE ADMIN VARIABLES TO DISK;对应的 PgSQL 子系统SAVE PGSQL USERS TO DISK等在仓库中同样存在命令族的定义可见 lib/ProxySQL_Admin.cpp。FAQ 还指出两个已知限制目前不存在一次性保存所有配置项的命令没有SAVE ALL TO DISK之类的原子操作没有现成命令可以查看磁盘与内存之间的差异需要自行比对。磁盘上这些配置以SQLite3 数据库二进制格式保存即 ProxySQL 数据目录下的proxysql.db。这与--initial启动参数形成呼应--initial会重命名/清空该数据库文件从而回到只认配置文件的初始状态。六、深度原理ProxySQL 的自动故障转移能力6.1 定位ProxySQL 不做故障转移它配合故障转移FAQ 给出了非常清晰的边界ProxySQL 支持故障转移场景但本身不执行故障转移——按设计它不是数据库管理器。它很容易与 MMM、MHA 这类复制管理/高可用方案互补协作主要有两种配合方式基于read_only的读写路由感知ProxySQL 持续监控后端服务器的read_only变量值当复制管理软件完成故障转移把新主库的read_only置为 0、老主库置为 1后ProxySQL 自动把流量引导到正确的位置。应用层完全无感知也不需要任何重新配置。读查询在途失败重试当存在多个可读后端时ProxySQL 可以检测正在执行中的查询失败并把该查询透明地重定向到另一个后端服务器——应用根本不知道发生过一次小故障。FAQ 声称这是当时市场上唯一具备该能力的代理注意这是 FAQ 作者的说法属于官方文档主张非本项目自行断言。6.2 源码佐证read_only 监控如何工作read_only监控在 lib/MySQL_Monitor.cpp 中有完整实现监控线程会周期性执行SELECT global.read_only read_only超时由mysql_thread___monitor_read_only_timeout控制处理函数为read_only_handler。针对不同高可用形态复制/Group Replication/Galera/PXC监控查询还会组合innodb_read_only、super_read_only或查询sys.gr_member_routing_candidate_status、wsrep_local_state等状态变量例如SELECT global.read_onlyglobal.innodb_read_only read_only SELECT global.read_only|global.innodb_read_only read_only监控结果落库为mysql_server_read_only_log表表结构定义见 include/MySQL_Monitor.hpp统计计数器mysql_monitor_read_only_check_ok/err记录探测成败。这些数据最终驱动路由层判断当后端被置为只读read_only1时写流量不再发往该服务器当新主接管后流量自动切换过去。而在途查询失败重试的能力从架构上看依赖会话层MySQL_Session对后端连接的细粒度管理与重试机制结合HostgroupRouting见 include/HostgroupRouting.h中先尝试default_hostgroup失败后再尝试其他 hostgroup的路由选择逻辑共同构成透明重试的基础。6.3 与外部高可用方案的协作建议要落地这套能力典型做法是在mysql_servers中把主库与从库分到不同 hostgroup如写组 0、读组 1或全部纳入并按read_only动态区分角色配置监控账号mysql-monitor_username/mysql-monitor_password让监控线程能够执行SELECT global.read_only将 MMM/MHA 等复制管理软件的切换动作与read_only的置位联动——切换时自动调整各后端read_only标志ProxySQL 无需重启、无需改配置即可跟随角色变化完成流量迁移。七、常见误操作自查清单症状原因正确操作改了密码不生效只改了内存层未推送运行时LOAD ADMIN VARIABLES TO RUNTIME重启后改动全丢未持久化到磁盘SAVE * TO DISK按需执行新用户连不上前端用户只在内存层LOAD MYSQL USERS TO RUNTIME旧端口还能连未推送admin-mysql_ifaces到运行时LOAD ADMIN VARIABLES TO RUNTIME期望一次保存所有配置无此命令FAQ 明确逐类执行 SAVE 命令期望 ProxySQL 自动做主从切换它只感知read_only并跟随流量搭配 MMM/MHA 等复制管理工具八、小结ProxySQL 的 FAQ 看似只回答三个问题实际上浓缩了其最核心的工程哲学配置分层、显式流转、在线变更。掌握Disk / Memory / Runtime三层模型与LOAD/SAVE命令族是使用 ProxySQL 一切功能账号管理、路由规则、连接池、查询缓存、集群同步的前提理解read_only监控与在途查询重试机制则是把 ProxySQL 正确接入生产高可用体系的关键。建议将本仓库的 lib/ProxySQL_Admin.cpp、include/ProxySQL_Admin_Tables_Definitions.h 与 lib/MySQL_Monitor.cpp 作为深入研读的起点并结合 doc/README.md 中的相关文档体系继续探索。赞分享后端数据库负载均衡【免费下载链接】proxysqlHigh-performance proxy for MySQL and PostgreSQL项目地址https://gitcode.com/gh_mirrors/pr/proxysql点击查看免费下载相关推荐免费AI视频放大教程3步将任何视频无损升级到4K超高清免费AI视频放大教程3步将任何视频无损升级到4K超高清 Video2X是一款基于机器学习的开源视频超分辨率与帧插值框架能够智能地将低分辨率视频无损放大到高清音视频视频处理图像处理深度学习Redis高可用实战Jedis Sentinel自动故障转移全配置Redis高可用实战Jedis Sentinel自动故障转移全配置 你是否还在手动切换Redis主从节点当主节点宕机时业务中断风险、人工操作延迟和配置易错数据库缓存后端Mailu 官方 FAQ 深度解读部署架构、配置覆盖与故障排查实战手册Mailu 官方 FAQ 深度解读部署架构、配置覆盖与故障排查实战手册 本篇技术指南以 Mailu 官方 FAQ docs/faq.rst https://后端通信上一篇Material Dashboard图标库终极指南掌握Nucleo Icons的完整使用方法下一篇Vulkan着色器语言终极指南GLSL、HLSL和Slang性能对比分析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ProxySQL 三层配置体系实战：用户认证、配置持久化与自动故障转移（FAQ 深度解读）
后端数据库负载均衡【免费下载链接】proxysqlHigh-performance proxy for MySQL and PostgreSQL项目地址https://gitcode.com/gh_mirrors/pr/proxysql点击查看免费下载本文围绕 ProxySQL 官方 FAQ 展开系统讲解为什么改了用户名密码不生效重启后配置丢失怎么办ProxySQL 能否做自动故障转移这三个高频问题并结合本仓库源码lib/ProxySQL_Admin.cpp、lib/Admin_Handler.cpp、lib/MySQL_Monitor.cpp、include/ProxySQL_Admin_Tables_Definitions.h剖析其底层实现。读完你不仅能照做完整的改账号→验证→持久化流程还能理解 ProxySQL 多层配置架构、SQLite3 磁盘存储以及基于read_only监控的路由与故障转移原理。一、问题背景为什么改密码不生效很多初次接触 ProxySQL 的运维都会遇到同一个困惑明明修改了配置甚至重启了服务但改动就是不生效——用户连不上、端口没变、密码还是旧的。这并非 ProxySQL 的 Bug而是因为它采用了一套从路由器借鉴而来的三层3-tiered配置系统配置文件disk只是起点真正生效的是内存memory与运行时runtime中的状态。一句话总结 FAQ 给出的结论配置文件只会在第一次启动 ProxySQL 时被加载以及当你手动执行--initial参数强制重置所有设置、重新从配置文件加载时才再次被读取。--initial在源码中的语义是Rename/empty database file重命名/清空数据库文件见 lib/ProxySQL_GloVars.cpp即启动时清空并重建配置数据库从而让proxysql.cnf的内容重新灌入。因此日常变更账号、端口、路由规则等都不应该依赖重启服务或改配置文件而是通过Admin 接口6032 端口在线完成内存层 → 运行时层 → 磁盘层的流转。二、三层配置体系Disk / Memory / RuntimeProxySQL 的配置在每个子系统admin 变量、mysql 变量、mysql 服务器、mysql 用户、查询规则等上都存在三层层级名称说明Disk磁盘层持久化在 SQLite3 二进制格式数据库文件中重启不丢失Memory内存层通过 Admin 接口INSERT/UPDATE/DELETE修改的暂存区相当于一个可编辑的草稿Runtime运行时层真正被 ProxySQL 线程读取、立即生效的配置相当于线上环境三层的流转由一组LOAD / SAVE命令驱动。以 admin 变量为例源码中定义了完整的一组等价命令见 lib/ProxySQL_Admin.cpp 与 lib/Admin_Handler.cppLOAD ADMIN VARIABLES TO MEMORY等价于LOAD ADMIN VARIABLES TO MEM/LOAD ADMIN VARIABLES FROM DISK把磁盘上的配置读入内存层SAVE ADMIN VARIABLES TO DISK等价于SAVE ADMIN VARIABLES FROM MEMORY/SAVE ADMIN VARIABLES FROM MEM把内存层写回磁盘LOAD ADMIN VARIABLES TO RUNTIME等价于LOAD ADMIN VARIABLES TO RUN/LOAD ADMIN VARIABLES FROM MEMORY/LOAD ADMIN VARIABLES FROM MEM把内存层推向运行时层立即生效SAVE ADMIN VARIABLES TO MEMORY等价于SAVE ADMIN VARIABLES FROM RUNTIME把当前运行时配置抓取回内存层便于在此基础上继续编辑。同样的命令模式对MYSQL SERVERS、MYSQL USERS、MYSQL VARIABLES、PGSQL *等子系统全部成立。这套设计使得你可以先把一系列改动都放进内存层确认无误后再一次性推送到运行时实现无停机的事务式配置变更。三、实战一修改 Admin 管理员账号与监听地址3.1 连接默认管理端口ProxySQL 默认的 Admin 端口是6032默认管理员账号为admin:admin。先使用 MySQL 客户端连接$ mysql -u admin -padmin -h 127.0.0.1 -P6032登录成功后查看与管理员相关的两个全局变量admin-admin_credentials管理员账号密码与admin-mysql_ifacesAdmin 接口监听地址/端口/Unix Socketmysql SELECT * FROM global_variables WHERE variable_name IN (admin-admin_credentials,admin-mysql_ifaces); ----------------------------------------- | variable_name | variable_value | ----------------------------------------- | admin-admin_credentials | admin:admin | | admin-mysql_ifaces | 127.0.0.1:6032 | ----------------------------------------- 2 rows in set (0.00 sec)3.2 在内存层修改在 Admin 接口中执行的UPDATE只作用于内存层。把管理员密码改为test:test同时把 Admin 监听改为127.0.0.1:6034并追加一个 Unix Socket/tmp/proxysql_admin.sockmysql UPDATE global_variables SET variable_valuetest:test WHERE variable_nameadmin-admin_credentials; Query OK, 1 row affected (0.00 sec) mysql UPDATE global_variables SET variable_value127.0.0.1:6034;/tmp/proxysql_admin.sock WHERE variable_nameadmin-mysql_ifaces; Query OK, 1 row affected (0.00 sec) mysql SELECT * FROM global_variables WHERE variable_name IN (admin-admin_credentials,admin-mysql_ifaces); ------------------------------------------------------------------ | variable_name | variable_value | ------------------------------------------------------------------ | admin-admin_credentials | test:test | | admin-mysql_ifaces | 127.0.0.1:6034;/tmp/proxysql_admin.sock | ------------------------------------------------------------------ 2 rows in set (0.00 sec)注意此时改动尚未生效如果你立刻用新端口连接会失败。3.3 推送到运行时并验证执行LOAD ADMIN VARIABLES TO RUNTIME;将内存层改动一次性推送到运行时mysql LOAD ADMIN VARIABLES TO RUNTIME; Query OK, 0 rows affected (0.00 sec) mysql quit随后验证旧端口6032已不可用新端口6034配合新密码test:test可以正常登录$ mysql -u admin -padmin -h 127.0.0.1 -P6032 ERROR 2003 (HY000): Cant connect to MySQL server on 127.0.0.1 (111) $ mysql -u test -ptest -h 127.0.0.1 -P6034 Welcome to the MySQL monitor. Commands end with ; or \g. mysql提示admin-mysql_ifaces支持用分号分隔多个监听地址例如127.0.0.1:6034;/tmp/proxysql_admin.sock即同时监听 TCP 端口与 Unix Socket。源码层面admin-admin_credentials与admin-mysql_ifaces在 lib/Admin_Handler.cpp 等位置被识别为需要特殊处理的管理员变量。3.4 让修改跨重启生效上面两步只完成了内存 → 运行时。若不做任何持久化重启后一切回到旧值。需要把内存层内容写回磁盘mysql SAVE ADMIN VARIABLES TO DISK;至此完整的改 Admin 账号标准流程为UPDATE内存→ LOAD ADMIN VARIABLES TO RUNTIME运行时→ SAVE ADMIN VARIABLES TO DISK磁盘。四、实战二为后端服务器创建连接用户4.1 后端用户存放在 mysql_users 而非 admin 变量FAQ 特别强调连接后端服务器的(username, password)组合存放在另一个位置即mysql_users表而不是 admin 变量。每个 hostgroup一组被分组管理的后端服务器集合中一个(user, password)组合对应一份凭据新建用户默认落入 hostgroup 0。在 include/ProxySQL_Admin_Tables_Definitions.h 中可以看到当前版本mysql_users的表结构除username、password外还包含大量可调字段例如字段默认值说明active1是否启用0/1use_ssl0是否要求 SSL 连接0/1default_hostgroup0该用户默认路由到的 hostgroupdefault_schemaNULL默认 schematransaction_persistent1事务是否固定在初始 hostgroupfast_forward0是否启用 fast_forward 直通max_connections10000该用户允许的最大前端连接数4.2 插入新用户并验证$ mysql -u admin -padmin -h 127.0.0.1 -P6032 mysql INSERT INTO mysql_users (username, password) VALUES (user1, 123456);由于多层配置系统的存在该用户此刻只存在于内存层。现在可以通过 ProxySQL 的前端端口默认6033用该用户连接$ mysql -u user1 -p123456 -h 127.0.0.1 -P6033 mysqlFAQ 特别提醒成功连接到 ProxySQL 并不代表已经连接到后端服务器——后端连接的建立可能延后到你执行第一条查询时具体取决于代理当时的内部状态连接池按需建连。若要让该用户被代理真正使用还需要mysql LOAD MYSQL USERS TO RUNTIME;若需要跨重启保留该用户再执行mysql SAVE MYSQL USERS TO DISK;五、实战三重启后配置丢失为什么5.1 设计初衷ProxySQL 本就不该频繁重启FAQ 明确说明默认情况下改动不会持久化到磁盘因此重启后全部丢失。同时强调 ProxySQL 从设计上就不应该被频繁重启常见的重启场景只有几种修改了无法在运行时变更的 admin 变量如线程栈大小 thread stack sizeFAQ 指出理论上这种变量也可以实现动态修改但实现非常复杂作者选择不做升级到新版本软件项目更偏好低频但更稳定的发布节奏内部崩溃例如运行 nightly 构建等不稳定版本时。5.2 必须显式持久化SAVE ... TO DISK 家族要在重启后保留配置必须知道你想持久化哪一部分配置并显式执行对应的 SAVE 命令SAVE MYSQL USERS TO DISK; SAVE MYSQL SERVERS TO DISK; SAVE MYSQL QUERY RULES TO DISK; SAVE MYSQL VARIABLES TO DISK; SAVE ADMIN VARIABLES TO DISK;对应的 PgSQL 子系统SAVE PGSQL USERS TO DISK等在仓库中同样存在命令族的定义可见 lib/ProxySQL_Admin.cpp。FAQ 还指出两个已知限制目前不存在一次性保存所有配置项的命令没有SAVE ALL TO DISK之类的原子操作没有现成命令可以查看磁盘与内存之间的差异需要自行比对。磁盘上这些配置以SQLite3 数据库二进制格式保存即 ProxySQL 数据目录下的proxysql.db。这与--initial启动参数形成呼应--initial会重命名/清空该数据库文件从而回到只认配置文件的初始状态。六、深度原理ProxySQL 的自动故障转移能力6.1 定位ProxySQL 不做故障转移它配合故障转移FAQ 给出了非常清晰的边界ProxySQL 支持故障转移场景但本身不执行故障转移——按设计它不是数据库管理器。它很容易与 MMM、MHA 这类复制管理/高可用方案互补协作主要有两种配合方式基于read_only的读写路由感知ProxySQL 持续监控后端服务器的read_only变量值当复制管理软件完成故障转移把新主库的read_only置为 0、老主库置为 1后ProxySQL 自动把流量引导到正确的位置。应用层完全无感知也不需要任何重新配置。读查询在途失败重试当存在多个可读后端时ProxySQL 可以检测正在执行中的查询失败并把该查询透明地重定向到另一个后端服务器——应用根本不知道发生过一次小故障。FAQ 声称这是当时市场上唯一具备该能力的代理注意这是 FAQ 作者的说法属于官方文档主张非本项目自行断言。6.2 源码佐证read_only 监控如何工作read_only监控在 lib/MySQL_Monitor.cpp 中有完整实现监控线程会周期性执行SELECT global.read_only read_only超时由mysql_thread___monitor_read_only_timeout控制处理函数为read_only_handler。针对不同高可用形态复制/Group Replication/Galera/PXC监控查询还会组合innodb_read_only、super_read_only或查询sys.gr_member_routing_candidate_status、wsrep_local_state等状态变量例如SELECT global.read_onlyglobal.innodb_read_only read_only SELECT global.read_only|global.innodb_read_only read_only监控结果落库为mysql_server_read_only_log表表结构定义见 include/MySQL_Monitor.hpp统计计数器mysql_monitor_read_only_check_ok/err记录探测成败。这些数据最终驱动路由层判断当后端被置为只读read_only1时写流量不再发往该服务器当新主接管后流量自动切换过去。而在途查询失败重试的能力从架构上看依赖会话层MySQL_Session对后端连接的细粒度管理与重试机制结合HostgroupRouting见 include/HostgroupRouting.h中先尝试default_hostgroup失败后再尝试其他 hostgroup的路由选择逻辑共同构成透明重试的基础。6.3 与外部高可用方案的协作建议要落地这套能力典型做法是在mysql_servers中把主库与从库分到不同 hostgroup如写组 0、读组 1或全部纳入并按read_only动态区分角色配置监控账号mysql-monitor_username/mysql-monitor_password让监控线程能够执行SELECT global.read_only将 MMM/MHA 等复制管理软件的切换动作与read_only的置位联动——切换时自动调整各后端read_only标志ProxySQL 无需重启、无需改配置即可跟随角色变化完成流量迁移。七、常见误操作自查清单症状原因正确操作改了密码不生效只改了内存层未推送运行时LOAD ADMIN VARIABLES TO RUNTIME重启后改动全丢未持久化到磁盘SAVE * TO DISK按需执行新用户连不上前端用户只在内存层LOAD MYSQL USERS TO RUNTIME旧端口还能连未推送admin-mysql_ifaces到运行时LOAD ADMIN VARIABLES TO RUNTIME期望一次保存所有配置无此命令FAQ 明确逐类执行 SAVE 命令期望 ProxySQL 自动做主从切换它只感知read_only并跟随流量搭配 MMM/MHA 等复制管理工具八、小结ProxySQL 的 FAQ 看似只回答三个问题实际上浓缩了其最核心的工程哲学配置分层、显式流转、在线变更。掌握Disk / Memory / Runtime三层模型与LOAD/SAVE命令族是使用 ProxySQL 一切功能账号管理、路由规则、连接池、查询缓存、集群同步的前提理解read_only监控与在途查询重试机制则是把 ProxySQL 正确接入生产高可用体系的关键。建议将本仓库的 lib/ProxySQL_Admin.cpp、include/ProxySQL_Admin_Tables_Definitions.h 与 lib/MySQL_Monitor.cpp 作为深入研读的起点并结合 doc/README.md 中的相关文档体系继续探索。赞分享后端数据库负载均衡【免费下载链接】proxysqlHigh-performance proxy for MySQL and PostgreSQL项目地址https://gitcode.com/gh_mirrors/pr/proxysql点击查看免费下载相关推荐免费AI视频放大教程3步将任何视频无损升级到4K超高清免费AI视频放大教程3步将任何视频无损升级到4K超高清 Video2X是一款基于机器学习的开源视频超分辨率与帧插值框架能够智能地将低分辨率视频无损放大到高清音视频视频处理图像处理深度学习Redis高可用实战Jedis Sentinel自动故障转移全配置Redis高可用实战Jedis Sentinel自动故障转移全配置 你是否还在手动切换Redis主从节点当主节点宕机时业务中断风险、人工操作延迟和配置易错数据库缓存后端Mailu 官方 FAQ 深度解读部署架构、配置覆盖与故障排查实战手册Mailu 官方 FAQ 深度解读部署架构、配置覆盖与故障排查实战手册 本篇技术指南以 Mailu 官方 FAQ docs/faq.rst https://后端通信上一篇Material Dashboard图标库终极指南掌握Nucleo Icons的完整使用方法下一篇Vulkan着色器语言终极指南GLSL、HLSL和Slang性能对比分析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考