Кратко

  • Коммит Whois 252681a от 10 сентября переводит перечисление и проверку источников в NrtmService на NrtmSourceSlaveDao, подключённый к datasource для чтения.
  • DAO уведомлений умеет после пустого результата на slave повторить поиск на master, однако вызывается только после того, как ранняя проверка получила объект источника из реплики.
  • Из кода не следует, что изменение развёрнуто или что задержка репликации уже вызвала ошибку. Узкий контроль — квитанция допуска источника перед активацией.

Резервный путь часто описывают как свойство всей операции: если реплика не ответила, система обратится к основной базе. Коммит RIPE NCC 252681a0865d5a10dbcfeaeeaf81bf33ef2c3855 показывает более точную картину. Резерв есть у одного запроса, но до него расположен другой запрос, способный завершить обработку.

Изменение датировано 10 сентября 2026 года, 10:56 UTC, и называется «Use read-only (slave) source DAO in NRTMv4 Service». Оно затрагивает три файла. NrtmSourceDao получает аннотацию @Primary. Добавляется двадцатистрочный наследник NrtmSourceSlaveDao, который передаёт общей логике nrtmSlaveDataSource. Затем NrtmService начинает принимать именно этот тип.

У решения есть сильная практическая защита. Каталог источников мал и редко меняется, а публичные чтения повторяются постоянно. Реплика разгружает путь записи и отделяет выдачу от управления. Сам NRTMv4 построен вокруг проверяемости: Update Notification File подписан, snapshot и delta связаны хешами, session_id и версии отмечают непрерывность. В DAO уведомлений уже предусмотрено повторное чтение с master, если slave не вернул payload.

Поэтому речь не о вреде реплик и не об отсутствии инженерной осторожности. Граница определяется последовательностью.

Сначала каталог, затем резерв уведомления

Исходный NrtmSourceDao запрашивает id и name из таблицы source. Его конструктор использует nrtmMasterDataSource. Новый класс наследует запросы, но подставляет datasource реплики. В сервисе этот результат влияет на два внешних поведения.

Корневая HTML-страница проходит по getSources() и строит ссылку на Update Notification File для каждого найденного источника. Строка, ещё не видимая на стороне чтения, не появится в списке.

При прямом запросе уведомления каталог становится шлюзом допуска. Сервис вычисляет findLastNotification(getSource(source)). Внутренняя getSource() снова читает источники, ищет совпадение имени и при отсутствии выбрасывает Bad Request с сообщением «Invalid source».

В Java аргумент вычисляется до входа во внешний метод. Следовательно, getSource() должна вернуть объект, прежде чем findLastNotification() получит управление. Если реплика каталога ещё не знает строку, резервная логика уведомления вообще не запускается.

Её собственное устройство заслуживает положительной оценки. UpdateNotificationFileSourceAwareDao сначала ищет последний payload. Если результат пуст, а текущий SourceContext имеет тип SLAVE, код создаёт соответствующий master-источник, временно меняет контекст, повторяет запрос и восстанавливает прежний контекст в finally. Это разумная обработка состояния «источник известен, последняя запись уведомления ещё не видна в первом контексте».

Состояние «источник ещё не виден каталогу чтения» находится раньше. Резерв не сломан; его область начинается после проверки имени. Корневой список тоже не пользуется им.

Пограничен момент включения, а не обычная работа

Для давно существующих источников строки, вероятно, уже присутствуют на обеих сторонах. Тогда проверка имени проходит, а поиск уведомления сохраняет fallback. В собранных материалах нет метрики репликации, фактической ошибки, пропавшей ссылки или пострадавшего клиента.

Последовательность важна при добавлении источника, повторном создании строки, восстановлении datasource или смене конфигурации. В коротком переходе master может уже знать имя, а сервисная реплика — ещё нет. Если такое состояние возникнет, корень не перечислит источник, а прямой путь отклонит его до повторного чтения payload на master. Следствие доказуемо из порядка вызовов; само состояние не наблюдалось.

Нет и доказательства, что коммит вошёл в рабочий релиз. Публичная ветка не равна production. Нельзя утверждать сбой, устаревание данных, потерю маршрутов или уязвимость. Это ревизия контракта между каталогом и процедурой активации, а не отчёт об инциденте.

Реплика по определению может сходиться с основной базой не мгновенно, получая взамен масштабирование и изоляцию. Задача управления — определить, какие решения допускают такой контракт. Массовое чтение установившегося набора допускает его лучше, чем однократное расширение множества имён, доступных публике.

Криптографическая цепочка начинается с доступного объекта

На момент фиксации IETF Datatracker указывал ревизию 11 проекта NRTMv4. Протокол односторонне синхронизирует записи Internet Routing Registry через HTTPS. Публикация включает один Update Notification File, активный Snapshot File и ноль или несколько Delta Files.

Уведомление оформляется как JSON Web Signature. Клиент заранее знает его URL, имя IRR-базы и открытый ключ. Он сверяет source, проверяет подпись и SHA-256-хеши файлов. session_id ограничивает последовательность версий; при его смене клиент должен загрузить свежий snapshot, а не предполагать продолжение утраченной цепочки изменений.

Эти правила дают сильные ответы: ожидаемый ли издатель подписал уведомление, совпадает ли файл с подписанной ссылкой, непрерывна ли версия в этой сессии. Они не свидетельствуют, что внутренняя строка источника дошла до datasource HTTP-сервиса до включения имени. Если шлюз не принимает имя, клиент не получает объект, подпись которого умеет проверить.

Добавлять сведения о хостах или позиции репликации в сетевой протокол было бы неверно. Внутренняя топология не нужна зеркалу. Недостающее доказательство относится к решению издателя об активации.

Квитанция допуска связывает две готовности

Минимальный контроль — внутренняя квитанция допуска каталога. Она связывает редкое изменение набора источников с доказательством, что путь обслуживания готов. Раскрывать устройство базы для этого не требуется.

В квитанции фиксируются имя источника и поколение конфигурации, одобрение или создание на стороне записи, предназначенный для сервиса datasource и момент, когда он увидел строку, либо эквивалентный watermark готовности. Затем добавляется первое успешное получение корректно подписанного уведомления через реальный путь обслуживания, увиденные session_id и версия, ссылка на ключ.

Проверка корневого списка и прямого URL показывает два внешних представления. Имя одобрившего, время активации, условие rollback и связь со следующей квитанцией дают истории автора. Имена внутренних узлов, offsets, идентификаторы строк и секреты можно не включать.

Порядок автоматизируется: утвердить на write-side, дождаться наблюдения на service-side, получить и проверить уведомление тем же путём, только после этого открыть источник. Если контрольный срок истёк, активация остаётся на паузе либо используется специально одобренный временный маршрут.

Тесты должны разделять два случая. В первом новая строка есть на master, но отсутствует на slave: проверяется выбранная политика допуска. Во втором строка видима, но последнего payload на стороне чтения нет: проверяется имеющийся fallback. Один общий тест «реплика отстаёт» способен покрыть второй вариант и оставить первый незамеченным.

Такой контроль не уничтожает выгоду изменения. Платит редкая операция, меняющая публичный набор, а не каждый последующий запрос. Именно там и должна находиться дополнительная проверка.

Источники