हाय सब लोग और आपकी मदद के लिए अग्रिम धन्यवाद। हम SQL सर्वर 2017 उपलब्धता समूहों के साथ चुनौतियों का सामना कर रहे हैं।
पृष्ठभूमि
कंपनी एक खुदरा बी 2 बी बैक-एंड सॉफ्टवेयर है। लगभग 500 एकल किरायेदार डेटाबेस और 5 साझा डेटाबेस सभी किरायेदारों द्वारा उपयोग किए जाते हैं। वर्कलोड की विशेषता ज्यादातर पढ़ी जाती है, और अधिकांश डेटाबेस में बहुत कम गतिविधि होती है।
सह-स्थान पर होस्ट किए गए भौतिक उत्पादन सर्वर हाल ही में एक साझा SAN / FCI कॉन्फ़िगरेशन में SQL Server 2014 एंटरप्राइज़ से Windows Server 2012 में अपग्रेड किए गए थे, 2 सॉकेट / 32 कोर / 768 GB रैम और स्थानीय पर SQL Server 2017 एंटरप्राइज़ Windows Server 2016 पर ऑलसेन एजी का उपयोग कर एसएसडी ड्राइव। एजी ट्रैफ़िक एक पार किए गए केबल कनेक्शन के साथ समर्पित 10G एनआईसी पोर्ट का उपयोग करता है।
उनकी आवश्यकता सभी डेटाबेस के लिए एक साथ विफलता के लिए है, इसलिए उन्हें उन सभी को एक ही एजी में रखना पड़ा। यह एक समान सर्वर पर एक एकल, गैर-पठनीय सिंक्रोनस प्रतिकृति है।
नए सर्वर जून 2018 से उत्पादन में हैं। नवीनतम सीयू (उस समय सीयू 7) और विंडोज अपडेट इंस्टॉल किए गए थे, और सिस्टम अच्छी तरह से काम कर रहा था। लगभग एक महीने बाद, CU7 से CU9 तक के सर्वरों को अपडेट करने के बाद, उन्होंने प्राथमिकता के क्रम में सूचीबद्ध निम्नलिखित चुनौतियों को नोट करना शुरू कर दिया।
हम SQL संतरी का उपयोग कर सर्वर की निगरानी कर रहे हैं और कोई शारीरिक अड़चन नहीं देखी गई है। सभी प्रमुख संकेतक अच्छे लगते हैं। CPU औसतन 20% है, IO समय आमतौर पर 1ms से कम है, RAM पूरी तरह से उपयोग नहीं किया गया है, और नेटवर्क <1%।
चुनौतियां
असफलता के बाद लक्षण बेहतर होने लगते हैं, लेकिन कुछ दिनों के भीतर वापस आ जाते हैं, इस बात की परवाह किए बिना कि सर्वर प्राथमिक है - लक्षण दोनों सर्वरों पर समान हैं।
छिटपुट ग्राहक समय बहिष्कार और कनेक्टिविटी विफलताओं जैसे कि
... कनेक्शन स्थापित करते समय त्रुटि आई ...
या
निष्पादन समय समाप्त हो गया
कभी-कभी ये 40 सेकंड तक चलते हैं, और फिर कम हो जाते हैं।
लेन-देन लॉग बैकअप कार्य पहले की तुलना में 10X अधिक समय लेता है। पहले सभी 500 डेटाबेस के लॉग का बैकअप लेने में 2 - 3 मिनट लगते थे, अब इसमें 15-25 लगते हैं। हमने यह सत्यापित किया है कि बैकअप स्वयं अच्छे थ्रूपुट के साथ ठीक चलता है। हालांकि, एक लॉग का बैकअप पूरा करने के बाद, और अगला शुरू करने से पहले एक छोटी सी देरी है। यह बहुत कम शुरू होता है, लेकिन एक या दो दिनों के भीतर 2-3 सेकंड तक हो जाता है। 500 डेटाबेस से गुणा किया जाता है, और अंतर होता है।
कभी-कभी, कुछ प्रतीत होता है यादृच्छिक डेटाबेस मैन्युअल विफलता के बाद "सिंक्रनाइज़ेशन नहीं" स्थिति में फंस जाते हैं। इसका समाधान करने का एकमात्र तरीका द्वितीयक प्रतिकृति पर या तो SQL सर्वर सेवा को पुनरारंभ करना है, या इन डेटाबेस को एजी में फिर से निकालना और फिर से जोड़ना है।
CU10 द्वारा शुरू किया गया एक अन्य मुद्दा (और CU11 में हल नहीं किया गया है): Master.sys.dat डेटाबेस पर अवरुद्ध करने पर माध्यमिक समय-समय पर कनेक्शन और यहां तक कि माध्यमिक प्रतिकृति के लिए SSMS ऑब्जेक्ट एक्सप्लोरर का उपयोग करने में असमर्थ। मूल कारण Microsoft SQL Server VSS लेखक द्वारा निम्नलिखित क्वेरी जारी करने से अवरुद्ध होता है:
select name, recovery_model_desc, state_desc, CONVERT(integer, is_in_standby), ISNULL(source_database_id,0) from master.sys.databases
टिप्पणियों
मेरा मानना है कि मुझे त्रुटि लॉग में धूम्रपान बंदूक मिली। त्रुटि लॉग एजी संदेशों से भरे हुए हैं, जिन्हें 'केवल सूचनात्मक' के रूप में लेबल किया गया है, लेकिन ऐसा लगता है कि वे बिल्कुल भी सामान्य नहीं हैं, और अनुप्रयोग त्रुटियों के लिए उनकी आवृत्ति का बहुत मजबूत संबंध है।
त्रुटियां कई प्रकार की होती हैं, और क्रम में आती हैं:
DbMgrPartnerCommitPolicy :: SetSyncState: GUID
DbMgrPartnerCommitPolicy :: SetSyncAndRecoveryPoint: GUID
हमेशा उपलब्धता समूह के साथ द्वितीयक डेटाबेस कनेक्शन प्राथमिक प्रतिकृति के लिए प्राथमिक डेटाबेस 'एक्सवाईजेड' के लिए समाप्त होता है, प्रतिकृति आईडी के साथ 'डीबी': {GUID}। यह केवल सूचनात्मक संदेश है। कोई उपयोगकर्ता कार्रवाई की आवश्यकता नहीं है।
हमेशा उपलब्धता समूह प्रतिकृति के साथ प्राथमिक डेटाबेस 'एबीसी' के लिए स्थापित द्वितीयक डेटाबेस के साथ कनेक्शन प्रतिकृति आईडी: {GUID}। यह केवल सूचनात्मक संदेश है। कोई उपयोगकर्ता कार्रवाई की आवश्यकता नहीं है।
कुछ दिनों में उन हजारों में से 10 हैं।
यह लेख SQL 2016 पर त्रुटियों के अनुक्रम के उसी प्रकार पर चर्चा करता है और वहाँ यह असामान्य है। यह भी विफलता के बाद 'गैर-सिंक्रनाइज़िंग' घटना की व्याख्या करता है। इस मुद्दे पर चर्चा 2016 के लिए हुई थी और इस साल की शुरुआत में सीयू में तय की गई थी। हालाँकि, यह एकमात्र प्रासंगिक संदर्भ है जो मुझे पहले 2 प्रकार के संदेशों के लिए मिल सकता है, अन्य स्वत: प्रारंभिक सीडिंग संदेशों के संदर्भों के अलावा जो एजी के पहले से ही यहां स्थापित नहीं होने चाहिए।
यहां पिछले सप्ताह की दैनिक त्रुटियों का एक सारांश है, उन दिनों के लिए> PRIMARY पर प्रति प्रकार 10K त्रुटियां थीं (माध्यमिक शो 'प्राथमिक के साथ संबंध खो देता है ...'):
Date Message Type (First 50 characters) Num Errors
10/8/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 61953
10/3/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 56812
10/4/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 27951
10/2/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 24158
10/7/2018 DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint: 14904
10/8/2018 Always On Availability Groups connection with seco 13301
10/3/2018 DbMgrPartnerCommitPolicy::SetSyncState: 783CAF81-4 11057
10/3/2018 Always On Availability Groups connection with seco 10080हम कभी-कभी "अजीब" संदेश भी देखते हैं जैसे:
उपलब्धता समूह डेटाबेस "DB" "SECONDARY" से "SECONDARY" में भूमिकाएं बदल रहा है, क्योंकि भूमिका सिंक्रनाइज़ेशन के कारण मिररिंग सत्र या उपलब्धता समूह विफल रहा। यह केवल सूचनात्मक संदेश है। कोई उपयोगकर्ता कार्रवाई की आवश्यकता नहीं है।
... बदलते राज्यों के एक मेजबान के बीच "SECONDARY" से "RESOLVING" तक।
मैनुअल विफलता के बाद, सिस्टम कई दिनों तक इन प्रकारों के एक भी संदेश के बिना जा सकता है, और अचानक, बिना किसी स्पष्ट कारण के, हमें एक साथ हजारों मिलेंगे, जिसके कारण सर्वर अप्रतिसादी हो जाता है, और अनुप्रयोग का कारण बनता है कनेक्शन टाइमआउट। यह एक महत्वपूर्ण बग है क्योंकि उनके कुछ एप्लिकेशन एक रिट्री मैकेनिज्म को शामिल नहीं करते हैं, और इसलिए डेटा खो सकते हैं। जब इस तरह की त्रुटियां होती हैं, तो निम्न प्रतीक्षा आकाश-रॉकेट की तरह होती है। ऐसा लगता है कि एजी के ठीक बाद के वेट्स से लगता है कि एक बार में सभी डेटाबेस से कनेक्शन खत्म हो गया है:
लगभग 30 सेकंड बाद, वेट के संदर्भ में सब कुछ सामान्य हो जाता है, लेकिन एजी संदेश अलग-अलग दरों पर त्रुटि लॉग को भरते रहते हैं और दिन के अलग-अलग समय के दौरान, पीक आवर्स सहित बेतरतीब ढंग से बार-बार प्रकट होते हैं। इन एरर के फटने के दौरान वर्कलोड में लगातार वृद्धि निश्चित रूप से चीजों को बदतर बनाती है। यदि केवल कुछ डेटाबेस डिस्कनेक्ट हो जाते हैं, तो यह आमतौर पर कनेक्शन को समय से बाहर करने का कारण नहीं बनता है क्योंकि यह अपने आप ही जल्दी से हल हो जाता है।
हमने यह सत्यापित करने का प्रयास किया कि यह वास्तव में CU9 था जिसने इस मुद्दे को शुरू किया था, लेकिन हम दोनों नोड्स को केवल CU9 में डाउनग्रेड करने में सक्षम थे। CU8 में नोड को या तो डाउनग्रेड करने का प्रयास किया गया, जिसके परिणामस्वरूप नोड लॉग में समान त्रुटि दिखाते हुए 'रिज़ॉल्यूशन' स्थिति में अटक गया:
हमेशा संबंधित संसाधन ID के साथ उपलब्धता समूह पर जारी कॉन्फ़िगरेशन को नहीं पढ़ा जा सकता है '...। निरंतर कॉन्फ़िगरेशन एक उच्च-संस्करण SQL सर्वर द्वारा लिखा गया है जो प्राथमिक उपलब्धता प्रतिकृति को होस्ट करता है। स्थानीय SQL प्रतिकृति को द्वितीयक प्रतिकृति बनने के लिए स्थानीय SQL सर्वर आवृत्ति का नवीनीकरण करें।
इसका मतलब है कि हमें एक ही समय में CU8 में दोनों नोड्स को डाउनग्रेड करने में सक्षम होने के लिए नीचे का समय देना होगा। इससे यह भी पता चलता है कि एजी के लिए कुछ प्रमुख अपडेट थे जो यह बता सकते हैं कि हम क्या अनुभव कर रहे हैं।
हमने पहले से ही 0 से डिफ़ॉल्ट ( इस लेख के आधार पर हमारे बॉक्स पर 960 = ) को धीरे-धीरे 2,000 तक की त्रुटियों के साथ कोई प्रभाव नहीं देखा।
हम इन एजी डिस्कनेक्ट को हल करने के लिए क्या कर सकते हैं? वहाँ किसी को भी इसी तरह के मुद्दों का सामना कर रहा है? क्या एक एजी में बड़ी संख्या में डेटाबेस वाले अन्य लोग शायद CU9 या CU8 से शुरू होने वाले SQL त्रुटि लॉग में समान संदेश देख सकते हैं?
किसी भी सहायता के लिए अग्रिम रूप से धन्यवाद!