phpEnv MySQL 5.7配置多源复制 phpEnv数据库同步进阶教程

想在 phpEnv 里跑 MySQL 5.7 的多源复制？技术上可行，但默认配置压根没给你留这个口子。master-info-repository 和 relay-log-info-repository 这两项，必须改成 TABLE，否则 CHANGE MASTER TO ... FOR CHANNEL 不是报错就是静默完蛋。

phpEnv 的 my.ini 必须手动补全多源关键参数

phpEnv 自带的 MySQL 5.7 配置只覆盖了最基础的主从场景，my.ini（通常藏在 phpEnv\MySQL\my.ini 或 phpEnv\MySQL57\my.ini）里十有八九是找不到这两行的：

• master-info-repository = TABLE
• relay-log-info-repository = TABLE

必须警惕的是，如果这两个参数缺了任何一个，第二个通道就会直接报错，错误码是 3079，提示你多源复制只能在 master-info-repository 设为 TABLE 时才能配置。顺手再补上这几个，能省掉后续一堆麻烦：

• relay-log = relay-bin（防止默认文件名撞车）
• server-id = 100（全局唯一，别跟任何一个主库重复）
• log-sla ve-updates = ON（如果将来想级联或再做复制，还是开着省心）

改完之后，记得去 Windows 服务管理器里把 MySQL57 进程重启一遍，光点 phpEnv 面板的重启按钮不一定能保证配置生效。

每个主库通道要用独立的 FOR CHANNEL 名称

很多人在 phpEnv 环境下容易栽在一个细节上，就是直接拿旧式的单主写法去配：

CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_PORT=3306, ... ——这只会覆盖默认通道，第二个主库死活加不进去。

正确的做法是显式给每个通道起个名字，就像这样：

CHANGE MASTER TO 
  MASTER_HOST='192.168.10.212',
  MASTER_PORT=4300,
  MASTER_USER='repl',
  MASTER_PASSWORD='123456',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=154
FOR CHANNEL 'master_a';

再来第二个：

CHANGE MASTER TO 
  MASTER_HOST='192.168.10.212',
  MASTER_PORT=4400,
  MASTER_USER='repl',
  MASTER_PASSWORD='123456',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=154
FOR CHANNEL 'master_b';

这里有几个坑得提前避开：

• 通道名（比如 'master_a'）必须是合法标识符，点、短横、空格全不能用
• MASTER_LOG_FILE 和 MASTER_LOG_POS 得从对应主库的 SHOW MASTER STATUS 里抄，不能张冠李戴
• 配任何一个通道之前，最好先 STOP SLA VE，不然部分通道可能会卡在 Connecting 状态不挪窝

启动与验证必须按通道粒度操作

配好了怎么启动？千万别像单主复制那样直接 START SLA VE 了事，那样只会启动默认通道（空字符串），另一个通道根本不会动。正确做法是挨个来：

• START SLA VE FOR CHANNEL 'master_a';
• START SLA VE FOR CHANNEL 'master_b';

检查状态也得带上通道名：

SHOW SLA VE STATUS FOR CHANNEL 'master_a'\G

主要看这三项：

• Sla ve_IO_Running: Yes（IO 线程连上了主库）
• Sla ve_SQL_Running: Yes（SQL 线程在老老实实回放）
• Seconds_Behind_Master: 0（延迟归零才算同步就绪）

要是哪个通道显示 Sla ve_IO_Running: Connecting，八成是网络不通、用户权限没给对，或者主库的 bind-address 还绑在 127.0.0.1（phpEnv 默认就这样，跨机同步必须改成 0.0.0.0）。

数据库名冲突和表结构一致性是 runtime 隐患

phpEnv 多用于本地开发，经常把多个业务库映射到同一台从库，这时候陷阱就来了：

• 两个主库都有 user 表，而且都往 test 库写——从库会因为主键或唯一键冲突直接中断 SQL 线程
• 主库 A 用 utf8mb4，主库 B 用 latin1，从库建库时没统一字符集，同步时报 ERROR 1366 是常有的事
• 忘了配 replicate-do-db 或 replicate-ignore-db，系统库（比如 mysql）被拉过来，权限直接乱套

稳妥的方案是在从库的 my.ini 里显式约束一下：

replicate-do-db = app_v1
replicate-do-db = app_v2
replicate-ignore-db = mysql
replicate-ignore-db = information_schema

如果想更安全，可以用 replicate-rewrite-db 做库名映射，彻底避免同名冲突。

说到底，多源复制不是“配完就稳”的事儿，FOR CHANNEL 的每个环节都得独立校验。特别是在 phpEnv 这种集成环境里，配置文件的位置、服务的加载顺序、端口占用情况，都比标准部署更容易出偏差，多留个心眼总没错。