Agendi asukoht, mitte andmete asukoht, on otsus, mis kujundab SQL Serveri tellimuse. Agenti käivitav masin avab ühenduse, töötab kindla konto all ja võtab süü, kui sünkroonimine takerdub. Saitidevahelises VPN-is on see erinevus disain, mitte detail. Joonistage agendi ühendused enne, kui joonistate võrgu.

Kolm rolli, mitte kaks

Publisher omab artikli andmeid, Distributor omab jaotuse andmebaasi ja Subscriber võtab muudatusi vastu. Log Reader Agent töötab Distributoris tehingulise replikatsiooni jaoks. Distribution Agent on see, mille asukoht muutub tellimuse tüübiga, ja seetõttu määrab see võrgu disaini. Tehke need rollid selgeks enne, kui räägite VPN-i reeglitest.

Push-tellimus käivitab Distribution Agenti Distributoris ja pull-tellimus käivitab selle Subscriberis, nagu märgib Microsofti tellimuste dokumentatsioon ütleb. Kõik võrguvestluses tuleneb sellest, milline masin see on. Kirjutage iga tellimuse kohta üles neli fakti: agendi host, selle protsessi identiteet, kasutatavad andmebaasi sisselogimised ja ressursid, milleni see peab jõudma. Need faktid, mitte diagrammi nool, ütlevad, milline suund peab töötama.

Push tähendab, et agent elab Distributoris

Push-tellimuse korral avab Distributor ühenduse Subscriberi poole üle VPN-i. Kuulaja, tulemüür ja SQL-i sisselogimine tellija poolel peavad vastu võtma kaugemalt saabuvaid ühendusi. Distributori teenusekontol on vaja ka õigust tellija andmebaasil. Planeerige see sissetulev tee enne tellimuse loomist, sest selle hilisem avastamine tähendab tavaliselt uuesti loomist.

Hetktõmmise kohaletoimetamine lisab tee, mida püsiv replikatsioon kunagi ei kasuta. Kui hetktõmmis on failijagamises, loeb Distribution Agent sellest jagamisest ja tellija konto peab jõudma samale UNC-teele. Nädalaid kestev muudatuste voog ei ütle midagi selle kohta, kas uuesti algatamine töötab. Seepärast kuulub hetktõmmise jagamine plaani algusest peale.

Ärge lugege pushi ühesuunalise liiklusena. Agent vajab vastuseid, kinnitusi ja oma autentimisvahetusi. Tee peab olema ühenduse tasandil kahesuunaline ka siis, kui andmed liiguvad ühes suunas.

Pull tähendab, et agent elab Subscriberis

Pull-tellimus pöörab ühenduse ümber: Subscriber käivitab Distribution Agendi ja pöördub Distributori poole. See lahendus sobib VPN-i poliitikaga, mis lubab harukontorist väljuvaid ühendusi ja blokeerib sissetulevaid. See paneb ka ajakava otsuse selle kätte, kes harukontori serveri eest hoolitseb. Valige see, kui harukontori meeskond peaks omama oma sünkroonimist ja märkama oma tõrkeid.

Tellija SQL Server Agent teenusekontol on vaja lugemisõigust jaotuse andmebaasile ja hetktõmmise jagamisele. See konto on identiteet, mis ilmub replikatsioonivigades, ja domeeniõigusteta kohalik teenusekonto ebaõnnestub kohas, mis näeb välja nagu võrgu rike, kuid on tegelikult mandaadi rike. Kontrollige kontot enne tunnelisilumist. Sisselogimise parandamine on tavaliselt kiirem kui võrgu süütuse tõestamine.

Omand järgib agenti. Valige push, kui keskne meeskond peaks omama nii ajakava kui ka tõrkeid. Mida iganes valite, kirjutage see tellimuse kõrvale, et järgmine insener teaks, kuhu esimesena vaadata.

Uuesti avaldamine muudab harunemist, mitte omandit

Tellijat saab seadistada uuesti avaldama edasistele tellijatele, mis võimaldab ühel harukontori andmebaasil teenindada mitut kohalikku tarbijat ilma, et igaüks tõmbaks üle WAN-i. Keskmine andmebaas hoiab nüüd avaldist ja oma agente. See pärib ka õigused, jälgimise ja taastamise plaani, mida sellel varem ei olnud. See lisaroll on korduva WAN-kohaletoimetamise eemaldamise hind.

Dokumenteeritud järjekord on oluline: algatage sissetulev tellimus enne allavoolu avaldise loomist. Käsitlege seda elutsükli sammuna koos kontrolliga, mitte vahelejäetava pabertööna. Selle ümberpööramine loob ahela, mis näeb seadistatud välja ja ei toimetagi midagi.

Öelge kirjutamise mudel selgelt välja. Ainult lugemiseks mõeldud andmestiku replikatsioon kohalikule tarbijale on teistsugune disain kui kirjutuste vastuvõtmine mitmes kohas, ja noolte ahel ei loo konfliktide lahendamist. Kui harukontor peab kirjutama, on see eraldi otsus oma topoloogiaga. Tehke nähtavaks ka sõltuvus: kui uuesti avaldaja on maas, on iga tarbija selle all aegunud.

Tõestage paigutus otsast lõpuni

Lugege tellimuse tüüp jaotuse andmebaasist, selle asemel et mälu usaldada, ja kontrollige siis, kas muudatused tõesti saabuvad:

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 väärtusega 0 on push ja 1 on pull ning seda ei saa kohapeal muuta, seega tähendab ebakõla tellimuse uuesti loomist, mitte selle muutmist. Ootel käskude kutse ütleb teile, kas valitud agent liigutab tööd või ainult töötab. Tellimus, mis teatab null ootel käsku, samal ajal kui tellija tabel jääb tühjaks, on erinev rike kui see, mis teatab kasvavast mahajäämusest, ja mõlemad viivad erinevate omanikeni.

Lõpetage tegeliku muudatusega: sisestage või värskendage Publisheris üks rida, oodake agendi aruannet ja lugege see rida Subscriberis. Tehke seda veel kord üle lühikese VPN-i katkestuse, et näha, kuidas agent taastub. Tellimus, mis selle testi üle elab, on paigutusega, mida saate dokumenteerida ja kaitsta.

Seotud artiklid