साइट 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 तर्फ जडान खोल्छ। सदस्यको पक्षको सुन्ने, firewall र 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 अवरोधका बीच यो फेरि एकपटक गर्नुहोस्। त्यो परीक्षण पार गर्ने सदस्यताको यस्तो स्थान हुन्छ जुन तपाईंले अभिलेख गर्न र बचाउन सक्नुहुन्छ।