સાઇટ VPN પર push અને pull રેપ્લિકેશન એજન્ટ

એજન્ટનું સ્થાન, ડેટાનું સ્થાન નહીં, એ નિર્ણય છે જે SQL Server સબ્સ્ક્રિપ્શનને આકાર આપે છે. જે મશીન એજન્ટ ચલાવે છે તે કનેક્શન ખોલે છે, ચોક્કસ એકાઉન્ટ હેઠળ ચાલે છે અને સિંક્રોનાઇઝેશન અટકે ત્યારે દોષ લે છે. સાઇટ-થી-સાઇટ VPN પર એ ફરક જ ડિઝાઇન છે, કોઈ નાની વિગત નહીં. નેટવર્ક દોરતા પહેલાં એજન્ટના કનેક્શન દોરો.

ત્રણ ભૂમિકાઓ, બે નહીં

Publisher આર્ટિકલના ડેટાનો માલિક છે, Distributor ડિસ્ટ્રિબ્યુશન ડેટાબેઝનો માલિક છે, અને Subscriber ફેરફારો મેળવે છે. Log Reader Agent ટ્રાન્ઝેક્શનલ રેપ્લિકેશન માટે Distributor પર ચાલે છે. Distribution Agent એ છે જેનું સ્થાન સબ્સ્ક્રિપ્શનના પ્રકાર સાથે બદલાય છે, અને તેથી તે નેટવર્ક ડિઝાઇન નક્કી કરે છે. VPN નિયમો વિશે વાત કરતા પહેલાં એ ભૂમિકાઓ સ્પષ્ટ કરો.

push સબ્સ્ક્રિપ્શન Distribution Agentને Distributor પર ચલાવે છે, અને pull સબ્સ્ક્રિપ્શન તેને Subscriber પર ચલાવે છે, જેમ Microsoftનું સબ્સ્ક્રિપ્શન દસ્તાવેજીકરણ જણાવે છે. નેટવર્ક વાતચીતનું બધું જ એના પરથી આવે છે કે એ કઈ મશીન છે. દરેક સબ્સ્ક્રિપ્શન માટે ચાર તથ્યો લખો: એજન્ટનું હોસ્ટ, તેની પ્રોસેસ ઓળખ, તે વાપરે છે તે ડેટાબેઝ લોગિન અને જે સંસાધનો સુધી તેને પહોંચવું છે. એ તથ્યો, ડાયાગ્રામનું તીર નહીં, કહે છે કે કઈ દિશાએ કામ કરવું પડશે.

push એટલે એજન્ટ Distributor પર રહે છે

push સબ્સ્ક્રિપ્શનમાં Distributor VPN દ્વારા Subscriber તરફનું કનેક્શન ખોલે છે. સબ્સ્ક્રાઇબર બાજુનું લિસનર, ફાયરવોલ અને SQL લોગિન દૂરની બાજુથી આવતા કનેક્શન સ્વીકારવા પડે છે. Distributorના સર્વિસ એકાઉન્ટને પણ સબ્સ્ક્રાઇબર ડેટાબેઝ પર પરવાનગી જોઈએ. સબ્સ્ક્રિપ્શન બનાવતા પહેલાં એ આવક માર્ગનું આયોજન કરો, કારણ કે પછી એ શોધવાનો અર્થ સામાન્ય રીતે એ ફરી બનાવવો હોય છે.

સ્નેપશોટ ડિલિવરી એ માર્ગ ઉમેરે છે જે સ્થિર રેપ્લિકેશન ક્યારેય વાપરતું નથી. જો સ્નેપશોટ ફાઇલ શેર પર મૂકેલો હોય, તો Distribution Agent એ શેરમાંથી વાંચે છે અને સબ્સ્ક્રાઇબરના એકાઉન્ટે એ જ UNC માર્ગ સુધી પહોંચવું પડે છે. અઠવાડિયાં સુધી ચાલતો ફેરફારનો પ્રવાહ એ વિશે કંઈ કહેતો નથી કે ફરી શરૂ કરવું કામ કરશે કે નહીં. તેથી સ્નેપશોટ શેર શરૂઆતથી જ યોજનાનો ભાગ છે.

pushને એકતરફી ટ્રાફિક તરીકે ન વાંચો. એજન્ટને જવાબો, સ્વીકૃતિઓ અને પોતાના પ્રમાણીકરણ વિનિમયની જરૂર છે. ડેટા એક દિશામાં ચાલે ત્યારે પણ માર્ગ કનેક્શન સ્તરે દ્વિદિશ હોવો જોઈએ.

pull એટલે એજન્ટ Subscriber પર રહે છે

pull સબ્સ્ક્રિપ્શન કનેક્શન ઉલટાવે છે: Subscriber જાતે Distribution Agent ચલાવે છે અને Distributor સુધી પહોંચે છે. એ ગોઠવણ એવી VPN નીતિને અનુરૂપ છે જે શાખામાંથી બહાર જતા કનેક્શનને મંજૂરી આપે છે અને અંદર આવતા કનેક્શનને અવરોધે છે. તે સમયપત્રકનો નિર્ણય પણ શાખા સર્વરની સંભાળ રાખનારના હાથમાં મૂકે છે. જ્યારે શાખા ટીમે પોતાનું સિંક્રોનાઇઝેશન ધરાવવું જોઈએ અને પોતાની નિષ્ફળતા જોવી જોઈએ ત્યારે તે પસંદ કરો.

સબ્સ્ક્રાઇબરના SQL Server Agent સર્વિસ એકાઉન્ટને ડિસ્ટ્રિબ્યુશન ડેટાબેઝ અને સ્નેપશોટ શેર પર વાંચવાની પરવાનગી જોઈએ. એ એકાઉન્ટ જ રેપ્લિકેશન ભૂલોમાં દેખાતી ઓળખ છે, અને ડોમેન અધિકાર વગરનું સ્થાનિક સર્વિસ એકાઉન્ટ એવા મુદ્દે નિષ્ફળ જાય છે જે નેટવર્ક ખામી જેવું લાગે પણ વાસ્તવમાં ઓળખપત્ર ખામી છે. ટનલ ડિબગ કરતા પહેલાં એકાઉન્ટ તપાસો. લોગિન સુધારવું સામાન્ય રીતે નેટવર્કને નિર્દોષ સાબિત કરવા કરતાં ઝડપી છે.

માલિકી એજન્ટને અનુસરે છે. જ્યારે કેન્દ્રીય ટીમે સમયપત્રક અને નિષ્ફળતા બંને ધરાવવા જોઈએ ત્યારે push પસંદ કરો. તમે ગમે તે પસંદ કરો, તેને સબ્સ્ક્રિપ્શનની બાજુમાં લખો જેથી આગલા ઇજનેરને ખબર પડે કે પહેલાં ક્યાં જોવું.

ફરી પ્રકાશન ફેલાવો બદલે છે, માલિકી નહીં

સબ્સ્ક્રાઇબરને વધુ સબ્સ્ક્રાઇબરોમાં ફરી પ્રકાશિત કરવા માટે ગોઠવી શકાય છે, જેથી એક શાખા ડેટાબેઝ ઘણા સ્થાનિક ગ્રાહકોને સેવા આપી શકે અને દરેકને WAN દ્વારા ખેંચવું ન પડે. મધ્યમ ડેટાબેઝ હવે એક પ્રકાશન અને પોતાના એજન્ટ ધરાવે છે. તે પહેલાં ન હતા તેવા પરવાનગીઓ, દેખરેખ અને પુનઃપ્રાપ્તિ યોજના પણ વારસામાં મેળવે છે. એ વધારાની ભૂમિકા વારંવારના WAN વિતરણને દૂર કરવાની કિંમત છે.

દસ્તાવેજીકૃત ક્રમ મહત્વપૂર્ણ છે: નીચેના પ્રકાશન બનાવતા પહેલાં આવતા સબ્સ્ક્રિપ્શનને શરૂ કરો. તેને ચકાસણી સાથેના જીવનચક્રના પગલા તરીકે લો, છોડી દેવાના કાગળકામ તરીકે નહીં. તેને ઉલટાવીએ તો એવી સાંકળ બને છે જે ગોઠવેલી લાગે પણ કંઈ પહોંચાડતી નથી.

લેખન મોડેલ સ્પષ્ટ કહો. ફક્ત-વાંચન ડેટાસેટને સ્થાનિક ગ્રાહક સુધી રેપ્લિકેટ કરવું એ ઘણી સાઇટ પર લેખન સ્વીકારવાથી અલગ ડિઝાઇન છે, અને તીરોની સાંકળ સંઘર્ષ નિરાકરણ બનાવતી નથી. જો શાખાએ લખવું જ પડે, તો એ પોતાના ટોપોલોજી સાથેનો અલગ નિર્ણય છે. અવલંબન પણ દૃશ્યમાન કરો: જ્યારે ફરી પ્રકાશક બંધ હોય, ત્યારે તેની નીચેનો દરેક ગ્રાહક જૂનો હોય છે.

સ્થાન શરૂઆતથી અંત સુધી સાબિત કરો

યાદશક્તિ પર ભરોસો કરવાને બદલે ડિસ્ટ્રિબ્યુશન ડેટાબેઝમાંથી સબ્સ્ક્રિપ્શનનો પ્રકાર વાંચો, પછી ચકાસો કે ફેરફારો ખરેખર પહોંચે છે:

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 ની કિંમત 0 એટલે push અને 1 એટલે pull, અને તેને જગ્યાએ બદલી શકાતું નથી, તેથી મેળ ન ખાય તો સબ્સ્ક્રિપ્શન ફરી બનાવવું પડે છે, સંપાદિત કરવું નહીં. બાકી રહેલા આદેશોનો કૉલ તમને કહે છે કે પસંદ કરેલ એજન્ટ કામ ખસેડે છે કે ફક્ત ચાલે છે. જે સબ્સ્ક્રિપ્શન શૂન્ય બાકી આદેશ જણાવે છે અને સબ્સ્ક્રાઇબર ટેબલ ખાલી રહે છે તે વધતા બેકલોગ જણાવતા સબ્સ્ક્રિપ્શનથી અલગ ખામી છે, અને બંને જુદા જુદા માલિકો તરફ દોરે છે.

ખરેખરા ફેરફાર સાથે પૂર્ણ કરો: Publisher પર એક પંક્તિ દાખલ કરો કે અપડેટ કરો, એજન્ટના અહેવાલની રાહ જુઓ અને Subscriber પર એ પંક્તિ વાંચો. એજન્ટ કેવી રીતે સાજો થાય તે જોવા માટે ટૂંકા VPN વિક્ષેપ દરમિયાન ફરી એક વાર કરો. જે સબ્સ્ક્રિપ્શન એ કસોટી પાર કરે છે તેનું એવું સ્થાન છે જે તમે દસ્તાવેજીકૃત કરી શકો અને તેનો બચાવ કરી શકો.