论坛

你好，已经查到这次事件的根本原因，逐点回复：

1. 13:52–14:01 是否有节点维护／drain？为何在非设定时间重启？ 是的。当天 13:38–14:01（UTC）ap-east-2（AWS）集群进行了一轮节点轮替：多台底层节点被终止（事件记录为“节点已不存在于云端供应商”），同时启动新节点接手。你的 app 与 PostgreSQL Pod 因为原节点被移除而被重新排程到刚加入的新节点。所以这次重启与你设定的 06:00 定时重启无关，是平台节点轮替造成的非预期重排。

2. DB 为何约 68 分钟才恢复？是否与 aws-cni IP 分配失败有关？ 是，主因有两个，且两者相关：

• 新节点刚加入、aws-cni 尚未把网络（ENI／IP 池）准备好，当下又有大量被重排的 Pod 同时涌入（整个集群数十个服务在同一时间都出现“failed to assign an IP address”），导致 IP 配发塞车，Pod 卡在无法建立网络。
• 新节点是“冷节点”、没有任何镜像快取，需要重新拉取镜像。你的 PostgreSQL（postgres:18）镜像在记录中显示拉取约 1 小时 7 分（含等待），app 镜像约 24 分钟（含等待）。这两段等待就是中断被拉长到约 68 分钟的主因。

换句话说，这不是 DB 本身的问题（你提供的 CPU/内存也佐证没有 OOM），而是“重新排程 + 网络配发 + 重新拉取镜像”的恢复过程过久。

3. PostgreSQL 是否有平台侧或误设定的定时重启？ 没有。这次 DB 重启是上述节点轮替造成的 Pod 重排（Pod 名称有更换、镜像重新拉取），并非 in-place 的定时重启。你的服务上没有平台侧的定时重启设定，无需关闭。

4. 未来这类维护是否有事前通知或状态页可订阅？ 平台事件可在状态页 https://status.zeabur.com 查看，目前提供 RSS 订阅（https://status.zeabur.com/feed ，可加进 RSS 阅读器或自动通知）。另外我们已将这次节点轮替造成 aws-cni IP 配发塞车、以及冷节点重拉镜像导致恢复过久的问题回报给基础设施团队，会改善节点轮替时的排空与 IP 预热流程，降低之后类似情况的中断时间。

补充建议： 这次中断的根源在于“共享集群”的节点会随平台维护一起轮替，你的 Pod 因此被迫重排到刚开机的新节点。如果你的服务对连接稳定性要求较高，可以考虑改用 专用服务器（Dedicated Server）：专用服务器是单租户的独立节点，不会被纳入共享集群的整体节点轮替，能大幅降低这类非预期重排与恢复过久的影响；同时节点上已有镜像快取，重启恢复也更快。如果有兴趣，我可以再协助你评估适合的规格。