La ubicació de l’agent, no la de les dades, és la decisió que dona forma a una subscripció de SQL Server. La màquina que executa l’agent obre la connexió, treballa amb un compte concret i assumeix la culpa quan la sincronització s’atura. En una VPN entre llocs aquesta diferència és el disseny, no un detall. Dibuixeu les connexions de l’agent abans de dibuixar la xarxa.

Tres rols, no dos

El Publisher posseeix les dades de l’article, el Distributor posseeix la base de dades de distribució i el Subscriber rep els canvis. El Log Reader Agent s’executa al Distributor per a la replicació transaccional. El Distribution Agent és el que canvia d’ubicació segons el tipus de subscripció, i per això determina el disseny de la xarxa. Aclariu aquests rols abans de parlar de regles de VPN.

Una subscripció push executa el Distribution Agent al Distributor, i una subscripció pull l’executa al Subscriber, tal com indica la documentació de subscripcions de Microsoft. Tot el diàleg de xarxa depèn de quina és aquesta màquina. Anoteu quatre fets per a cada subscripció: l’amfitrió de l’agent, la seva identitat de procés, els inicis de sessió de base de dades que utilitza i els recursos que ha d’assolir. Aquests fets, no una fletxa del diagrama, us diuen quina direcció ha de funcionar.

Push vol dir que l’agent viu al Distributor

Amb una subscripció push, el Distributor obre la connexió cap al Subscriber a través de la VPN. L’oient, el firewall i l’inici de sessió SQL del costat del subscriptor han d’acceptar connexions que arriben del costat remot. El compte de servei del Distributor també necessita permís a la base de dades del subscriptor. Planifiqueu aquest camí d’entrada abans de crear la subscripció, perquè descobrir-lo després normalment vol dir tornar-la a crear.

El lliurament d’instantànies afegeix un camí que la replicació estable mai no recorre. Si la instantània es col·loca en un recurs compartit de fitxers, el Distribution Agent llegeix d’aquest recurs i el compte del subscriptor ha d’arribar al mateix camí UNC. Un flux de canvis que dura setmanes no diu res sobre si funcionarà una reinicialització. Per això el recurs compartit de la instantània forma part del pla des del principi.

No llegiu push com a trànsit d’una sola direcció. L’agent necessita respostes, confirmacions i els seus propis intercanvis d’autenticació. El camí ha de ser bidireccional a nivell de connexió fins i tot quan les dades viatgen en una sola direcció.

Pull vol dir que l’agent viu al Subscriber

Una subscripció pull inverteix la connexió: el Subscriber executa el Distribution Agent i s’adreça al Distributor. Aquest arranjament encaixa amb una política de VPN que permet connexions sortints des de la sucursal i bloqueja les entrants. També posa la decisió de planificació en mans de qui s’ocupa del servidor de la sucursal. Trieu-la quan l’equip de la sucursal ha de posseir la seva pròpia sincronització i adonar-se dels seus propis errors.

El compte de servei de SQL Server Agent del subscriptor necessita accés de lectura a la base de dades de distribució i al recurs compartit de la instantània. Aquest compte és la identitat que apareix als errors de replicació, i un compte de servei local sense drets de domini falla en un punt que sembla una fallada de xarxa però en realitat és una fallada de credencials. Reviseu el compte abans de depurar el túnel. Arreglar l’inici de sessió sol ser més ràpid que demostrar la innocència de la xarxa.

La propietat segueix l’agent. Trieu push quan l’equip central ha de posseir tant la planificació com les fallades. Triï el que triï, anoteu-ho al costat de la subscripció perquè el següent enginyer sàpiga on mirar primer.

La republicació canvia el ventall, no la propietat

Un subscriptor es pot configurar per republicar a altres subscriptors, cosa que permet que una base de dades de sucursal serveixi diversos consumidors locals sense que cadascun estiri a través de la WAN. La base de dades intermèdia ara conté una publicació i els seus propis agents. També hereta permisos, monitoratge i un pla de recuperació que abans no tenia. Aquest rol addicional és el preu d’eliminar el lliurament repetit per WAN.

L’ordre documentat importa: inicialitzeu la subscripció entrant abans de crear la publicació descendent. Tracteu-ho com un pas del cicle de vida amb verificació, no com a paperassa per saltar. Invertir-lo produeix una cadena que sembla configurada i no lliura res.

Declareu el model d’escriptura explícitament. Replicar un conjunt de dades només de lectura a un consumidor local és un disseny diferent d’acceptar escriptures en diversos llocs, i una cadena de fletxes no crea resolució de conflictes. Si la sucursal ha d’escriure, és una decisió separada amb la seva pròpia topologia. Feu també visible la dependència: quan el republicador està caigut, cada consumidor per sota seu queda desactualitzat.

Demostreu la ubicació d’extrem a extrem

Llegiu el tipus de subscripció de la base de dades de distribució en lloc de confiar en la memòria, i després comproveu que els canvis arriben realment:

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 és push i 1 és pull, i no es pot canviar in situ, així que una discrepància vol dir tornar a crear la subscripció en lloc d’editar-la. La crida de comandes pendents us diu si l’agent triat mou feina o simplement s’executa. Una subscripció que informa de zero comandes pendents mentre la taula del subscriptor queda buida és una fallada diferent d’una que informa d’una cua creixent, i les dues porten a propietaris diferents.

Acabeu amb un canvi real: inseriu o actualitzeu una fila al Publisher, espereu que l’agent informi i llegiu aquesta fila al Subscriber. Feu-ho una vegada més durant una breu interrupció de la VPN per veure com es recupera l’agent. Una subscripció que supera aquesta prova té una ubicació que podeu documentar i defensar.

Articles relacionats