MySQL 5.7如何通过ProxySQL实现读写分离的安全校验_配置用户映射-mysql教程-PHP中文网

ProxySQL 不自动校验后端密码一致性，须手动确保 monitor 用户、mysql_users 表应用用户与后端 MySQL 实例三者用户名密码完全匹配，否则导致健康检测失败或连接被拒；monitor 用户需在所有后端实例存在并具备 REPLICATION CLIENT 和 PROCESS 权限，ProxySQL 仅依赖其查询 @@read_only 判断主从状态，且不解析 binlog 或 SHOW SLAVE STATUS。

mysql 5.7如何通过proxysql实现读写分离的安全校验_配置用户映射

ProxySQL 不会自动校验后端 MySQL 用户密码是否一致，必须手动确保 monitor 用户、mysql_users 表中应用用户、以及真实后端 MySQL 实例上的对应账户三者密码完全匹配，否则健康检测失败或连接被拒。

monitor 用户必须在所有后端 MySQL 实例上存在且权限正确

ProxySQL 依赖 monitor 用户执行 SELECT @@read_only 和 SELECT 1 来判断节点状态和只读属性。若该用户缺失、密码错误或权限不足，会导致：

从库被误判为可写，进入 hostgroup_id=1（写组），破坏读写分离逻辑
mysql_servers 表中 status 长期为 OFFLINE_HARD 或反复切换
即使主从同步正常，ProxySQL 也会拒绝将 select 路由到从库

正确做法：

在每个 MySQL 5.7 实例（主+所有从）上执行：
CREATE USER 'monitor'@'%' IDENTIFIED BY 'your_monitor_password';
GRANT REPLICATION CLIENT, PROCESS ON *.* TO 'monitor'@'%';
FLUSH PRIVILEGES;
确认 monitor 用户能连通所有节点：
mysql -umonitor -pyour_monitor_password -h192.168.0.11 -P3306 -e "SELECT @@read_only;"
在 ProxySQL 管理端设置统一凭证：
SET mysql-monitor_username='monitor';
SET mysql-monitor_password='your_monitor_password';
LOAD MYSQL VARIABLES TO RUNTIME;
SAVE MYSQL VARIABLES TO DISK;

mysql_users 表中的应用用户需与后端 MySQL 用户一一映射

ProxySQL 的 mysql_users 表不存储真实密码，只做路由转发时的凭据透传。如果后端 MySQL 没有同名用户，或密码不一致，连接会在转发阶段直接报错 Access denied for user。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

务必在每个后端 MySQL 实例上创建相同用户名和密码的应用账户（例如 root / 123456）
不要依赖 ProxySQL 的 default_hostgroup 自动 fallback：它只决定未命中规则时的默认目标组，不解决认证失败问题
若使用不同用户区分读写（如 app_rw 写、app_ro 读），需在 mysql_users 中配置多条记录，并用 default_hostgroup + transaction_persistent 控制行为
验证方式：
mysql -uapp_rw -p123456 -h127.0.0.1 -P6033 -e "SELECT 1;"（应成功）
mysql -uapp_rw -pwrongpass -h127.0.0.1 -P6033 -e "SELECT 1;"（应报错）

MySQL 5.7 的 read_only 是 ProxySQL 区分主从的唯一依据

ProxySQL 不解析 binlog、不查 GTID、不调用 SHOW SLAVE STATUS —— 它只依赖 monitor 用户查询 @@read_only 值来决定节点归属哪个 hostgroup_id。这意味着：

从库 my.cnf 中必须显式配置 read_only=ON（或运行时执行 SET GLOBAL read_only=ON;）
主库不能意外开启 read_only=ON，否则会被踢出写组；可通过 SELECT hostgroup_id, hostname, status, read_only FROM runtime_mysql_servers; 实时确认
双主架构下，read_only=OFF 的节点都会被归入同一写组，ProxySQL 不做冲突仲裁 —— 路由安全需靠上层业务或额外脚本保障
若从库因故障临时关闭复制（Slave_SQL_Running: No），只要 read_only 仍为 ON，ProxySQL 仍视其为合法读节点（但实际数据已滞后）

最容易被忽略的是：ProxySQL 的健康检测和路由决策完全解耦。即使 monitor 连接失败，只要之前缓存的 read_only 值没过期，它仍可能继续向一个已宕机的从库转发 select 请求 —— 所以必须定期检查 runtime_mysql_servers 中的 status 和 Uptime_s 字段，而非仅信 read_only 值。