故障事件记录：WordPress Multisite sitemeta 表异常

此次故障源于 WordPress 多站点核心表 sitemeta 数据异常，虽表本身数据量不大（约 300 行），但对全局配置至关重要，一旦损坏会影响整个网络。已采取紧急替换恢复措施，并计划加强备份、变更控制和监控，避免类似问题再次发生。

日期： 2025-08-27

系统： WordPress Multisite（多站点网络）

影响范围： 所有子站点访问异常，部分页面出现 500 Internal Server Error

事件经过

1. 异常发现

   • 用户在访问子站点时出现 500 错误。

   • 主站点可以打开，但部分子站点和页面报错。

   • 清除浏览器缓存后可临时恢复，但登录后问题再次出现。

2. 排查过程

   问题非常诡异的是 页面虽然显示不完全正常，各个页面都能打开，但是连接在 F12的 network中显示有500报错，但仍然能访问。

   • 初步怀疑是 缓存 / Cookie 导致，但问题复现后排除单纯缓存问题。

   • 检查 Web Server (Nginx) 与 PHP 错误日志，发现报错指向 WordPress 数据库层。

   • 对比本地开发与线上数据库，定位到 wp_sitemeta 表存在异常。

   • 将本地（正常）数据库中的 sitemeta 表替换线上版本后，问题立刻恢复正常。

3. 根因推测

   • sitemeta 表在 WordPress 多站点中存储 全局网络级别配置，影响所有子站点（如：站点 URL、上传路径、插件启用信息等）。

   • 线上 sitemeta 表可能在最近一次 配置修改 / 数据迁移（WP Migrate 插件） 中被破坏：

     • 某些关键字段（如 siteurl、active_sitewide_plugins、upload_filetypes 等）异常。

     • 数据编码或序列化信息出错，导致 WordPress 加载失败。

影响评估

• 影响时长： 数小时

• 影响用户： 全站近十万用户均可能受影响

• 严重性： 高（主业务中断）

临时解决方案

• 用历史正常版本的 sitemeta 表替换当前异常版本，服务恢复。

后续改进措施

1. 数据库备份

   • 关键表（sitemeta、options、usermeta）增加独立备份策略。

   • 全库每日备份（保留 30 天），关键表额外快照（保留 7 天）。

2. 变更管控

   • 禁止直接在线上修改 sitemeta。

   • 所有配置修改先在本地/预生产验证，再同步到线上。

3. 监控报警

   • 增加 500 错误率 监控。

   • 增加对 sitemeta 表关键字段（如 siteurl, active_sitewide_plugins）的定时一致性校验。

? 结论：

此次故障源于 WordPress 多站点核心表 sitemeta 数据异常，虽表本身数据量不大（约 300 行），但对全局配置至关重要，一旦损坏会影响整个网络。已采取紧急替换恢复措施，并计划加强备份、变更控制和监控，避免类似问题再次发生。