Como implementar bidirecional replicação transacional

Este artigo passo a passo descreve como implementar replicação transacional bidirecional. Este artigo também descreve os problemas envolvidos na implementação de replicação transacional bidirecional.

Bidirecional replicação transacional

Replicação transacional bidirecional, também conhecido como bidirecional replicação transacional, permite que um servidor para ser um editor e um assinante aos mesmos dados. Porque os servidores que participam da replicação serão replicar que as alterações para outros servidores, as alterações não são ser propagada volta ao servidor de origem.

Por exemplo, se você tiver dois servidores (servidor e servidor B), os servidores são considerados na replicação transacional bidirecional se as duas condições a seguir forem verdadeiras:

• As alterações efectuadas a tabela T1 no Server A são replicadas para tabela T1 no servidor B.
• As alterações efectuadas a tabela T1 no servidor B são replicadas para tabela T1 no servidor a.

Portanto, se uma alteração é gerado por servidor, a alteração é duplicada para servidor B, mas servidor B não propaga a alteração mesma replicação da. Server usará um mecanismo de detecção de auto-retorno que o distribuidor usa para determinar se para enviar as alterações de volta para o servidor de origem.

Planejar a topologia de replicação transacional bidirecional

Para replicação transacional bidirecional, um dos servidores pode atuar como assinante central e todos os outros servidores se inscrever o assinante central. Portanto, quaisquer alterações que se originam em um servidor são replicadas para o assinante central e, em seguida, o assinante central, por sua vez, replica as alterações para todos os outros servidores que participam da replicação. No entanto, com a Ajuda do mecanismo de detecção de auto-retorno, o distribuidor pára a alteração sejam propagadas para o servidor de origem.

Por exemplo, se três servidores (servidor, servidor B e C Server) participam da replicação transacional bidirecional e servidor é o assinante central, editores e assinantes são mantidos em das seguintes maneiras:

• Publica um servidor para servidor B e C. Server
• Servidor A assina do servidor B e C. Server
• Servidor B publica e inscreve-se de somente Server a.
• Servidor C publica e inscreve-se de somente Server a.

Portanto, qualquer alteração que se origina no servidor B é replicada para o servidor A e C. Server

Está em conflito na bidirecional replicação transacional

Quando você faz alterações em um servidor que participe da duplicação, as alterações são replicadas para todos os outros servidores participantes. Durante essa replicação, podem ocorrer conflitos e replicação pode falhar. A lista a seguir descreve possíveis conflitos e as formas que você pode evitar esses conflitos:

• Se você inserir um registro que possui uma chave em uma tabela em um dos servidores e outro registro que possui a mesma chave já existe em outros servidores que participam da replicação, a replicação não propaga as alterações para outros servidores.
  
  ação sugerida Para evitar esse problema, certifique-se de que você use chaves diferentes em cada servidor que participa da replicação. Para fazer isso, alocar um intervalo predeterminado de teclas para cada servidor que participa da replicação. Você também pode usar uma chave composta em cada servidor.
• Quando você atualiza um registro que foi excluído em outro servidor, a instrução UPDATE afeta zero linhas no servidor onde o registro foi excluído e a replicação falha com um erro.
  
  ação sugerida Para evitar esse problema, execute uma das seguintes etapas:
  • Remover @@ ROWCOUNT verificar após a instrução UPDATE real no procedimento armazenado personalizado de atualização.
    
    - ou -
  • Use o -Skiperrors parâmetro para o agente de distribuição ignorar este erro. Para obter mais informações sobre erros ignorando na replicação transacional, visite o seguinte site:
    
    http://msdn2.microsoft.com/en-us/library/aa178842(SQL.80).aspx (http://msdn2.microsoft.com/en-us/library/aa178842(SQL.80).aspx)
    - ou -
  • Procure um registro antes da instrução UPDATE na atualização do procedimento armazenado. Se nenhum registro existir, ignore a instrução UPDATE e o registro será excluído de todos os assinantes.
• Quando você atualiza uma coluna em um registro é atualizado ao mesmo tempo em outro servidor, os dados podem ser diferentes em dois servidores.
  
  ação sugerida Para evitar esse problema, determinar se os dados está sendo atualizados ao mesmo tempo em outros servidores e executar qualquer ação necessária. Para fazer isso, modifique o procedimento armazenado personalizado de atualização e usar sintaxe XCALL para chamar a atualização de procedimento armazenado. A sintaxe XCALL fornece os valores de todas as colunas antes do procedimento de atualização é chamado e fornece os valores atualizados na coluna. Você pode comparar o valor atual da coluna com o valor antes que o procedimento armazenado de atualização é chamado. Se você vir valores diferentes, a coluna está sendo atualizada ao mesmo tempo por servidores diferentes. Você pode personalizar o procedimento armazenado para selecionar qual valor persiste. Para obter mais informações sobre como usar XCALL, visite o seguinte site:
  
  http://msdn2.microsoft.com/en-us/library/Aa237133(SQL.80).aspx (http://msdn2.microsoft.com/en-us/library/Aa237133(SQL.80).aspx)
  Observação Você pode especificar a sintaxe XCALL para chamar a atualização correspondente procedimento armazenado ou excluir o procedimento armazenado usando sp_addarticle durante a publicação. Você também pode especificar a sintaxe XCALL usando SQL Server Enterprise Manager. Para fazer isso, execute estas etapas:
  1. No SQL Server Enterprise Manager, localize a publicação que você deseja.
  2. Clique a publicação com o botão direito do mouse e, em seguida, clique em Propriedades .
  3. Clique na guia artigos , localize o artigo e clique no botão Propriedades do artigo (...) ao lado para o artigo.
  4. Na caixa de diálogo Propriedades da tabela artigo , clique na guia comandos .
  5. Na caixa de texto comandos UPDATE substituir com essa chamada de procedimento armazenado , digite XCALL e, em seguida, clique em OK .
  6. Na caixa de diálogo Propriedades de publicação , clique em OK .
• Quando você atualizar colunas diferentes em um registro, atualizações simultâneas de colunas diferentes de um registro, às vezes, podem levar a conflitos.
  
  ação sugerida Para evitar esse problema, determine se as colunas diferentes no mesmo registro são atualizadas ao mesmo tempo e em seguida, executar qualquer ação necessária. Para fazer isso, modifique o procedimento armazenado personalizado de atualização e usar o XCALL sintaxe para chamar a atualização de procedimento armazenado. Como a sintaxe XCALL fornece os valores antes que o procedimento armazenado de atualização é chamado, você pode adicionar uma das seguintes opções para o procedimento armazenado de atualização antes que a atualização real seja realizada:
  • Compare os valores atuais de todas as colunas em relação aos seus valores antes da atualização de procedimento armazenado é chamado.
  • Adicione uma coluna para representar a versão de linha e para comparar seu valor atual com seu valor antes da atualização de procedimento armazenado é chamada.
  Valores diferentes indicam que colunas diferentes estão sendo atualizadas ao mesmo tempo. Em seguida, você pode decidir se deseja atualizar a coluna.
• Quando você excluir uma linha que está sendo atualizada por outro servidor ao mesmo tempo, a replicação poderá falhar.
  
  ação sugerida Para determinar se uma linha é atualizada e excluída ao mesmo tempo, use a sintaxe XCALL no procedimento de exclusão armazenado. Compare cada coluna da linha que está sendo excluída contra os valores antes que o procedimento excluir armazenado é chamado. Valores diferentes indicam que essas atualizações estão sendo executadas ao mesmo tempo. Você pode excluir ou manter a linha atualizada.
  
  Observação Mesmo se você não excluir o registro no assinante, o registro não existe mais no servidor que originou o DELETE instrução.
• Quando você exclui uma linha que está sendo excluída ao mesmo tempo em outro servidor que está participando na replicação, a replicação falhará porque a instrução DELETE não afeta as linhas em alguns dos assinantes.
  
  ação sugerida Para evitar esse problema, execute uma das seguintes etapas:
  • Remover @@ ROWCOUNT verificar após a instrução DELETE real no procedimento armazenado personalizado de atualização.
    
    - ou -
  • Use o -Skiperrors parâmetro no agente de distribuição para ignorar este erro. Para obter mais informações sobre erros ignorando na replicação transacional, visite o seguinte site:
    
    http://msdn2.microsoft.com/en-us/library/aa178842(SQL.80).aspx (http://msdn2.microsoft.com/en-us/library/aa178842(SQL.80).aspx)

Observação Cada implantação pode exigir uma abordagem diferente para resolver esses conflitos, dependendo dos requisitos comerciais. Esses conflitos são mais fáceis resolver quando apenas dois servidores envolvidos. Quando mais de dois servidores estão envolvidos, você poderá usar procedimentos armazenados para determinar qual servidor foi originada as alterações. O procedimento armazenado de atualização que é usado para atualizar os registros no servidor C não sabe se a alteração foi originada no servidor ou no servidor B. Ao contrário de replicação de mesclagem, replicação transacional não foi projetada para resolver conflitos. Replicação transacional apenas em cenários onde os conflitos podem ser evitados em vez de implantar resolvido.

Implementar bidirecional replicação transacional

Para implementar bidirecional replicação transacional, todas as seguintes condições devem ser verdadeiras:

• Os dados serão sincronizados entre os servidores de duplicação.
• Procedimentos armazenados que são usados por replicação estão localizados em todos os participantes bancos de dados.
• A inscrição foi configurada usando @ loopback_detection = 'true' parâmetro.
  
  Observação A opção de Definir @ loopback_detection = 'true' não está disponível no momento na interface do usuário. Portanto, você deve inscrever-se usando o procedimento sp_addsubscription armazenados.

Se você executar um backup e uma restauração, lembre-se que sites diferentes exigem diferentes restrições sobre a chave primária para se certificar que chaves primárias duplicadas não são criadas. Lembre-se também de criar todas as restrições com a cláusula NOT FOR REPLICATION.

Você pode usar o exemplo a seguir para configurar a replicação transacional bidirecional em um computador executando o SQL Server 2000.

Observação Instruções de Transact-SQL são listadas para cada uma das seguintes etapas. Execute as instruções Transact-SQL para executar a tarefa mencionada na etapa anterior.

1. Crie um distribuidor, editores e assinantes em um computador executando o SQL Server. Para fazer isso, execute estas etapas:
   1. Criar dois bancos de dados:

      use master
      go
      
      create database test1
      go
      
      create database test2
      go
      

   2. Criar duas tabelas que possuem uma coluna IDENTITY com o conjunto de opção NOT FOR REPLICATION:

      use test1
      go
      
      create table two_way_test1 
      (
      	pkcol		INTEGER PRIMARY KEY NOT NULL,
      	intcol		INTEGER IDENTITY(1,1) NOT FOR REPLICATION,
       	charcol		CHAR(100),
      	timestampcol 	TIMESTAMP
      )
      
      use test2
      go
      
      create table two_way_test2 
      (
      	pkcol 		INTEGER PRIMARY KEY NOT NULL,
      	intcol 		INTEGER IDENTITY(1000000000,1) NOT FOR REPLICATION,
       	charcol 	CHAR(100),
       	timestampcol 	TIMESTAMP
      )
      go

   3. Alocar um intervalo predeterminado de valores para a coluna de chave primária para que os valores em diferentes servidores não sejam no mesmo intervalo. Por exemplo, você pode aplicar 1-1000 como o intervalo de chave para a tabela two_way_test1 no banco de dados test1 e impor 1001-2000 como intervalo de two_way_test2 tabela no banco de dados test2 chave. Para fazer isso, use o seguinte código:

      	-- Constraint to enforce a range of values between 1 and 1000 in database test1 
      use test1
      go
      
      alter table 
      	two_way_test1 
      with nocheck 
      add constraint 
      	checkprimcol check NOT FOR REPLICATION 
      	(
      		pkcol BETWEEN 1 and 1000
      	) 
      go 
      
      
      use test2
      go
      
      	-- Constraint to enforce a range of values between 1001 and 2000 in the database test2 
      
      alter table 
      	two_way_test2
      with nocheck 
      add constraint 
      	checkprimcol check NOT FOR REPLICATION 
      	(
      		pkcol BETWEEN 1001 and 2000
      	) 
      go 
      
      

2. Ativar o servidor como o distribuidor e crie um banco de dados de distribuição:

   use master
   go
   sp_adddistributor @distributor = '<distributor name>' 
   go
   use master
   go
   sp_adddistributiondb @database='distribution'
   go

3. Permitem que todos os computadores que executam o SQL Server que estão participando da replicação como editores:

   use master
   go
   
   exec sp_adddistpublisher 
   	@publisher = '<Your Server Name>', 
   	@distribution_db ='distribution', 
   	@security_mode = 0, 
   	@login = 'sa', 
   	@password = 'sa',
   	@working_directory ='<Location of Directory>'

4. Ativar todos os os bancos de identificados dados de replicação:

   use master
   go
   
   exec sp_replicationdboption N'test1', N'publish', true
   go
   
   exec sp_replicationdboption N'test2', N'publish', true
   go
   

5. Criar procedimentos armazenados personalizados para INSERT, UPDATE e DELETE operações em todos os bancos de dados para aplicar as alterações feitas durante a replicação.
   
   Observação Normalmente, quando você insere um valor em uma coluna IDENTITY, a opção de IDENTITY_INSERT para a tabela deve ser ativado. Esta tarefa é obtida pela opção NOT FOR REPLICATION para agentes de replicação de entrada.
   
   Você não pode atualizar os valores na coluna IDENTITY. Portanto, quando você atualiza os valores durante a duplicação, você precisará remover os valores antigos e inserir os novos valores. Para criar os procedimentos armazenados personalizados, execute essas etapas:
   1. Create the custom stored procedures in the test1 database:

      use test1
      go
      
      -- INSERT Stored Procedure
      
      create procedure sp_ins_two_way_test1	
      	@pkcol int, 
      	@intcol int, 
      	@charcol char(100), 
      	@timestampcol timestamp,
      	@rowidcol uniqueidentifier
      as
      	insert into two_way_test1 
      	(
      		pkcol,
      		intcol,
      		charcol
      	) 
      	values
      	(
      		@pkcol, 
      		@intcol, 
      		@charcol
      	)
      go
      
      --UPDATE Stored Procedure
      
      create procedure sp_upd_two_way_test1	
      	@pkcol int, 
          	@intcol int, 
          	@charcol char(100), 
          	@timestampcol timestamp,
      	@rowidcol uniqueidentifier,
          	@old_pkcol int
      as
      	declare @x int
      	declare @y int
      	declare @z char(100)
       
      	select 
      		@x=pkcol, 
      		@y=intcol, 
      		@z=charcol 
      	from 
      		two_way_test1 
      	where 
      		pkcol = @pkcol
      
      
      
      	delete 
      		two_way_test1 
      	where 
      		pkcol=@pkcol
      
      
      
      	insert into two_way_test1 
      	(
      		pkcol, 
      		intcol, 
      		charcol
      	) 
      	values
      	(
      		case isnull(@pkcol,0) when 0 then @x else @pkcol end,
      		case isnull(@intcol,0) when 0 then @y else @intcol end,
      		case isnull(@charcol,'N') when 'N' then @z else @charcol end
      	)
      go
      
      --  DELETE Stored Procedure
      
      create procedure sp_del_two_way_test1 
      	@old_pkcol int
      as
      	delete 
      		two_way_test1 
      	where 
      		pkcol = @old_pkcol
      go
      
      

   2. Create the custom stored procedures in the test2 database:

      use test2
      go
      
      -- INSERT Stored Procedure
      
      create procedure sp_ins_two_way_test2	
      	@pkcol int, 
      	@intcol int, 
      	@charcol char(100), 
      	@timestampcol timestamp,
      	@rowidcol uniqueidentifier
      as
      	insert into two_way_test2 
      	(
      		pkcol,
      		intcol,
      		charcol
      	) 
      	values
      	(
      		@pkcol, 
      		@intcol, 
      		@charcol
      	)
      go
      
      --UPDATE Stored Procedure
      
      create procedure sp_upd_two_way_test2	
      	@pkcol int, 
          	@intcol int, 
          	@charcol char(100), 
          	@timestampcol timestamp,
      	@rowidcol uniqueidentifier,
          	@old_pkcol int
      as
      	declare @x int
      	declare @y int
      	declare @z char(100)
       
      	select 
      		@x=pkcol, 
      		@y=intcol, 
      		@z=charcol 
      	from 
      		two_way_test2 
      	where 
      		pkcol = @pkcol
      
      
      
      	delete 
      		two_way_test2 
      	where 
      		pkcol=@pkcol
      
      
      
      	insert into two_way_test2 
      	(
      		pkcol, 
      		intcol, 
      		charcol
      	) 
      	values
      	(
      		case isnull(@pkcol,0) when 0 then @x else @pkcol end,
      		case isnull(@intcol,0) when 0 then @y else @intcol end,
      		case isnull(@charcol,'N') when 'N' then @z else @charcol end
      	)
      go
      
      
      --  DELETE Stored Procedure
      
      create procedure sp_del_two_way_test2 
      	@old_pkcol int
      as
      	delete 
      		two_way_test2 
      	where 
      		pkcol = @old_pkcol
      go
      

6. Criar uma publicação transacional e adicionar artigos para publicação no test1 e os bancos de dados test2 :

   --In the database test1.
   
   use test1
   go
   
   --  Adding the transactional publication.
   exec sp_addpublication 
   	@publication = N'two_way_pub_test1', 
   	@restricted = N'false',
   	@sync_method = N'native', 
   	@repl_freq = N'continuous',
   	@description = N'Transactional publication of database test1.',
   	@status = N'active', 
   	@allow_push = N'true', 
   	@allow_pull = N'true',
   	@allow_anonymous = N'false', 
   	@enabled_for_internet = N'false',
   	@independent_agent = N'false', 
   	@immediate_sync = N'false',
   	@allow_sync_tran = N'true', 
   	@autogen_sync_procs = N'true',
   	@retention = 72
   go
   
   exec sp_addpublication_snapshot 
   	@publication = N'two_way_pub_test1',
   	@frequency_type = 4,
   	@frequency_interval = 1, 
   	@frequency_relative_interval = 0,
   	@frequency_recurrence_factor = 1, 
   	@frequency_subday = 1,
   	@frequency_subday_interval = 0, 
   	@active_start_date = 0,
   	@active_end_date = 0, 
   	@active_start_time_of_day = 233000,
   	@active_end_time_of_day = 0
   go
   
   --  Adding the transactional articles.
   
   exec sp_addarticle 
   	@publication = N'two_way_pub_test1', 
   	@article = N'two_way_test1',
   	@source_owner = N'dbo', 
   	@source_object = N'two_way_test1',
   	@destination_table = N'two_way_test1', 
   	@type = N'logbased',
   	@creation_script = null, 
   	@description = null, 
   	@pre_creation_cmd = N'drop',
           @schema_option = 0x00000000000000F1, 
   	@status = 16,
   	@vertical_partition = N'false', 
   	@ins_cmd = N'CALL sp_ins_two_way_test2',
   	@del_cmd = N'CALL sp_del_two_way_test2',
   	@upd_cmd = N'CALL sp_upd_two_way_test2', 
   	@filter = null,
   	@sync_object = null
   go
   
   --  In the database test2
   use test2
   go
   
   --  Adding the transactional publication.
   
   exec sp_addpublication 
   	@publication = N'two_way_pub_test2', 
   	@restricted = N'false',
   	@sync_method = N'native', 
   	@repl_freq = N'continuous',
   	@description = N'Transactional publication of database test2',
   	@status = N'active', 
   	@allow_push = N'true', 
   	@allow_pull = N'true',
   	@allow_anonymous = N'false', 
   	@enabled_for_internet = N'false',
   	@independent_agent = N'false', 
   	@immediate_sync = N'false',
   	@allow_sync_tran = N'true', 
   	@autogen_sync_procs = N'true',
   	@retention = 72
   go
   
   exec sp_addpublication_snapshot 
   	@publication = N'two_way_pub_test2',
   	@frequency_type = 4,
   	@frequency_interval = 1, 
   	@frequency_relative_interval = 0,
   	@frequency_recurrence_factor = 1, 
   	@frequency_subday = 1,
   	@frequency_subday_interval = 0, 
   	@active_start_date = 0,
   	@active_end_date = 0, 
   	@active_start_time_of_day = 233000,
   	@active_end_time_of_day = 0
   go
   
   --  Adding the transactional articles.
   exec sp_addarticle 
   	@publication = N'two_way_pub_test2', 
   	@article = N'two_way_test2',
   	@source_owner = N'dbo', 
   	@source_object = N'two_way_test2',
   	@destination_table = N'two_way_test2', 
   	@type = N'logbased',
   	@creation_script = null, 
   	@description = null, 
   	@pre_creation_cmd = N'drop',
   	@schema_option = 0x00000000000000F1, 
   	@status = 16,
   	@vertical_partition = N'false', 
   	@ins_cmd = N'CALL sp_ins_two_way_test1',
   	@del_cmd = N'CALL sp_del_two_way_test1',
   	@upd_cmd = N'CALL sp_upd_two_way_test1', 
   	@filter = null,
   	@sync_object = null
   go
   

7. Ativar como assinantes todos os servidores que participam da replicação:

   exec sp_addsubscriber 
   	@subscriber = '<Your Server Name>', 
   	@login = '<login name>', 
   	@password = '<password>'
   go
   
   

8. Identifica um dos bancos de dados como o assinante central. Crie inscrições transacionais em todos os bancos de dados que participam da replicação para que todos os bancos de dados se inscrever para o assinante central e o assinante central assina a todos os outros bancos de dados.
   
   Por exemplo, nesse cenário, o banco de dados test1 é assinante central. Crie inscrições transacionais no banco de dados test2 que inscrever-se a publicação em test1 e no banco de dados test1 que inscrever-se a publicação em test2 .
   
   Observação Crie todas as inscrições com a opção LOOPBACK_DETECTION habilitada.
   
   Para fazer isso, use o seguinte código:

   --Adding the transactional subscription in test1.
   
   use test1
   go
   exec sp_addsubscription 
   	@publication = N'two_way_pub_test1', 
   	@article = N'all', 
   	@subscriber = '<Your Server Name>', 
   	@destination_db = N'test2', 
   	@sync_type = N'none', 
   	@status = N'active', 
   	@update_mode = N'sync tran', 
   	@loopback_detection = 'true'
   go
   
   -- Adding the transactional subscription in test2.
   
   use test2
   go
   exec sp_addsubscription 
   	@publication = N'two_way_pub_test2', 
   	@article = N'all', 
   	@subscriber = '<Your Server Name>', 
   	@destination_db = N'test1', 
   	@sync_type = N'none', 
   	@status = N'active', 
   	@update_mode = N'sync tran', 
   	@loopback_detection = 'true'
   go
   

Observação Você também pode criar procedimentos armazenados personalizados para todas as publicações usando o procedimento armazenado do sistema de sp_scriptpublicationcustomprocs . Para obter mais informações sobre sp_scriptpublicationcustomprocs procedimento armazenado do sistema, consulte o tópico "sp_scriptpublicationcustomprocs" SQL Server 2000 atualizado Books Online.

Observação SQL Query Analyzer retorna somente 256 caracteres por coluna. Você pode alterar esta opção para o valor máximo permitido.

Para obter informações adicionais, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft: Para obter informações adicionais sobre como implementar bidirecional replicação transacional no SQL Server 7.0, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft: