在搭建MySQL主从复制时，从库连接主库通常需要提供复制账号的用户名和密码。过去很多环境把密码明文写在配置文件或启动命令中，这种方式在多人共用的服务器上极不安全。mysql_config_editor是MySQL自带的凭据管理工具，能够将连接信息以加密形式保存到用户家目录下的.mylogin.cnf文件里，之后执行客户端命令或配置复制时可直接引用登录路径，而不必暴露真实密码。
mysql_config_editor的底层原理与文件结构
mysql_config_editor通过对输入的登录凭据使用AES算法进行加密，将结果写入当前用户主目录中的隐藏文件.mylogin.cnf。该文件默认的Unix权限为600，意味着仅文件所有者可以读写，其他系统用户包括root在某些配置下也需切换身份才能查看内容。它并不是把密码彻底隐藏到数据库系统表里，而是把"账号、密码、主机、端口"等组合成一个被叫作login-path的逻辑名称，后续工具读取时自动解密并填充连接参数。
这种机制与在操作系统中使用钥匙串的思路类似。当你执行mysql_config_editor set --login-path=repl --host=192.168.0.1 --user=repl --password时，工具会交互式要求输入密码，随后把加密数据追加进.mylogin.cnf。由于文件绑定的是执行命令的系统用户，如果换一个系统账户运行MySQL客户端，即使路径相同也读不到对方凭据，这天然实现了多用户环境下的凭据隔离。
需要注意的是，login-path本身并不限制你用它来连哪个实例，它只是凭据容器。在主从复制场景里，我们通常会为从库本地操作建一个login-path，也为从库连接主库用的复制账号建另一个login-path，避免把主库密码散落在多个脚本中。下面这段示例展示如何查看已存在的登录路径（密码部分会被星号遮盖）：
mysql_config_editor print --all # 输出示例 # [repl] # user = repl # password = ***** # host = 192.168.0.1
在主从复制中配置并使用加密凭据
假设主库地址为192.168.0.1，复制账号为repl，密码为StrongPass#123。我们首先在从库所在服务器上，用从库运行MySQL的系统用户（如mysql或普通运维账号）生成专属login-path。执行命令后工具会提示输入密码，输入完成即写入加密文件。这一步不需要重启任何服务，也不会影响正在运行的实例。
配置好login-path后，可以在从库上用mysql --login-path=repl直接连主库做连通性测试。相比在命令行写-prepl -pStrongPass#123，前者不会在进程列表里暴露密码，也不会被shell历史记录捕获。确认能连通后，就可以在从库执行CHANGE MASTER语句，把主库信息指向该login-path对应的账号，或者通过环境变量让复制线程在启动时读取凭据。
一种常见做法是把复制配置写进从库配置文件时使用凭据文件引用，而非明文。虽然MySQL的CHANGE MASTER本身仍需在语句中指定用户名，但配合login-path可以做到运维脚本不落盘密码。以下示例展示用login-path连接主库并启动复制的简化脚本逻辑：
-- 先通过login-path测试连接 -- mysql --login-path=repl -e "SELECT 1" -- 在从库内执行（用户名来自同一login-path，密码已由文件提供） CHANGE MASTER TO MASTER_HOST='192.168.0.1', MASTER_USER='repl', MASTER_PASSWORD='StrongPass#123', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=154; START SLAVE;
上述SQL里的MASTER_PASSWORD仍是明文，因此更安全的方案是把复制账号密码仅保留在.mylogin.cnf，并在自动化工具中用mysql --login-path=repl方式拉起检测脚本，避免把密码写进可被读到的.sql文件。对于完全不想在CHANGE MASTER写密码的场景，可借助mysql客户端变量与脚本拼接，但核心依然依赖login-path提供的加密源。
安全边界、权限管理与常见误区
不少用户误以为.mylogin.cnf里的密码永远无法被取出，实际上拥有该文件及相应用户权限的人仍可通过mysql客户端正常使用凭据，只是看不到明文。因此它防的是"被动泄露"（如配置文件误传、ps命令被截获），而非"主动滥用"。服务器被攻破且攻击者拿到用户权限时，凭据依然可被利用，所以仍需配合网络隔离与最小权限账号。
另一个误区是多个系统用户共用同一个.mylogin.cnf。由于文件权限是600，直接cp给其他用户会导致权限错乱或读不出。正确做法是由每个需要连接的系统账户各自执行mysql_config_editor生成自己的login-path。主从复制中若从库以mysql系统用户运行，就应切到mysql用户下生成文件，而不是在root下生成再改属主，否则可能因安全校验失败而无法加载。
此外，mysql_config_editor只适用于MySQL官方客户端工具链。如果你用第三方语言驱动（如Python的PyMySQL）连接主从，并不能直接读.mylogin.cnf，需要自己实现读取解密或改用操作系统级密钥管理。下表对比了几种主从密码管理方式的差异：
| 方式 | 密码是否明文 | 适用场景 | 维护成本 |
|---|---|---|---|
| my.cnf明文 | 是 | 内网测试 | 低 |
| 命令行传参 | 进程列表可见 | 临时调试 | 低 |
| mysql_config_editor | 加密存储 | 生产运维脚本 | 中 |
| 密钥管理服务 | 动态获取 | 云环境 | 高 |
综合来看，mysql_config_editor是MySQL主从复制凭据加密里成本适中且官方原生支持的选择。把它和严格的文件权限、专用复制账号结合在一起，能显著提升从库连接主库时的安全性，又不会给日常运维带来过多负担。
mysql_config_editorMySQL主从复制凭据加密修改时间：2026-08-18 13:50:31