摘要

  • PeeringDB 的 2.84.0 版本说明把发布日期列为 10 月 21 日，并记载修复了 RIR 状态清理时，网络和交换点连接的删除未被 ?since= 增量同步接收的问题。原始缺陷单同时指出，有些 netixlan 行被直接抹掉，有些网络虽然变为 deleted，updated 时间却没有变化。
  • 10 月 20 日合并的修复改动删除流程，并新增 API 回归测试：删除状态和新时间戳必须经 ?since= 返回。它能管住今后的这条路径；旧镜像留下的过期行仍须完整同步清除。公开材料没有列出完成重建的客户端数量。

目录里的一条旧路

维护交换点连接清单的人常把 PeeringDB 数据复制到本地。这样做省去反复抓取全部目录，也方便把记录同自己的设备、工单和联系人放在一起。一份清单来自 PeeringDB 当前公开视图，另一份来自定时更新的镜像。如果前者已经没有某网络在交换点的条目，后者仍显示它，运营团队面前就出现两个“当前事实”。目录条目能帮助寻找联系人和规划接入；实际 BGP 会话与流量要由运行记录回答。光是目录分叉，已经足够浪费一次接洽和一次排查。

PeeringDB 的 API 规范给了镜像一条明确的省力路线：用 Unix 时间戳做 ?since= 参数，只取最近改变的对象；要找删除对象，可结合 status=deleted 与正值的 since。其常见问题文档说明，peeringdb-py 第一次下载完整数据，随后按变更增量更新。这个约定的关键不是轮询频率，而是“改变”的定义。新增、修改、删除都要出现在可观察的变更流里；少报删除，本地副本就会越用越像旧电话簿。

10 月 7 日，Remco van Mook 在 PeeringDB 自身的代码仓库提交缺陷单 #2057。他把一个通过 ?since= 更新的副本同 API 的完整列表相比，找到了两种漏报。第一种出现在按区域互联网注册管理机构状态清理网络的程序中。程序先对网络下的 netixlan 条目执行批量删除，再删网络。批量删除绕过了对象本应使用的软删除方法：既没有留下 deleted 状态，也没有把 updated 推到新时间。源库里这行已经不见，镜像询问“上次以后有什么变化”却收不到讣告。

第二种漏报更狡猾。一些网络对象确实变成 deleted，但时间字段停在旧值。缺陷单给出的样本显示，2026 年发生的删除对应的 updated 仍是 2022 年。镜像拿着 2026 年的游标查询，服务器把这条新删除归档在四年前，当然不会返回。轮询程序可以准时运行、无报错结束，结果仍然与源头背离。

修复覆盖了什么

报告者在约六个月的比对中找到 286 条被硬删除的 netixlan，属于 125 个网络；另有 46 个网络删除没有推动 updated。这些是他在所比对数据中的计数。PeeringDB 没公布受影响客户总数，也没有披露由此引发了多少错误决定。这里真正刺眼的是机制和重复出现的样本：目录拥有删除权，却没把删除变成下游能读到的事件。

同一缺陷单 10 月 9 日的补充还记录反向问题：源头当时活跃的 569 条 netixlan 不在镜像里，跨 349 个网络和 279 个交换点。报告者提出两条可能的时序：长事务在客户端已跨过时间窗口后才提交，或者被恢复的行没有更新日期。他没有把原因定死。修好删除路径，不等于这批“活着却缺席”的记录自动回来了；要解开它，需要逐行重建写入、提交和可见的时间顺序。

10 月 20 日合并的提交 81ac767把那段直接批量删除活跃连接的代码拿掉，让网络自身的删除流程处理关联对象。新增测试不满足于“数据库里行没了”：它创建网络、交换点连接和技术联系人，触发 RIR 状态清理，检查网络及连接变为 deleted、更新时间前进，并验证 GET /api/netixlan?since=... 确实返回这些删除行。镜像只看 API；测试把成功标准放在镜像能看到的地方。

PeeringDB 发布说明把 2.84.0 标为 10 月 21 日发布，并明确列出 #2057 的同步删除修复。页面上的计划表曾写 10 月 20 日为生产目标，两处日期各有用途：合并发生在 20 日，版本说明写发布于 21 日。修复证据指向一条今后会报出删除的流程，而不是一个能伸进所有旧副本、自动擦去过时条目的远程开关。

一次完整同步的账单

对早已被硬删除的记录，源库里已没有一行可供日后补发 deleted。对时间仍留在 2022 年的删除，2026 年游标也不会忽然向后翻。缺陷单给出客户端补救办法：做一次完整重新同步。这恰好是增量接口原本试图节省的工作。谁运行本地镜像，谁就要拿新的全量源视图同旧副本对账；发布补丁的机构无法替每一个未知的副本完成这件事。

这一笔账属于治理，而非仅仅程序员的扫尾。PeeringDB 掌握源目录、删除代码和 API 的语义；运营者掌握镜像、更新间隔及其使用场景。源头的状态变动若不能以客户端可消费的方式公开，权威只留在源头屏幕上，决策却可能发生在旧副本上。绿色的同步日志说明请求成功，不说明目录一致。

另一个方向的承诺写在 PeeringDB API v3 草案里：增量数据必须包含删除与撤回，每日快照承担启动和回退。草案尚未上线，不能替 2.84.0 的旧副本还债。但它提出了下一代接口必须回答的硬问题：每一次撤回有没有版本和可追踪的通知？客户端能否证明自己持有的是哪一个公开状态？服务器百分之百在线，也可能百分之百漏报某条关键删除。

这起缺陷的起点是一行批量删除代码，终点却不在代码仓库。源头修好了通知；镜像运营者还要确认旧幽灵是否已经搬走。删除一条记录的权力，要带上把删除交付给依赖者的责任。