Peer-to-Peer - Replicação Transacional

Aplica-se a:SQL Server

A replicação ponto a ponto fornece uma solução de expansão e alta disponibilidade mantendo cópias de dados em várias instâncias de servidor, também conhecidas como nós. Construída com base na replicação transacional, a replicação ponto a ponto propaga alterações transacionais consistentes quase em tempo real. Isso permite que os aplicativos que exigem expansão de operações de leitura distribuam as leituras dos clientes em vários nós. Como os dados são mantidos nos nós quase em tempo real, a replicação ponto a ponto fornece redundância de dados, o que aumenta a disponibilidade dos dados.

Considere um aplicativo Web. Isso pode se beneficiar da replicação ponto a ponto das seguintes maneiras:

• As consultas de catálogo e outras leituras estão espalhadas por 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 aplicativo poderá redirecionar as gravações desse nó para outro nó. Isso mantém a disponibilidade.

• Se um nó requer manutenção ou todo o sistema requer uma atualização, cada nó pode ser colocado offline e adicionado de volta ao sistema sem afetar a disponibilidade do aplicativo.

Embora a replicação ponto a ponto permita o dimensionamento de operações de leitura, o desempenho de gravação para a topologia é semelhante ao de um único nó. Isso ocorre 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 a um determinado nó e impede que as alterações percorram os nós mais de uma vez. É altamente recomendável que as operações de gravação para cada linha sejam executadas em apenas um nó, pelos seguintes motivos:

• Se uma linha for modificada em mais de um nó, ela poderá causar um conflito ou até 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. Para aplicativos que exigem que a alteração mais recente seja vista imediatamente, o balanceamento de carga dinâmico do aplicativo em vários nós pode ser problemático.

A replicação ponto a ponto inclui a opção de habilitar a deteção de conflitos em uma topologia ponto a ponto. Essa opção ajuda a evitar os problemas causados por conflitos não detetados, incluindo comportamento inconsistente do aplicativo e atualizações perdidas. Ao habilitar essa opção, por padrão, uma alteração conflitante é tratada como um erro crítico que causa a falha do Distribution Agent. No caso de um conflito, a topologia permanece 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 Deteção de conflitos na replicação ponto a ponto.

Topologias ponto a ponto

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

Topologia que tem dois bancos de dados participantes

Ambas as ilustrações anteriores mostram dois bancos de dados participantes, com tráfego de usuário direcionado para os bancos de dados por meio de um servidor de aplicativos. Essa configuração pode ser usada para vários aplicativos, de sites a aplicativos de grupo de trabalho, e fornece os seguintes benefícios:

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

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

Em ambas as ilustrações, a atividade de leitura tem balanceamento de carga entre os bancos de dados participantes, mas as atualizações são tratadas de forma diferente:

• À esquerda, as atualizações são particionadas entre os dois servidores. Se o banco de dados contivesse um catálogo de produtos, você poderia, por exemplo, ter um aplicativo personalizado atualizações diretas para o nó A para nomes de produtos que começam com A a M e atualizações diretas para o nó B para nomes de produtos que começam com N a Z. As atualizações são replicadas para o outro nó.

• À direita, todas as atualizações são direcionadas para o nó B. A partir daí, 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 está online novamente, as atualizações podem fluir para ele, e o servidor de aplicativos pode 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 qualquer uma das abordagens, mas o exemplo de atualização central à direita também é frequentemente usado com a 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 mundial de suporte de software, com escritórios em Los Angeles, Londres e Taipei. Os engenheiros de suporte de cada escritório atendem as chamadas dos clientes e inserem e atualizam informações sobre cada chamada do cliente. Os fusos horários dos três escritórios estão separados por oito horas, portanto, não há sobreposição na jornada de trabalho. À medida que o escritório de Taipei fecha, o escritório de Londres está abrindo para o dia. Se uma chamada ainda estiver em andamento enquanto um escritório está fechando, a chamada é transferida para um representante no próximo escritório a ser aberto.

Cada local tem um banco de dados e um servidor de aplicativos, que são usados pelos engenheiros de suporte à medida que inserem e atualizam informações sobre chamadas de clientes. A topologia é particionada por tempo. Portanto, as atualizações ocorrem somente no nó que está atualmente aberto para negócios e, em seguida, as atualizações fluem para os outros bancos de dados participantes. Essa topologia oferece os seguintes benefícios:

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

• Maior disponibilidade em caso de falha ou para permitir a manutenção em uma ou mais das bases de dados participantes.

  

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

• Porque outro escritório é aberto.

• Para fornecer maior disponibilidade para suportar a manutenção ou aumentar a tolerância a falhas se ocorrer uma falha de disco ou outra falha importante.

Observe que, nas topologias de três e quatro nós, todos os bancos de dados publicam e assinam todos os outros bancos de dados. Isso fornece disponibilidade máxima se houver necessidades de manutenção ou falhas de um ou mais nós. À medida que os nós são adicionados, você deve equilibrar as necessidades de disponibilidade e escalabilidade em relação ao desempenho e à complexidade da implantação e administração.

Configurando a replicação ponto a ponto

A configuração de uma topologia de replicação ponto a ponto é semelhante à configuração de uma série de publicações e assinaturas transacionais 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 na ilustração anterior que mostra a topologia ponto a ponto.

Configurar a criptografia TLS 1.3

O SQL Server 2025 (17.x) introduz suporte ao TDS 8.0 para replicação peer-to-peer, que inclui:

• Configuração de agentes de replicação para usar encriptação TLS 1.3 entre instâncias do SQL Server 2025 (17.x) e também entre SQL Server 2025 (17.x) e Azure SQL Managed Instance.
• Encriptação padrão para comunicação entre servidores ligados de instâncias do SQL Server 2025 (17.x) numa topologia de replicação. Os servidores ligados no SQL Server 2025 (17.x) utilizam o driver OLE DB v19, que usa encriptação por defeito Encrypt=Mandatory.

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 está disponível somente na edição corporativa do SQL Server.

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

  • Nomes de objetos, esquemas de objetos e nomes de publicações devem ser idênticos.

  • As publicações devem permitir que as alterações de esquema sejam replicadas. (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 filtragem de linhas e colunas.

• Cada nó deve usar seu próprio banco de dados de distribuição. Isso elimina o potencial de ter 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 deve ser habilitada para replicação ponto a ponto antes que qualquer assinatura seja criada.

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

• Não use colunas de identidade. Ao usar identidades, você deve gerenciar manualmente os intervalos atribuídos às tabelas em cada banco de dados participante. Para obter mais informações, consulte Atribuição de intervalos para gerenciamento manual de intervalos de identidade.

Restrições de recursos

A replicação ponto a ponto suporta os principais recursos da replicação transacional, mas não suporta as seguintes opções:

• Inicialização e reinicialização com um instantâneo.

• Filtros de linha e coluna.

• Colunas de carimbo de data/hora.

• Editores e assinantes que não são do SQL Server.

• Atualização imediata e atualizações em fila de assinaturas.

• Subscrições anónimas.

• Subscrições parciais.

• Subscrições amovíveis e subscrições transformáveis. (Ambas as opções foram preteridas no SQL Server 2005 (9.x).)

• Agentes de distribuição compartilhados.

• O parâmetro Distribution Agent -SubscriptionStreams e o parâmetro Log Reader Agent -MaxCmdsInTran.

• As propriedades @destination_owner do artigo 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 de sua chave primária.

As seguintes propriedades têm considerações especiais:

• A propriedade @allow_initialize_from_backup publication requer um valor true.

• A propriedade @replicate_ddl article requer um valor true,@identityrangemanagementoption requer um valor de manual e @status requer que a opção 24 seja definida.

• O valor das propriedades @ins_cmddo artigo , @del_cmde @upd_cmd não pode ser definido como SQL.

• A propriedade @sync_type de subscrição requer um valor de nenhum ou automático.

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

Considerações sobre manutenção

Algumas ações exigem que o sistema seja quiescente. Isso significa interromper a atividade em tabelas publicadas em todos os nós e certificar-se de que cada nó recebeu todas as alterações de todos os outros nós.

As alterações de esquema de topologia (adicionar ou descartar um artigo) exigem quiescing. Para obter mais informações, consulte Administrar uma topologia ponto a ponto (replicação Transact-SQL programação).

Remover um nó da topologia nunca requer quiescing.

Alterar as propriedades do artigo usando sp_changearticle nunca requer quiescing. As alterações permitidas (para P2P) são as descriptionpropriedades , ins_cmd, upd_cmd, e del_cmd .

Artigo As alterações de esquema (adicionar/soltar coluna) nunca exigem quiescing.

• Adicionando artigo: Para adicionar um artigo a uma configuração existente, precisamos desativar o sistema, executar a instrução CREATE TABLE & carregar 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 desativar a topologia

Para obter mais informações, consulte Desativar uma topologia de replicação (replicação Transact-SQL programação) e Administrar uma topologia ponto a ponto (replicação Transact-SQL programação).

• Se você adicionar um novo nó a uma topologia ponto a ponto, deverá restaurar somente a partir de backups criados após a adição do novo nó.

• Não é possível reinicializar assinaturas em uma topologia ponto a ponto. Se você tiver que 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 (replicação Transact-SQL programação)
• Estratégias para backup e restauração de snapshot e replicação transacional
• Replicação transacional