Push ir pull replikacijos agentai per VPN tarp svetainių

Agento vieta, o ne duomenų vieta, yra sprendimas, kuris formuoja SQL Server prenumeratą. Mašina, kuri vykdo agentą, atidaro jungtį, dirba pagal konkrečią paskyrą ir prisiima kaltę, kai sinchronizacija sustoja. VPN tarp svetainių atveju tas skirtumas yra projektas, o ne smulkmena. Nubrėžkite agento jungtis prieš braižydami tinklą.

Trys vaidmenys, o ne du

Publisher valdo straipsnio duomenis, Distributor valdo paskirstymo duomenų bazę, o Subscriber gauna pakeitimus. Log Reader Agent veikia Distributor pusėje transakcinės replikacijos atveju. Distribution Agent yra tas, kurio vieta keičiasi priklausomai nuo prenumeratos tipo, todėl jis lemia tinklo projektą. Išsiaiškinkite šiuos vaidmenis prieš kalbėdami apie VPN taisykles.

push prenumerata vykdo Distribution Agent Distributor pusėje, o pull prenumerata jį vykdo Subscriber pusėje, kaip nurodo Microsoft prenumeratų dokumentacija teigia. Viskas tinklo pokalbyje kyla iš to, kuri tai mašina. Užrašykite keturis faktus kiekvienai prenumeratai: agento kompiuterį, jo proceso tapatybę, naudojamus duomenų bazės prisijungimus ir išteklius, kuriuos jis turi pasiekti. Šie faktai, o ne diagramos rodyklė, pasako, kuri kryptis turi veikti.

push reiškia, kad agentas gyvena Distributor pusėje

push prenumeratos atveju Distributor atidaro jungtį į Subscriber per VPN. Prenumeruotojo pusės klausytojas, ugniasienė ir SQL prisijungimas turi priimti jungtis, ateinančias iš tolimosios pusės. Distributor paslaugos paskyrai taip pat reikia leidimo prenumeruotojo duomenų bazėje. Suplanuokite šį įeinantį kelią prieš kurdami prenumeratą, nes jo atradimas vėliau paprastai reiškia jos kūrimą iš naujo.

Momentinės kopijos pristatymas prideda kelią, kurio pastovioji replikacija niekada nenaudoja. Jei momentinė kopija patalpinta failų bendrinime, Distribution Agent skaito iš to bendrinimo, o prenumeruotojo paskyra turi pasiekti tą patį UNC kelią. Savaites trunkantis pakeitimų srautas nieko nesako apie tai, ar veiks pakartotinė inicializacija. Todėl momentinės kopijos bendrinimas priklauso planui nuo pat pradžių.

Neskaitykite push kaip vienkryptės eismo. Agentui reikia atsakymų, patvirtinimų ir savo autentifikacijos mainų. Kelias turi būti dvipusis jungties lygiu, net kai duomenys juda viena kryptimi.

pull reiškia, kad agentas gyvena Subscriber pusėje

pull prenumerata apverčia jungtį: Subscriber vykdo Distribution Agent ir kreipiasi į Distributor. Ši sąranka tinka VPN politikai, kuri leidžia išeinančias jungtis iš filialo ir blokuoja įeinančias. Ji taip pat atiduoda tvarkaraščio sprendimą tam, kas prižiūri filialo serverį. Rinkitės ją, kai filialo komanda turi valdyti savo sinchronizaciją ir pastebėti savo gedimus.

Prenumeruotojo SQL Server Agent paslaugos paskyrai reikia skaitymo prieigos prie paskirstymo duomenų bazės ir prie momentinės kopijos bendrinimo. Ta paskyra yra tapatybė, kuri pasirodo replikacijos klaidose, o vietinė paslaugos paskyra be domeno teisių žlunga toje vietoje, kuri atrodo kaip tinklo gedimas, bet iš tikrųjų yra prisijungimo duomenų gedimas. Patikrinkite paskyrą prieš derindami tunelį. Prisijungimo sutvarkymas paprastai greitesnis nei tinklo nekaltybės įrodymas.

Nuosavybė seka agentą. Rinkitės push, kai centrinė komanda turi valdyti ir tvarkaraštį, ir gedimus. Kad ir ką pasirinktumėte, užrašykite tai prie prenumeratos, kad kitas inžinierius žinotų, kur pirmiausia žiūrėti.

Pakartotinis publikavimas keičia šakojimąsi, o ne nuosavybę

Prenumeruotoją galima sukonfigūruoti pakartotinai publikuoti tolesniems prenumeruotojams, taip viena filialo duomenų bazė gali aptarnauti kelis vietinius vartotojus, kai kiekvienas neturi tempti per WAN. Tarpinė duomenų bazė dabar laiko publikaciją ir savo agentus. Ji taip pat paveldi leidimus, stebėjimą ir atkūrimo planą, kurių anksčiau neturėjo. Tas papildomas vaidmuo yra pasikartojančio WAN pristatymo pašalinimo kaina.

Dokumentuota tvarka svarbi: inicializuokite įeinančią prenumeratą prieš kurdami pasroviui esančią publikaciją. Traktuokite tai kaip gyvavimo ciklo žingsnį su patikra, o ne kaip praleidžiamą popierizmą. Apvertus tvarką gaunama grandinė, kuri atrodo sukonfigūruota ir nieko nepristato.

Aiškiai nurodykite rašymo modelį. Tik skaitymui skirto duomenų rinkinio replikavimas vietiniam vartotojui yra kitoks projektas nei rašymų priėmimas keliose vietose, o rodyklių grandinė nesukuria konfliktų sprendimo. Jei filialas turi rašyti, tai atskiras sprendimas su savo topologija. Padarykite priklausomybę matomą: kai pakartotinis publikuotojas neveikia, kiekvienas vartotojas po juo yra pasenęs.

Įrodykite išdėstymą nuo pradžios iki galo

Skaitykite prenumeratos tipą iš paskirstymo duomenų bazės, o ne pasikliaukite atmintimi, tada patikrinkite, ar pakeitimai tikrai atkeliauja:

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 reikšmė 0 reiškia push, o 1 - pull, ir jo vietoje pakeisti negalima, todėl neatitikimas reiškia prenumeratos kūrimą iš naujo, o ne redagavimą. Laukiančių komandų iškvietimas pasako, ar pasirinktas agentas judina darbą, ar tik veikia. Prenumerata, kuri praneša nulį laukiančių komandų, kol prenumeruotojo lentelė lieka tuščia, yra kitoks gedimas nei ta, kuri praneša augantį atsilikimą, ir abi veda pas skirtingus savininkus.

Užbaikite tikru pakeitimu: įterpkite arba atnaujinkite vieną eilutę Publisher pusėje, palaukite agento ataskaitos ir perskaitykite tą eilutę Subscriber pusėje. Padarykite tai dar kartą per trumpą VPN pertraukimą, kad pamatytumėte, kaip agentas atsistato. Prenumerata, kuri atlaiko šį bandymą, turi išdėstymą, kurį galite dokumentuoti ir apginti.