Agenti replikacije push in pull čez VPN med lokacijami

Lokacija agenta, ne lokacija podatkov, je odločitev, ki oblikuje naročnino na SQL Server. Računalnik, ki poganja agenta, odpre povezavo, deluje pod določenim računom in prevzame krivdo, ko se sinhronizacija ustavi. Na VPN med lokacijami je ta razlika zasnova, ne podrobnost. Narišite povezave agenta, preden narišete omrežje.

Tri vloge, ne dve

Publisher ima v lasti podatke članka, Distributor ima v lasti distribucijsko bazo, Subscriber pa prejema spremembe. Log Reader Agent teče na Distributorju za transakcijsko replikacijo. Distribution Agent je tisti, katerega lokacija se spreminja z vrsto naročnine, in zato določa zasnovo omrežja. Razčistite te vloge, preden govorite o pravilih VPN.

Naročnina push poganja Distribution Agent na Distributorju, naročnina pull pa ga poganja na Subscriberju, kot navaja dokumentacija o naročninah Microsofta. Vse v omrežnem pogovoru izhaja iz tega, kateri računalnik je to. Zapišite štiri dejstva za vsako naročnino: gostitelja agenta, identiteto njegovega procesa, prijave v bazo, ki jih uporablja, in vire, do katerih mora priti. Ta dejstva, ne puščica v diagramu, vam povedo, katera smer mora delovati.

push pomeni, da agent živi na Distributorju

Pri naročnini push Distributor odpre povezavo do Subscriberja čez VPN. Poslušalec, požarni zid in prijava SQL na strani naročnika morajo sprejemati povezave, ki prihajajo z oddaljene strani. Tudi servisni račun Distributorja potrebuje dovoljenje v bazi naročnika. Načrtujte to dohodno pot, preden ustvarite naročnino, ker odkritje pozneje običajno pomeni ponovno ustvarjanje.

Dostava posnetka doda pot, ki je ustaljena replikacija nikoli ne uporabi. Če je posnetek shranjen v datotečni delitvi, Distribution Agent bere iz te delitve in račun naročnika mora doseči isto pot UNC. Tok sprememb, ki teče tedne, ne pove ničesar o tem, ali bo ponovna inicializacija delovala. Zato delitev s posnetkom sodi v načrt od začetka.

push ne berite kot enosmerni promet. Agent potrebuje odgovore, potrditve in svoje lastne izmenjave preverjanja pristnosti. Pot mora biti dvosmerna na ravni povezave, tudi ko se podatki premikajo v eno smer.

pull pomeni, da agent živi na Subscriberju

Naročnina pull obrne povezavo: Subscriber poganja Distribution Agent in se obrne na Distributorja. Ta ureditev ustreza politiki VPN, ki dovoljuje odhodne povezave iz podružnice in blokira dohodne. Odločitev o urniku tudi položi v roke tistega, ki skrbi za strežnik podružnice. Izberite jo, ko mora ekipa podružnice imeti v lasti svojo sinhronizacijo in opaziti svoje lastne napake.

Servisni račun SQL Server Agent naročnika potrebuje bralni dostop do distribucijske baze in do delitve s posnetkom. Ta račun je identiteta, ki se pojavi v napakah replikacije, lokalni servisni račun brez pravic domene pa odpove na točki, ki je videti kot omrežna okvara, v resnici pa je okvara poverilnic. Preverite račun, preden odpravljate napake v tunelu. Popravljanje prijave je običajno hitrejše od dokazovanja nedolžnosti omrežja.

Lastništvo sledi agentu. Izberite push, ko mora osrednja ekipa imeti v lasti tako urnik kot napake. Kar koli izberete, zapišite to ob naročnini, da bo naslednji inženir vedel, kam pogledati najprej.

Ponovno objavljanje spremeni razvejanje, ne lastništva

Naročnika je mogoče konfigurirati za ponovno objavljanje nadaljnjim naročnikom, kar eni bazi podružnice omogoča, da služi več lokalnim porabnikom, ne da bi vsak vlekel čez WAN. Vmesna baza zdaj hrani objavo in svoje agente. Podeduje tudi dovoljenja, spremljanje in načrt obnovitve, ki jih prej ni imela. Ta dodatna vloga je cena za odstranitev ponavljajoče se dostave čez WAN.

Dokumentirani vrstni red je pomemben: inicializirajte dohodno naročnino, preden ustvarite objavo navzdol. Obravnavajte to kot korak življenjskega cikla s preverjanjem, ne kot papirje, ki jih preskočite. Obrnjen vrstni red ustvari verigo, ki je videti konfigurirana in ne dostavi ničesar.

Izrecno navedite model pisanja. Repliciranje nabora podatkov samo za branje lokalnemu porabniku je drugačna zasnova kot sprejemanje zapisov na več lokacijah, in veriga puščic ne ustvari reševanja konfliktov. Če mora podružnica pisati, je to ločena odločitev z lastno topologijo. Naredite vidno tudi odvisnost: ko ponovni objavljavec ne deluje, je vsak porabnik pod njim zastarel.

Dokažite postavitev od začetka do konca

Preberite vrsto naročnine iz distribucijske baze, namesto da zaupate spominu, nato preverite, ali spremembe resnično pridejo:

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

subscription_type z vrednostjo 0 pomeni push, 1 pa pull, in ga ni mogoče spremeniti na mestu, zato neujemanje pomeni ponovno ustvarjanje naročnine in ne njeno urejanje. Klic čakajočih ukazov vam pove, ali izbrani agent premika delo ali samo teče. Naročnina, ki poroča nič čakajočih ukazov, medtem ko tabela naročnika ostane prazna, je drugačna napaka od tiste, ki poroča naraščajoč zaostanek, in obe vodita do različnih lastnikov.

Končajte s pravno spremembo: vstavite ali posodobite eno vrstico pri Publisherju, počakajte na poročilo agenta in preberite to vrstico pri Subscriberju. Naredite to še enkrat med kratko prekinitvijo VPN, da vidite, kako si agent opomore. Naročnina, ki prestane ta preizkus, ima postavitev, ki jo lahko dokumentirate in branite.