MySQL सेमीसिंक्रोनस प्रतिकृति में डेटा अखंडता और प्रदर्शन संबंधी विचार

MySQL सेमीसिंक्रोनस प्रतिकृति बेहतर डेटा अखंडता प्रदान करती है क्योंकि जब कोई प्रतिबद्ध सफलतापूर्वक लौटता है, तो यह ज्ञात होता है कि डेटा कम से कम दो स्थानों पर मौजूद है - मास्टर और उसका दास। इस ब्लॉग पोस्ट में, हम कुछ MySQL होस्टिंग कॉन्फ़िगरेशन की समीक्षा करते हैं जो डेटा अखंडता और सेमीसिंक्रोनस प्रतिकृति के प्रदर्शन पहलुओं को प्रभावित करते हैं। हम 3-नोड प्रतिकृति सेट (मास्टर और 2 दास) में InnoDB स्टोरेज इंजन और GTID- आधारित प्रतिकृति का उपयोग करेंगे, जो यह सुनिश्चित करेगा कि दासों में अतिरेक है। इसका मतलब यह है कि अगर एक दास के साथ कोई समस्या है, तो हम दूसरे पर वापस आ सकते हैं।

कॉन्फ़िगरेशन मास्टर और स्लेव नोड दोनों पर लागू

• innodb_flust_log_at_trx_commit =1
• sync_binlog =1

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

मास्टर नोड पर कॉन्फ़िगरेशन।

• rpl_semi_sync_master_wait_for_slave_count:

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

• rpl_semi_sync_master_timeout:

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

स्लेव नोड्स पर कॉन्फ़िगरेशन

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

निम्न विन्यासों के माध्यम से दासों की दुर्घटना-सुरक्षा सुनिश्चित करना महत्वपूर्ण है:

• relay_log_info_repository =तालिका
• relay_log_recovery =ON

Relay_log_info_repository को TABLE पर सेट करने से यह सुनिश्चित हो जाएगा कि SQL थ्रेड की स्थिति स्लेव पर प्रत्येक ट्रांजैक्शन कमिट के साथ अपडेट की गई है। हालाँकि, IO थ्रेड की सटीक स्थिति को बनाए रखना और डिस्क पर फ्लश करना मुश्किल है। ऐसा इसलिए है क्योंकि मास्टर बाइनरी लॉग पढ़ना और दास रिले लॉग को लिखना लेनदेन पर आधारित नहीं है। यदि IO थ्रेड स्थिति को अद्यतन किया जाना है और प्रत्येक दास रिले लॉग को लिखने के बाद डिस्क पर फ़्लश किया गया है, तो प्रदर्शन पर प्रभाव बहुत अधिक है। रिले_लॉग_रिकवरी =ON सेट करने के लिए एक अधिक सुरुचिपूर्ण समाधान होगा, इस स्थिति में, यदि कोई MySQL पुनरारंभ होता है, तो वर्तमान रिले लॉग को दूषित माना जाएगा और SQL थ्रेड स्थिति के आधार पर मास्टर से नए सिरे से खींचा जाएगा।

अंतिम लेकिन कम से कम, यह ध्यान रखना महत्वपूर्ण है कि सेमीसिंक्रोनस प्रतिकृति यह सुनिश्चित करती है कि डेटा मास्टर द्वारा लेन-देन करने से पहले दासों में से एक तक 'पहुंच' गया है, और इसका मतलब यह नहीं है कि लेन-देन दास पर किए जाते हैं। इसलिए, यह सुनिश्चित करना अच्छा होगा कि SQL थ्रेड अच्छे प्रदर्शन के साथ काम करता है। आदर्श स्थिति में, SQL थ्रेड IO थ्रेड के साथ हाथ से चलता है ताकि हमें न केवल लेन-देन प्राप्त करने वाले दास का लाभ मिल सके, बल्कि उन्हें करने का भी लाभ मिल सके। मल्टी-थ्रेडेड स्लेव कॉन्फ़िगरेशन के साथ जाने की अनुशंसा की जाती है ताकि हम स्लेव SQL थ्रेड प्रदर्शन को बढ़ा सकें। मल्टी-थ्रेडेड स्लेव के लिए महत्वपूर्ण कॉन्फ़िगरेशन हैं:

• slave_parallel_workers : एकाधिक स्लेव SQL थ्रेड वर्कर को सक्षम करने के लिए इसे> 1 पर सेट करें। मास्टर पर लिखे गए धागों की संख्या के आधार पर, हम इसके लिए एक इष्टतम संख्या तय कर सकते हैं ताकि दास पीछे न रहे।
• गुलाम-समानांतर-प्रकार =LOGICAL_CLOCK
• दास-संरक्षण-प्रतिबद्ध-आदेश =1

उपरोक्त विन्यास दास में समानता का वादा करने जा रहे हैं, जबकि साथ ही, मास्टर पर देखे गए लेनदेन के क्रम को संरक्षित करते हुए।

संक्षेप में, हमारे MySQL प्रतिकृति सेट पर उपरोक्त कॉन्फ़िगरेशन का उपयोग करके, हम एक इष्टतम प्रदर्शन के साथ उच्च डेटा अखंडता बनाए रखने में सक्षम हैं।

हमेशा की तरह, यदि आपके कोई प्रश्न हैं, तो हमें एक टिप्पणी दें, ट्विटर पर @scalegridio पर हमसे संपर्क करें, या हमें समर्थन पर एक ईमेल भेजें @scalegrid.io.