इस लेख में, हम आपको Windows Server 2019 पर चल रहे SQL Server पर Always On Availability Groups को इंस्टॉल और कॉन्फ़िगर करने के चरण-दर-चरण गाइड के माध्यम से ले जाएंगे, फेलओवर परिदृश्यों पर चर्चा करेंगे, और कुछ अन्य संबंधित विषयों पर।
Always On Availability Groups Microsoft SQL Server में हाई अवेलेबिलिटी प्रदान करते हैं। Always On MSSQL 2012 रिलीज में दिखाई दिया।
SQL Server में Always On Availability Groups की विशेषताएं
आप SQL Server उपलब्धता ग्रुप्स का उपयोग किस लिए कर सकते हैं?
- MS SQL हाई अवेलेबिलिटी और स्वचालित फेलओवर;
- नोड्स के बीच SELECT क्वेरीज़ का लोड बैलेंसिंग (सेकेंडरी रेप्लिकास पठनीय हो सकते हैं);
- सेकेंडरी रेप्लिकास से बैकअप;
- डेटा रिडंडेंसी। प्रत्येक रेप्लिका उपलब्धता ग्रुप डेटाबेस की कॉपी रखता है।
Always On Windows Server Failover Cluster (WSFC) पर आधारित है। WSFC उपलब्धता ग्रुप नोड्स की निगरानी करता है और स्वचालित फेलओवर प्रदान करता है। MS SQL Server 2017 से शुरू होकर, Always On का उपयोग WSFC के बिना और Linux होस्ट्स पर भी किया जा सकता है। Linux-आधारित क्लस्टर बनाते समय, आप WSFC के बजाय Pacemaker का उपयोग कर सकते हैं।
Always On Standard संस्करण में उपलब्ध है, लेकिन इसकी कुछ सीमाएं हैं:
- यह 2 रेप्लिकास (प्राइमरी और सेकेंडरी) तक सीमित है;
- सेकेंडरी रेप्लिका का उपयोग डेटा पढ़ने के लिए नहीं किया जा सकता;
- सेकेंडरी रेप्लिका का उपयोग MS SQL बैकअप के लिए नहीं किया जा सकता;
- प्रति उपलब्धता ग्रुप केवल 1 डेटाबेस समर्थित है।
Enterprise संस्करण में कोई प्रतिबंध नहीं हैं।
MS SQL Server लाइसेंसिंग पहलुओं के बारे में यहाँ पढ़ें।
आइए शर्तों पर विचार करें।
- Always On Availability Group रेप्लिकास और डेटाबेस का एक सेट है;
- Replica उपलब्धता ग्रुप में एक SQL Server इंस्टेंस है। एक रेप्लिका प्राइमरी या सेकेंडरी हो सकता है। प्रत्येक रेप्लिका में एक या अधिक डेटाबेस हो सकते हैं।
Always On WSFC पर आधारित है। प्रत्येक उपलब्धता ग्रुप नोड को Windows फेलओवर क्लस्टर का सदस्य होना चाहिए। प्रत्येक SQL Server इंस्टेंस में कई उपलब्धता ग्रुप हो सकते हैं। प्रत्येक उपलब्धता ग्रुप में अधिकतम 8 सेकेंडरी रेप्लिकास हो सकते हैं।
यदि प्राइमरी रेप्लिका विफल होता है, तो क्लस्टर एक नए प्राइमरी रेप्लिका के लिए वोट करेगा, और Always On सेकेंडरी रेप्लिकास में से एक को प्राइमरी बना देगा। चूंकि उपयोगकर्ता Listener (एक विशेष क्लस्टर IP पता और संबंधित DNS नाम) से कनेक्ट होते हैं जब Always On के साथ काम करते हैं, तो राइट क्वेरीज़ फिर से चलाना संभव हो जाएगा। Listener SELECT क्वेरीज़ को सेकेंडरी रेप्लिकास के बीच संतुलित करने के लिए भी जिम्मेदार है।
Always On Availability Group के लिए Windows फेलओवर क्लस्टर कॉन्फ़िगर करें
सबसे पहले, हमें Always On द्वारा उपयोग किए जाने वाले सभी नोड्स पर फेलओवर क्लस्टर कॉन्फ़िगर करना होगा।
यहाँ मेरा कॉन्फ़िगरेशन है:
- Windows Server 2019 चलाने वाली 2 वर्चुअल मशीन्स
- 2 SQL Server 2019 Enterprise इंस्टेंस
- नोड होस्टनाम testnode1 और testnode2 हैं। SQL Server इंस्टेंस नाम node1 और node2 हैं।
Failover Clustering भूमिका Server Manager का उपयोग करके जोड़ें या PowerShell के माध्यम से इंस्टॉल करें:
Install-WindowsFeature –Name Failover-Clustering –IncludeManagementTools
Failover Cluster Manager स्नैप-इन (FailoverClusters.SnapInHelper.msc) चलाएं और एक नया क्लस्टर बनाएं।
उन होस्ट्स के नाम जोड़ें जिन्हें आप अपने क्लस्टर में जोड़ना चाहते हैं।
फिर विज़ार्ड कुछ टेस्ट लेने की पेशकश करता है। ऐसा करने के लिए, पहला आइटम चुनें।
क्लस्टर नाम निर्दिष्ट करें, एक नेटवर्क चुनें, और एक क्लस्टर IP पता। क्लस्टर नाम स्वचालित रूप से DNS में दिखाई देगा; आपको मैन्युअली DNS रिकॉर्ड बनाने की आवश्यकता नहीं है। मेरे मामले में, क्लस्टर नाम ClusterAG है।
Add all eligible storage to the cluster विकल्प अनचेक करें क्योंकि हम डिस्क बाद में जोड़ सकते हैं।
क्लस्टर में केवल दो नोड्स हैं, इसलिए आपको Cluster Quorum कॉन्फ़िगर करना होगा। Cluster Quorum एक कास्टिंग वोट है। उदाहरण के लिए, यदि क्लस्टर नोड्स में से एक अनुपलब्ध हो जाता है, तो क्लस्टर को पता लगाना होगा कि कौन से नोड्स वास्तव में ऑनलाइन हैं और एक-दूसरे को देख सकते हैं। Cluster Quorum क्लस्टर स्थिरता प्रदान करता है (Cluster -> More Actions -> Configure Cluster Quorum Settings)।
Quorum विटनेस विकल्प चुनें।
फिर विटनेस प्रकार चुनें: एक फ़ाइल शेयर विटनेस।
साझा फ़ोल्डर का UNC पथ निर्दिष्ट करें। डायरेक्टरी स्वयं बनाएं। यह आपके फेलओवर क्लस्टर के बाहर एक सर्वर पर मौजूद होनी चाहिए।
जब आप अपना क्लस्टर कॉन्फ़िगर करते हैं, तो आपको निम्न त्रुटि दिखाई दे सकती है:
There was an error configuring the file share witness. Unable to save property changes for File Share Witness. The system cannot find the file specified.
इसकी संभावना है कि जिस उपयोगकर्ता खाते के तहत क्लस्टर चल रहा है, उसके पास साझा फ़ोल्डर तक पहुंचने के लिए NTFS अनुमतियां नहीं हैं। डिफ़ॉल्ट रूप से, क्लस्टर एक लोकल उपयोगकर्ता खाते के तहत चल रहा है। आप फ़ोल्डर पर सभी क्लस्टर कंप्यूटर्स को विशेषाधिकार दे सकते हैं या क्लस्टर सर्विस के लिए खाता बदल सकते हैं और इसे प्रासंगिक विशेषाधिकार दे सकते हैं।
बुनियादी Windows Failover Cluster कॉन्फ़िगरेशन पूरा हो गया है।
MS SQL Server पर Always On Availability Group कॉन्फ़िगर करना
ठेठ SQL Server इंस्टेंस इंस्टॉलेशन के बाद, आप Always On Availability Groups को सक्षम और कॉन्फ़िगर कर सकते हैं। SQL Server Configuration Manager के इंस्टेंस गुणों में उन्हें सक्षम करें। जैसा कि आप स्क्रीनशॉट में देख सकते हैं, SQL Server ने पहले ही पता लगा लिया है कि यह WSFC क्लस्टर से संबंधित है। Enable Always On Availability Groups चेक करें और MSSQL इंस्टेंस सर्विस रीस्टार्ट करें। दूसरे इंस्टेंस के लिए भी ऐसा ही करें।
टिप। Always On कॉन्फ़िगरेशन से पहले, सुनिश्चित करें कि SQL Server सर्विसेज लोकल सिस्टम अकाउंट के तहत नहीं चल रही हैं। Group Managed Service Accounts या सामान्य डोमेन अकाउंट का उपयोग करने की सिफारिश की जाती है। अन्यथा, आप Always-On कॉन्फ़िगरेशन पूरा नहीं कर पाएंगे।
SQL Server Management Studio चलाएं, अपने होस्ट से कनेक्ट करें, Always On High Availability, पर क्लिक करें, और New Availability Group Wizard. चलाएं।
SQL Server Management Studio 18.x में SQL Server 2017 और SQL Server 2019 के लिए कुछ Always On सेटिंग्स दिखाई दीं जो पहले केवल T-SQL में उपलब्ध थीं, इसलिए नवीनतम SSMS संस्करण का उपयोग करने की सिफारिश की जाती है।
अपने Always On उपलब्धता ग्रुप के लिए एक नाम निर्दिष्ट करें और Database Level Health Detection चुनें। इस विकल्प का उपयोग करके, Always On यह पता लगा सकेगा कि डेटाबेस कब अनहेल्दी है।
अपने Always On उपलब्धता ग्रुप में जोड़ने के लिए SQL Server डेटाबेस चुनें।
Add Replica पर क्लिक करें और दूसरा SQL सर्वर कनेक्ट करें। इस प्रकार आप 8 सर्वर तक जोड़ सकते हैं।
- Initial Role ग्रुप बनने के समय रेप्लिका भूमिका है। यह प्राइमरी या सेकेंडरी हो सकता है;
- Automatic Failover – यदि डेटाबेस अनुपलब्ध हो जाता है, तो Always On प्राइमरी भूमिका को दूसरे रेप्लिका पर ले जाएगा। इस आइटम को चेक करें;
- Availability Mode आपको Synchronous Commit या Asynchronous Commit चुनने की अनुमति देता है। यदि आप सिंक्रोनस मोड चुनते हैं, तो प्राइमरी रेप्लिका पर आने वाले ट्रांजेक्शन्स को सिंक्रोनस मोड वाले अन्य सभी सेकेंडरी रेप्लिकास को भेजा जाएगा। प्राइमरी रेप्लिका ट्रांजेक्शन को तभी समाप्त करता है जब अन्य रेप्लिकास ने इसे डिस्क पर लिख दिया हो। इस प्रकार, यदि प्राइमरी रेप्लिका विफल होता है तो डेटा हानि समाप्त हो जाती है। असिंक्रोनस मोड में, प्राइमरी रेप्लिका अन्य रेप्लिकास के जवाब की प्रतीक्षा किए बिना तुरंत परिवर्तन लिखता है।
- Readable Secondary एक पैरामीटर है जो सेकेंडरी रेप्लिकास के विरुद्ध SELECT क्वेरीज़ चलाने की अनुमति देता है। यदि मान yes है, तो क्लाइंट्स
ApplicationIntent=readonlyके बिना भी रीड-ओनली एक्सेस प्राप्त कर सकेंगे। - Required synchronized secondaries to commit ट्रांजेक्शन समाप्त करने के लिए सिंक्रोनाइज़्ड सेकेंडरी रेप्लिकास की संख्या है। रेप्लिकास की संख्या के आधार पर इसे सेट करें, मैं इसे 1 पर सेट करूंगा।
Endpoint टैब में कुछ भी संपादित न करें।
Backup Preferences टैब में, आप चुन सकते हैं कि बैकअप कहाँ से लिए जाएंगे। यहाँ डिफ़ॉल्ट सेटिंग्स छोड़ दें: Prefer Secondary।
उपलब्धता ग्रुप लिसनर का नाम, पोर्ट, और IP पता निर्दिष्ट करें।
Read-Only Routing सेटिंग्स अपरिवर्तित छोड़ दें।
रेप्लिका सिंक्रोनाइज़ेशन प्रकार चुनें। मैं पहला आइटम (Automatic seeding) चेक्ड छोड़ दूंगा।
फिर आपकी सेटिंग्स मान्य होनी चाहिए। यदि कोई त्रुटि नहीं है, तो परिवर्तन लागू करने के लिए Finish पर क्लिक करें।
मेरे मामले में, सभी टेस्ट सफल रहे, लेकिन इंस्टॉलेशन के बाद Results चरण में, विज़ार्ड ने उपलब्धता ग्रुप लिसनर बनाने की त्रुटि दिखाई। क्लस्टर इवेंट लॉग्स में EVENTID 1194 त्रुटि दिखाई दी:
Cluster network name resource failed to create its associated computer object in the domain.
इसका मतलब है कि क्लस्टर के पास लिसनर बनाने के लिए पर्याप्त अनुमतियां नहीं हैं। दस्तावेज़ीकरण में कहा गया है कि आपके क्लस्टर के ऑब्जेक्ट को कंप्यूटर-प्रकार के ऑब्जेक्ट बनाने का विशेषाधिकार देना पर्याप्त है। AD में विशेषाधिकार प्रतिनिधिमंडल का उपयोग करके ऐसा करना आसान है (या एक त्वरित, लेकिन असुरक्षित विकल्प CLUSTERAG$ ऑब्जेक्ट को अस्थायी रूप से Domain Admins ग्रुप में जोड़ना है)।
Always-On और उपलब्धता ग्रुप में कम SQL प्रदर्शन मुद्दों का निदान करते समय, आपको मानक SQL Server डायग्नोस्टिक टूल्स का उपयोग करने के अलावा Windows क्लस्टर लॉग्स का गहन अध्ययन करना चाहिए।
चूंकि मैंने उपलब्धता ग्रुप बना लिया है, लेकिन लिसनर नहीं, मैंने इसे मैन्युअली जोड़ा। अपने उपलब्धता ग्रुप के लिए संदर्भ मेनू खोलें और Add Listener पर क्लिक करें।
लिसनर का IP पता, पोर्ट, और DNS नाम निर्दिष्ट करें।
सुनिश्चित करें कि लिसनर आपके Always On ग्रुप के Availability Group Listeners खंड में दिखाई दिया है।
इस प्रकार, आपने Always On उपलब्धता ग्रुप की बुनियादी कॉन्फ़िगरेशन पूरी कर ली है।
SQL Server Always On: संचालन जांच और फेलओवर
आइए Availability Group Dashboard (Show Dashboard) पर नज़र डालें।
यह OK है, ग्रुप बनाया गया है और काम कर रहा है।
आइए node2 को मैन्युअली प्राइमरी इंस्टेंस बनाने का प्रयास करें। उपलब्धता ग्रुप पर राइट-क्लिक करें और Failover चुनें।
Failover Readiness में मान नोट करें। No data loss का मतलब है कि कोई डेटा खोया नहीं जाएगा।
node2 से कनेक्ट करें।
Finish पर क्लिक करें।
सुनिश्चित करें कि node2 उपलब्धता ग्रुप में प्राइमरी रेप्लिका (Primary Instance) बन गया है।
सुनिश्चित करें कि लिसनर सही ढंग से काम कर रहा है। SSMS में लिसनर DNS नाम और पोर्ट को कॉमा से अलग करके निर्दिष्ट करें: ag1-listener-1,1445
अपने डेटाबेस पर साधारण insert, select और update SQL क्वेरीज़ चलाएं।
फिर प्राइमरी रेप्लिका के स्वचालित फेलओवर की जांच करें। बस TESTNODE2 पर sqlservr.exe प्रोसेस को मार दें।
शेष नोड पर उपलब्धता ग्रुप स्थिति जांचें: TESTNODE1\NODE1।
क्लस्टर ने स्वचालित रूप से testnode1\node1 स्थिति को प्राइमरी में बदल दिया क्योंकि testnode2\node2 अनुपलब्ध हो गया।
लिसनर स्थिति जांचें क्योंकि क्लाइंट इससे कनेक्ट करने के लिए इसका उपयोग करेंगे।
मेरे मामले में, मैं लिसनर से सफलतापूर्वक कनेक्ट हुआ, लेकिन डेटाबेस तक पहुंचने का प्रयास करते समय, मुझे यह त्रुटि मिली:
Unable to access database 'TestDatabase' because it lacks a quorum of nodes for high availability. Try the operation again later.
यह त्रुटि Required synchronized secondaries to commit विकल्प के कारण दिखाई दी। चूंकि हमने इसे कॉन्फ़िगर करते समय इसका मान 1 पर सेट किया था, Always On डेटाबेस से कनेक्ट करने की अनुमति नहीं देता, क्योंकि हमारे पास केवल एक प्राइमरी रेप्लिका बचा है।
मान को 0 पर सेट करें और क्वेरी फिर से चलाने का प्रयास करें।
Testnode1 ने प्राइमरी इंस्टेंस स्थिति बरकरार रखी, जबकि testnode2 सेकेंडरी बन गया। जब कंप्यूटर चालू किया गया तो टेस्टनोड1 पर हमारे द्वारा किए गए परिवर्तन टेस्टनोड2 बंद होने के बाद सफलतापूर्वक सिंक्रोनाइज़ हो गए।
तो, हमने सुनिश्चित किया कि सब कुछ सही ढंग से काम करता है और डेटा क्रिटिकल विफलता के मामले में रीड/राइट के लिए उपलब्ध होगा।
आप Always On उपलब्धता ग्रुप्स को आसानी से कॉन्फ़िगर कर सकते हैं। यदि आप SQL Server-आधारित फेलओवर समाधान बनाना चाहते हैं, तो उपलब्धता ग्रुप्स इसे अच्छी तरह से प्रबंधित करेंगे।
