MySQL में प्रतिकृति लंबे समय से है, और पिछले कुछ वर्षों में लगातार सुधार हो रहा है। यह क्रांति के बजाय विकास की तरह अधिक रहा है। यह पूरी तरह से समझ में आता है, क्योंकि प्रतिकृति एक महत्वपूर्ण विशेषता है जिस पर बहुत से लोग निर्भर हैं - इसे काम करना है।
पिछले MySQL संस्करणों में, हमने समानांतर में लेनदेन को लागू करने के समर्थन के माध्यम से प्रतिकृति प्रदर्शन में सुधार देखा है। MySQL 5.6 में, स्कीमा स्तर पर समानांतरकरण किया गया था - सभी लेनदेन जो अलग-अलग स्कीमा में निष्पादित किए गए हैं, उन्हें एक ही बार में निष्पादित किया जा सकता है। यह उन वर्कलोड के लिए एक अच्छा सुधार था जिसमें एक ही सर्वर पर कई स्कीमा थे, और लोड कमोबेश समान रूप से सभी स्कीमाओं में वितरित किया गया था।
MySQL 5.7 में, एक और समानांतरकरण विधि जोड़ी गई, जिसे "तार्किक घड़ी" कहा जाता है। यह दास पर कुछ स्तर की समेकन प्राप्त करने की इजाजत देता है, भले ही आपका सभी डेटा एक ही स्कीमा में संग्रहीत किया गया हो। यह संक्षेप में, इस तथ्य पर आधारित था कि हार्डवेयर द्वारा जोड़े गए विलंबता के कारण कुछ लेनदेन एक साथ होंगे। आप binlog_group_commit_sync_delay का उपयोग करके दासों पर बेहतर समानांतरता प्राप्त करने के लिए उस विलंबता को मैन्युअल रूप से जोड़ सकते हैं।
यह समाधान वास्तव में अच्छा था लेकिन कमियों के बिना नहीं। लेन-देन करने में हर देरी अंततः एप्लिकेशन के उपयोगकर्ता-सामना वाले हिस्सों को प्रभावित कर सकती है। ज़रूर, आप कई मिलीसेकंड की सीमा के भीतर देरी सेट कर सकते हैं, लेकिन फिर भी, यह अतिरिक्त विलंबता है जो ऐप को धीमा कर देती है।
MySQL 8.0 में प्रतिकृति प्रदर्शन सुधार
MySQL 8.0, जो अभी (अगस्त 2017) अभी भी बीटा अवस्था में है, प्रतिकृति में कुछ अच्छे सुधार लाता है। मूल रूप से, इसे समूह प्रतिकृति (जीआर) के लिए विकसित किया गया था, लेकिन चूंकि जीआर हुड के तहत नियमित प्रतिकृति का उपयोग करता है, इसलिए "सामान्य" MySQL प्रतिकृति इससे लाभान्वित हुई। हमने जिस सुधार का उल्लेख किया है वह बाइनरी लॉग में संग्रहीत निर्भरता ट्रैकिंग जानकारी है। क्या होता है कि MySQL 8.0 के पास अब जानकारी संग्रहीत करने का एक तरीका है कि कौन सी पंक्तियाँ किसी दिए गए लेन-देन (तथाकथित राइटसेट) से प्रभावित हुईं, और यह विभिन्न लेनदेन से राइटसेट की तुलना करती है। इससे उन लेन-देन की पहचान करना संभव हो जाता है जो पंक्तियों के एक ही उपसमुच्चय पर काम नहीं करते थे और इसलिए, इन्हें समानांतर में लागू किया जा सकता है। यह MySQL 5.7 के कार्यान्वयन की तुलना में समांतरता स्तर को कई गुना बढ़ाने की अनुमति दे सकता है। आपको यह ध्यान रखने की आवश्यकता है कि, अंततः, एक दास को डेटा का एक अलग दृश्य दिखाई देगा, जो कि मास्टर पर कभी दिखाई नहीं दिया। ऐसा इसलिए है क्योंकि लेन-देन मास्टर की तुलना में भिन्न क्रम में लागू किया जा सकता है। हालांकि यह कोई समस्या नहीं होनी चाहिए। MySQL 5.7 में मल्टीथ्रेडेड प्रतिकृति का वर्तमान कार्यान्वयन भी इस समस्या का कारण हो सकता है जब तक कि आप स्पष्ट रूप से दास-संरक्षण-प्रतिबद्ध-आदेश को सक्षम नहीं करते हैं।
इस नए व्यवहार को नियंत्रित करने के लिए, एक चर binlog_transaction_dependency_tracking पेश किया गया है। इसमें तीन मान हो सकते हैं:
- COMMIT_ORDER:यह डिफ़ॉल्ट है, यह MySQL 5.7 में उपलब्ध डिफ़ॉल्ट तंत्र का उपयोग करता है।
- WRITESET:यह बेहतर समानांतरकरण को सक्षम बनाता है और मास्टर बाइनरी लॉग में राइटसेट डेटा को स्टोर करना शुरू कर देता है।
- WRITESET_SESSION:यह सुनिश्चित करता है कि लेन-देन दास पर क्रम में निष्पादित किया जाएगा और दास के साथ समस्या जो डेटाबेस की स्थिति को देखती है जो मास्टर पर कभी नहीं देखी गई थी। यह समानांतरीकरण को कम करता है लेकिन फिर भी यह डिफ़ॉल्ट सेटिंग्स की तुलना में बेहतर थ्रूपुट प्रदान कर सकता है।
बेंचमार्क
जुलाई में, mysqlhighavailability.com पर, Vitor Oliveira ने एक पोस्ट लिखी जिसमें उन्होंने नए मोड के प्रदर्शन को मापने की कोशिश की। उन्होंने पुराने और नए तरीकों के बीच अंतर दिखाने के लिए सबसे अच्छे मामले परिदृश्य का इस्तेमाल किया - कोई स्थायित्व नहीं। हमने उसी दृष्टिकोण का उपयोग करने का निर्णय लिया, इस बार अधिक वास्तविक दुनिया के सेटअप में:लॉग_स्लेव_अपडेट्स के साथ बाइनरी लॉग सक्षम। स्थायित्व सेटिंग्स को डिफ़ॉल्ट पर छोड़ दिया गया था (इसलिए, sync_binlog=1 - यह MySQL 8.0 में नया डिफ़ॉल्ट है, डबलराइट बफर सक्षम, InnoDB चेकसम सक्षम आदि) स्थायित्व में केवल अपवाद innodb_flush_log_at_trx_commit 2 पर सेट था।
हमने m4.2xl इंस्टेंसेस, 32G, 8 कोर का इस्तेमाल किया (इसलिए स्लेव_पैरेलल_वर्कर्स को 8 पर सेट किया गया था)। हमने sysbench, oltp_read_write.lua स्क्रिप्ट का भी इस्तेमाल किया। 32 टेबल में 16 मिलियन पंक्तियों को 1000GB gp2 वॉल्यूम (अर्थात 3000 IOPS) पर संग्रहीत किया गया था। हमने 1, 2, 4, 8, 16 और 32 समवर्ती sysbench कनेक्शन के लिए सभी मोड के प्रदर्शन का परीक्षण किया। प्रक्रिया इस प्रकार थी:स्लेव को रोकें, 100k लेन-देन निष्पादित करें, स्लेव शुरू करें और गणना करें कि स्लेव लैग को साफ़ करने में कितना समय लगता है।
सबसे पहले, हम वास्तव में नहीं जानते कि क्या हुआ जब sysbench केवल 1 थ्रेड का उपयोग करके निष्पादित किया गया था। वार्मअप रन के बाद प्रत्येक परीक्षण को पांच बार अंजाम दिया गया। इस विशेष कॉन्फ़िगरेशन का दो बार परीक्षण किया गया - परिणाम स्थिर हैं:सिंगल-थ्रेडेड वर्कलोड सबसे तेज़ था। क्या हुआ यह समझने के लिए हम इस पर और गौर करेंगे।
इसके अलावा, बाकी परिणाम हमारी अपेक्षा के अनुरूप हैं। COMMIT_ORDER सबसे धीमा है, विशेष रूप से कम ट्रैफ़िक, 2-8 थ्रेड्स के लिए। WRITESET_SESSION आमतौर पर COMMIT_ORDER से बेहतर प्रदर्शन करता है लेकिन कम समवर्ती ट्रैफ़िक के लिए यह WRITESET से धीमा है।
यह मेरी कैसे मदद कर सकता है?
पहला लाभ स्पष्ट है:यदि आपका कार्यभार धीमा है, फिर भी आपके दासों में प्रतिकृति में वापस आने की प्रवृत्ति है, तो जैसे ही मास्टर को 8.0 में अपग्रेड किया जाएगा, वे बेहतर प्रतिकृति प्रदर्शन से लाभ उठा सकते हैं। यहां दो नोट:पहला - यह सुविधा पिछड़ी संगत है और 5.7 दास भी इसका लाभ उठा सकते हैं। दूसरा - एक अनुस्मारक कि 8.0 अभी भी बीटा अवस्था में है, हम आपको उत्पादन पर बीटा सॉफ़्टवेयर का उपयोग करने के लिए प्रोत्साहित नहीं करते हैं, हालांकि इसकी सख्त आवश्यकता है, यह परीक्षण करने का एक विकल्प है। यह सुविधा न केवल आपकी मदद कर सकती है जब आपके दास पिछड़ रहे हों। वे पूरी तरह से पकड़े जा सकते हैं, लेकिन जब आप एक नया दास बनाते हैं या मौजूदा दास को पुन:प्रावधान करते हैं, तो वह दास पिछड़ जाएगा। "WRITESET" मोड का उपयोग करने की क्षमता होने से नए होस्ट को प्रोविज़न करने की प्रक्रिया बहुत तेज़ हो जाएगी।
कुल मिलाकर, इस सुविधा का इतना बड़ा प्रभाव होगा जितना आप सोच सकते हैं। प्रदर्शन में प्रतिगमन दिखाने वाले सभी बेंचमार्क को देखते हुए जब MySQL कम समरूपता के ट्रैफ़िक को संभालता है, तो कुछ भी जो ऐसे वातावरण में प्रतिकृति को गति देने में मदद कर सकता है वह एक बहुत बड़ा सुधार है।
यदि आप इंटरमीडिएट मास्टर्स का उपयोग करते हैं, तो यह भी देखने के लिए एक विशेषता है। कोई भी मध्यवर्ती मास्टर कुछ क्रमांकन जोड़ता है कि कैसे लेनदेन को संभाला और निष्पादित किया जाता है - वास्तविक दुनिया में, एक मध्यवर्ती मास्टर पर कार्यभार लगभग हमेशा मास्टर की तुलना में कम समानांतर होगा। बेहतर समानांतरकरण की अनुमति देने के लिए राइटसेट का उपयोग करने से न केवल मध्यवर्ती मास्टर पर समानांतरीकरण में सुधार होता है, बल्कि यह अपने सभी दासों पर समानांतरकरण में भी सुधार कर सकता है। यह संभव है (हालांकि यह सत्यापित करने के लिए गंभीर परीक्षण की आवश्यकता होगी कि सभी टुकड़े सही ढंग से फिट होंगे) अपने दासों के प्रतिकृति प्रदर्शन में सुधार के लिए 8.0 मध्यवर्ती मास्टर का उपयोग करने के लिए (कृपया ध्यान रखें कि MySQL 5.7 दास राइटसेट डेटा को समझ सकता है और इसका उपयोग कर सकता है, भले ही यह इसे अपने आप उत्पन्न नहीं कर सकता)। बेशक, 8.0 से 5.7 की नकल करना काफी मुश्किल लगता है (और यह केवल इसलिए नहीं है क्योंकि 8.0 अभी भी बीटा है)। कुछ परिस्थितियों में, यह काम कर सकता है और आपके 5.7 दासों पर CPU उपयोग को गति दे सकता है।
MySQL प्रतिकृति में अन्य परिवर्तन
राइटसेट का परिचय, जबकि यह सबसे दिलचस्प है, यह एकमात्र परिवर्तन नहीं है जो MySQL 8.0 में MySQL प्रतिकृति में हुआ है। आइए कुछ अन्य महत्वपूर्ण परिवर्तनों के बारे में भी जानें। यदि आप MySQL 5.0 से पुराने मास्टर का उपयोग करते हैं, तो 8.0 इसके बाइनरी लॉग प्रारूप का समर्थन नहीं करेगा। हम ऐसे कई सेटअप देखने की उम्मीद नहीं करते हैं, लेकिन यदि आप प्रतिकृति के साथ कुछ बहुत पुराने MySQL का उपयोग करते हैं, तो यह निश्चित रूप से अपग्रेड करने का समय है।
यह सुनिश्चित करने के लिए डिफ़ॉल्ट मान बदल गए हैं कि प्रतिकृति यथासंभव क्रैश-सुरक्षित है:master_info_repository और relay_log_info_repository TABLE पर सेट हैं। Expire_log_days भी बदल दिया गया है - अब डिफ़ॉल्ट मान 30 है। expire_log_days के अतिरिक्त , एक नया चर जोड़ा गया है, binlog_expire_log_seconds , जो अधिक बारीक बिनलॉग रोटेशन नीति की अनुमति देता है। कुछ अतिरिक्त टाइमस्टैम्प को बाइनरी लॉग में जोड़ा गया है ताकि माइक्रोसेकंड ग्रैन्युलैरिटी को पेश करते हुए प्रतिकृति लैग की निगरानी में सुधार किया जा सके।
हर तरह से, यह MySQL प्रतिकृति से संबंधित परिवर्तनों और सुविधाओं की पूरी सूची नहीं है। यदि आप अधिक जानना चाहते हैं, तो आप MySQL चैंज की जांच कर सकते हैं। सुनिश्चित करें कि आपने उन सभी की समीक्षा की है - अब तक, सभी 8.0 संस्करणों में सुविधाएं जोड़ी गई हैं।
जैसा कि आप देख सकते हैं, MySQL प्रतिकृति अभी भी बदल रही है और बेहतर हो रही है। जैसा कि हमने शुरुआत में कहा था, यह एक धीमी गति वाली प्रक्रिया होनी चाहिए लेकिन आगे क्या है यह देखना वाकई बहुत अच्छा है। समूह प्रतिकृति के काम को "नियमित" MySQL प्रतिकृति में पुन:उपयोग करने और पुन:उपयोग करने के लिए भी अच्छा है।
