पिछले भाग में हमने विभिन्न बैकअप संपीड़न स्तरों और विधियों के लिए बैकअप समय और संपीड़न की प्रभावशीलता का परीक्षण किया है। इस ब्लॉग में हम अपने प्रयासों को जारी रखेंगे और हम अधिक सेटिंग्स के बारे में बात करेंगे, जो शायद, अधिकांश उपयोगकर्ता वास्तव में नहीं बदलते हैं, फिर भी बैकअप प्रक्रिया पर उनका प्रभाव दिखाई दे सकता है।
सेटअप पिछले भाग की तरह ही है:हम ProxySQL और Keepalived के साथ MariaDB मास्टर-स्लेव प्रतिकृति क्लस्टर का उपयोग करेंगे।
हमने sysbench का उपयोग करके 7.6GB डेटा जेनरेट किया है:
sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=4 --mysql-host=10.0.0.111 --mysql-user=sbtest --mysql-password=sbtest --mysql-port=6033 --tables=32 --table-size=1000000 preparePIGZ का उपयोग करना
इस बार हम अपने बैकअप के लिए समानांतर gzip के लिए PIGZ का उपयोग करें सक्षम करने जा रहे हैं। पहले की तरह, हम यह देखने के लिए प्रत्येक संपीड़न स्तर का परीक्षण करेंगे कि यह कैसा प्रदर्शन करता है।
हम इंस्टेंस पर स्थानीय रूप से बैकअप स्टोर कर रहे हैं, इंस्टेंस के साथ कॉन्फ़िगर किया गया है 4 वीसीपीयू.
परिणाम उम्मीद के मुताबिक है। जब हम केवल एक सीपीयू कोर का उपयोग करते थे, तब बैकअप प्रक्रिया काफी तेज थी। बैकअप का आकार काफी हद तक समान रहता है, इसके महत्वपूर्ण रूप से बदलने का कोई वास्तविक कारण नहीं है। यह स्पष्ट है कि पिग्ज़ का उपयोग करने से बैकअप समय में सुधार होता है। हालांकि समानांतर gzip का उपयोग करने का एक स्याह पक्ष है, और यह CPU उपयोग है:
जैसा कि आप देख सकते हैं, CPU उपयोग आसमान छू रहा है और यह लगभग 100% तक पहुंच गया है। उच्च संपीड़न स्तरों के लिए। डेटाबेस सर्वर पर CPU उपयोग बढ़ाना आवश्यक रूप से सबसे अच्छा विचार नहीं है, आमतौर पर, हम चाहते हैं कि CPU डेटाबेस के लिए उपलब्ध हो। दूसरी ओर, यदि हमारे पास बैकअप लेने के लिए समर्पित प्रतिकृति है और, मान लें, भारी प्रश्न - एक नोड जिसका उपयोग OLTP प्रकार के ट्रैफ़िक की सेवा के लिए नहीं किया जाता है, तो हम बैकअप को कम करने के लिए समानांतर gzip को सक्षम कर सकते हैं समय। जैसा कि स्पष्ट रूप से देखा जा सकता है, यह हर किसी के लिए एक विकल्प नहीं है, लेकिन यह निश्चित रूप से कुछ ऐसा है जिसे आप कुछ विशेष परिदृश्यों में उपयोगी पा सकते हैं। बस यह ध्यान रखें कि CPU उपयोग कुछ ऐसा है जिसे आपको ट्रैक करने की आवश्यकता है क्योंकि यह प्रश्नों की विलंबता को प्रभावित करेगा और, इसके माध्यम से, यह उपयोगकर्ता अनुभव को प्रभावित करेगा - कुछ ऐसा जो हमें डेटाबेस के साथ काम करते समय हमेशा विचार करना चाहिए।
Xtrabackup समानांतर कॉपी थ्रेड
एक अन्य सेटिंग जिसे हम हाइलाइट करना चाहते हैं, वह है एक्स्ट्राबैकअप पैरेलल कॉपी थ्रेड्स। यह समझने के लिए कि यह क्या है, आइए Xtrabackup (या MariaBackup) के काम करने के तरीके के बारे में थोड़ी बात करें। संक्षेप में, वे उपकरण एक ही समय में दो कार्य करते हैं। वे किसी भी अपडेट के लिए InnoDB रीडो लॉग की निगरानी करते हुए डेटा, भौतिक फ़ाइलों को डेटाबेस सर्वर से बैकअप स्थान पर कॉपी करते हैं। बैकअप में फ़ाइलें और इनो डीबी में सभी परिवर्तनों का रिकॉर्ड होता है जो बैकअप प्रक्रिया के दौरान हुआ था। यह, रीड लॉक के साथ बैकअप लॉक या फ्लश टेबल के साथ, बैकअप बनाने की अनुमति देता है जो उस समय के अनुरूप है जब डेटा ट्रांसफर समाप्त हो गया है। Xtrabackup पैरेलल कॉपी थ्रेड्स डेटा ट्रांसफर करने वाले थ्रेड्स की संख्या को परिभाषित करते हैं। अगर हम इसे 1 पर सेट करते हैं, तो एक ही समय में एक फाइल कॉपी की जाएगी। यदि हम इसे 8 पर सेट करते हैं, तो सैद्धांतिक रूप से एक बार में अधिकतम 8 फ़ाइलें स्थानांतरित की जा सकती हैं। बेशक, ऐसी सेटिंग से वास्तव में लाभ उठाने के लिए पर्याप्त तेज़ संग्रहण होना चाहिए। हम Xtrabackup समानांतर कॉपी थ्रेड को 1 से 2 और 4 से 8 में बदलते हुए कई परीक्षण करने जा रहे हैं। हम समानांतर gzip सक्षम के साथ और बिना 6 के संपीड़न स्तर (डिफ़ॉल्ट एक) पर परीक्षण चलाएंगे।
पहले चार बैकअप (27 - 30) समानांतर gzip के बिना बनाए गए हैं, 1 से 2, 4 और 8 समानांतर कॉपी थ्रेड से शुरू। फिर हमने 31 से 34 के बैकअप के लिए इसी प्रक्रिया को दोहराया, इस बार समानांतर gzip का उपयोग करते हुए। जैसा कि आप देख सकते हैं, हमारे मामले में समानांतर प्रतिलिपि धागे के बीच शायद ही कोई अंतर है। यदि हम डेटा सेट के आकार को बढ़ाएंगे तो यह अधिक प्रभावशाली होगा। यदि हम तेज़, अधिक विश्वसनीय संग्रहण का उपयोग करेंगे तो यह बैकअप प्रदर्शन में भी सुधार करेगा। हमेशा की तरह, आपका माइलेज अलग-अलग होगा और अलग-अलग परिवेशों में यह सेटिंग बैकअप प्रक्रिया को हमारे द्वारा यहां देखे गए से अधिक प्रभावित कर सकती है।
नेटवर्क थ्रॉटलिंग
आखिरकार, अपनी लघु श्रृंखला के इस भाग में हम नेटवर्क के उपयोग को कम करने की क्षमता के बारे में बात करना चाहेंगे।
जैसा कि आपने देखा होगा, बैकअप को नोड पर स्थानीय रूप से संग्रहीत किया जा सकता है या इसे कंट्रोलर होस्ट पर भी स्ट्रीम किया जा सकता है। यह नेटवर्क पर होता है और, डिफ़ॉल्ट रूप से, यह "जितनी जल्दी हो सके" किया जाएगा।
कुछ मामलों में, जहां आपका नेटवर्क थ्रूपुट सीमित है (उदाहरण के लिए, क्लाउड इंस्टेंस), आप नेटवर्क ट्रांसफर पर एक सीमा निर्धारित करके मारियाबैकअप के कारण होने वाले नेटवर्क उपयोग को कम करना चाह सकते हैं। जब आप ऐसा करते हैं, तो ClusterControl प्रक्रिया के लिए उपलब्ध बैंडविड्थ को सीमित करने के लिए 'pv' टूल का उपयोग करेगा।
जैसा कि आप देख सकते हैं, पहले बैकअप में लगभग 3 मिनट का समय लगा लेकिन जब हमने नेटवर्क थ्रूपुट को थ्रॉटल किया, बैकअप में 13 मिनट और 37 सेकंड का समय लगा।
दोनों ही मामलों में हमने पिग्ज़ और कंप्रेशन लेवल 1 का इस्तेमाल किया। ऊपर दिया गया ग्राफ दिखाता है कि नेटवर्क को थ्रॉटलिंग करने से सीपीयू का उपयोग भी कम हो गया। यह समझ में आता है, अगर पिगज़ को डेटा ट्रांसफर करने के लिए नेटवर्क का इंतजार करना पड़ता है, तो उसे सीपीयू पर जोर नहीं लगाना पड़ता क्योंकि उसे ज्यादातर समय निष्क्रिय रहना पड़ता है।
उम्मीद है कि आपको यह छोटा ब्लॉग दिलचस्प लगा होगा और शायद यह आपको मारियाबैकअप की कुछ सामान्य रूप से उपयोग नहीं की जाने वाली सुविधाओं और विकल्पों के साथ प्रयोग करने के लिए प्रोत्साहित करेगा। यदि आप अपना कुछ अनुभव साझा करना चाहते हैं, तो हम नीचे टिप्पणी में आपसे सुनना चाहेंगे।
