Agenți de replicare push și pull printr-o VPN între site-uri

Locația agentului, nu locația datelor, este decizia care modelează o abonare SQL Server. Mașina care rulează agentul deschide conexiunea, lucrează sub un cont anume și își asumă vina când sincronizarea se blochează. Într-o VPN între site-uri acea diferență este proiectarea, nu un detaliu. Desenați conexiunile agentului înainte de a desena rețeaua.

Trei roluri, nu două

Publisher deține datele articolului, Distributor deține baza de date de distribuție, iar Subscriber primește modificările. Log Reader Agent rulează la Distributor pentru replicarea tranzacțională. Distribution Agent este cel a cărui locație se schimbă cu tipul de abonare, și de aceea el determină proiectarea rețelei. Lămuriți aceste roluri înainte de a vorbi despre regulile VPN.

O abonare push rulează Distribution Agent la Distributor, iar o abonare pull îl rulează la Subscriber, după cum arată documentația despre abonări a Microsoft. Totul în dialogul de rețea decurge din care mașină este aceea. Notați patru fapte pentru fiecare abonare: gazda agentului, identitatea procesului său, autentificările la baza de date pe care le folosește și resursele pe care trebuie să le atingă. Aceste fapte, nu o săgeată din diagramă, vă spun care direcție trebuie să funcționeze.

Push înseamnă că agentul trăiește la Distributor

Cu o abonare push, Distributor deschide conexiunea către Subscriber prin VPN. Ascultătorul, firewallul și autentificarea SQL din partea abonatului trebuie să accepte conexiuni care vin din partea îndepărtată. Contul de serviciu al Distributor are nevoie și el de permisiune pe baza de date a abonatului. Planificați acea cale de intrare înainte de a crea abonarea, pentru că descoperirea ei mai târziu înseamnă de obicei recrearea.

Livrarea instantaneului adaugă o cale pe care replicarea stabilă nu o folosește niciodată. Dacă instantaneul este plasat pe o partajare de fișiere, Distribution Agent citește din acea partajare, iar contul abonatului trebuie să atingă aceeași cale UNC. Un flux de modificări care durează săptămâni nu spune nimic despre dacă o reinițializare va funcționa. De aceea partajarea instantaneului face parte din plan de la început.

Nu citiți push ca trafic unidirecțional. Agentul are nevoie de răspunsuri, confirmări și propriile schimburi de autentificare. Calea trebuie să fie bidirecțională la nivel de conexiune chiar și când datele se mișcă într-o singură direcție.

Pull înseamnă că agentul trăiește la Subscriber

O abonare pull inversează conexiunea: Subscriber rulează Distribution Agent și se adresează Distributor. Această aranjare se potrivește unei politici VPN care permite conexiuni de ieșire din sucursală și blochează cele de intrare. Pune și decizia de programare în mâinile celui care se ocupă de serverul sucursalei. Alegeți-o când echipa sucursalei trebuie să dețină propria sincronizare și să observe propriile eșecuri.

Contul de serviciu SQL Server Agent al abonatului are nevoie de acces de citire la baza de date de distribuție și la partajarea instantaneului. Acel cont este identitatea care apare în erorile de replicare, iar un cont de serviciu local fără drepturi de domeniu eșuează într-un punct care pare o defecțiune de rețea, dar în realitate este o defecțiune de acreditări. Verificați contul înainte de a depana tunelul. Repararea autentificării este de obicei mai rapidă decât demonstrarea nevinovăției rețelei.

Proprietatea urmează agentul. Alegeți push când echipa centrală trebuie să dețină atât programul, cât și eșecurile. Orice ați alege, scrieți-l lângă abonare ca următorul inginer să știe unde să se uite mai întâi.

Republicarea schimbă dispersia, nu proprietatea

Un abonat poate fi configurat să republice către alți abonați, permițând unei baze de date de sucursală să deservească mai mulți consumatori locali fără ca fiecare să tragă prin WAN. Baza de date intermediară ține acum o publicare și propriii agenți. Moștenește și permisiuni, monitorizare și un plan de recuperare pe care nu le avea înainte. Acel rol suplimentar este prețul eliminării livrării repetate prin WAN.

Ordinea documentată contează: inițializați abonarea de intrare înainte de a crea publicarea din aval. Tratați asta ca pe un pas din ciclul de viață cu verificare, nu ca pe hârtii de sărit. Inversarea produce un lanț care pare configurat și nu livrează nimic.

Declarați explicit modelul de scriere. Replicarea unui set de date doar pentru citire către un consumator local este o proiectare diferită de acceptarea scrierilor în mai multe site-uri, iar un lanț de săgeți nu creează rezolvarea conflictelor. Dacă sucursala trebuie să scrie, aceea este o decizie separată cu propria topologie. Faceți vizibilă și dependența: când republicatorul este oprit, fiecare consumator de sub el este învechit.

Dovediți plasarea de la un capăt la altul

Citiți tipul abonării din baza de date de distribuție în loc să vă bazați pe memorie, apoi verificați dacă modificările chiar ajung:

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 este push și 1 este pull, și nu poate fi schimbat la fața locului, deci o nepotrivire înseamnă recrearea abonării, nu editarea ei. Apelul comenzilor în așteptare vă spune dacă agentul ales mută muncă sau doar rulează. O abonare care raportează zero comenzi în așteptare în timp ce tabelul abonatului rămâne gol este o defecțiune diferită de una care raportează o restanță tot mai mare, iar cele două duc la proprietari diferiți.

Încheiați cu o modificare reală: inserați sau actualizați un rând la Publisher, așteptați raportul agentului și citiți acel rând la Subscriber. Faceți asta încă o dată printr-o întrerupere scurtă a VPN pentru a vedea cum își revine agentul. O abonare care trece acel test are o plasare pe care o puteți documenta și apăra.