前言
日常巡检 1Panel 应用商店时，看到 Halo 及Mysql存在版本更新推送，便习惯性直接点击一键升级。等待升级流程走完访问站点，直接弹出502 Bad Gateway报错，起初以为是服务初始化需要短暂缓冲，静置等待许久后故障依旧，于是开始完整排查问题根源。
定位
进入 Docker 容器列表查看运行状态，Halo 容器长期处于
health: starting健康探测中，反复重启无法进入就绪状态；导出 Halo 运行日志分析，明确抛出 InnoDB 表空间缺失、数据表文件损坏异常，判定MySQL 数据库物理文件损坏是故障核心；
尝试恢复 1Panel 数据库备份修复站点，恢复操作执行完成后，502 报错并未解决，故障依旧；
核对 1Panel 备份任务记录才发现：近期自动备份任务持续执行失败，当前可用最新有效备份仅为 6 月 26 日批次，备份完整性不足，进一步增加修复难度。
修复
彻底关停原有异常 MySQL、Halo 故障容器，避免损坏文件持续触发异常重启；
在 1Panel 内全新部署 MySQL 实例，同步新建 Halo 容器，完成两套服务初始化部署；
利用 6 月 26 日有效备份，将历史数据导入全新 MySQL 数据库，核对库名、账号、权限配置完全匹配原有配置；
提取新容器正常运行的启动配置、环境变量，迁移配置至原有 Halo 容器，重启容器完成适配；
等待 Halo 启动完成、健康检查通过后，反向代理 502 报错消除，网站完整恢复正常访问。
整改
一、备份整改
定期核验 1Panel 自动备份任务执行日志。
关键版本升级前，手动执行一次全量备份，确认备份可用后再启动升级操作，杜绝升级翻车无退路。
二、升级规范
1Panel 一键升级前，先查看对应应用版本更新公告，留意破坏性变更、数据库结构改动说明，避免大版本跨级直接一键升级；
升级前临时关闭站点访问，避免升级中途写入数据导致数据表结构错乱、InnoDB 表空间冲突；
升级后不要直接关闭页面，持续观察容器运行日志 3–5 分钟，确认服务正常就绪、无报错再结束操作。
三、数据库避坑
MySQL 出现
Tablespace is missing、表空间 ID 冲突类报错，属于底层物理文件损毁，常规删表、外键修改命令大概率无法修复，及时采用重建实例迁移可用数据方案更高效；禁止随意手动删除 MySQL 数据目录内
.ibd表空间文件，极易引发数据字典错乱、数据库无法启动；给 MySQL 容器配置合理内存阈值，防止 OOM 强制杀库导致异常关机，诱发文件损坏。