HA集群镜像节点缺失MySQL数据文件无法启动，如何创建文件保障集群复制？

看起来你现在碰到的核心问题是镜像节点的MySQL数据目录几乎是空的，同时还遭遇了权限不足和InnoDB初始化失败的报错。别着急，咱们一步步来排查解决：

第一步：先解决目录权限问题 #

从报错里的InnoDB: operating system error number 13可以明确，这是MySQL进程没有/var/lib/mysql目录的读写权限导致的。你可以这么处理：

1. 先检查目录的属主属组：

   ls -ld /var/lib/mysql
   

   正常情况下，输出应该是drwxr-x--- mysql mysql这样的格式。
2. 如果权限不对，执行以下命令修正：

   chown -R mysql:mysql /var/lib/mysql
   chmod -R 750 /var/lib/mysql
   

   750权限是MySQL目录的标准配置，既能保证进程读写，又能避免其他用户访问。

第二步：不要手动创建数据文件！ #

你提到的database、innodbdata这些目录以及ibdata1这类文件，都是MySQL初始化或运行过程中自动生成的，手动创建的文件格式完全不符合要求，MySQL根本无法识别。正确的做法是从主节点同步完整的数据目录，这里给你两种适合HA集群的方案：

方案A：用mysqldump全量备份恢复（适合中小数据量） #

1. 先确保主节点数据处于一致状态：
   • 可以临时停止HA集群的MySQL资源，或者在主节点执行锁表命令（避免备份过程中有新数据写入）：

     FLUSH TABLES WITH READ LOCK;
     

2. 在主节点导出全量备份：

   mysqldump -u root -p --all-databases --flush-logs --master-data=2 > full_mysql_backup.sql
   

   参数说明：
   • --all-databases：导出所有库
   • --flush-logs：刷新二进制日志，方便后续复制定位
   • --master-data=2：在备份文件中记录主节点的二进制日志位置，用于镜像节点启动复制
3. 把备份文件传到镜像节点：

   scp full_mysql_backup.sql clsstd2:/tmp/
   

4. 在镜像节点恢复备份：
   • 先停止镜像节点的MySQL服务（如果之前启动失败，可能已经处于停止状态）
   • 清空/var/lib/mysql目录（保留err文件也可以，但建议清空避免干扰）
   • 执行恢复命令：

     mysql -u root -p < /tmp/full_mysql_backup.sql
     

5. 解锁主节点的表：

   UNLOCK TABLES;
   

方案B：用rsync直接同步数据目录（适合大数据量） #

1. 主节点锁表（避免数据变化）：

   FLUSH TABLES WITH READ LOCK;
   

2. 在镜像节点执行同步命令：

   rsync -avz --delete user@你的主节点IP:/var/lib/mysql/ /var/lib/mysql/
   

   参数说明：
   • -avz：归档模式、显示详细信息、压缩传输
   • --delete：删除镜像节点目录中主节点没有的文件，保证数据完全一致
3. 同步完成后，主节点解锁表：

   UNLOCK TABLES;
   

第三步：配置主从复制参数 #

不管用哪种方案，恢复完成后都要调整镜像节点的MySQL配置（my.cnf或my.ini）：

• 确保server-id和主节点不同（比如主节点设为1，镜像节点设为2）
• 开启中继日志：relay-log = /var/lib/mysql/relay-bin
• 开启只读模式（可选，避免误写）：read_only = 1（注意：root用户不受这个参数限制）

之后启动镜像节点的MySQL服务，登录后执行复制配置：

CHANGE MASTER TO
MASTER_HOST='你的主节点IP',
MASTER_USER='复制用的用户名',
MASTER_PASSWORD='复制密码',
MASTER_LOG_FILE='主节点的二进制日志文件名（从备份文件或主节点SHOW MASTER STATUS获取）',
MASTER_LOG_POS=对应的日志位置;

START SLAVE;

第四步：验证复制状态 #

登录镜像节点的MySQL，执行：

SHOW SLAVE STATUS\G

重点看以下两个字段：

• Slave_IO_Running：状态应为Yes，表示镜像节点能正常连接主节点获取二进制日志
• Slave_SQL_Running：状态应为Yes，表示镜像节点能正常执行中继日志中的SQL

如果有错误，查看Last_Error字段的提示，针对性排查即可。

第五步：修正HA集群资源配置 #

之前你的MySQL资源在两个节点都是standalone状态，这是导致双主数据不一致的根源。建议调整集群资源配置（比如用Pacemaker的话），配置为master-slave模式：

• 设置master-max=1：最多1个主节点
• 设置master-node-max=1：每个节点最多作为1次主节点
• 配置资源的克隆参数clone-max=2：允许两个节点都运行该资源（一主一从）

这样集群会自动管理主从切换，避免再次出现双主的情况。

备注：内容来源于stack exchange，提问作者Iván Jf