windows 上无法原生运行 mysql 集群，官方不支持；wsl2 是可行方案，需配置真实 ip、不同端口、原生文件系统及防火墙放行，网络连通性是集群启动关键。
MySQL 在 Windows 上没法直接搭原生集群
Windows 本身不支持 MySQL Group Replication 或 InnoDB Cluster 所依赖的 POSIX 线程语义和信号处理机制，官方明确不推荐、也不测试 Windows 作为集群节点。你看到的“Windows 搭 MySQL 集群”教程，90% 是单机多实例模拟，或用 Docker Desktop（底层仍走 WSL2 Linux 内核），不是真正高可用集群。
WSL2 是目前 Windows 上跑 MySQL 集群最可行的路径
WSL2 提供完整的 Linux 内核，能运行 mysqld、mysqlsh、gr_member_info 等全部集群组件，且网络互通、端口可暴露、文件系统兼容。但要注意：不是装了 WSL 就自动能集群，关键在配置隔离与网络打通。
- 必须用 WSL2（不是 WSL1），否则
group_replication插件加载失败，报错Plugin 'group_replication' is not loaded - 每个 MySQL 实例要绑定不同端口（如
3306、3307、3308），且bind_address设为0.0.0.0（不能是127.0.0.1，否则 WSL 内部节点间无法连接） - Windows 防火墙默认会拦掉 WSL2 的跨实例通信，需手动放行对应端口（如
3307、3308） -
loose-group_replication_local_address必须填 WSL2 的实际 IP（用ip addr show eth0 | grep inet查），不能写localhost或127.0.0.1
mysqlsh 创建集群时连不上其他节点？检查这三处
常见现象是 dba.createCluster('myCluster') 卡住，或报 Unable to connect to seed instance。根本原因不是密码错，而是网络层不通。
- 确认所有节点的
group_replication_group_seeds配置里写的地址，是其他节点在 WSL2 网络中的真实 IP + 端口（例如172.28.16.5:33071），不是 Windows 主机的127.0.0.1 - 在发起创建的节点上，手动用
mysql -h 172.28.16.5 -P 3307 -u root -p测试能否连通目标实例——连不通就别进mysqlsh，先修网络 - WSL2 默认使用虚拟交换网络，每次重启 IP 可能变。不要硬编码 IP，改用
/etc/hosts绑定固定主机名（如node1 172.28.16.5），然后在配置中写主机名
集群启动后状态一直是 RECOVERING？多半是 SELinux 或 datadir 权限问题
WSL2 虽无 SELinux，但 Ubuntu 默认的 AppArmor 或文件权限继承可能干扰 group_replication 写入恢复日志。现象是 SELECT * FROM performance_schema.replication_group_members 显示成员状态为 RECOVERING，持续数分钟不转 ONLINE。
- 检查
datadir所在路径是否挂载自 Windows（如/mnt/c/mysql/data）——绝对不要这么干，NTFS 权限不兼容，必须用 WSL2 原生文件系统（如/var/lib/mysql-node1） - 确保每个实例的
datadir所属用户是mysql:mysql，且权限为750（chmod 750 /var/lib/mysql-node1） - 关闭
apparmor（sudo systemctl stop apparmor）或临时禁用对应 profile（sudo ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/），避免策略拦截 socket 文件创建
WSL2 上跑 MySQL 集群不是“装完就跑”，核心难点在节点网络拓扑的显式声明和权限边界的严格控制——IP 不能猜、端口不能复用、目录不能跨文件系统。一旦某个节点卡在 RECOVERING，优先查它能不能被其他节点 TCP 连通，而不是翻日志里那几行 warning。
