Push un pull replikācijas aģenti pāri VPN starp vietnēm

Aģenta atrašanās vieta, nevis datu atrašanās vieta, ir lēmums, kas veido SQL Server abonementu. Mašīna, kas izpilda aģentu, atver savienojumu, darbojas ar konkrētu kontu un uzņemas vainu, kad sinhronizācija apstājas. VPN starp vietnēm šī atšķirība ir projektējums, nevis sīkums. Uzzīmējiet aģenta savienojumus pirms tīkla zīmēšanas.

Trīs lomas, nevis divas

Publisher pieder raksta dati, Distributor pieder izplatīšanas datubāze, un Subscriber saņem izmaiņas. Log Reader Agent darbojas pie Distributor transakciju replikācijai. Distribution Agent ir tas, kura atrašanās vieta mainās līdz ar abonementa tipu, un tāpēc tas nosaka tīkla projektējumu. Noskaidrojiet šīs lomas pirms runāšanas par VPN noteikumiem.

push abonements izpilda Distribution Agent pie Distributor, un pull abonements to izpilda pie Subscriber saskaņā ar Microsoft abonementu dokumentāciju. Viss tīkla sarunā izriet no tā, kura mašīna tas ir. Pierakstiet četrus faktus katram abonementam: aģenta saimnieku, tā procesa identitāti, izmantotos datubāzes pieteikumus un resursus, kas tam jāsasniedz. Šie fakti, nevis diagrammas bultiņa, pasaka, kuram virzienam jādarbojas.

push nozīmē, ka aģents dzīvo pie Distributor

push abonementa gadījumā Distributor atver savienojumu uz Subscriber pāri VPN. Abonenta puses klausītājam, ugunsmūrim un SQL pieteikumam jāpieņem savienojumi, kas nāk no attālās puses. Distributor servisa kontam arī vajadzīga atļauja abonenta datubāzē. Plānojiet šo ienākošo ceļu pirms abonementa izveides, jo tā atklāšana vēlāk parasti nozīmē tā izveidi no jauna.

Momentuzņēmuma piegāde pievieno ceļu, ko stabilā replikācija nekad neizmanto. Ja momentuzņēmums atrodas failu koplietojumā, Distribution Agent lasa no šī koplietojuma, un abonenta kontam jāsasniedz tas pats UNC ceļš. Nedēļām ilgs izmaiņu straume neko nepasaka par to, vai atkārtota inicializācija strādās. Tāpēc momentuzņēmuma koplietojums pieder pie plāna no paša sākuma.

Nelasiet push kā vienvirziena satiksmi. Aģentam vajadzīgas atbildes, apstiprinājumi un paša autentifikācijas apmaiņas. Ceļam jābūt divvirzienu savienojuma līmenī arī tad, kad dati pārvietojas vienā virzienā.

pull nozīmē, ka aģents dzīvo pie Subscriber

pull abonements apgriež savienojumu otrādi: Subscriber pats izpilda Distribution Agent un vēršas pie Distributor. Šis izvietojums atbilst VPN politikai, kas atļauj izejošos savienojumus no filiāles un bloķē ienākošos. Tas arī nodod grafika lēmumu tā ziņā, kurš rūpējas par filiāles serveri. Izvēlieties to, kad filiāles komandai jāpārvalda sava sinhronizācija un jāpamana savi bojājumi.

Abonenta SQL Server Agent servisa kontam vajadzīga lasīšanas piekļuve izplatīšanas datubāzei un momentuzņēmuma koplietojumam. Šis konts ir identitāte, kas parādās replikācijas kļūdās, un vietējais servisa konts bez domēna tiesībām neizdodas vietā, kas izskatās kā tīkla bojājums, bet patiesībā ir pieteikšanās datu bojājums. Pārbaudiet kontu pirms tuneļa atkļūdošanas. Pieteikšanās salabošana parasti ir ātrāka nekā tīkla nevainības pierādīšana.

Īpašumtiesības seko aģentam. Izvēlieties push, kad centrālajai komandai jāpārvalda gan grafiks, gan bojājumi. Ko vien izvēlētos, pierakstiet to blakus abonementam, lai nākamais inženieris zinātu, kur skatīties vispirms.

Atkārtota publicēšana maina sadalījumu, nevis īpašumtiesības

Abonentu var konfigurēt atkārtoti publicēt tālākiem abonentiem, ļaujot vienai filiāles datubāzei apkalpot vairākus vietējos patērētājus, bez tam, ka katrs velk pāri WAN. Starpposma datubāze tagad satur publikāciju un savus aģentus. Tā arī manto atļaujas, uzraudzību un atkopšanas plānu, kāda iepriekš nebija. Šī papildu loma ir cena par atkārtotas WAN piegādes noņemšanu.

Dokumentētā secība ir svarīga: inicializējiet ienākošo abonementu pirms lejupējās publikācijas izveides. Uztveriet to kā dzīves cikla soli ar pārbaudi, nevis kā izlaižamu papīru darbu. Apgriežot to otrādi, tiek iegūta ķēde, kas izskatās konfigurēta un neko nepiegādā.

Skaidri norādiet rakstīšanas modeli. Tikai lasāmas datu kopas replikācija vietējam patērētājam ir cits projektējums nekā rakstīšanas pieņemšana vairākās vietās, un bultiņu ķēde nerada konfliktu risināšanu. Ja filiālei jāraksta, tas ir atsevišķs lēmums ar savu topoloģiju. Padariet redzamu arī atkarību: kad atkārtotais publicētājs nedarbojas, katrs patērētājs zem tā ir novecojis.

Pierādiet izvietojumu no sākuma līdz beigām

Lasiet abonementa tipu no izplatīšanas datubāzes, nevis paļaujieties uz atmiņu, pēc tam pārbaudiet, vai izmaiņas patiešām pienāk:

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ērtība 0 nozīmē push, bet 1 - pull, un to nevar mainīt uz vietas, tāpēc neatbilstība nozīmē abonementa izveidi no jauna, nevis rediģēšanu. Gaidošo komandu izsaukums pasaka, vai izvēlētais aģents pārvieto darbu vai tikai darbojas. Abonements, kas ziņo par nulli gaidošu komandu, kamēr abonenta tabula paliek tukša, ir cits bojājums nekā tas, kas ziņo par augošu atpalicību, un abi ved pie dažādiem īpašniekiem.

Pabeidziet ar reālām izmaiņām: ievietojiet vai atjauniniet vienu rindu pie Publisher, nogaidiet aģenta ziņojumu un nolasiet šo rindu pie Subscriber. Izdariet to vēlreiz īsas VPN pārtraukuma laikā, lai redzētu, kā aģents atkopjas. Abonements, kas iztur šo pārbaudi, ir ar izvietojumu, ko varat dokumentēt un aizstāvēt.