साइट 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 व्यत्ययातून हे अजून एकदा करा। ती चाचणी टिकून राहणाऱ्या सदस्यतेचे असे स्थान आहे जे तुम्ही नोंदवू आणि रक्षण करू शकता।