mysql mmm agent 如何配置与监控 MySQL 主主复制

mysql mmm agent 如何配置与监控 MySQL 主主复制

MySQL MMM 适合用在两台主库互为主从、再配一台监控节点的老架构里，通过 writer VIP 和 reader VIP 控制业务入口。需要先说明边界：MMM 项目较老，生产环境要先在测试环境核对操作系统、Perl 依赖、MySQL 版本和发行版仓库是否仍可用；如果是新项目，也应同步评估 MHA、Orchestrator、ProxySQL、MySQL InnoDB Cluster 等方案。下面按可落地的方式讲 agent 配置和监控流程。

一、规划主机、角色和虚拟 IP

先把架构定清楚，不然后面的配置很容易互相打架。假设有三台机器：db1 是 192.168.10.11，db2 是 192.168.10.12，monitor 是 192.168.10.20。db1 和 db2 都安装 MySQL 与 mmm-agent，monitor 安装 mmm-monitor。

虚拟 IP 建议单独规划，例如 writer VIP 是 192.168.10.100，只允许当前写主库持有；reader VIP 可以是 192.168.10.101 和 192.168.10.102，分配给可读节点。确认这些 IP 没有被 DHCP 或其他机器占用，并且三台服务器在同一二层网络内，否则 VIP 漂移后业务可能连不上。

二、配置 MySQL 主主复制基础

在 db1 和 db2 的 MySQL 配置中分别设置唯一 server-id，开启 binlog 和 relay log。db1 可以使用 server-id=11，db2 使用 server-id=12。两边都建议开启 log_bin、relay_log、log_slave_updates，并设置自增步长避免双写时主键冲突，例如 auto_increment_increment=2，db1 的 auto_increment_offset=1，db2 的 auto_increment_offset=2。

重启 MySQL 后，在两台库上创建复制账号，例如 repl，并只授权给对端 IP。然后分别查看当前 binlog 文件和位置，在 db1 上执行 show master status，拿到 File 和 Position；在 db2 上用 change master to 指向 db1。反过来，在 db2 上查 show master status，再在 db1 上用 change master to 指向 db2。

启动复制后，两边都执行 show slave statusG，重点看 Slave_IO_Running 和 Slave_SQL_Running 是否为 Yes，Seconds_Behind_Master 是否正常。如果这里没有跑通，不要先装 MMM，因为 MMM 只能管理和监控复制状态，不能替你修好错误的复制链路。

三、创建 MMM 所需账号

MMM 至少需要两个账号：一个用于 monitor 检查 MySQL 状态，一个用于 agent 在本机执行只读、VIP 等控制动作。常见做法是在 db1 和 db2 上创建 mmm_monitor 与 mmm_agent。

mmm_monitor 需要能连接数据库并查看复制状态，mmm_agent 需要具备 SUPER、REPLICATION CLIENT 等权限，具体权限要结合你使用的 MMM 版本配置要求核对。为了避免权限问题，测试环境可以先按官方示例授予所需权限，生产环境再收敛到最小权限。创建后从 monitor 节点手工连接 db1、db2，确认账号、密码、防火墙和 bind-address 都没有问题。

四、安装 mmm-agent 和 mmm-monitor

在 db1、db2 安装 mysql-mmm-agent，在 monitor 安装 mysql-mmm-monitor。不同发行版包名可能略有差异，有的仓库已经不再默认提供，需要通过发行版历史仓库或内部源安装。安装完成后，确认系统里存在 mmm_agentd、mmm_mond 或对应服务文件。

如果使用 systemd，后面用 systemctl 管理服务；如果是较老系统，可能用 service 管理。不要混着用，先确认实际服务名，再写入运维文档。

五、配置所有节点共用的 mmm_common.conf

MMM 的核心配置在 mmm_common.conf，db1、db2、monitor 三台机器要保持一致。这里要定义集群名称、主机 IP、角色、虚拟 IP、MySQL 账号和网卡。

配置时把 db1、db2 分别声明为 host，mode 通常都设为 master，因为它们是主主复制。writer 角色只绑定一个 VIP，例如 192.168.10.100；reader 角色可以绑定一个或多个 VIP。interface 要写业务网卡名称，例如 eth0、ens192 或 bond0，必须和系统实际网卡一致。写错后 agent 可能启动正常，但 VIP 无法挂上。

配置完成后，把同一份 mmm_common.conf 分发到 db1、db2、monitor。结果应该是三台机器看到的集群定义完全一致，避免 monitor 判断一套角色、agent 执行另一套角色。

六、配置 db1、db2 的 mmm_agent.conf

在 db1 的 mmm_agent.conf 中设置 this db1，在 db2 的 mmm_agent.conf 中设置 this db2。这个字段必须和 mmm_common.conf 里的 host 名称完全一致，大小写也不要随意变化。

接着启动 agent 服务。启动后查看日志，确认没有出现 unknown host、access denied、interface not found、cannot assign requested address 等错误。此时 agent 只是待命，它会等待 monitor 下发角色控制。

七、配置 monitor 节点的 mmm_mon.conf

monitor 节点需要知道集群名称、监控间隔、报警方式以及允许管理命令的用户。最关键的是 active_master_role，通常设置为 writer，表示 monitor 会确保只有一个节点持有写 VIP。

配置完成后先不要急着让业务接入，启动 mmm-monitor，然后运行 mmm_control show。正常情况下能看到 db1、db2 的状态，以及 writer、reader 角色分配。如果节点显示为 AWAITING_RECOVERY，说明 MMM 还没有把它放回可用状态，需要确认复制无误后执行 set_online。

八、把节点切到 ONLINE 并验证 VIP

在 monitor 上执行 mmm_control set_online db1，再执行 mmm_control set_online db2。随后执行 mmm_control show，理想结果是两个节点都处于 ONLINE，其中一个节点持有 writer，reader VIP 分布在可读节点上。

到 db1、db2 上用 ip addr 查看 VIP 是否真正绑定到网卡。再从业务同网段机器连接 writer VIP，执行 select @@hostname 或 select @@server_id，确认写入口落在当前 writer 节点。对 reader VIP 做同样测试，确认读入口可连接。

九、验证故障切换是否符合预期

在非业务时段做一次演练。先记录当前 writer 在哪台机器，然后停止该机器的 MySQL 服务。monitor 应该在检测到故障后把 writer VIP 漂移到另一台机器。此时 mmm_control show 会显示原 writer 不可用，新 writer 获得写角色。

恢复故障节点后，不要直接让它上线。先检查 MySQL 是否启动，复制线程是否为 Yes，是否存在复制错误。确认数据追平后，再执行 mmm_control set_online 节点名。结果应该是它重新参与 reader 或备用角色，而不是抢回 writer。

十、日常监控要看哪些指标

MMM 自身要监控 mmm_mond 和 mmm_agentd 服务是否存活，mmm_control show 是否能返回 ONLINE、HARD_OFFLINE、AWAITING_RECOVERY 等状态。MySQL 层面要监控复制线程、复制延迟、binlog 磁盘空间、错误日志、连接数和只读状态。

特别要盯住 read_only。正常情况下，非 writer 节点应保持只读，当前 writer 允许写入。MMM 可以帮你切换角色，但如果应用绕过 VIP 直连某台 MySQL，仍可能写到错误节点，所以业务连接串要统一走 VIP 或代理层。

十一、常见问题处理

如果 VIP 不漂移，先查网卡名、子网掩码、防火墙和 ARP，再看 agent 日志。很多问题不是 MMM 判断失败，而是系统层无法添加地址。

如果节点一直 AWAITING_RECOVERY，通常是 monitor 不信任该节点当前复制状态。检查 show slave status 的 Last_IO_Error、Last_SQL_Error，修复后再 set_online。

如果发生双写冲突，要先停业务写入，确认哪台是事实主库，再修复复制。MMM 的 writer VIP 只能保证一个入口，不能阻止人为直连或应用配置错误造成双主同时写。

收尾建议

完成 mysql mmm agent 如何配置与监控 MySQL 主主复制后，把三类信息写进运维文档：节点与 VIP 对应关系、常用 mmm_control 命令、故障切换和恢复步骤。上线前至少演练一次 MySQL 停止、网络断开、复制中断三种场景。能稳定通过这些验证，MMM 才算真正接管了主主复制的高可用，而不是只把配置文件放到了服务器上。