Ponto a ponto – Replicação transacional

Aplica-se a:SQL Server

A replicação ponto a ponto fornece uma solução de escalabilidade horizontal e alta disponibilidade ao manter cópias de dados em várias instâncias de servidor, também chamadas de nodes. Baseada na replicação transacional, a replicação ponto a ponto propaga alterações transacionalmente consistentes quase em tempo real. Isso permite que aplicativos que exigem escalabilidade horizontal das operações de leitura distribuam as leituras dos clientes entre vários nós. Como os dados são mantidos entre os nós em quase tempo real, a replicação ponto a ponto fornece redundância de dados, o que aumenta a disponibilidade dos dados.

Considere um aplicativo Web. Ele pode se beneficiar da replicação ponto a ponto dos seguintes modos:

• As consultas de catálogo e outras operações de leitura são distribuídas entre vários nós. Isso permite que o desempenho permaneça consistente à medida que as leituras aumentam.

• Se um dos nós do sistema falhar, uma camada de aplicação poderá redirecionar as operações de gravação desse nó para outro nó. Isso mantém a disponibilidade.

• Se um nó exigir a manutenção ou o sistema inteiro necessitar de uma atualização, cada nó poderá ser posto offline e adicionado de volta ao sistema sem que a disponibilidade do aplicativo seja afetada.

Embora a replicação ponto a ponto permita escalar as operações de leitura, o desempenho de escrita nessa topologia é igual ao de um único nó. Isso porque, em última análise, todas as inserções, atualizações e exclusões são propagadas para todos os nós. A replicação reconhece quando uma alteração foi aplicada em um determinado nó e impede que as alterações circulem pelos nós mais de uma vez. Recomendamos enfaticamente que as operações de gravação de cada linha sejam realizadas em apenas um nó, pelos seguintes motivos:

• Se uma linha for modificada em mais de um nó, isso poderá causar um conflito ou mesmo uma atualização perdida quando a linha for propagada para outros nós.

• Há sempre alguma latência envolvida quando as alterações são replicadas. Com relação aos aplicativos que requerem que a última alteração seja vista de imediato, equilibrar a carga do aplicativo de maneira dinâmica pelos vários nós poderá se transformar em um problema.

A replicação ponto a ponto inclui a opção de ativar a detecção de conflitos em uma topologia ponto a ponto. Essa opção ajuda a evitar os problemas causados por conflitos não detectados, inclusive o comportamento inconsistente do aplicativo e as atualizações perdidas. Ao ativar essa opção, por padrão uma alteração de conflito é tratada como erro crítico que causa a falha do Agente de Distribuição. No evento de um conflito, a topologia é mantida em um estado inconsistente até que o conflito seja resolvido manualmente e os dados sejam tornados consistentes em toda a topologia. Para obter mais informações, consulte Conflict Detection in Peer-to-Peer Replication.

Topologias ponto a ponto

Os cenários a seguir ilustram usos típicos para replicação ponto a ponto.

Topologia com participação de dois bancos de dados

Ambas as ilustrações precedentes mostram dois bancos de dados participantes, com tráfego de usuário direcionado para os bancos de dados por meio do servidor de aplicativos. Essa configuração pode ser usada para uma série de aplicativos, de sites a aplicativos de grupos de trabalho, e oferece as seguintes vantagens:

• Melhor desempenho de leitura, porque as leituras são distribuídas entre dois servidores.

• Maior disponibilidade se for necessária manutenção ou se houver falha em um nó.

Em ambas as ilustrações, a atividade de leitura é equilibrada por carga entre os bancos de dados participantes, mas as atualizações são controladas diferentemente:

• À esquerda, as atualizações são particionadas entre os dois servidores. Se o banco de dados contiver um catálogo de produtos, você poderá, por exemplo, fazer com que um aplicativo personalizado atualize diretamente no nó A com relação aos nomes de produto começando de A a M, e que ele atualize diretamente no nó B com relação aos nomes de produtos começando de N a Z. As atualizações, em seguida, são replicadas no outro nó.

• À direita, todas as atualizações são direcionadas ao nó B. De lá, as atualizações são replicadas para o nó A. Se B estiver offline (por exemplo, para manutenção), o servidor de aplicativos poderá direcionar toda a atividade para A. Quando B voltar a ficar online, as atualizações poderão fluir para ele, e o servidor de aplicativos poderá mover todas as atualizações de volta para B ou continuar direcionando-as para A.

A replicação ponto a ponto pode oferecer suporte a ambas as abordagens, mas o exemplo de atualização central à direita é também usado com frequência na replicação transacional padrão.

Topologias com três ou mais bancos de dados participantes

A ilustração anterior mostra três bancos de dados participantes que fornecem dados para uma organização de suporte a software mundial, e com escritórios em Los Angeles, Londres e Taipei. Os engenheiros de suporte de cada escritório recebem chamadas telefônicas e atualizam informações sobre cada uma das chamadas de cliente. Os fusos horários dos três escritórios têm oito horas de diferença entre si, de modo a não haver sobreposições no dia de trabalho. O escritório de Taipei fecha, quando o escritório de Londres está apenas começando o expediente. Se uma chamada ainda está em andamento quando um escritório estiver fechando, a chamada será transferida para um representante no primeiro escritório que abrir.

Cada local tem um banco de dados e um servidor de aplicativo, que são usados por engenheiros de suporte à medida que eles digitam e atualizam informações sobre as chamadas de cliente. A topologia é particionada por tempo. Por isso, as atualizações ocorrem apenas no nó que está atualmente aberto para negócios e, em seguida, elas fluem para outros bancos de dados participantes. Essa topologia oferece as seguintes vantagens:

• Independência sem isolamento: cada escritório pode inserir, atualizar ou excluir dados, de forma independente, mas também compartilhá-los, porque eles são replicados em todos os outros bancos de dados.

• Disponibilidade superior no caso de falha ou permissão de manutenção em um ou mais dos bancos de dados participantes.

  

  A ilustração anterior mostra a adição de um nó à topologia de três nós. Um nó poderia ser adicionado a esse cenário pelos seguintes motivos:

• Porque outro escritório foi aberto.

• Para fornecer alta disponibilidade em suporte à manutenção ou para aumentar a tolerância a falhas, ou caso ocorra uma falha de disco ou outra falha significativa.

Observe que, em ambas as topologias, de três e de quatro nós, todos os bancos de dados publicam em e se inscrevem em todos os outros bancos de dados. Isso oferece um máximo de disponibilidade no caso de necessidades de manutenção ou falha de um ou mais nós. À medida que os nós são adicionados, é preciso equilibrar as necessidades de disponibilidade e escalabilidade, segundo o desempenho e a complexidade da implantação e do gerenciamento.

Configurando a replicação ponto a ponto

Configurar uma topologia de replicação ponto a ponto é semelhante a configurar uma série de publicações transacionais e assinaturas padrão. As etapas descritas nos artigos a seguir mostram a configuração de um sistema de três nós, semelhante à configuração mostrada à esquerda da ilustração anterior, que apresenta a topologia ponto a ponto.

Configurar a criptografia TLS 1.3

O SQL Server 2025 (17.x) apresenta suporte ao TDS 8.0 para replicação ponto a ponto, o que inclui:

• Configurando agentes de replicação para usar a criptografia TLS 1.3 entre instâncias do SQL Server 2025 (17.x) e também entre o SQL Server 2025 (17.x) e a Instância Gerenciada de SQL do Azure.
• Criptografia padrão para comunicação entre servidores vinculados entre instâncias do SQL Server 2025 (17.x) em uma topologia de replicação. Servidores vinculados no SQL Server 2025 (17.x) usam o driver OLE DB v19, que usa como padrão a Encrypt=Mandatory criptografia.

Considerações sobre o uso da replicação ponto a ponto

Esta seção fornece informações e diretrizes a serem consideradas ao usar a replicação ponto a ponto.

Considerações gerais

• A replicação ponto a ponto estará disponível apenas na edição Enterprise do SQL Server.

• Todos os bancos de dados que participam da replicação ponto a ponto devem conter esquema e dados idênticos:

  • Os nomes de objeto, de esquema de objeto e de publicação devem ser idênticos.

  • As publicações precisam permitir a replicação de alterações de esquema. (Esta é uma configuração de 1 para a propriedade de publicação replicate_ddl, que é a configuração padrão.) Para obter mais informações, consulte Fazer alterações de esquema em bancos de dados de publicação.

  • Não há suporte para filtragens de linha e de coluna.

• Cada nó deve usar seu próprio banco de dados de distribuição. Isso elimina o potencial de haver um único ponto de falha.

• Tabelas e outros objetos não podem ser incluídos em várias publicações ponto a ponto em um único banco de dados de publicação.

• Uma publicação precisa ser ativada para replicação ponto a ponto antes que qualquer assinatura seja criada.

• As assinaturas devem ser inicializadas usando um backup ou com a opção replication support only. Para obter mais informações, consulte Inicializar uma assinatura transacional sem snapshot.

• Não use colunas de identidade. Ao usar identidades, será preciso gerenciar manualmente os intervalos atribuídos às tabelas em todos os bancos de dados participantes. Para obter mais informações, confira Atribuir intervalos para o gerenciamento de intervalos de identidade manual.

Restrições de funcionalidades

A replicação ponto a ponto oferece suporte aos principais recursos da replicação transacional, mas não às seguintes opções:

• Inicialização e reinicialização com snapshot.

• Filtros de linha e de coluna.

• Colunas de data e hora.

• Publicadores e Assinantes que não são do SQL Server.

• Assinaturas de atualização imediata e de atualização em fila.

• Assinaturas anônimas.

• Assinaturas parciais.

• Assinaturas que podem ser anexadas e assinaturas que podem ser transformadas. (Ambas as opções foram preteridas no SQL Server 2005 (9.x).)

• Agentes de distribuição compartilhados.

• O parâmetro Agente de Distribuição -SubscriptionStreams e o parâmetro Log Reader Agent -MaxCmdsInTran.

• As propriedades do artigo @destination_owner e @destination_table.

• A replicação transacional ponto a ponto não oferece suporte à criação de uma assinatura transacional unidirecional para uma publicação ponto a ponto

• A replicação transacional ponto a ponto não oferece suporte à publicação de tabelas com colunas computadas como parte da chave primária.

As propriedades a seguir têm considerações especiais:

• A propriedade de publicação @allow_initialize_from_backup exige um valor igual a true.

• A propriedade de artigo @replicate_ddl exige um valor igual a true; @identityrangemanagementoption exige um valor igual a manual; e @status exige que a opção 24 esteja definida.

• O valor das propriedades de artigo @ins_cmd, @del_cmde @upd_cmdnão pode ser definido como SQL.

• A propriedade de assinatura @sync_type exige um valor igual a none ou automatic.

• O SQL Server 2019 (15.x) CU 13 introduz a propriedade de publicação, @p2p_confictdetection_policy. O valor do parâmetro padrão é originatorid e resolve o conflito na base da ID do originador. O valor do parâmetro lastwriter resolve o conflito com base no Last Writer.

Considerações sobre manutenção

Algumas ações exigem que o sistema esteja inativo. Isso significa interromper a atividade nas tabelas publicadas em todos os nós e garantir que cada nó tenha recebido todas as alterações de todos os outros nós.

Alterações no esquema da topologia (adição ou remoção de um artigo) exigem quiescência. Para obter mais informações, consulte Administrar uma topologia ponto a ponto (programação Transact-SQL de replicação).

A remoção de um nó da topologia nunca requer desativação.

A alteração das propriedades do artigo usando sp_changearticle nunca requer desativação. As alterações permitidas (para P2P) são as propriedades description, ins_cmd, upd_cmde del_cmd .

Alterações no esquema do artigo (adição/remoção de coluna) nunca requerem quiescência.

• Adição de artigo: Para adicionar um artigo a uma configuração existente, precisamos colocar o sistema em quiescência, executar a instrução CREATE TABLE & carregar os dados iniciais em cada nó da topologia e adicionar o novo artigo em cada nó da topologia.

• Descartando artigo: Se quisermos um estado consistente em todos os nós, precisamos colocar a topologia em estado quiescente

Para obter mais informações, consulte Suspender uma Topologia de Replicação (Programação de Replicação Transact-SQL) e Administrar uma Topologia Ponto a Ponto (Programação de Replicação Transact-SQL).

• Ao adicionar um novo nó a uma topologia ponto a ponto, você deve restaurar apenas dos backups que foram criados depois que o novo nó foi adicionado.

• Você não pode reinicializar assinaturas em uma topologia ponto a ponto. Se for necessário garantir que um nó tenha uma nova cópia dos dados, restaure um backup no nó.

Conteúdo relacionado

• Administrar uma topologia Ponto a Ponto (Programação Transact-SQL de replicação)
• Estratégias para fazer backup e restaurar o instantâneo e a replicação transacional
• Replicação transacional