Кратко

  • В примечаниях к версии 2.84.0 от 21 октября PeeringDB указала исправление удалений, которые не доходили до пользователей инкрементального запроса ?since=. Первичное сообщение об ошибке описывает физическое удаление строк netixlan и сети со статусом deleted, у которых поле updated оставалось прежним.
  • Изменение, включённое 20 октября, убрало массовое удаление и добавило проверку ответа API с удалёнными объектами. Исправление касается дальнейшей работы выявленного пути. Уже расходящуюся локальную копию, по словам автора сообщения, нужно загрузить заново целиком; открытой статистики такого восстановления нет.

Невидимый выезд из каталога

Откройте живой PeeringDB и локальную копию, обновляемую только через ?since=. В первом соединение сети с точкой обмена уже вычеркнуто. Во второй оно всё ещё годится как цель для письма о пиринге или внутренней сверки. API отвечает исправно; удаление не попало в его поток изменений. Копия выдаёт вчерашнюю запись за сегодняшнюю. Она не удостоверяет действующую BGP-сессию, но уже направляет поиск не туда.

Документация API PeeringDB предлагает экономичный порядок. Клиент запрашивает объекты, изменённые после времени Unix, через ?since=; удалённые записи можно получить при status=deleted и положительном since. В официальном FAQ описан обычный режим peeringdb-py: сначала полная копия, затем только изменения. Экономия оправданна, пока источник сообщает и о появлении, и об исчезновении объекта. Молчаливая утрата строк делает местную базу музеем, который по расписанию получает новые экспонаты, но никогда не снимает старые таблички.

7 октября Remco van Mook открыл вопрос #2057 в репозитории PeeringDB. Он сравнил копию, обновлявшуюся через ?since=, с полными списками API и нашёл два механизма расхождения. Первый был в плановой проверке статуса сети в региональных интернет-регистрах. Перед удалением сети служебная команда массово удаляла её активные строки netixlan — связи сети с LAN точки обмена. Такая операция миновала метод модели, который должен поставить deleted и сдвинуть updated. В центральной базе строки уже нет, а в очередной порции изменений для клиента сообщения о ней не возникло.

Во втором механизме сеть переходила в состояние deleted, но дата updated сохраняла старое значение. В приведённых примерах удаление, связанное с 2026 годом, соседствует с временем обновления из 2022-го. Клиент с курсором за 2026 годом спрашивает о новых событиях и закономерно не получает событие, которое источник пометил четырьмя годами ранее. Ошибка находится на границе между изменением состояния и его публикацией.

Сколько записей увидел исследователь

В своей сверке за приблизительно шесть месяцев автор обнаружил 286 массово удалённых строк netixlan, относящихся к 125 сетям, и 46 сетей, удалённых без продвижения времени updated. Это числа из конкретного сравнения, а не оценка всех установок PeeringDB. Ни число клиентов с застарелыми копиями, ни число решений, принятых по ним, источник не публиковал. Зато имеются идентификаторы и времена, по которым можно понять работу дефекта.

9 октября тот же автор добавил пример обратного разрыва: 569 активных в источнике строк netixlan отсутствовали в его копии; они охватывали 349 сетей и 279 точек обмена. Возможны два порядка событий: долгую транзакцию клиент прочитал раньше, чем её изменения стали видны, хотя метка времени уже попала в прошлое; либо восстановленные строки не получили новую дату. Комментарий оставляет причину открытой. Исправление массового удаления нельзя записывать в счёт этой второй проблемы без отдельной хронологии записи и чтения.

20 октября PeeringDB приняла коммит 81ac767. Он удаляет команду прямого массового удаления соединений и передаёт обработку зависимых строк процедуре удаления сети. Новый тест создаёт сеть, точку обмена, связи и технический контакт, запускает проверку статуса RIR, затем требует статуса deleted и новой даты у сети и связей. Последняя часть теста запрашивает /api/netixlan?since=... и проверяет наличие удалённых связей в ответе. Проверяется результат, который видит зависимая копия, а не только состояние внутренней таблицы.

Примечания к выпуску датируют 2.84.0 21 октября и называют #2057 исправлением удаления для синхронизирующих пользователей. Таблица планирования на той же странице указывала 20 октября как намеченный день промышленного запуска. Слияние коммита, план и дата опубликованного выпуска — разные сведения. Зафиксированная коррекция касается пути будущего удаления; в примечаниях нет отчёта о массовой очистке уже разошедшихся локальных баз.

Устранение причины и уборка последствий

У физически удалённой в прошлом строки больше нет объекта, способного задним числом выдать tombstone. У строки со старым updated нет шанса попасть в запрос с новым временным курсором. Поэтому автор вопроса прямо называет полную повторную синхронизацию средством исправить уже накопленное расхождение на стороне клиента. PeeringDB не сообщила, сколько местных копий были пересобраны. Такая статистика позволила бы оценить остаток старых записей.

Повторная загрузка всего набора стоит дороже небольшого добавочного запроса. Цена ложится на владельцев копий, хотя исходный промах находился в маршруте удаления у источника. PeeringDB контролирует запись, переход статуса и смысл API; внешний оператор — свой курсор, частоту обновления и решение о полной сверке. Между этими полномочиями и образуется действительная власть каталога. Успешный запрос лишь подтверждает, что сервер ответил. Совпадение данных нужно доказывать отдельно.

Черновик API v3 требует отображать удаления и отзыв публичных данных в дельтах, а ежедневные снимки использовать для первой загрузки и восстановления. Это ещё проект, не выпущенная замена существующей копии. История 2.84.0 задаёт ему проверку: можно ли для каждой отмены установить версию и доставку, а для каждого зеркала — доказать, какой публичный набор у него действительно хранится? Доступность сервиса не отвечает на вопрос о полноте перемен.

Одна массовая операция обошла сигнал удаления. PeeringDB закрыла этот путь, но будущая версия не пришлёт задним числом уведомления о строках, стёртых до исправления. Владельцу зеркала нужен полный снимок и сравнение с нынешним источником. Без него база с сегодняшней датой на обложке остаётся архивом старых соединений.