Replicação transacional ponto a ponto

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. Criada com base 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 expansão de operações de leitura distribuam as leituras de clientes em vários nós. Como os dados são mantidos entre os nós quase em tempo real, a replicação ponto a ponto fornece redundância de dados, o que aumenta a disponibilidade de dados.

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

• Consultas de catálogo e outras leituras 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 no sistema falhar, uma camada de aplicativo poderá redirecionar as gravações desse nó para outro nó. Isso mantém a disponibilidade.

• Se um nó exigir manutenção ou todo o sistema exigir uma atualização, cada nó poderá ser colocado offline e adicionado novamente 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 é similar 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 sejam executadas por meio dos nós mais de uma vez. É altamente recomendável que as operações de gravação para cada linha sejam realizadas 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 é propagada para outros nós.

• Sempre há 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 dinâmico de carga do aplicativo em vários nós pode ser problemático.

A replicação ponto a ponto inclui a opção de habilitar 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, 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 Agente de Distribuição. No caso de um conflito, a topologia permanece em um estado inconsistente até que o conflito seja resolvido manualmente e os dados sejam consistentes em toda a topologia. Para obter mais informações, consulte Detecçã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 uma variedade de aplicativos, desde sites até aplicativos de grupo de trabalho e fornece os seguintes benefícios:

• Desempenho de leitura aprimorado, porque as leituras são distribuídas em dois servidores.

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

Em ambas as ilustrações, a atividade de leitura é balanceada por 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 contiver um catálogo de produtos, você poderá, por exemplo, ter um aplicativo personalizado de 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 dar suporte a qualquer abordagem, mas o exemplo de atualização central à direita também é frequentemente usado com replicação transacional padrão.

Topologias que têm 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 em cada escritório tomam chamadas de clientes e inserem e atualizam informações sobre cada chamada do cliente. Os fusos horários dos três escritórios têm oito horas de diferença, portanto, não há sobreposição no dia útil. À 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 quando um escritório estiver fechando, a chamada será 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 apenas no nó que está aberto atualmente para empresas e, em seguida, as atualizações fluem para os outros bancos de dados participantes. Esta topologia fornece as seguintes vantagens:

• 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 um ou mais bancos 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 por razões como as seguintes:

• Porque outro escritório está aberto.

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

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 em caso de necessidades de manutenção ou falha 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 da administração.

Configurando a replicação ponto a ponto

Configurar uma topologia de replicação ponto a ponto é muito semelhante à configuração de uma série de publicações e assinaturas transacionais padrão. As etapas descritas nos tópicos 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.

Considerações sobre como usar a 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 só está disponível nas versões enterprise do SQL Server.

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

  • Nomes de objeto, esquema de objeto e nomes de publicação 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.

• Recomendamos que cada nó use 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 banco de dados de publicação única.

• Uma publicação deve ser habilitada para replicação ponto a ponto antes de qualquer assinatura ser criada.

• As assinaturas devem ser inicializadas usando um backup ou com a opção "somente suporte de replicação" . Para mais informações, consulte Inicializar uma assinatura transacional sem um instantâneo.

• Não recomendamos o uso de 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 a seção "Atribuindo intervalos para gerenciamento manual do intervalo de identidades" em Replicação de Colunas de Identidade.

Restrições de funcionalidades

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

• Inicialização e reinicialização com uma imagem.

• 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 assinaturas de atualização na fila.

• Assinaturas anônimas.

• Assinaturas parciais.

• Assinaturas anexáveis e assinaturas transformáveis. (Ambas as opções foram preteridas no SQL Server 2005.)

• Agentes de Distribuição Compartilhados.

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

• As propriedades do artigo @destination_owner e @destination_table.

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

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

• A propriedade de publicação @allow_initialize_from_backup requer um valor de true.

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

• O valor das propriedades do artigo @ins_cmd, @del_cmd e @upd_cmd não pode ser definido como SQL.

• A propriedade de assinatura @sync_type requer um valor de none ou automatic.

Considerações sobre manutenção

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

• Adicionar um nó do SQL Server 2005 à uma topologia já existente

• Adicionando um artigo a uma publicação existente

• Fazendo alterações de esquema

• Restaurando um nó de um backup

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

• Se você adicionar um novo nó a uma topologia ponto a ponto, deve garantir que a restauração seja feita apenas 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ê precisar garantir que um nó tenha uma nova cópia dos dados, restaure um backup no nó.

Consulte Também

Administrar uma topologia Ponto a Ponto (Programação Transact-SQL de replicação)
Estratégias para backup e restauração de snapshots e replicação transacional
Tipos de publicação para replicação transacional