windows server 2022 上 mysql 8.0 原生不支持自动故障转移的高可用（ha），主从复制需手动配置 server-id、log-bin 等核心参数，且真生产级 ha 应选用 linux 环境部署 group replication 或 innodb cluster。
主从复制必须配 server-id 和 log-bin
这是主从同步的硬门槛，缺一不可，且每个实例 server-id 必须唯一（不能都是 1）。log-bin 默认关闭，必须显式启用：
-
server-id=1（主）、server-id=2（从），值为正整数，不能重复 -
log-bin=mysql-bin—— 路径名不含目录，实际日志会写入datadir下 - 从库还需加
read_only=1防误写，但 root 用户仍可写，需额外限制权限 - Windows 下路径分隔符统一用
/或双反斜杠\，单反斜杠在my.ini中可能被解析为转义符
Windows 上启动从库时常见报错：ERROR 2003 / ERROR 2005
不是网络不通，而是从库连不上主库的 binlog 位置。原因集中在三处：
- 主库没执行
SHOW MASTER STATUS就重启过，导致File和Position失效 - 从库执行
CHANGE REPLICATION SOURCE TO（MySQL 8.0.23+ 语法）时，SOURCE_LOG_FILE和SOURCE_LOG_POS填错，尤其容易把mysql-bin.000001写成mysql-bin.00001（少一位） - 主库防火墙没放开 3306，或
bind-address仍是127.0.0.1，导致从库 IP 连接被拒
自动故障切换不能靠 Windows 服务自带机制
Windows 的 sc failure 或服务恢复操作只能重启进程，无法判断主库是否真的宕机，更不会自动把从库提为主库。真实可行的轻量方案只有两种：
- 用 PowerShell 脚本定时
mysqladmin ping -h 主IP -u root -p密码，失败后调用STOP SLAVE; RESET SLAVE ALL;并切换应用连接串 —— 但存在脑裂风险，需配合 VIP 或 DNS 切换 - 引入 Orchestrator（Go 编写，Windows 可运行）或 MHA（Perl，Windows 兼容性差），前者更推荐，但需额外部署 Consul 或 etcd 做状态存储
- 别碰 MySQL Router + InnoDB Cluster：虽标称支持 Windows，但 2026 年实测在 Server 2022 上初始化集群常卡在
cluster.addInstance()，且日志无明确错误提示
my.ini 里最容易漏掉的两个安全项
主从环境一旦暴露在内网甚至公网，这两项不设就等于裸奔：
-
require_secure_transport=ON—— 强制所有连接走 SSL/TLS，否则复制账号明文传输密码 -
default_authentication_plugin=mysql_native_password—— MySQL 8.0 默认用caching_sha2_password，而旧版客户端（如某些监控工具、PHP 7.4）不兼容，主从间认证失败静默丢包
mysql-error.log、Windows 事件查看器里的服务日志、还有 PowerShell 脚本 stdout/stderr 重定向的输出文件——它们不在同一目录，也不用同一时间戳格式。
