Mawakala wa urudufishaji push na pull kupitia VPN kati ya maeneo

Mahali pa wakala, si mahali pa data, ni uamuzi unaounda usajili wa SQL Server. Mashine inayoendesha wakala hufungua muunganisho, hufanya kazi chini ya akaunti maalum na hubeba lawama usawazishaji unapokwama. Kwenye VPN kati ya maeneo tofauti huo ni muundo, si maelezo madogo. Chora miunganisho ya wakala kabla ya kuchora mtandao.

Majukumu matatu, si mawili

Publisher anamiliki data ya makala, Distributor anamiliki hifadhidata ya usambazaji, na Subscriber hupokea mabadiliko. Log Reader Agent hufanya kazi kwenye Distributor kwa urudufishaji wa miamala. Distribution Agent ni yule ambaye mahali pake hubadilika na aina ya usajili, na ndiyo sababu huongoza muundo wa mtandao. Fafanua majukumu hayo kabla ya kuzungumza kuhusu kanuni za VPN.

Usajili wa push huendesha Distribution Agent kwenye Distributor, na usajili wa pull huendesha kwenye Subscriber, kama inavyosema nyaraka za usajili za Microsoft. Kila kitu kwenye mazungumzo ya mtandao hutokana na mashine hiyo ni ipi. Andika ukweli wanne kwa kila usajili: mwenyeji wa wakala, utambulisho wa mchakato wake, kuingia kwa hifadhidata anayotumia na rasilimali anazopaswa kufikia. Mishale ya mchoro si kitu, ukweli huu husema ni mwelekeo upi unapaswa kufanya kazi.

push inamaanisha wakala anaishi kwenye Distributor

Kwa usajili wa push, Distributor hufungua muunganisho kwa Subscriber kupitia VPN. Msikilizaji, firewall na kuingia kwa SQL upande wa mteja lazima zikubali miunganisho inayotoka upande wa mbali. Akaunti ya huduma ya Distributor pia inahitaji ruhusa kwenye hifadhidata ya mteja. Panga njia hiyo ya kuingia kabla ya kuunda usajili, kwa sababu kuigundua baadaye kwa kawaida humaanisha kuunda upya.

Uwasilishaji wa picha ya papo hapo huongeza njia ambayo urudufishaji thabiti hautumii kamwe. Ikiwa picha imewekwa kwenye kushiriki faili, Distribution Agent husoma kutoka kwenye kushiriki hicho na akaunti ya mteja lazima ifikie njia hiyo hiyo ya UNC. Mtiririko wa mabadiliko unaodumu kwa wiki hausemi chochote kuhusu kama uanzishaji upya utafanya kazi. Ndiyo sababu kushiriki kwa picha ni sehemu ya mpango tangu mwanzo.

Usisome push kama trafiki ya mwelekeo mmoja. Wakala anahitaji majibu, uthibitisho na mabadilishano yake mwenyewe ya uthibitishaji. Njia lazima iwe ya pande mbili katika ngazi ya muunganisho hata data inaposonga upande mmoja.

pull inamaanisha wakala anaishi kwenye Subscriber

Usajili wa pull hugeuza muunganisho: Subscriber mwenyewe huendesha Distribution Agent na kumfikia Distributor. Mpangilio huo unafaa sera ya VPN inayoruhusu miunganisho ya kutoka kutoka tawi na kuzuia inayoingia. Pia huweka uamuzi wa ratiba mikononi mwa anayeshughulikia seva ya tawi. Ichague wakati timu ya tawi inapaswa kumiliki usawazishaji wake na kutambua hitilafu zake.

Akaunti ya huduma ya SQL Server Agent ya mteja inahitaji ufikiaji wa kusoma hifadhidata ya usambazaji na kushiriki kwa picha. Akaunti hiyo ni utambulisho unaoonekana katika hitilafu za urudufishaji, na akaunti ya huduma ya ndani isiyo na haki za kikoa hushindwa mahali panapoonekana kama hitilafu ya mtandao lakini kwa kweli ni hitilafu ya vitambulisho. Angalia akaunti kabla ya kutatua matatizo ya handaki. Kurekebisha kuingia kwa kawaida ni haraka kuliko kuthibitisha kuwa mtandao hauna hatia.

Umiliki hufuata wakala. Chagua push wakati timu kuu inapaswa kumiliki ratiba na hitilafu zote mbili. Chochote unachochagua, kiandike kando ya usajili ili mhandisi anayefuata ajue pa kuangalia kwanza.

Uchapishaji upya hubadilisha usambazaji, si umiliki

Mteja anaweza kusanidiwa kuchapisha upya kwa wateja wengine, hivyo hifadhidata moja ya tawi inaweza kuhudumia watumiaji kadhaa wa ndani bila kila mmoja kuvuta kupitia WAN. Hifadhidata ya kati sasa inashikilia uchapishaji na mawakala wake. Pia hurithi ruhusa, ufuatiliaji na mpango wa urejeshaji ambao haukuwa nao awali. Jukumu hilo la ziada ni gharama ya kuondoa uwasilishaji wa WAN unaorudiwa.

Mpangilio ulioandikwa ni muhimu: anzisha usajili unaoingia kabla ya kuunda uchapishaji wa chini. Ichukulie kama hatua ya mzunguko wa maisha yenye uthibitisho, si karatasi za kupuuzwa. Kuubadilisha kwa mpangilio kinyume huzalisha mnyororo unaoonekana umesanidiwa na hawasilishi chochote.

Taja mfano wa uandishi kwa uwazi. Kurudufisha seti ya data ya kusoma tu kwa mtumiaji wa ndani ni muundo tofauti na kukubali maandishi katika maeneo kadhaa, na mnyororo wa mishale hauzalishi utatuzi wa migogoro. Ikiwa tawi lazima liandike, huo ni uamuzi tofauti na topolojia yake mwenyewe. Fanya utegemezi uonekane pia: mchapishaji upya anapokwama, kila mtumiaji chini yake amepitwa na wakati.

Thibitisha upangaji kutoka mwanzo hadi mwisho

Soma aina ya usajili kutoka kwenye hifadhidata ya usambazaji badala ya kuamini kumbukumbu, kisha angalia kama mabadiliko yanafika kweli:

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 yenye thamani 0 ni push na 1 ni pull, na haiwezi kubadilishwa mahali pake, kwa hivyo kutokulingana humaanisha kuunda upya usajili na si kuubadilisha. Mwito wa amri zinazosubiri hukuambia kama wakala aliyechaguliwa anasogeza kazi au anafanya kazi tu. Usajili unaoripoti amri sifuri zinazosubiri wakati jedwali la mteja linabaki tupu ni hitilafu tofauti na ule unaoripoti mlundikano unaoongezeka, na zote mbili hupelekea wamiliki tofauti.

Maliza kwa mabadiliko ya kweli: ingiza au sasisha safu moja kwenye Publisher, subiri ripoti ya wakala na usome safu hiyo kwenye Subscriber. Fanya tena wakati wa usumbufu mfupi wa VPN ili kuona jinsi wakala anavyopona. Usajili unaostahimili jaribio hilo una upangaji ambao unaweza kuandika na kuutetea.