主库 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:\MySQL\Slave），改好my.ini中的port（比如3307）、datadir、server-id=2 - 以管理员身份运行 cmd，cd 到从库
bin目录，执行：mysqld install MySQLSlave --defaults-file="C:\MySQL\Slave\my.ini" - 注册后检查注册表
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MySQLSlave下的ImagePath值是否完整包含--defaults-file=...参数 —— 很多启动失败是因为这里路径不对或引号缺失
注意：mysqld --initialize 必须在注册服务前执行（生成 data 目录和初始 root 密码），否则服务启动直接报错“找不到 data 目录”。
在 Windows 上执行终端命令，或对比 Windows 与 Linux 的 Shell 语法时使用。建议先检测当前 Shell 是 PowerShell 还是 cmd.exe，再给出相应命令……
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 STATUS\G 是唯一可信依据，只看这两项：
-
Slave_IO_Running: Yes（说明能连上主库并读取 binlog） -
Slave_SQL_Running: Yes（说明能解析并执行 relay log）
如果其中一个是 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; 才生效，否则应用直连从库写入会悄无声息破坏一致性。
