Puŝaj kaj tiradaj reproduktaj agentoj trans VPN inter ejoj

La loko de la agento, ne la loko de la datumoj, estas la decido, kiu formas SQL Server-abonon. La maŝino, kiu rulas la agenton, malfermas la konekton, funkcias sub specifa konto kaj prenas la kulpon, kiam la sinkronigo haltas. En VPN inter ejoj tiu diferenco estas la dezajno, ne detalo. Desegnu la agentajn konektojn antaŭ ol desegni la reton.

Tri roloj, ne du

La Publisher posedas la artikolajn datumojn, la Distributor posedas la distribuan datumbazon, kaj la Subscriber ricevas ŝanĝojn. La Log Reader Agent rulas ĉe la Distributor por transakcia reproduktado. La Distribution Agent estas tiu, kies loko ŝanĝiĝas kun la abona tipo, kaj tial ĝi direktas la retan dezajnon. Klarigu tiujn rolojn antaŭ ol paroli pri VPN-reguloj.

Puŝa abono rulas la Distribution Agent ĉe la Distributor, kaj tirada abono rulas ĝin ĉe la Subscriber, kiel diras la dokumentaro pri abonoj de Microsoft. Ĉio en la reta interparolo sekvas el tio, kiu maŝino ĝi estas. Notu kvar faktojn por ĉiu abono: la gastiganto de la agento, ĝia proceza identeco, la datumbazaj ensalutoj, kiujn ĝi uzas, kaj la rimedoj, kiujn ĝi devas atingi. Tiuj faktoj, ne sago en diagramo, diras al vi, kiu direkto devas funkcii.

Puŝo signifas, ke la agento loĝas ĉe la Distributor

Ĉe puŝa abono la Distributor malfermas la konekton al la Subscriber trans la VPN. La aŭskultanto, fajroŝirmilo kaj SQL-ensaluto ĉe la abonanta flanko devas akcepti konektojn venantajn de la fora flanko. La serva konto de la Distributor ankaŭ bezonas permeson sur la abona datumbazo. Planu tiun envenan vojon antaŭ ol krei la abonon, ĉar malkovri ĝin poste kutime signifas rekrei ĝin.

La liverado de momenta kopio aldonas vojon, kiun stabila reproduktado neniam uzas. Se la momenta kopio estas metita sur dosierpartigaĵo, la Distribution Agent legas de tiu partigaĵo kaj la konto de la abonanto devas atingi la saman UNC-vojon. Ŝanĝa fluo, kiu daŭras semajnojn, diras nenion pri tio, ĉu reinitialigo funkcios. Tial la partigaĵo de la momenta kopio apartenas al la plano de la komenco.

Ne legu puŝon kiel unudirektan trafikon. La agento bezonas respondojn, konfirmojn kaj proprajn aŭtentikigajn interŝanĝojn. La vojo devas esti dudirekta je la konekta nivelo eĉ kiam datumoj moviĝas en unu direkton.

Tirado signifas, ke la agento loĝas ĉe la Subscriber

Tirada abono inversigas la konekton: la Subscriber rulas la Distribution Agent kaj turnas sin al la Distributor. Tiu aranĝo taŭgas por VPN-politiko, kiu permesas elirajn konektojn el la filio kaj blokas enirajn. Ĝi ankaŭ metas la decidon pri horaro en la manojn de tiu, kiu zorgas pri la filia servilo. Elektu ĝin, kiam la filia teamo devas posedi sian propran sinkronigon kaj rimarki siajn proprajn malsukcesojn.

La serva konto de SQL Server Agent de la abonanto bezonas legan aliron al la distribua datumbazo kaj al la partigaĵo de la momenta kopio. Tiu konto estas la identeco, kiu aperas en reproduktaj eraroj, kaj loka serva konto sen domajnaj rajtoj malsukcesas ĉe punkto, kiu aspektas kiel reta paneo sed fakte estas akreditaĵa paneo. Kontrolu la konton antaŭ ol sencimigi la tunelon. Ripari la ensaluton kutime estas pli rapide ol pruvi la senkulpecon de la reto.

Posedo sekvas la agenton. Elektu puŝon, kiam la centra teamo devas posedi kaj la horaron kaj la malsukcesojn. Kion ajn vi elektas, skribu ĝin apud la abono, por ke la sekva inĝeniero sciu, kie unue rigardi.

Republikigo ŝanĝas la disbranĉiĝon, ne la posedon

Abonanto povas esti agordita republikigi al pliaj abonantoj, ebligante al unu filia datumbazo servi plurajn lokajn konsumantojn sen ke ĉiu el ili tirus trans la WAN. La meza datumbazo nun tenas publikaĵon kaj proprajn agentojn. Ĝi ankaŭ heredas permesojn, observadon kaj reakiran planon, kiujn ĝi antaŭe ne havis. Tiu aldona rolo estas la prezo por forigi ripetatan WAN-liveradon.

La dokumentita ordo gravas: inicializu la envenantan abonon antaŭ ol krei la malsupran publikaĵon. Traktu tion kiel paŝon de la vivociklo kun kontrolo, ne kiel paperaron por preterpasi. Inversigi ĝin produktas ĉenon, kiu aspektas agordita kaj liveras nenion.

Deklaru la skribmodelon eksplicite. Reprodukti nurlegan datumaron al loka konsumanto estas alia dezajno ol akcepti skribojn ĉe pluraj ejoj, kaj ĉeno de sagoj ne kreas konfliktsolvon. Se la filio devas skribi, tio estas aparta decido kun propra topologio. Ankaŭ vidigu la dependecon: kiam la republikiganto estas malŝaltita, ĉiu konsumanto sub ĝi estas malaktuala.

Pruvu la lokigon de komenco ĝis fino

Legu la abonan tipon el la distribua datumbazo anstataŭ fidi la memoron, poste kontrolu, ĉu la ŝanĝoj vere alvenas:

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 de 0 estas puŝo kaj 1 estas tirado, kaj ĝi ne ŝanĝeblas surloke, do malkongruo signifas rekrei la abonon anstataŭ redakti ĝin. La voko de atendaj komandoj diras al vi, ĉu la elektita agento movas laboron aŭ nur funkcias. Abono, kiu raportas nulon da atendaj komandoj dum la abona tabelo restas malplena, estas alia paneo ol tiu, kiu raportas kreskantan postrestaĵon, kaj ambaŭ kondukas al malsamaj posedantoj.

Finu per reala ŝanĝo: enmetu aŭ ĝisdatigu unu vicon ĉe la Publisher, atendu, ke la agento raportu, kaj legu tiun vicon ĉe la Subscriber. Faru tion ankoraŭ unufoje dum mallonga VPN-interrompo por vidi, kiel la agento resaniĝas. Abono, kiu postvivas tiun teston, havas lokigon, kiun vi povas dokumenti kaj defendi.