Agjentët e replikimit push dhe pull përmes një VPN midis site-ve

Vendndodhja e agjentit, jo vendndodhja e të dhënave, është vendimi që formon një abonim SQL Server. Makina që ekzekuton agjentin hap lidhjen, punon nën një llogari të caktuar dhe merr fajin kur sinkronizimi ngec. Në një VPN midis site-ve ai ndryshim është projektimi, jo një detaj. Vizatoni lidhjet e agjentit para se të vizatoni rrjetin.

Tre role, jo dy

Publisher zotëron të dhënat e artikullit, Distributor zotëron bazën e të dhënave të shpërndarjes, dhe Subscriber merr ndryshimet. Log Reader Agent ekzekutohet te Distributor për replikimin transaksional. Distribution Agent është ai, vendndodhja e të cilit ndryshon me llojin e abonimit, dhe për këtë arsye ai përcakton projektimin e rrjetit. Sqaroni këto role para se të flisni për rregullat e VPN-së.

Një abonim push ekzekuton Distribution Agent te Distributor, dhe një abonim pull e ekzekuton atë te Subscriber, siç tregon dokumentacioni i abonimeve i Microsoft. Gjithçka në bisedën e rrjetit rrjedh nga cila makinë është ajo. Shkruani katër fakte për çdo abonim: hostin e agjentit, identitetin e procesit të tij, hyrjet në bazën e të dhënave që përdor dhe burimet që duhet të arrijë. Këto fakte, jo një shigjetë në diagram, ju tregojnë cili drejtim duhet të funksionojë.

push do të thotë që agjenti jeton te Distributor

Me një abonim push, Distributor hap lidhjen drejt Subscriber përmes VPN-së. Dëgjuesi, firewall-i dhe hyrja SQL në anën e abonuesit duhet të pranojnë lidhjet që vijnë nga ana e largët. Llogaria e shërbimit e Distributor gjithashtu ka nevojë për leje në bazën e të dhënave të abonuesit. Planifikoni atë rrugë hyrëse para se të krijoni abonimin, sepse zbulimi i saj më vonë zakonisht do të thotë rikrijim.

Dorëzimi i snapshot shton një rrugë që replikimi i qëndrueshëm nuk e përdor kurrë. Nëse snapshot është vendosur në një ndarje skedarësh, Distribution Agent lexon nga ajo ndarje dhe llogaria e abonuesit duhet të arrijë të njëjtën rrugë UNC. Një rrjedhë ndryshimesh që zgjat javë nuk thotë asgjë se a do të funksionojë një riinitializim. Prandaj ndarja e snapshot-it i përket planit që në fillim.

Mos e lexoni push si trafik njëdrejtimësh. Agjenti ka nevojë për përgjigje, konfirmime dhe shkëmbimet e veta të vërtetimit. Rruga duhet të jetë dydrejtimëshe në nivel lidhjeje edhe kur të dhënat lëvizin në një drejtim.

pull do të thotë që agjenti jeton te Subscriber

Një abonim pull e kthen lidhjen mbrapsht: Subscriber ekzekuton Distribution Agent dhe i drejtohet Distributor. Ky rregullim i përshtatet një politike VPN që lejon lidhjet dalëse nga dega dhe bllokon ato hyrëse. Ai gjithashtu e vendos vendimin e planifikimit në duart e atij që kujdeset për serverin e degës. Zgjidhni atë kur ekipi i degës duhet të zotërojë sinkronizimin e vet dhe të vërejë dështimet e veta.

Llogaria e shërbimit SQL Server Agent e abonuesit ka nevojë për akses leximi në bazën e të dhënave të shpërndarjes dhe në ndarjen e snapshot-it. Ajo llogari është identiteti që shfaqet në gabimet e replikimit, dhe një llogari lokale shërbimi pa të drejta domeni dështon në një pikë që duket si defekt rrjeti, por në të vërtetë është defekt kredencialesh. Kontrolloni llogarinë para se të korrigjoni tunelin. Rregullimi i hyrjes zakonisht është më i shpejtë se sa vërtetimi i pafajësisë së rrjetit.

Zotërimi ndjek agjentin. Zgjidhni push kur ekipi qendror duhet të zotërojë edhe planin edhe dështimet. Çfarëdo që të zgjidhni, shkruajeni pranë abonimit që inxhinieri i radhës të dijë ku të shohë së pari.

Ribotimi ndryshon shpërndarjen, jo zotërimin

Një abonues mund të konfigurohet të ribotojë te abonues të tjerë, duke lejuar një bazë të dhënash dege të shërbejë disa konsumatorë lokalë pa tërhequr secili përmes WAN. Baza e të dhënave e mesme tani mban një publikim dhe agjentët e vet. Ajo trashëgon gjithashtu leje, monitorim dhe një plan rikuperimi që nuk i kishte më parë. Ai rol shtesë është çmimi për heqjen e dorëzimit të përsëritur përmes WAN.

Rendi i dokumentuar ka rëndësi: inicializoni abonimin hyrës para se të krijoni publikimin në rrjedhën e poshtme. Trajtojeni atë si një hap të ciklit të jetës me verifikim, jo si letra që anashkalohen. Kthimi i tij prodhon një zinxhir që duket i konfiguruar dhe nuk dorëzon asgjë.

Deklaroni modelin e shkrimit shprehimisht. Replikimi i një grupi të dhënash vetëm për lexim te një konsumator lokal është një projektim tjetër nga pranimi i shkrimeve në disa site, dhe një zinxhir shigjetash nuk krijon zgjidhje konfliktesh. Nëse dega duhet të shkruajë, ky është një vendim i veçantë me topologjinë e vet. Bëni të dukshme edhe varësinë: kur ribotuesi është jashtë, çdo konsumator nën të është i vjetruar.

Vërtetoni vendosjen nga fillimi në fund

Lexoni llojin e abonimit nga baza e të dhënave e shpërndarjes në vend që t’i besoni kujtesës, pastaj kontrolloni nëse ndryshimet vijnë vërtet:

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 me vlerë 0 është push dhe 1 është pull, dhe nuk mund të ndryshohet në vend, prandaj mospërputhja do të thotë rikrijim i abonimit dhe jo redaktim i tij. Thirrja e komandave në pritje ju tregon nëse agjenti i zgjedhur po lëviz punë apo thjesht po ekzekutohet. Një abonim që raporton zero komanda në pritje ndërsa tabela e abonuesit mbetet bosh është defekt tjetër nga ai që raporton një vonesë në rritje, dhe të dy çojnë te zotërues të ndryshëm.

Përfundoni me një ndryshim real: futni ose përditësoni një rresht te Publisher, prisni raportin e agjentit dhe lexoni atë rresht te Subscriber. Bëjeni edhe një herë përmes një ndërprerjeje të shkurtër të VPN-së për të parë si rikuperohet agjenti. Një abonim që i mbijeton atij testi ka një vendosje që mund ta dokumentoni dhe ta mbroni.