उच्च उपलब्धता MySQL और MariaDB समाधानों में उच्च विलंबता के प्रभावों को समझना

उच्च उपलब्धता उस समय का एक उच्च प्रतिशत है जब सिस्टम व्यवसाय की जरूरतों के अनुसार काम कर रहा है और प्रतिक्रिया दे रहा है। उत्पादन डेटाबेस सिस्टम के लिए इसे आमतौर पर 100% के करीब रखना सर्वोच्च प्राथमिकता है। हम विफलता के सभी एकल बिंदु को खत्म करने के लिए डेटाबेस क्लस्टर बनाते हैं। यदि कोई उदाहरण अनुपलब्ध हो जाता है, तो दूसरा नोड कार्यभार लेने और वहां से आगे बढ़ने में सक्षम होना चाहिए। एक आदर्श दुनिया में, एक डेटाबेस क्लस्टर हमारी सभी सिस्टम उपलब्धता समस्याओं का समाधान करेगा। दुर्भाग्य से, जबकि कागज पर सब कुछ अच्छा लग सकता है, वास्तविकता अक्सर अलग होती है। तो यह कहाँ गलत हो सकता है?

ट्रांजेक्शनल डेटाबेस सिस्टम परिष्कृत स्टोरेज इंजन के साथ आते हैं। कई नोड्स में डेटा को सुसंगत रखना इस कार्य को कठिन बना देता है। क्लस्टरिंग कई नए चर पेश करता है जो अत्यधिक नेटवर्क और अंतर्निहित बुनियादी ढांचे पर निर्भर करते हैं। यह एक स्टैंडअलोन डेटाबेस इंस्टेंस के लिए असामान्य नहीं है जो एकल नोड पर ठीक चल रहा था, अचानक क्लस्टर वातावरण में खराब प्रदर्शन करता है।

क्लस्टर उपलब्धता को प्रभावित करने वाली कई चीजों में, विलंबता के मुद्दे महत्वपूर्ण भूमिका निभाते हैं। हालांकि, विलंबता क्या है? क्या यह केवल नेटवर्क से संबंधित है?

शब्द "विलंबता" वास्तव में डेटा के प्रसंस्करण में होने वाली कई प्रकार की देरी को संदर्भित करता है। किसी जानकारी को एक मंच से दूसरे चरण में जाने में कितना समय लगता है।

इस ब्लॉग पोस्ट में, हम MySQL और MariaDB के लिए दो मुख्य उच्च उपलब्धता समाधान देखेंगे, और वे कैसे विलंबता समस्याओं से प्रभावित हो सकते हैं।

लेख के अंत में, हम आधुनिक लोड बैलेंसर्स पर एक नज़र डालते हैं और चर्चा करते हैं कि वे कुछ प्रकार के विलंबता मुद्दों को हल करने में आपकी सहायता कैसे कर सकते हैं।

पिछले लेख में, मेरे सहयोगी Krzysztof Książek ने "MySQL या MariaDB के लिए एक HA समाधान तैयार करते समय अविश्वसनीय नेटवर्क से निपटना" के बारे में लिखा था। आपको ऐसे सुझाव मिलेंगे जो आपके उत्पादन के लिए तैयार HA आर्किटेक्चर को डिज़ाइन करने में आपकी मदद कर सकते हैं, और यहाँ वर्णित कुछ समस्याओं से बच सकते हैं।

उच्च उपलब्धता के लिए मास्टर-स्लेव प्रतिकृति।

MySQL मास्टर-स्लेव प्रतिकृति शायद ग्रह पर सबसे लोकप्रिय डेटाबेस क्लस्टर प्रकार है। अपने मास्टर-स्लेव प्रतिकृति क्लस्टर को चलाते समय आप जिन मुख्य चीजों की निगरानी करना चाहते हैं, उनमें से एक है स्लेव लैग। आपकी एप्लिकेशन आवश्यकताओं और आपके डेटाबेस का उपयोग करने के तरीके के आधार पर, प्रतिकृति विलंबता (स्लेव लैग) यह निर्धारित कर सकती है कि डेटा को स्लेव नोड से पढ़ा जा सकता है या नहीं। मास्टर पर किए गए डेटा लेकिन अभी तक एक अतुल्यकालिक दास पर उपलब्ध नहीं है, इसका मतलब है कि दास की स्थिति पुरानी है। जब दास से पढ़ना ठीक नहीं है, तो आपको मास्टर के पास जाना होगा, और यह एप्लिकेशन के प्रदर्शन को प्रभावित कर सकता है। सबसे खराब स्थिति में, आपका सिस्टम मास्टर पर सभी कार्यभार को संभालने में सक्षम नहीं होगा।

स्लेव लैग और बासी डेटा

मास्टर-स्लेव प्रतिकृति की स्थिति की जांच करने के लिए, आपको निम्न आदेश से प्रारंभ करना चाहिए:

SHOW SLAVE STATUS\G
MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.0.3.100
                  Master_User: rpl_user
                  Master_Port: 3306
                Connect_Retry: 10
              Master_Log_File: binlog.000021
          Read_Master_Log_Pos: 5101
               Relay_Log_File: relay-bin.000002
                Relay_Log_Pos: 809
        Relay_Master_Log_File: binlog.000021
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 5101
              Relay_Log_Space: 1101
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 3
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
                   Using_Gtid: Slave_Pos
                  Gtid_IO_Pos: 0-3-1179
      Replicate_Do_Domain_Ids: 
  Replicate_Ignore_Domain_Ids: 
                Parallel_Mode: conservative
1 row in set (0.01 sec)

उपरोक्त जानकारी का उपयोग करके आप यह निर्धारित कर सकते हैं कि समग्र प्रतिकृति विलंबता कितनी अच्छी है। "Seconds_Behind_Master" में आप जितना कम मान देखेंगे, प्रतिकृति के लिए डेटा स्थानांतरण गति उतनी ही बेहतर होगी।

ऐसी कई चीजें हैं जो प्रतिकृति समय को प्रभावित कर सकती हैं। सबसे स्पष्ट नेटवर्क थ्रूपुट है और आप कितना डेटा स्थानांतरित कर सकते हैं। प्रतिकृति प्रक्रिया को अनुकूलित करने के लिए MySQL कई कॉन्फ़िगरेशन विकल्पों के साथ आता है। आवश्यक प्रतिकृति संबंधित पैरामीटर हैं:

• समानांतर लागू
• तार्किक घड़ी एल्गोरिथम
• संपीड़न
• चुनिंदा मास्टर-दास प्रतिकृति
• प्रतिकृति मोड

समानांतर लागू

समानांतर प्रक्रिया लागू करने के साथ प्रतिकृति ट्यूनिंग शुरू करना असामान्य नहीं है। इसका कारण डिफ़ॉल्ट रूप से है, MySQL अनुक्रमिक बाइनरी लॉग लागू के साथ जाता है, और एक विशिष्ट डेटाबेस सर्वर उपयोग करने के लिए कई CPU के साथ आता है।

अनुक्रमिक लॉग लागू करने के लिए, मारियाडीबी और माईएसक्यूएल दोनों समानांतर प्रतिकृति प्रदान करते हैं। कार्यान्वयन प्रति विक्रेता और संस्करण भिन्न हो सकता है। उदा. MySQL 5.6 समानांतर प्रतिकृति प्रदान करता है जब तक कि एक स्कीमा प्रश्नों को अलग करती है जबकि मारियाडीबी (शुरुआती संस्करण 10.0) और MySQL 5.7 दोनों स्कीमा में समानांतर प्रतिकृति को संभाल सकते हैं। विभिन्न विक्रेता और संस्करण अपनी सीमाओं और विशेषताओं के साथ आते हैं इसलिए हमेशा दस्तावेज़ीकरण की जांच करें।

यदि आप भारी लिखते हैं, तो समानांतर स्लेव थ्रेड्स के माध्यम से प्रश्नों को निष्पादित करना आपकी प्रतिकृति स्ट्रीम को गति दे सकता है। हालाँकि, यदि आप नहीं हैं, तो पारंपरिक सिंगल-थ्रेडेड प्रतिकृति से चिपके रहना सबसे अच्छा होगा। समानांतर प्रसंस्करण को सक्षम करने के लिए, गुलाम_समानांतर_वर्कर्स को उस सीपीयू थ्रेड्स की संख्या में बदलें, जिसे आप प्रक्रिया में शामिल करना चाहते हैं। उपलब्ध CPU थ्रेड्स की संख्या के मान को कम रखने की अनुशंसा की जाती है।

समानांतर प्रतिकृति समूह के साथ सबसे अच्छा काम करती है। यह जांचने के लिए कि क्या आपके पास समूह कमिट हो रहा है, निम्नलिखित क्वेरी चलाएँ।

show global status like 'binlog_%commits';

इन दोनों मूल्यों के बीच जितना बड़ा अनुपात होगा उतना ही बेहतर होगा।

तार्किक घड़ी

स्लेव_पैरेलल_टाइप=LOGICAL_CLOCK लैम्पपोर्ट क्लॉक एल्गोरिथम का कार्यान्वयन है। मल्टीथ्रेडेड स्लेव का उपयोग करते समय यह वेरिएबल यह तय करने के लिए उपयोग की जाने वाली विधि को निर्दिष्ट करता है कि कौन से लेन-देन दास पर समानांतर में निष्पादित करने की अनुमति है। वेरिएबल का स्लेव पर कोई प्रभाव नहीं पड़ता है जिसके लिए मल्टीथ्रेडिंग सक्षम नहीं है इसलिए सुनिश्चित करें कि स्लेव_पैरेलल_वर्कर्स 0 से ऊपर सेट है।

मारियाडीबी उपयोगकर्ताओं को संस्करण 10.1.3 में पेश किए गए आशावादी मोड की भी जांच करनी चाहिए क्योंकि यह आपको बेहतर परिणाम भी दे सकता है।

GTID

मारियाडीबी जीटीआईडी ​​के अपने कार्यान्वयन के साथ आता है। मारियाडीबी के अनुक्रम में एक डोमेन, सर्वर और लेनदेन शामिल हैं। डोमेन विशिष्ट आईडी के साथ बहु-स्रोत प्रतिकृति की अनुमति देते हैं। अलग-अलग डोमेन आईडी का इस्तेमाल आउट-ऑफ-ऑर्डर (समानांतर में) डेटा के हिस्से को दोहराने के लिए किया जा सकता है। जब तक यह आपके आवेदन के लिए ठीक है, यह प्रतिकृति विलंबता को कम कर सकता है।

इसी तरह की तकनीक MySQL 5.7 पर लागू होती है जो मल्टीसोर्स मास्टर और स्वतंत्र प्रतिकृति चैनलों का भी उपयोग कर सकती है।

संपीड़न

सीपीयू पावर समय के साथ कम खर्चीली होती जा रही है, इसलिए इसे बिनलॉग कम्प्रेशन के लिए उपयोग करना कई डेटाबेस वातावरणों के लिए एक अच्छा विकल्प हो सकता है। गुलाम_संपीड़ित_प्रोटोकॉल पैरामीटर MySQL को संपीड़न का उपयोग करने के लिए कहता है यदि मास्टर और दास दोनों इसका समर्थन करते हैं। डिफ़ॉल्ट रूप से, यह पैरामीटर अक्षम है।

मारियाडीबी 10.2.3 से शुरू होकर, नेटवर्क स्थानान्तरण को बचाने के लिए बाइनरी लॉग में चयनित घटनाओं को वैकल्पिक रूप से संपीड़ित किया जा सकता है।

प्रतिकृति प्रारूप

MySQL कई प्रतिकृति मोड प्रदान करता है। सही प्रतिकृति प्रारूप चुनने से क्लस्टर नोड्स के बीच डेटा पास करने में लगने वाले समय को कम करने में मदद मिलती है।

उच्च उपलब्धता के लिए मल्टीमास्टर प्रतिकृति

कुछ एप्लिकेशन पुराने डेटा पर काम नहीं कर सकते।

ऐसे मामलों में, आप समकालिक प्रतिकृति के साथ सभी नोड्स में संगतता लागू करना चाह सकते हैं। डेटा को सिंक्रोनस रखने के लिए एक अतिरिक्त प्लगइन की आवश्यकता होती है, और कुछ के लिए, उसके लिए बाजार पर सबसे अच्छा समाधान गैलेरा क्लस्टर है।

गैलेरा क्लस्टर wsrep एपीआई के साथ आता है जो सभी नोड्स में लेनदेन को प्रसारित करने और क्लस्टर-वाइड ऑर्डर के अनुसार उन्हें निष्पादित करने के लिए जिम्मेदार है। यह बाद के प्रश्नों के निष्पादन को तब तक अवरुद्ध कर देगा जब तक कि नोड ने अपनी लागू कतार से सभी राइट-सेट लागू नहीं कर दिए। हालांकि यह स्थिरता के लिए एक अच्छा समाधान है, आप कुछ वास्तु सीमाओं को प्रभावित कर सकते हैं। सामान्य विलंबता मुद्दे इससे संबंधित हो सकते हैं:

• क्लस्टर में सबसे धीमा नोड
• क्षैतिज स्केलिंग और लेखन संचालन
• जियोलोकेटेड क्लस्टर
• हाई पिंग
• लेन-देन का आकार

क्लस्टर में सबसे धीमा नोड

डिज़ाइन के अनुसार, क्लस्टर का लेखन प्रदर्शन क्लस्टर में सबसे धीमे नोड के प्रदर्शन से अधिक नहीं हो सकता है। मशीन संसाधनों की जाँच करके अपनी क्लस्टर समीक्षा शुरू करें और यह सुनिश्चित करने के लिए कॉन्फ़िगरेशन फ़ाइलों को सत्यापित करें कि वे सभी समान प्रदर्शन सेटिंग्स पर चलती हैं।

समानांतरता

समानांतर धागे बेहतर प्रदर्शन की गारंटी नहीं देते हैं, लेकिन यह क्लस्टर के साथ नए नोड्स के सिंक्रनाइज़ेशन को गति दे सकता है। स्थिति wsrep_cert_deps_distance हमें समानांतरीकरण की संभावित डिग्री बताती है। यह उच्चतम और निम्नतम seqno मानों के बीच की औसत दूरी का मान है जिसे संभवतः समानांतर में लागू किया जा सकता है। संभव स्लेव थ्रेड्स की अधिकतम संख्या निर्धारित करने के लिए आप wsrep_cert_deps_distance स्थिति चर का उपयोग कर सकते हैं।

क्षैतिज स्केलिंग

क्लस्टर में अधिक नोड्स जोड़कर, हमारे पास कम अंक हैं जो विफल हो सकते हैं; हालाँकि, सूचना को प्रतिबद्ध होने तक बहु-उदाहरणों में जाने की आवश्यकता होती है, जो प्रतिक्रिया समय को गुणा करता है। यदि आपको स्केलेबल राइट्स की आवश्यकता है, तो शार्डिंग पर आधारित आर्किटेक्चर पर विचार करें। एक अच्छा समाधान स्पाइडर स्टोरेज इंजन हो सकता है।

कुछ मामलों में, क्लस्टर नोड्स में साझा की गई जानकारी को कम करने के लिए, आप एक समय में एक लेखक रखने पर विचार कर सकते हैं। लोड बैलेंसर का उपयोग करते समय इसे लागू करना अपेक्षाकृत आसान है। जब आप इसे मैन्युअल रूप से करते हैं तो सुनिश्चित करें कि आपके लेखक नोड के नीचे जाने पर आपके पास DNS मान बदलने की प्रक्रिया है।

जियोलोकेटेड क्लस्टर

हालांकि गैलेरा क्लस्टर समकालिक है, लेकिन गैलेरा क्लस्टर को डेटा केंद्रों में तैनात करना संभव है। MySQL क्लस्टर (NDB) की तरह सिंक्रोनस प्रतिकृति दो-चरण की प्रतिबद्धता को लागू करती है, जहां एक 'तैयार' चरण में क्लस्टर में सभी नोड्स को संदेश भेजे जाते हैं, और संदेशों का एक और सेट 'प्रतिबद्ध' चरण में भेजा जाता है। नोड्स के बीच संदेश भेजने में विलंब के कारण, यह दृष्टिकोण आमतौर पर भौगोलिक रूप से भिन्न नोड्स के लिए उपयुक्त नहीं है।

हाई पिंग

डिफ़ॉल्ट सेटिंग्स के साथ गैलेरा क्लस्टर अच्छी तरह से उच्च नेटवर्क विलंबता को संभाल नहीं पाता है। यदि आपके पास एक नोड वाला नेटवर्क है जो उच्च पिंग समय दिखाता है, तो evs.send_window और evs.user_send_window पैरामीटर बदलने पर विचार करें। ये चर एक समय में प्रतिकृति में डेटा पैकेट की अधिकतम संख्या को परिभाषित करते हैं। WAN सेटअप के लिए, वैरिएबल को 2 के डिफ़ॉल्ट मान से काफी अधिक मान पर सेट किया जा सकता है। इसे 512 पर सेट करना सामान्य है। ये पैरामीटर wsrep_provider_options का हिस्सा हैं।

--wsrep_provider_options="evs.send_window=512;evs.user_send_window=512"

लेन-देन का आकार

गैलेरा क्लस्टर चलाते समय आपको जिन चीजों पर विचार करने की आवश्यकता है उनमें से एक लेनदेन का आकार है। लेन-देन के आकार, प्रदर्शन और गैलेरा प्रमाणन प्रक्रिया के बीच संतुलन का पता लगाना कुछ ऐसा है जिसका आपको अपने आवेदन में अनुमान लगाना होगा। आप इसके बारे में अधिक जानकारी लेख में पा सकते हैं कि अशरफ शरीफ द्वारा MySQL या मारियाडीबी के लिए गैलेरा क्लस्टर के प्रदर्शन में सुधार कैसे करें।

लोड बैलेंसर कारण संगति पढ़ता है

डेटा विलंबता मुद्दों के न्यूनतम जोखिम के साथ भी, मानक MySQL एसिंक्रोनस प्रतिकृति स्थिरता की गारंटी नहीं दे सकती है। यह अभी भी संभव है कि डेटा अभी तक दास को दोहराया नहीं गया है, जबकि आपका आवेदन इसे वहां से पढ़ रहा है। तुल्यकालिक प्रतिकृति इस समस्या को हल कर सकती है, लेकिन इसकी वास्तुकला सीमाएँ हैं और यह आपकी आवेदन आवश्यकताओं (जैसे, गहन थोक लेखन) के अनुरूप नहीं हो सकता है। तो इसे कैसे दूर किया जाए?

पुराने डेटा रीडिंग से बचने के लिए पहला कदम एप्लिकेशन को प्रतिकृति विलंब के बारे में जागरूक करना है। यह आमतौर पर एप्लिकेशन कोड में प्रोग्राम किया जाता है। सौभाग्य से, GTID ट्रैकिंग पर आधारित अनुकूली क्वेरी रूटिंग के समर्थन के साथ आधुनिक डेटाबेस लोड बैलेंसर हैं। ProxySQL और Maxscale सबसे लोकप्रिय हैं।

प्रॉक्सीएसक्यूएल 2.0

ProxySQL Binlog Reader ProxySQL को वास्तविक समय में यह जानने की अनुमति देता है कि कौन सा GTID प्रत्येक MySQL सर्वर, दासों और स्वयं मास्टर पर निष्पादित किया गया है। इसके लिए धन्यवाद, जब कोई क्लाइंट एक पठन निष्पादित करता है जिसे कारण संगति प्रदान करने की आवश्यकता होती है, तो ProxySQL तुरंत जानता है कि किस सर्वर पर क्वेरी निष्पादित की जा सकती है। यदि किसी भी कारण से अभी तक किसी दास पर लेखन निष्पादित नहीं किया गया है, तो ProxySQL को पता चल जाएगा कि लेखक को मास्टर पर निष्पादित किया गया था और वहां पढ़ा गया था।

मैक्सस्केल 2.3

मारियाडीबी ने मैक्सस्केल 2.3.0 में आकस्मिक पठन की शुरुआत की। जिस तरह से यह काम करता है वह ProxySQL 2.0 के समान है। मूल रूप से जब causal_reads सक्षम होते हैं, तो दास सर्वर पर किए गए किसी भी बाद के पढ़ने को इस तरह से किया जाएगा जो परिणामों को प्रभावित करने से प्रतिकृति अंतराल को रोकता है। यदि दास कॉन्फ़िगर किए गए समय के भीतर मास्टर तक नहीं पहुंचा है, तो मास्टर पर क्वेरी का पुन:प्रयास किया जाएगा।