Resumo

  • O commit 252681a, de 10 de setembro, faz o NrtmService enumerar e validar fontes por um NrtmSourceSlaveDao ligado ao datasource de leitura.
  • A busca da notificação tenta o principal quando não encontra payload no contexto de réplica, mas só recebe controle depois que a primeira consulta já transformou o nome em um objeto fonte.
  • Não há prova de implantação, atraso ou falha real. Um recibo de admissão do catálogo pode proteger a ativação de novas fontes e preservar a arquitetura de réplica.

O mérito de uma estratégia de fallback depende de uma pergunta banal: ela começa antes ou depois da decisão que pode encerrar a solicitação? No commit 252681a0865d5a10dbcfeaeeaf81bf33ef2c3855, o RIPE NCC oferece uma resposta particularmente legível.

Registrada às 10h56 UTC de 10 de setembro de 2026, a alteração se chama “Use read-only (slave) source DAO in NRTMv4 Service”. O escopo é reduzido. NrtmSourceDao recebe a anotação @Primary. Surge uma subclasse de vinte linhas, NrtmSourceSlaveDao, que reutiliza a mesma implementação com nrtmSlaveDataSource. O NrtmService passa a injetar essa subclasse.

Há boas razões para isso. O catálogo tem poucas fontes e muda raramente, enquanto os pedidos de leitura podem ser constantes. Desviar consultas públicas do principal reduz disputa com gravações e separa responsabilidades. O protocolo NRTMv4 já entrega uma base forte de confiança: Update Notification File assinado, hashes para snapshots e deltas, session_id e versões. A camada de acesso à notificação ainda contém um fallback explícito para o principal quando o primeiro resultado é vazio.

Nada disso precisa ser desfeito. A observação é mais estreita: a lógica de fallback não envolve a porta que decide se o nome existe.

A lista pública e o pedido direto compartilham o catálogo

O DAO original usa nrtmMasterDataSource. Ele guarda os nomes configurados das fontes principal e não autoritativa e consulta a tabela source, devolvendo id e nome. A nova subclasse fornece o datasource de réplica ao construtor herdado. No serviço, o resultado aparece em duas decisões.

Na raiz, getSources() alimenta uma lista de links. Para cada linha, o código constrói o caminho do respectivo Update Notification File. Uma fonte ausente da visão de leitura também fica ausente da descoberta.

No pedido de uma notificação, a validação ganha poder de veto. A expressão chama findLastNotification(getSource(source)). Dentro de getSource(), o serviço consulta novamente o DAO, procura o nome e, se não o encontra, lança “Invalid source”.

Como os argumentos são avaliados antes da chamada em Java, getSource() termina — ou falha — antes de findLastNotification() começar. Uma linha que ainda não chegou à réplica não produz o objeto necessário para a segunda consulta.

O segundo DAO foi escrito com cuidado. UpdateNotificationFileSourceAwareDao procura o payload mais recente. Se o resultado não existe e o SourceContext é SLAVE, ele cria a fonte mestre correspondente, muda o contexto temporariamente, repete a consulta e restaura o contexto original no bloco finally. É uma recuperação adequada para “fonte conhecida, notificação ainda não visível no lado de leitura”.

Não é uma recuperação para “fonte ainda desconhecida pelo lado de leitura”. A distinção não diminui o fallback; impede apenas que ele receba crédito por uma etapa que o código não lhe entrega. A página raiz também não passa por essa lógica.

O caso relevante é a transição

O catálogo de uma operação estável provavelmente já está replicado. Nessa condição, a fonte é aceita e o fallback da notificação continua disponível. O commit não informa o estado de qualquer banco real. Não há observação de link omitido, resposta rejeitada, dado atrasado ou espelho prejudicado.

A fronteira surge ao cadastrar uma fonte, recriar uma linha, recuperar um datasource ou mudar configuração. Pode existir um intervalo no qual o principal conhece a fonte e a réplica consultada pelo serviço ainda não. Se esse estado ocorrer, a lista não mostrará o nome e o caminho direto poderá rejeitá-lo antes de procurar a notificação no principal. O “se” é parte indispensável da afirmação.

Também não sabemos se o commit foi implantado. Código em repositório não equivale a release nem a produção. Chamar o caso de incidente ou vulnerabilidade trocaria uma revisão de ordem operacional por uma acusação sem base. O máximo que as fontes permitem dizer é que o caminho capturado tem uma condição de admissão anterior ao seu mecanismo de recuperação de payload.

Réplicas existem justamente para trocar imediatismo absoluto por escala e isolamento. Não são, por definição, um erro. A escolha correta depende do tipo de decisão. Ler uma tabela assentada milhares de vezes tolera uma propriedade de convergência que talvez seja inadequada para o instante único em que um nome novo passa a ser público.

Integridade de conteúdo não é prontidão do catálogo

Na captura, o IETF Datatracker indicava a revisão 11 do rascunho NRTMv4. O protocolo distribui registros de Internet Routing Registry em sentido único por HTTPS. Uma publicação reúne uma notificação, um snapshot ativo e nenhum ou vários deltas.

A notificação usa JSON Web Signature. O cliente é configurado com sua URL, o nome do banco IRR e a chave pública. Ele compara a fonte, verifica a assinatura e usa os hashes SHA-256 presentes no documento para validar os arquivos. O session_id delimita a sequência de versões; quando muda, o cliente deixa de pressupor continuidade e recarrega o snapshot atual.

São garantias importantes. Elas permitem rejeitar conteúdo alterado, assinatura inválida e encadeamento quebrado. Não medem se o registro interno que autoriza um nome já foi observado pelo datasource escolhido para servir HTTP. Sem passar pela porta, o cliente nem recebe o documento que sabe verificar.

A solução não é acrescentar topologia de banco ao formato NRTMv4. Hosts, posições de replicação e ids internos não pertencem ao contrato público. A prontidão pode ser comprovada dentro do processo de ativação.

Um recibo para a mudança de conjunto

O instrumento adequado é um recibo de admissão de fonte. Ele associa o ato raro de mudar o catálogo a evidências das duas camadas, sem cobrar uma consulta ao principal de cada solicitação futura.

O recibo começaria com o nome da fonte e a geração da configuração. Registraria a aprovação no lado de escrita, qual datasource deve atender o serviço e quando esse caminho observou a entrada — ou atingiu um marco de prontidão equivalente. Em seguida, guardaria a primeira recuperação válida de uma notificação assinada no caminho de serviço, com session_id, versão e referência da chave.

Duas verificações completam a perspectiva do usuário: a fonte aparece na página raiz e responde no caminho direto. Responsável, instante de ativação, condição de rollback e ligação ao recibo posterior dão autoria e histórico. Nada obriga a revelar hostname, offset, id da linha ou segredo.

A regra operacional pode ser automatizada: aprovar no principal, aguardar a visão de serviço, buscar e verificar a notificação pelo caminho real e só então marcar a fonte como ativa. Se o prazo falhar, manter o alta pendente ou usar um desvio temporário claramente autorizado.

Os testes devem representar estados distintos. Um deles deixa a linha no principal e a remove da réplica para verificar a política de admissão. Outro torna a linha visível mas deixa o payload ausente, confirmando o fallback atual. Uma prova genérica de replicação pode testar o segundo caso e ainda assim não alcançar o primeiro.

Esse recorte preserva o melhor da mudança. O problema não pede que todas as leituras retornem ao principal. Pede que a operação de baixa frequência que altera o conjunto público tenha seu próprio ponto de confirmação.

Fontes