主库的 my.ini 必须配置 server-id=1、log-bin=mysql-bin、binlog-format=ROW、binlog-ignore-db=mysql、sync-binlog=1 这五项，缺一不可。先直接给出结论：MySQL 主从复制并非靠安装实现，而是通过配置、服务注册与 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，切换到从库的
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';，密码策略需兼容，MySQL 8.0+ 默认要求符合密码强度，太短会拒绝。 - 从库的
relay-log名称要显式指定，例如relay-log=mysql-relay-bin，否则可能因默认名冲突导致START SLAVE后 IO 线程卡在Connecting状态。
典型错误：MASTER_LOG_FILE 写成 mysql-bin.000001 但主库当前已是 .000002；或者 MASTER_LOG_POS 填了 0 而不是实际位置，导致从库报错 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; 才会生效，否则应用直接连接从库写入数据会悄无声息地破坏一致性。
