Agenti di replica push e pull su una VPN tra sedi

La posizione dell’agente, non quella dei dati, è la decisione che dà forma a una sottoscrizione SQL Server. La macchina che esegue l’agente apre la connessione, lavora con un account specifico e si assume la colpa quando la sincronizzazione si blocca. Su una VPN tra sedi quella differenza è il progetto, non un dettaglio. Disegnate le connessioni dell’agente prima di disegnare la rete.

Tre ruoli, non due

Il Publisher possiede i dati dell’articolo, il Distributor possiede il database di distribuzione e il Subscriber riceve le modifiche. Il Log Reader Agent viene eseguito sul Distributor per la replica transazionale. Il Distribution Agent è quello la cui posizione cambia con il tipo di sottoscrizione, ed è per questo che guida il progetto della rete. Chiarite questi ruoli prima di parlare di regole VPN.

Una sottoscrizione push esegue il Distribution Agent sul Distributor, e una sottoscrizione pull lo esegue sul Subscriber, come indica la documentazione sulle sottoscrizioni di Microsoft. Tutto il dialogo di rete dipende da quale macchina sia questa. Annotate quattro fatti per ogni sottoscrizione: l’host dell’agente, la sua identità di processo, gli accessi al database che usa e le risorse che deve raggiungere. Questi fatti, non una freccia del diagramma, vi dicono quale direzione deve funzionare.

Push significa che l’agente vive sul Distributor

Con una sottoscrizione push, il Distributor apre la connessione verso il Subscriber attraverso la VPN. Il listener, il firewall e l’accesso SQL lato sottoscrittore devono accettare connessioni che arrivano dal lato remoto. Anche l’account di servizio del Distributor ha bisogno di un’autorizzazione sul database del sottoscrittore. Pianificate quel percorso in ingresso prima di creare la sottoscrizione, perché scoprirlo dopo di solito significa ricrearla.

La consegna dello snapshot aggiunge un percorso che la replica a regime non usa mai. Se lo snapshot è collocato su una condivisione file, il Distribution Agent legge da quella condivisione e l’account del sottoscrittore deve raggiungere lo stesso percorso UNC. Un flusso di modifiche che dura settimane non dice nulla sulla riuscita di una reinizializzazione. Per questo la condivisione dello snapshot appartiene al piano fin dall’inizio.

Non leggete push come traffico a senso unico. L’agente ha bisogno di risposte, conferme e dei propri scambi di autenticazione. Il percorso deve essere bidirezionale a livello di connessione anche quando i dati viaggiano in una sola direzione.

Pull significa che l’agente vive sul Subscriber

Una sottoscrizione pull inverte la connessione: il Subscriber esegue il Distribution Agent e si rivolge al Distributor. Questa disposizione si adatta a una politica VPN che consente connessioni in uscita dalla filiale e blocca quelle in entrata. Mette anche la decisione sulla pianificazione nelle mani di chi si occupa del server della filiale. Sceglietela quando il team della filiale deve possedere la propria sincronizzazione e notare i propri errori.

L’account di servizio di SQL Server Agent del sottoscrittore ha bisogno di accesso in lettura al database di distribuzione e alla condivisione dello snapshot. Quell’account è l’identità che compare negli errori di replica, e un account di servizio locale senza diritti di dominio fallisce in un punto che sembra un guasto di rete ma in realtà è un guasto di credenziali. Controllate l’account prima di fare debug del tunnel. Correggere l’accesso è di solito più veloce che dimostrare l’innocenza della rete.

La proprietà segue l’agente. Scegliete push quando il team centrale deve possedere sia la pianificazione sia i guasti. Qualunque cosa scegliate, scrivetela accanto alla sottoscrizione così il prossimo ingegnere sa dove guardare per primo.

La ripubblicazione cambia la diffusione, non la proprietà

Un sottoscrittore può essere configurato per ripubblicare verso altri sottoscrittori, permettendo a un database di filiale di servire diversi consumatori locali senza che ciascuno tiri attraverso la WAN. Il database intermedio ora contiene una pubblicazione e i propri agenti. Eredita anche autorizzazioni, monitoraggio e un piano di ripristino che prima non aveva. Quel ruolo aggiuntivo è il prezzo per eliminare la consegna WAN ripetuta.

L’ordine documentato conta: inizializzate la sottoscrizione in entrata prima di creare la pubblicazione a valle. Trattatelo come un passo del ciclo di vita con verifica, non come scartoffie da saltare. Invertirlo produce una catena che sembra configurata e non consegna nulla.

Dichiarate esplicitamente il modello di scrittura. Replicare un set di dati di sola lettura verso un consumatore locale è un progetto diverso dall’accettare scritture su più sedi, e una catena di frecce non crea la risoluzione dei conflitti. Se la filiale deve scrivere, è una decisione separata con la propria topologia. Rendete visibile anche la dipendenza: quando il ripubblicatore è fermo, ogni consumatore sotto di esso è obsoleto.

Dimostrate il posizionamento da un capo all’altro

Leggete il tipo di sottoscrizione dal database di distribuzione invece di fidarvi della memoria, poi verificate che le modifiche arrivino davvero:

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 di 0 è push e 1 è pull, e non può essere cambiato sul posto, quindi una discrepanza significa ricreare la sottoscrizione invece di modificarla. La chiamata dei comandi in sospeso vi dice se l’agente scelto sta spostando lavoro o sta solo girando. Una sottoscrizione che riporta zero comandi in sospeso mentre la tabella del sottoscrittore resta vuota è un guasto diverso da una che riporta un arretrato crescente, e le due portano a proprietari diversi.

Concludete con una modifica reale: inserite o aggiornate una riga sul Publisher, aspettate il rapporto dell’agente e leggete quella riga sul Subscriber. Fatelo ancora una volta durante una breve interruzione della VPN per vedere come l’agente si riprende. Una sottoscrizione che supera quella prova ha un posizionamento che potete documentare e difendere.