SQL सर्वर हमेशा उपलब्धता समूह पर SQL सर्वर डेटाबेस के लिए उच्च उपलब्धता और आपदा पुनर्प्राप्ति प्राप्त करने के लिए एक समाधान है। हम इस कार्यक्षमता को विंडोज-आधारित SQL सर्वर इंस्टॉलेशन, लिनक्स-आधारित SQL सर्वर इंस्टॉलेशन और यहां तक कि लिनक्स और विंडोज-आधारित SQL सर्वर इंस्टॉलेशन के बीच भी कॉन्फ़िगर कर सकते हैं।
उपलब्धता समूहों को क्लस्टर प्रौद्योगिकियों के साथ स्वचालित विफलता और डेटा सुरक्षा के रूप में उनके संबंधित माध्यमिक प्रतिकृतियों में डेटा की प्रतिलिपि बनाकर मजबूती से एकीकृत किया जाता है। हालांकि, उपलब्धता समूहों को कॉन्फ़िगर करने के लिए क्लस्टर संसाधन प्रबंधक का होना हमेशा अनिवार्य नहीं होता है।
SQL सर्वर उपलब्धता समूहों को कॉन्फ़िगर करने के लिए, हमें WSFC की आवश्यकता है - Windows सर्वर फ़ेलओवर क्लस्टर Windows . के लिए प्रौद्योगिकी -आधारित SQL सर्वर संस्थापन और पेसमेकर लिनक्स . के लिए -आधारित SQL सर्वर संस्थापन।
पेसमेकर एक ओपन-सोर्स क्लस्टर संसाधन प्रबंधक है जिसका उपयोग हम संसाधनों के प्रबंधन और सिस्टम की उपलब्धता सुनिश्चित करने के लिए कर सकते हैं, यदि लिनक्स सिस्टम पर कोई विफलता होती है।
डब्ल्यूएसएफसी Windows-आधारित क्लस्टर आवश्यकताओं का समर्थन करने के लिए विकसित एक Microsoft उत्पाद है।
जब आप दोनों प्रकार के OS के लिए SQL सर्वर के भीतर कॉन्फ़िगर किए गए उपलब्धता समूहों को देखते हैं, तो यह SQL सर्वर प्रबंधन स्टूडियो में समान लगता है।
हालांकि, यह आलेख उबंटू लिनक्स-आधारित SQL सर्वर के बीच उपलब्धता समूहों की व्याख्या करता है पेसमेकर . का उपयोग कर इंस्टॉलेशन क्लस्टर तकनीक इसलिए मैं केवल इस कॉन्फ़िगरेशन पर विचार करूंगा।
क्लस्टर प्रकार कॉन्फ़िगरेशन
जैसा कि मैंने ऊपर कहा है, हमारे पास OS के आधार पर SQL सर्वर के लिए उपलब्धता समूहों को कॉन्फ़िगर करने के लिए तीन प्रकार हैं:
- Windows-आधारित SQL सर्वर स्थापनाओं के बीच;
- लिनक्स-आधारित SQL सर्वर स्थापनाओं के बीच;
- मिश्रित प्रकार के Windows और Linux-आधारित SQL सर्वर स्थापनाओं के बीच।
Microsoft ने Cluster_type . पेश किया है उपलब्धता समूहों के लिए उपयुक्त क्लस्टर तकनीक को पहचानने और कॉन्फ़िगर करने के लिए कॉन्फ़िगरेशन सेटिंग। यह एक कॉन्फ़िगरेशन आइटम है जो परिभाषित करता है कि हम उपलब्धता समूहों के लिए किस प्रकार की क्लस्टर तकनीक का उपयोग करते हैं, इससे कोई फर्क नहीं पड़ता कि SQL सर्वर इंस्टेंस किस OS पर आधारित है।
आप SQL सर्वर डायनामिक मैनेजमेंट व्यू (DMV) sys.availability_groups का उपयोग करके क्लस्टर प्रकार के मौजूदा कॉन्फ़िगरेशन को प्राप्त और सत्यापित कर सकते हैं। . cluster_type . नाम के दो कॉलम हैं और cluster_type_desc . उपलब्धता समूह सेटअप के क्लस्टर प्रकार कॉन्फ़िगरेशन को परिभाषित करने के लिए हम इन स्तंभों को पढ़ सकते हैं।
इस कॉन्फ़िगरेशन सेटिंग में प्रत्येक प्रकार के लिए क्लस्टर प्रौद्योगिकी आवश्यकताओं को पूरा करने के लिए 3 मान हैं:
डब्ल्यूएसएफसी .यदि आपके पास Windows-आधारित SQL सर्वर संस्थापन है, तो आपको WSFC (Windows सर्वर फ़ेलओवर क्लस्टर) विकल्प का उपयोग करना चाहिए। यह Linux-आधारित SQL सर्वर संस्थापन के लिए समर्थित नहीं है।
बाहरी . यदि आप Linux-आधारित SQL सर्वर स्थापनाओं के बीच उपलब्धता समूहों को कॉन्फ़िगर कर रहे हैं, तो आपको PACEMAKER क्लस्टर प्रबंधक का उपयोग करना चाहिए और बाहरी चुनना चाहिए। क्लस्टर टाइप करें . फ़ेलओवर मोड भी बाहरी होना चाहिए (WSFC में यह स्वचालित होगा)।
कोई नहीं . यदि आप अपने उपलब्धता समूहों के लिए किसी क्लस्टरिंग तकनीक का उपयोग नहीं करना चाहते हैं, तो कोई नहीं चुनें . यदि आप उपलब्धता समूहों को Linux और Windows-आधारित SQL सर्वर इंस्टेंस के बीच कॉन्फ़िगर करना चाहते हैं तो यह विकल्प लागू होता है। भले ही आपने अपने सिस्टम के लिए क्लस्टरिंग कॉन्फ़िगर किया हो, एक बार जब आप क्लस्टर प्रकार मान को NONE पर सेट कर देते हैं, तो उपलब्धता समूह क्लस्टर तकनीक का उपयोग नहीं करेंगे। क्लस्टर प्रकार NONE के लिए फ़ेलओवर मोड हमेशा मैन्युअल होता है ।
एक नई सेटिंग:प्रतिबद्ध करने के लिए आवश्यक सिंक्रनाइज़ सेकेंडरी
SQL सर्वर 2017 से शुरू होकर, Microsoft ने required_synchronized_secondaries_to_commit नामक एक नई सेटिंग पेश की है। . यदि आपने PACEMAKER क्लस्टर कॉन्फ़िगरेशन के लिए क्लस्टर प्रकार को EXTERNAL के रूप में कॉन्फ़िगर किया है, तो यह स्वचालित फ़ेलओवर विकल्प को सक्षम करता है।
जब आप SQL सर्वर संसाधन एजेंट mssql-server-ha को कॉन्फ़िगर करते हैं तो इस सेटिंग का मान डिफ़ॉल्ट रूप से सेट होता है और क्लस्टर कॉन्फ़िगरेशन बनाएं।
साथ ही, आप नीचे दिए गए आदेश को चलाकर अपनी आवश्यकताओं के लिए मान को मैन्युअल रूप से संशोधित कर सकते हैं:
--Run below commands to change value for setting required_synchronized_secondaries_to_commit
--AGResourceName is the name of the resource configured for the Availability group
sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<Value>
नोट:हम उपरोक्त सेटिंग को केवल Linux पर पेसमेकर के माध्यम से बदल सकते हैं। Linux-आधारित परिनियोजन के लिए T-SQL कथन का उपयोग करके इसे संशोधित करना असंभव है। हालाँकि, Windows-आधारित परिनियोजन के लिए, हम इस सेटिंग को T-SQL कथन द्वारा बदल सकते हैं।
required_synchronized_secondaries_to_commit के लिए संभावित मान नीचे दिए गए हैं
0 – इसका मतलब है कि माध्यमिक प्रतिकृतियों को संबंधित प्राथमिक प्रतिकृति के साथ सिंक्रनाइज़ करने की आवश्यकता नहीं है। इस प्रकार, यह स्वचालित विफलता का समर्थन नहीं करता है। यदि प्राथमिक प्रतिकृति नीचे जाती है, तो आपको मैन्युअल रूप से विफलता आरंभ करने की आवश्यकता है। महत्वपूर्ण:जब आप इस मान को कॉन्फ़िगरेशन के लिए चुनते हैं तो डेटा हानि की संभावना होती है।
1 – इसका मतलब है कि स्वचालित विफलता प्राप्त करने के लिए कम से कम एक माध्यमिक प्रतिकृति सिंक्रनाइज़ स्थिति में होनी चाहिए।
2 – इसका मतलब है कि दोनों माध्यमिक प्रतिकृतियों को प्राथमिक प्रतिकृति के साथ सिंक्रनाइज़ किया जाना चाहिए। स्वचालित विफलता समर्थित है।
उपलब्धता समूह में भाग लेने के लिए प्रतिकृतियां
उपलब्धता समूह में भाग लेने वाले प्रतिकृतियों की संख्या स्थापित SQL सर्वर संस्करण पर निर्भर करती है।
- एसक्यूएल सर्वर मानक संस्करण केवल दो-नोड प्रतिकृति का समर्थन करता है अतिरिक्त कॉन्फ़िगरेशन-केवल प्रतिकृति के साथ उपलब्धता समूह के लिए।
- एसक्यूएल सर्वर उद्यम संस्करण नौ तक . का समर्थन करता है प्रतिकृतियां - एक प्राथमिक और आठ माध्यमिक प्रतिकृतियां।
चूंकि SQL सर्वर मानक संस्करण केवल दो प्रतिकृतियों (एक प्राथमिक प्रतिकृति और एक द्वितीयक प्रतिकृति) का समर्थन करता है, Microsoft ने केवल-कॉन्फ़िगरेशन प्रतिकृति नामक एक नई अवधारणा पेश की है। SQL सर्वर 2017 CU1 में Linux सिस्टम पर चलने वाले SQL सर्वर के लिए स्वचालित विफलता प्राप्त करने के लिए।
दो संभावित डिज़ाइन विकल्प हैं:
- तीन समकालिक प्रतिकृतियां। यह कॉन्फ़िगरेशन केवल SQL सर्वर एंटरप्राइज़ संस्करण के साथ परिनियोजित किया जा सकता है। आपके उपलब्धता डेटाबेस की 3 प्रतियां होंगी। यह आर्किटेक्चर सभी 3 कार्यात्मकताओं को रीड-स्केल, उच्च उपलब्धता और डेटा सुरक्षा की अनुमति देता है।
- दो समकालिक प्रतिकृतियां और एक केवल-कॉन्फ़िगरेशन प्रतिकृति। आप SQL सर्वर मानक संस्करण की सहायता से इस डिज़ाइन को कॉन्फ़िगर कर सकते हैं, SQL सर्वर मानक संस्करण पर दो सिंक्रोनस प्रतिकृतियां और SQL सर्वर एक्सप्रेस संस्करण पर 3 प्रतिकृति चला रहे हैं जो केवल कॉन्फ़िगरेशन प्रतिकृति के रूप में कार्य करता है। यह एक लागत प्रभावी डिज़ाइन है जो स्वचालित विफलता और डेटाबेस सुरक्षा के साथ उच्च उपलब्धता का समर्थन करता है।
दो-नोड प्रतिकृति
दो-नोड प्रतिकृति कॉन्फ़िगरेशन उपलब्धता समूहों के लिए SQL सर्वर डेटाबेस की उच्च उपलब्धता सुनिश्चित करने के लिए एक बहुत लोकप्रिय परिनियोजन विकल्प है। हम Windows सर्वर फ़ेलओवर क्लस्टर तकनीक और Windows-आधारित SQL सर्वर परिनियोजन में एक फ़ाइल साझा गवाह की सहायता से स्वचालित फ़ेलओवर प्राप्त करते हैं।
फ़ाइल साझा आम तौर पर दो-नोड प्रतिकृति कॉन्फ़िगरेशन के लिए कोरम कॉन्फ़िगरेशन प्रदान करने के लिए WSFC में एक अतिरिक्त नोड पर उपयोग किया जाता है। WSFC सभी कॉन्फ़िगरेशन मेटाडेटा को प्रतिकृतियों और तीसरे नोड या फ़ाइल साझा गवाह दोनों के लिए सुचारू विफलता के लिए सिंक्रनाइज़ करता है। Windows-आधारित SQL सर्वर उपलब्धता समूह के लिए सभी फ़ेलओवर मध्यस्थता WSFC परत पर होती है।
यदि हम Linux-आधारित SQL सर्वर उपलब्धता समूह परिनियोजन के लिए स्वचालित विफलता प्राप्त करना चाहते हैं, तो उपरोक्त कॉन्फ़िगरेशन काम नहीं करेगा। ऐसा इसलिए है क्योंकि WSFC का उपयोग केवल Windows-आधारित SQL सर्वर स्थापनाओं के लिए किया जा सकता है।
इस सीमा को दूर करने और Linux-आधारित दो-प्रतिकृति परिनियोजन के लिए स्वचालित विफलता को सक्षम करने के लिए, Microsoft ने एक नई अवधारणा पेश की है।
कॉन्फ़िगरेशन-केवल प्रतिकृति
कॉन्फ़िगरेशन-केवल प्रतिकृति एक विकल्प है जहां हम तीसरे नोड पर SQL सर्वर का एक अतिरिक्त उदाहरण स्थापित करते हैं। वह नोड स्वचालित विफलता का समर्थन करने के लिए दो-नोड प्रतिकृति कॉन्फ़िगरेशन के लिए एक गवाह सर्वर के रूप में काम करेगा। हम प्रति उपलब्धता समूह के लिए केवल एक कॉन्फ़िगरेशन-प्रतिकृति बना सकते हैं ।
Linux-आधारित SQL सर्वर इंस्टेंस के लिए जहां हम PACEMAKER के लिए बाहरी के रूप में क्लस्टर प्रकार का उपयोग करते हैं, विफलता मध्यस्थता WSFC की तरह क्लस्टर परत पर काम नहीं करती है। सभी फ़ेलओवर मध्यस्थता SQL सर्वर परत पर होती है क्योंकि सभी उपलब्धता समूह कॉन्फ़िगरेशन मेटाडेटा प्रत्येक प्रतिकृति के मास्टर डेटाबेस में संग्रहीत होता है।
Microsoft ने Linux-आधारित SQL सर्वर उपलब्धता समूहों के लिए कोरम को संभालने के लिए केवल-कॉन्फ़िगरेशन प्रतिकृति अवधारणा पेश की है। यह अवधारणा उपलब्धता समूह में भाग लेने के लिए किसी उपयोगकर्ता डेटाबेस को होस्ट नहीं करती है। यह सुनिश्चित करने के लिए मास्टर डेटाबेस में सभी उपलब्धता समूह कॉन्फ़िगरेशन जानकारी संग्रहीत करता है कि सभी विफलता मध्यस्थता सुचारू रूप से होती है।
आप केवल-कॉन्फ़िगरेशन प्रतिकृति के लिए SQL सर्वर के किसी भी संस्करण का उपयोग कर सकते हैं। यहां तक कि SQL सर्वर एक्सप्रेस संस्करण भी तीसरी प्रतिकृति के लिए आपकी लाइसेंस लागत को बचाने के लिए उपयुक्त होगा। याद रखें, केवल-कॉन्फ़िगरेशन प्रतिकृति उपलब्धता समूह के भीतर किसी डेटाबेस को होस्ट नहीं करेगी। इस प्रकार, आपके पास उपलब्धता समूह में डेटाबेस की केवल दो प्रतियां होंगी।
डिफ़ॉल्ट रूप से, required_synchronized_secondaries_to_commit 0 . पर सेट है जब हम कॉन्फ़िगरेशन-केवल प्रतिकृति का उपयोग करते हैं। यदि आवश्यक हो तो हम इस मान को मैन्युअल रूप से 1 में संशोधित कर सकते हैं।
स्वचालित विफलता और डेटा सुरक्षा प्राप्त करने के लिए दो-नोड सिंक्रोनस प्रतिकृति के डिज़ाइन आरेख और कॉन्फ़िगरेशन-केवल प्रतिकृति पर एक नज़र डालें।
हम देख सकते हैं कि AOAGVM1, AOAGVM2 और AOAGVM3 नाम के 3 VM हैं। वे सभी उबंटू लिनक्स सिस्टम द्वारा चल रहे हैं, और एसक्यूएल सर्वर तीनों लिनक्स सिस्टम पर कॉन्फ़िगर किया गया है। उपलब्धता डेटाबेस AOAGVM1 और AOAGVM2 पर होस्ट किए जाते हैं।
AOAGVM1 एक प्राथमिक प्रतिकृति के रूप में कार्य कर रहा है, जबकि AOAGVM2 एक द्वितीयक प्रतिकृति है। AOAGVM3 केवल कॉन्फ़िगरेशन प्रतिकृति के रूप में कार्य करता है, जो SQL सर्वर एक्सप्रेस संस्करण है। इस तीसरी प्रतिकृति पर कोई उपयोगकर्ता डेटाबेस होस्ट नहीं किया गया है।
पेसमेकर क्लस्टर को Linux-आधारित उपलब्धता समूह कॉन्फ़िगरेशन के लिए क्लस्टर तकनीक का समर्थन करने के लिए सभी तीन नोड्स के बीच कॉन्फ़िगर किया गया है।
उपरोक्त डिज़ाइन को कॉन्फ़िगर या कार्यान्वित करने के लिए, हमें निम्नलिखित चरणों का पालन करने की आवश्यकता है:
- तीन उबंटू सिस्टम पर SQL सर्वर स्थापित करें (SQL सर्वर एक्सप्रेस संस्करण केवल-कॉन्फ़िगरेशन प्रतिकृति के लिए उपयुक्त होगा)।
- उपलब्धता समूहों को तीन नोड्स के बीच कॉन्फ़िगर करें।
- पेसमेकर क्लस्टर को तीन नोड्स के बीच कॉन्फ़िगर करें।
- उपलब्धता समूह को क्लस्टर समूह में संसाधन के रूप में जोड़ें या एकीकृत करें।
चरण 1 को पूरा करने के लिए संबंधित आलेख पर एक नज़र डालें (तीन नोड्स पर SQL सर्वर इंस्टेंस स्थापित करना)।
मेरे अगले लेख के लिए बने रहें जहाँ मैं उपरोक्त डिज़ाइन को लागू करने के लिए चरण-दर-चरण प्रक्रिया की व्याख्या करूँगा। हमारा लक्ष्य 2-नोड सिंक्रोनस प्रतिकृति और कॉन्फ़िगरेशन-केवल प्रतिकृति का उपयोग करके स्वचालित विफलता और डेटा सुरक्षा प्राप्त करना होगा।
इस मामले पर आपके विचार और व्यावहारिक सुझाव सुनकर हमें खुशी होगी। बेझिझक उन्हें टिप्पणी अनुभाग में साझा करें।
