साइट 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 रुकावट के दौरान इसे एक बार और करें ताकि देख सकें कि एजेंट कैसे सुधरता है। जो सदस्यता उस परीक्षण को झेल जाती है, उसका स्थान ऐसा है जिसे आप प्रलेखित और बचा सकते हैं।