AWS ECS/Fargate部署MySQL遇InnoDB无法锁定ibdata1错误求助

你的判断完全正确——新部署的MySQL容器启动失败，就是因为旧任务的MySQL进程还在持有EFS卷上ibdata1文件的锁，导致新容器无法获取该文件的排他锁，触发MY-012574错误（error 11对应资源暂时不可用）。

核心原因 #

ECS默认的滚动部署策略是先启动新任务，再终止旧任务（默认最小健康百分比100%，最大百分比200%），这会导致短时间内新旧两个MySQL容器同时运行。而MySQL的InnoDB引擎需要对核心数据文件（如ibdata1）持有排他锁，同一时间只能有一个进程访问；加上EFS基于NFS协议，文件锁的生效范围覆盖整个文件系统，旧容器未释放锁前，新容器必然无法启动。

解决办法 #

1. 修改ECS服务部署策略，避免新旧任务并发运行

将ECS服务的部署配置调整为先终止旧任务，再启动新任务：

• 进入ECS服务的部署配置页面，设置：
  • Minimum healthy percentage = 0
  • Maximum percentage = 100
• 这样部署流程会变为：先停止正在运行的旧MySQL任务，确认其完全释放EFS文件锁后，再启动新任务，从根本上避免锁冲突。

2. 确保MySQL服务仅单实例运行

不要给MySQL所在的ECS服务设置大于1的任务数，MySQL单实例模式下不支持多进程共享同一个数据目录，即使部署成功，多实例同时运行也会持续触发文件锁冲突，导致服务异常。

3. 验证EFS挂载的锁机制

确认EFS使用NFSv4协议（Fargate默认挂载的是NFSv4），NFSv4支持可靠的文件锁机制，而NFSv3的锁机制存在局限性。可以在任务定义的EFS卷配置中显式指定协议版本：

"efsVolumeConfiguration": {
  "fileSystemId": "fs-xxxxxxxxxxxxx",
  "rootDirectory": "/mysql-data",
  "transitEncryption": "ENABLED",
  "fileSystemAuthorizationConfig": {
    "iam": "ENABLED"
  },
  "version": "4.0"
}

额外验证步骤 #

部署前可以手动终止旧任务，再启动新任务测试，确认锁冲突是否消失；同时再次确认ECS任务的IAM角色拥有elasticfilesystem:ClientMount、elasticfilesystem:ClientWrite权限，EFS的安全组允许任务所在VPC的流量访问。

内容的提问来源于stack exchange，提问作者Floating Point