Agentes de replicação push e pull através de uma VPN entre sites

A localização do agente, não a dos dados, é a decisão que molda uma subscrição de SQL Server. A máquina que executa o agente abre a ligação, trabalha com uma conta específica e assume a culpa quando a sincronização pára. Numa VPN entre sites essa diferença é o desenho, não um detalhe. Desenhe as ligações do agente antes de desenhar a rede.

Três papéis, não dois

O Publisher é dono dos dados do artigo, o Distributor é dono da base de dados de distribuição e o Subscriber recebe alterações. O Log Reader Agent é executado no Distributor para a replicação transaccional. O Distribution Agent é aquele cuja localização muda com o tipo de subscrição, e é por isso que determina o desenho da rede. Esclareça esses papéis antes de falar de regras de VPN.

Uma subscrição push executa o Distribution Agent no Distributor, e uma subscrição pull executa-o no Subscriber, como indica a documentação sobre subscrições da Microsoft. Tudo no diálogo de rede depende de qual é essa máquina. Anote quatro factos por subscrição: o anfitrião do agente, a sua identidade de processo, os inícios de sessão de base de dados que utiliza e os recursos que tem de alcançar. Esses factos, não uma seta do diagrama, dizem-lhe que direcção tem de funcionar.

Push significa que o agente vive no Distributor

Com uma subscrição push, o Distributor abre a ligação ao Subscriber através da VPN. O ouvinte, a firewall e o início de sessão SQL do lado do subscritor têm de aceitar ligações vindas do lado remoto. A conta de serviço do Distributor também precisa de permissão na base de dados do subscritor. Planeie esse caminho de entrada antes de criar a subscrição, porque descobri-lo depois costuma significar recriá-la.

A entrega de instantâneos acrescenta um caminho que a replicação estável nunca usa. Se o instantâneo estiver colocado numa partilha de ficheiros, o Distribution Agent lê dessa partilha e a conta do subscritor tem de alcançar o mesmo caminho UNC. Um fluxo de alterações que dura semanas não diz nada sobre se uma reinicialização funcionará. Por isso a partilha do instantâneo pertence ao plano desde o início.

Não leia push como tráfego de sentido único. O agente precisa de respostas, confirmações e das suas próprias trocas de autenticação. O caminho tem de ser bidireccional ao nível da ligação mesmo quando os dados viajam num só sentido.

Pull significa que o agente vive no Subscriber

Uma subscrição pull inverte a ligação: o Subscriber executa o Distribution Agent e dirige-se ao Distributor. Essa disposição adequa-se a uma política de VPN que permite ligações de saída a partir da filial e bloqueia as de entrada. Também coloca a decisão de agendamento nas mãos de quem trata do servidor da filial. Escolha-a quando a equipa da filial deve possuir a sua própria sincronização e notar as suas próprias falhas.

A conta de serviço do SQL Server Agent do subscritor precisa de acesso de leitura à base de dados de distribuição e à partilha do instantâneo. Essa conta é a identidade que aparece nos erros de replicação, e uma conta de serviço local sem direitos de domínio falha num ponto que parece uma falha de rede mas na realidade é uma falha de credenciais. Verifique a conta antes de depurar o túnel. Corrigir o início de sessão é normalmente mais rápido do que provar a inocência da rede.

A propriedade segue o agente. Escolha push quando a equipa central deve possuir tanto o agendamento como as falhas. Escolha o que escolher, escreva-o junto à subscrição para que o próximo engenheiro saiba onde olhar primeiro.

A republicação muda o leque, não a propriedade

Um subscritor pode ser configurado para republicar para outros subscritores, permitindo que uma base de dados de filial sirva vários consumidores locais sem que cada um puxe através da WAN. A base de dados intermédia contém agora uma publicação e os seus próprios agentes. Também herda permissões, monitorização e um plano de recuperação que antes não tinha. Esse papel adicional é o preço de eliminar a entrega WAN repetida.

A ordem documentada importa: inicialize a subscrição de entrada antes de criar a publicação a jusante. Trate isso como um passo do ciclo de vida com verificação, não como papelada que se salta. Invertê-la produz uma cadeia que parece configurada e não entrega nada.

Declare o modelo de escrita explicitamente. Replicar um conjunto de dados só de leitura para um consumidor local é um desenho diferente de aceitar escritas em vários locais, e uma cadeia de setas não cria resolução de conflitos. Se a filial tiver de escrever, é uma decisão separada com a sua própria topologia. Torne também a dependência visível: quando o republicador está em baixo, cada consumidor abaixo dele fica desactualizado.

Prove a colocação de ponta a ponta

Leia o tipo de subscrição da base de dados de distribuição em vez de confiar na memória, e depois verifique se as alterações chegam de facto:

USE distribution;
SELECT publication, subscriber_db, subscription_type
FROM dbo.MSsubscriptions;
EXEC sp_replmonitorsubscriptionpendingcmds
  @publisher = 'PUB1', @publisher_db = 'Sales',
  @publication = 'SalesPub', @subscriber = 'BR1',
  @subscriber_db = 'Sales';

Um subscription_type de 0 é push e 1 é pull, e não pode ser alterado no local, portanto uma divergência significa recriar a subscrição em vez de editá-la. A chamada de comandos pendentes diz-lhe se o agente escolhido está a mover trabalho ou apenas a executar. Uma subscrição que reporta zero comandos pendentes enquanto a tabela do subscritor fica vazia é uma falha diferente de uma que reporta um atraso crescente, e as duas levam a donos diferentes.

Termine com uma alteração real: insira ou actualize uma linha no Publisher, espere pelo relatório do agente e leia essa linha no Subscriber. Faça-o mais uma vez durante uma breve interrupção da VPN para ver como o agente recupera. Uma subscrição que sobrevive a esse teste tem uma colocação que pode documentar e defender.