要約

  • PeeringDBの2.84.0公開記録は10月21日付で、RIR状態に基づくネットワーク削除が?since=利用者へ伝わらなかった不具合の修正を挙げる。元の報告は、netixlan行の物理削除と、一部ネットワークでupdated時刻が進まない問題を具体例で示した。
  • 20日に取り込まれた変更は削除手順を変え、削除済み行がAPIの増分応答に現れることを試験する。既に食い違った複製を片づけるには全件再同期が必要だというのが報告者の説明で、再同期を終えた利用者数は公開されていない。

消えたのは記録か、通知か

ピアリング担当者が交換点の接続候補を調べる。PeeringDBの公開画面には対象のネットワークが出ない。一方、社内で維持するコピーにはネットワークと交換LANの結びつきが残っている。後者を使う人だけが古い相手へ連絡するかもしれない。ディレクトリ上の接続は運用中のBGPセッションそのものではない。問題は、同じディレクトリを根拠にする二つの机で異なる現況が見えることだ。

PeeringDBのAPI仕様は、Unix時刻を使う?since=でその後の変更を取得できると説明する。削除済みオブジェクトもstatus=deletedと正のsinceで調べられる。公式FAQによれば、peeringdb-pyは初回に全件を取り、以後は差分を取り込む。毎回すべてを読み直さずに済む、筋のよい約束である。ただし、差分に「追加」と「修正」だけを入れて「削除」を落とせば、複製は次第に古い接続の収集箱になる。

10月7日、Remco van MookはPeeringDBの公式リポジトリに問題報告#2057を出した。増分同期したコピーを全件APIと比べ、二つの欠落を見つけた。一つはRIRの割当状態を確認して古いネットワークを整理する処理にある。ネットワークを削除する前に、そのネットワークのnetixlan、すなわちネットワークと交換LANを結ぶ行を一括で消していた。この一括処理は、行をdeletedへ変えupdatedを進めるモデルの削除処理を通らない。元の行は消え、差分を求める利用者には何も届かない。

もう一つは時刻のずれだ。一部のネットワーク行はdeletedになってもupdatedが旧時刻のままだった。報告の例では、2026年に削除されたネットワークの更新時刻が2022年を指す。2026年の同期カーソルを持つクライアントに、その変更が返るはずがない。問い合わせが正常終了しても、手元の状態は現在のPeeringDBから離れたままだ。

数字が示す範囲

報告者が約6か月の比較で見つけたのは、125ネットワークに属する286件の一括削除されたnetixlanと、更新時刻が進まないまま削除された46ネットワークである。これは報告者の比較で数えた行数だ。影響を受けた全クライアント数や実際のピアリング判断数は公表されていない。言えるのは、同じ仕組みから複数回、古い記録が残り得たということだ。

9日の追記には逆向きの食い違いもある。元データで有効なnetixlan569件がコピーに欠けており、349ネットワークと279交換点に及んだ。報告者は、長いトランザクションが時刻より遅く可視化された可能性と、復元時に時刻が動かなかった可能性を挙げた。原因を確定する履歴は追記にない。今回の削除修正で、この逆方向の欠落まで直ったと扱えば、別の調査を消してしまう。

20日にマージされたコミット81ac767は、接続行を先に一括削除する命令を取り除き、ネットワーク自身の削除処理に任せる。追加された試験はネットワーク、交換点、接続、技術連絡先を作り、RIR状態の整理を実行する。その上でネットワークと接続がdeletedになり、時刻が更新され、GET /api/netixlan?since=...が削除された接続を返すことを確かめる。データベース内で「消えた」ことではなく、利用者へ「消えたと伝わる」ことが合格条件になった。

公開されたリリースノートは2.84.0の日付を10月21日とし、#2057を同期利用者向けの削除修正として載せる。同じページの予定表には20日が本番目標として残る。マージ日、目標日、リリースノートの日付を一つの出来事に丸める必要はない。公表された修正の対象は、今後その処理を通る削除の通知である。

古い複製は誰が掃除する

以前に物理削除された行は、元に行がないため、後から削除通知を出せない。2022年のupdatedが残る削除も、2026年以降のカーソルでは拾えない。問題報告は、既存のずれに対するクライアント側の手段を全件再同期と書く。各利用者がどれほど再同期したかを示す公開記録は見つからない。その実施数が分かれば、残る古いコピーの規模を判断できる。

全件再同期は、差分同期が節約していた通信と処理を再び支払うことだ。原因が元データの削除経路にあっても、古いコピーを持つ側が照合の作業を引き受ける。PeeringDBは元の状態遷移とAPIを握り、利用者はカーソルと再構築の時期を握る。この責任の継ぎ目が問題の中心にある。定期実行ジョブが緑色でも、内容の一致は別に証明しなければならない。

API v3の草案は差分に削除と公開情報の取り下げを含め、日次スナップショットを初期取得と復旧に使うと定める案だ。まだ草案であり、今あるv2の古いコピーを掃除する機能ではない。むしろ、次の契約を試す物差しになる。削除された事実に版と時刻が付くか。利用者が自分のコピーの版を確認できるか。稼働率だけでは、欠落した一件を検出できない。

PeeringDBは削除を実行した。2.84.0では、削除を伝える経路も修理した。残った幽霊はコピーごとに数え直すしかない。ディレクトリの権威は、元の画面で正しいだけでは届かない。