在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 主库（默认服务名 MySQL）的 my.ini 必须在 [mysqld] 下明确写入以下几项，缺一不可：

• server-id=1（整数，范围 1–4294967295，不能为 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（说明能连上主库并读取 binlog）
• Slave_SQL_Running: Yes（说明能解析并执行 relay log）

如果其中一个是 No，别急着重配，先查 Last_IO_Error 或 Last_SQL_Error 字段——90% 的问题就藏在这里。比如：error connecting to master '[email protected]: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; 才生效，否则应用直连从库写入会悄无声息破坏一致性。