Windows Server MySQL主从复制安装配置指南

主库的 my.ini 必须配置 server-id=1、log-bin=mysql-bin、binlog-format=ROW、binlog-ignore-db=mysql、sync-binlog=1 这五项，缺一不可。先直接给结论：主从复制不是安装出来的，而是靠配置、服务注册和 SQL 命令协同生效的；Windows Server 上最常卡住的地方，其实就三个：服务名冲突、my.ini 路径错位，以及 CHANGE MASTER TO 里用错了 MASTER_LOG_FILE 和 MASTER_LOG_POS。

---

主库 my.ini 配置必须包含哪些项？

在 Windows Server 上，MySQL 主库的 my.ini 文件，必须在 [mysqld] 段落里明确写入下面这几项，一样都不能少：

• server-id=1：这个整数不能是 0 或重复，否则主从会乱套。
• log-bin=mysql-bin：开启二进制日志，文件前缀不能带路径，否则启动失败。
• binlog-format=ROW：强烈推荐，避免触发器或函数导致从库执行失败。
• binlog-ignore-db=mysql：必须忽略系统库，否则权限同步会出错。
• sync-binlog=1：保证每次事务都落盘，数据一致性关键。

常见错误：log-bin 写成绝对路径，比如 log-bin=C:/data/mysql-bin，Windows 下 MySQL 不认；server-id 前面有空格，整个配置节会被跳过。

从库服务怎么注册不冲突？

同一台 Windows Server 上跑两个 MySQL 实例，服务名不能都叫 MySQL。从库必须用自定义服务名注册，且 my.ini 要指向正确位置。具体步骤：

• 先复制一份主库目录，比如 C:MySQLSlave，然后改好 my.ini 中的 port（比如 3307）、datadir、server-id=2。
• 以管理员身份运行 cmd，cd 到从库 bin 目录，执行：
  mysqld install MySQLSlave --defaults-file="C:MySQLSlavemy.ini"
• 注册后检查注册表 HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMySQLSlave 下的 ImagePath 值是否完整包含 --defaults-file=... 参数——很多启动失败是因为这里路径不对或引号缺失。

注意：mysqld --initialize 必须在注册服务前执行，生成 data 目录和初始 root 密码，否则服务启动直接报错“找不到 data 目录”。

CHANGE MASTER TO 执行前要确认什么？

这是主从打通最关键的 SQL 命令，但极易因信息不匹配失败。执行前必须核对三件事：

• 先在主库上执行 SHOW MASTER STATUS;，记录返回的 File（如 mysql-bin.000002）和 Position（如 154）——这俩值必须原样填进从库命令。
• 从库连接主库的账号必须已创建且授权：GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY 'xxx';，密码策略要兼容，8.0+ 默认 require password policy，太短会拒绝。
• 从库的 relay-log 名称要显式指定，比如 relay-log=mysql-relay-bin，否则可能因默认名冲突导致 START SLAVE 后 IO 线程卡在 Connecting 状态。

典型错误：MASTER_LOG_FILE 写成 mysql-bin.000001 但主库当前已是 .000002；或者 MASTER_LOG_POS 用了 0 而不是实际 position，导致从库报错 Could not find first log file name in binary log index file。

验证同步是否真生效？

SHOW SLAVE STATUSG 是唯一可信的依据，只看这两项：Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes。如果其中一个是 No，别急着重配，先查 Last_IO_Error 或 Last_SQL_Error 字段——90% 的问题就藏在这里。比如：error connecting to master 'repl@x.x.x.x:3306' 是网络或防火墙问题；Could not execute Write_rows event on table xxx; Duplicate entry '1' for key 'PRIMARY' 是从库写了脏数据破坏了主键约束。

真正容易被忽略的是：主从库时间不同步，尤其 Windows Server 默认禁用 NTP，会导致基于 GTID 的复制异常；还有 read_only=1 虽然写在从库配置里，但必须手动执行 SET GLOBAL read_only=ON; 才生效，否则应用直连从库写入会悄无声息破坏一致性。