退出码137表示容器被SIGKILL（信号9）强制终止，主因是OOM Killer触发：若docker inspect显示"OOMKilled": true，则为超内存limit被cgroup杀；若为false，则多因宿主机全局OOM或MemoryPressure驱逐。
容器反复重启，先看退出码是不是137
退出码 137 是最常见线索——它代表进程被内核用 SIGKILL 强杀，基本等于“内存不够被OOM Killer干掉了”。别急着查MySQL日志，先确认这个：
- 运行
docker inspect <容器名>，搜"ExitCode"和"OOMKilled"字段 - 如果看到
"ExitCode": 137且"OOMKilled": true（或虽为false但dmesg -T有Out of memory记录），就是宿主机内存见底了 -
free -h看available值，低于 500MB 就危险；docker stats <容器名>看实时内存占用是否贴近你设的memorylimit
MySQL数据目录挂载失效，90%的“丢数据”都源于此
容器重启后 MySQL 表结构/数据消失，大概率不是 MySQL 崩溃，而是 /var/lib/mysql 根本没挂上持久化存储。验证三步走：
- 进容器执行
docker exec -it <容器名> ls -ld /var/lib/mysql：若权限是drwxr-xr-x 1 root root，说明挂载点空着；正常应是drwx------ 1 mysql mysql - 再跑
docker exec -it <容器名> find /var/lib/mysql -maxdepth 1 -type d | wc -l：返回1就是空目录，挂载失败或卷为空 -
docker inspect <容器名>查Mounts字段：确认Destination是/var/lib/mysql，且Source指向命名卷（如mysql-data）或绝对路径（如/data/mysql）；若Source是一串哈希值（如/var/lib/docker/volumes/abc123/_data），那是匿名卷，每次重启都新建，数据不复用
健康检查配置太激进，把活的MySQL当死的杀
如果你用了 healthcheck，它可能在 MySQL 还没初始化完就发起探测，连续失败触发重启。典型症状是容器刚起来几秒就挂，docker logs 里看不到 MySQL 错误，但 docker inspect 显示 "Status": "unhealthy"。
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 检查
docker-compose.yml或run命令里的healthcheck配置，重点关注start_period和initial_delay - MySQL 启动慢（尤其带大量数据时），
start_period至少设成60s，timeout不低于10s，retries别小于3 - 临时禁用健康检查验证：删掉
healthcheck块或加disable: true，观察是否还重启
磁盘空间不足或文件系统损坏，InnoDB直接报错退出
MySQL 容器反复重启，docker logs 里出现 InnoDB: Error number 28 means 'No space left on device' 或 Database page corruption，说明底层存储出问题了。
- 运行
df -h查宿主机根分区和 MySQL 挂载点所在分区，Use%超过 90% 就要清理 - 常见占空间大户：
docker system prune -a清镜像/悬空卷，journalctl --disk-usage查日志体积 - 若挂载的是宿主机目录，检查该目录权限是否为
mysql用户可写（chown -R 999:999 /path/to/mysql，MySQL 官方镜像默认用 UID 999） - 发现
ibdata1锁定失败或崩溃恢复失败，别硬重启，先docker volume inspect <卷名>找到宿主机路径，用mysqld --innodb-force-recovery=1尝试导出数据
真实场景里，137 和挂载失效占了八成以上。查完退出码和挂载，再看日志才有意义——否则就是在错误方向上反复折腾。
