Axentes de replicación push e pull a través dunha VPN entre sitios

A localización do axente, non a dos datos, é a decisión que dá forma a unha subscrición de SQL Server. A máquina que executa o axente abre a conexión, traballa baixo unha conta concreta e asume a culpa cando a sincronización se atasca. Nunha VPN entre sitios esa diferenza é o deseño, non un detalle. Debuxe as conexións do axente antes de debuxar a rede.

Tres roles, non dous

O Publisher posúe os datos do artigo, o Distributor posúe a base de datos de distribución e o Subscriber recibe os cambios. O Log Reader Agent execútase no Distributor para a replicación transaccional. O Distribution Agent é o que cambia de localización co tipo de subscrición, e por iso determina o deseño da rede. Aclare eses roles antes de falar de regras de VPN.

Unha subscrición push executa o Distribution Agent no Distributor, e unha subscrición pull execútao no Subscriber, como indica a documentación sobre subscricións de Microsoft. Todo o diálogo de rede depende de cal é esa máquina. Anote catro feitos por subscrición: o host do axente, a súa identidade de proceso, os inicios de sesión de base de datos que usa e os recursos que debe alcanzar. Eses feitos, non unha frecha do diagrama, dinlle que dirección debe funcionar.

Push significa que o axente vive no Distributor

Cunha subscrición push, o Distributor abre a conexión cara ao Subscriber a través da VPN. O escoitador, a devasa e o inicio de sesión SQL do lado do subscritor deben aceptar conexións que cheguen do lado remoto. A conta de servizo do Distributor tamén necesita permiso na base de datos do subscritor. Planifique esa ruta de entrada antes de crear a subscrición, porque descubrila despois adoita significar recreala.

A entrega de instantáneas engade unha ruta que a replicación estable nunca usa. Se a instantánea está situada nun recurso compartido de ficheiros, o Distribution Agent le dese recurso e a conta do subscritor debe alcanzar a mesma ruta UNC. Un fluxo de cambios que dura semanas non di nada sobre se funcionará unha reinicialización. Por iso o recurso compartido da instantánea pertence ao plan desde o principio.

Non lea push como tráfico dunha soa dirección. O axente necesita respostas, confirmacións e os seus propios intercambios de autenticación. A ruta debe ser bidireccional a nivel de conexión mesmo cando os datos viaxan nunha soa dirección.

Pull significa que o axente vive no Subscriber

Unha subscrición pull inverte a conexión: o Subscriber executa o Distribution Agent e diríxese ao Distributor. Ese arranxo encaixa cunha política de VPN que permite conexións saíntes desde a sucursal e bloquea as entrantes. Tamén pon a decisión de programación nas mans de quen atende o servidor da sucursal. Escóllaa cando o equipo da sucursal deba posuír a súa propia sincronización e notar os seus propios fallos.

A conta de servizo de SQL Server Agent do subscritor necesita acceso de lectura á base de datos de distribución e ao recurso compartido da instantánea. Esa conta é a identidade que aparece nos erros de replicación, e unha conta de servizo local sen dereitos de dominio falla nun punto que parece un fallo de rede pero en realidade é un fallo de credenciais. Revise a conta antes de depurar o túnel. Arranxar o inicio de sesión adoita ser máis rápido que demostrar a inocencia da rede.

A propiedade segue o axente. Escolla push cando o equipo central deba posuír tanto a programación como os fallos. Escolla o que escolla, anóteo xunto á subscrición para que o seguinte enxeñeiro saiba onde mirar primeiro.

A republicación cambia o abano, non a propiedade

Un subscritor pódese configurar para republicar a máis subscritores, o que permite que unha base de datos de sucursal sirva a varios consumidores locais sen que cada un tira a través da WAN. A base de datos intermedia agora contén unha publicación e os seus propios axentes. Tamén herda permisos, supervisión e un plan de recuperación que antes non tiña. Ese rol adicional é o prezo de eliminar a entrega repetida por WAN.

A orde documentada importa: inicialice a subscrición entrante antes de crear a publicación descendente. Tráteo como un paso do ciclo de vida con verificación, non como papeleo que se salta. Invertelo produce unha cadea que parece configurada e non entrega nada.

Declare o modelo de escritura explicitamente. Replicar un conxunto de datos de só lectura a un consumidor local é un deseño distinto de aceptar escrituras en varios sitios, e unha cadea de frechas non crea resolución de conflitos. Se a sucursal debe escribir, é unha decisión aparte coa súa propia topoloxía. Faga tamén visible a dependencia: cando o republicador está caído, cada consumidor por debaixo queda desactualizado.

Demostre a localización de extremo a extremo

Lea o tipo de subscrición da base de datos de distribución en lugar de confiar na memoria, e despois comprobe que os cambios chegan de verdade:

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';

Un subscription_type de 0 é push e 1 é pull, e non se pode cambiar no lugar, así que unha discrepancia significa recrear a subscrición en vez de editarla. A chamada de comandos pendentes dinlle se o axente escollido move traballo ou só se executa. Unha subscrición que informa cero comandos pendentes mentres a táboa do subscritor queda baleira é un fallo distinto dunha que informa unha cola crecente, e as dúas levan a propietarios distintos.

Remate cun cambio real: insira ou actualice unha fila no Publisher, espere a que o axente informe e lea esa fila no Subscriber. Fágao unha vez máis durante unha breve interrupción da VPN para ver como se recupera o axente. Unha subscrición que sobrevive a esa proba ten unha localización que pode documentar e defender.