Windows Server MySQL主从复制安装配置指南
来源：互联网 2026-07-22 08:43:08在WindowsServer上配置MySQL主从复制，主库my.ini须配置server-id=1、log-bin、binlog-format=ROW、binlog-ignore-db=mysql和sync-binlog=1等参数。从库需自定义服务名避免冲突，并设置中继日志。主库需创建复制账户并授权。执行CHANGEMASTERTO前核对主库File和Pos
主库的 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; 才生效，否则应用直连从库写入会悄无声息破坏一致性。
侠游戏发布此文仅为了传递信息，不代表侠游戏网站认同其观点或证实其描述
相关攻略
更多同类更新
更多
热游推荐
更多-
- DreamStudio
- Android/ | AI绘图
- 2026-06-30
-
-
- Playground AI
- Android/ | AI绘图
- 2026-06-30
-
- Adobe Firefly
- Android/ | AI绘图
- 2026-06-30
-
-
-
- Leonardo AI
- Android/ | AI绘图
- 2026-06-30
-
- Stable Diffusion
- Android/ | AI绘图
- 2026-06-30
