गैलेरा क्लस्टर पर एसएसटी ऑपरेशन को कैसे रोकें या थ्रॉटल करें

स्टेट स्नैपशॉट ट्रांसफर (एसएसटी) गैलेरा द्वारा उपयोग किए जाने वाले दो तरीकों में से एक है, जब नोड एक क्लस्टर में शामिल हो रहा है, जब तक कि नोड को सिंक और "प्राथमिक घटक" का हिस्सा घोषित नहीं किया जाता है। डेटासेट के आकार और कार्यभार के आधार पर, SST बहुत तेज़ हो सकता है, या एक महंगा ऑपरेशन हो सकता है जो आपकी डेटाबेस सेवा को घुटनों पर ला देगा।

एसएसटी 3 अलग-अलग तरीकों से किया जा सकता है:

mysqldump
rsync (या rsync_wan)
xtrabackup (या xtrabackup-v2, mariabackup)

अधिकांश समय, एक्स्ट्राबैकअप-वी2 और मारियाबैकअप पसंदीदा विकल्प हैं। हम शायद ही कभी लोगों को प्रोडक्शन क्लस्टर में rsync या mysqldump पर चलते हुए देखते हैं।

समस्या

जब एसएसटी शुरू किया जाता है, तो जॉइनर नोड पर कई प्रक्रियाएं शुरू होती हैं, जिन्हें "mysql" उपयोगकर्ता द्वारा निष्पादित किया जाता है:

$ ps -fu mysql
UID         PID   PPID  C STIME TTY          TIME CMD
mysql    117814 129515  0 13:06 ?        00:00:00 /bin/bash -ue /usr//bin/wsrep_sst_xtrabackup-v2 --role donor --address 192.168.55.173:4444/xtrabackup_sst//1 --socket /var/lib/mysql/mysql.sock --datadir
mysql    120036 117814 15 13:06 ?        00:00:06 innobackupex --no-version-check --tmpdir=/tmp/tmp.pMmzIlZJwa --user=backupuser --password=x xxxxxxxxxxxxxx --socket=/var/lib/mysql/mysql.sock --galera-inf
mysql    120037 117814 19 13:06 ?        00:00:07 socat -u stdio TCP:192.168.55.173:4444
mysql    129515      1  1 Oct27 ?        01:11:46 /usr/sbin/mysqld --wsrep_start_position=7ce0e31f-aa46-11e7-abda-56d6a5318485:4949331

डोनर नोड पर रहते हुए:

mysql     43733      1 14 Oct16 ?        03:28:47 /usr/sbin/mysqld --wsrep-new-cluster --wsrep_start_position=7ce0e31f-aa46-11e7-abda-56d6a5318485:272891
mysql     87092  43733  0 14:53 ?        00:00:00 /bin/bash -ue /usr//bin/wsrep_sst_xtrabackup-v2 --role donor --address 192.168.55.172:4444/xtrabackup_sst//1 --socket /var/lib/mysql/mysql.sock --datadir /var/lib/mysql/  --gtid 7ce0e31f-aa46-11e7-abda-56d6a5318485:2883115 --gtid-domain-id 0
mysql     88826  87092 30 14:53 ?        00:00:05 innobackupex --no-version-check --tmpdir=/tmp/tmp.LDdWzbHkkW --user=backupuser --password=x xxxxxxxxxxxxxx --socket=/var/lib/mysql/mysql.sock --galera-info --stream=xbstream /tmp/tmp.oXDumYf392
mysql     88827  87092 30 14:53 ?        00:00:05 socat -u stdio TCP:192.168.55.172:4444

एक बड़े डेटासेट (सैकड़ों GBytes) के विरुद्ध SST कोई मज़ा नहीं है। हार्डवेयर, नेटवर्क और वर्कलोड के आधार पर इसे पूरा होने में घंटों लग सकते हैं। ऑपरेशन के दौरान सर्वर संसाधनों को संतृप्त किया जा सकता है। SST में थ्रॉटलिंग समर्थित होने के बावजूद (केवल xtrabackup और mariabackup के लिए) --rlimit और --use-memory विकल्पों का उपयोग करते हुए, हम तब भी एक अवक्रमित क्लस्टर के संपर्क में रहते हैं जब आपके पास बहुसंख्यक सक्रिय नोड्स समाप्त हो जाते हैं। उदाहरण के लिए, यदि आप बदकिस्मत हैं कि तीन में से केवल एक नोड चल रहा है। इसलिए, आपको सलाह दी जाती है कि शांत घंटों के दौरान एसएसटी करें। हालांकि, आप इस ब्लॉग पोस्ट में वर्णित कुछ मैन्युअल कदम उठाकर एसएसटी से बच सकते हैं।

एसएसटी रोकना

एक एसएसटी को रोकना डोनर और जॉइनर दोनों नोड्स पर किया जाना चाहिए। जॉइनर एसएसटी को यह निर्धारित करने के बाद ट्रिगर करता है कि क्लस्टर के सेक्नो के साथ स्थानीय गैलेरा सेक्नो की तुलना करते समय कितना बड़ा अंतर है। यह wsrep_sst_{wsrep_sst_method} को क्रियान्वित करता है आज्ञा। इसे चुने हुए डोनर द्वारा चुना जाएगा, जो जॉइनर को डेटा स्ट्रीम करना शुरू कर देगा। गैलेरा समूह संचार द्वारा एक बार चुने जाने पर या wsrep_sst_donor में परिभाषित मान के अनुसार, एक दाता नोड में स्नैपशॉट स्थानांतरण की सेवा से इनकार करने की कोई क्षमता नहीं होती है। चर। एक बार सिंकिंग शुरू हो जाने के बाद और आप निर्णय को वापस लेना चाहते हैं, तो ऑपरेशन को रोकने के लिए एक भी कमांड नहीं है।

SST को रोकते समय मूल सिद्धांत यह है:

जॉइनर को गैलेरा ग्रुप कम्युनिकेशन पॉइंट-ऑफ-व्यू (शटडाउन, फेंस, ब्लॉक, रीसेट, अनप्लग केबल, ब्लैकलिस्ट, आदि) से मृत दिखाना है
दाता पर एसएसटी प्रक्रियाओं को मार डालो

कोई यह सोचेगा कि डोनर पर इनोबैकअपेक्स प्रक्रिया (किल -9 {इनोबैकअपेक्स पीआईडी}) को मारना काफी होगा, लेकिन ऐसा नहीं है। यदि आप दाता (या जॉइनर) पर एसएसटी प्रक्रियाओं को जॉइनर को बंद किए बिना मार देते हैं, तो गैलेरा अभी भी जॉइनर को सक्रिय के रूप में देख सकता है और एसएसटी प्रक्रिया को अपूर्ण के रूप में चिह्नित करेगा, इस प्रकार प्रक्रियाओं के एक नए सेट को जारी रखने या फिर से शुरू करने के लिए प्रतिक्रिया देगा। आप एक वर्ग में वापस आ जाएंगे। यह एसएसटी संचालन की सुरक्षा के लिए /usr/bin/wsrep_sst_{method} स्क्रिप्ट का अपेक्षित व्यवहार है जो टाइमआउट के लिए असुरक्षित है (उदाहरण के लिए, यदि यह लंबे समय तक चलने वाला और संसाधन गहन है)।

आइए एक उदाहरण देखें। हमारे पास एक दुर्घटनाग्रस्त जॉइनर नोड है जिसे हम क्लस्टर में फिर से जोड़ना चाहते हैं। हम जॉइनर पर निम्न कमांड चलाकर शुरू करेंगे:

$ systemctl start mysql # or service mysql start

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

$ iptables -A INPUT -p tcp --dport 4444 -j DROP
$ iptables -A INPUT -p tcp --dport 4567:4568 -j DROP

फिर दाता पर, एसएसटी प्रक्रियाओं की पीआईडी प्राप्त करें ("mysql" उपयोगकर्ता के स्वामित्व वाली प्रक्रियाओं की सूची बनाएं):

$ ps -u mysql
   PID TTY          TIME CMD
117814 ?        00:00:00 wsrep_sst_xtrab
120036 ?        00:00:06 innobackupex
120037 ?        00:00:07 socat
129515 ?        01:11:47 mysqld

अंत में, mysqld प्रक्रिया को छोड़कर उन सभी को मार दें (आपको दाता पर mysqld प्रक्रिया को न मारने के लिए बेहद सावधान रहना चाहिए!):

$ kill -9 117814 120036 120037

फिर, दाता MySQL त्रुटि लॉग पर, आपको ~100 सेकंड के बाद दिखाई देने वाली निम्न पंक्ति पर ध्यान देना चाहिए:

2017-10-30 13:24:08 139722424837888 [Warning] WSREP: Could not find peer: 42b85e82-bd32-11e7-87ae-eff2b8dd2ea0
2017-10-30 13:24:08 139722424837888 [Warning] WSREP: 1.0 (192.168.55.172): State transfer to -1.-1 (left the group) failed: -32 (Broken pipe)

इस बिंदु पर, दाता को wsrep_local_state_comment द्वारा रिपोर्ट की गई "समन्वयित" स्थिति में वापस लौटना चाहिए और एसएसटी प्रक्रिया पूरी तरह से ठप हो गई है। दाता अपनी परिचालन स्थिति में वापस आ गया है और पूरी क्षमता से ग्राहकों की सेवा करने में सक्षम है।

जॉइनर पर सफाई प्रक्रिया के लिए, आप बस iptables श्रृंखला को फ्लश कर सकते हैं:

$ iptables -F

या बस -D ध्वज वाले नियमों को हटा दें:

$ iptables -D INPUT -p tcp --dport 4444 -j DROP
$ iptables -D INPUT -p tcp --dport 4567:4568 -j DROP

समान दृष्टिकोण का उपयोग अन्य SST विधियों जैसे rsync, mariabackup और mysqldump के साथ किया जा सकता है।

SST का थ्रॉटलिंग (केवल एक्स्ट्राबैकअप विधि)

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

Xtrabackup को --throttle= के साथ थ्रॉटल किया जा सकता है, यदि आप डरते हैं कि यह आपके डिस्क को संतृप्त करेगा, तो केवल IO ऑपरेशन की संख्या को सीमित करने के लिए, लेकिन यह विकल्प केवल बैकअप प्रक्रिया के रूप में xtrabackup चलाते समय लागू होता है, न कि IO ऑपरेशन की संख्या को सीमित करने के लिए। एक एसएसटी ऑपरेटर के रूप में। इसी तरह के विकल्प rlimit (दर सीमा) के साथ उपलब्ध हैं और RAM के उपयोग को सीमित करने के लिए --use-memory के साथ जोड़ा जा सकता है। MySQL कॉन्फ़िगरेशन फ़ाइल के अंदर [sst] निर्देश के तहत मान सेट करके, हम यह सुनिश्चित कर सकते हैं कि SST ऑपरेशन दाता पर बहुत अधिक भार नहीं डालेगा, भले ही इसे पूरा होने में अधिक समय लग सकता है। डोनर नोड पर, निम्न सेट करें:

[sst]
rlimit=128k
inno-apply-opts="--use-memory=200M"

Percona Xtrabackup SST प्रलेखन पृष्ठ पर अधिक विवरण।

हालांकि, वहाँ एक पकड़ है। प्रक्रिया इतनी धीमी हो सकती है कि यह लेन-देन लॉग के साथ कभी नहीं पकड़ पाएगा जो कि InnoDB लिख रहा है, इसलिए SST कभी भी पूरा नहीं हो सकता है। आम तौर पर, यह स्थिति बहुत ही असामान्य होती है, जब तक कि आपके पास वास्तव में बहुत अधिक लेखन-गहन कार्यभार न हो या आप SST को बहुत सीमित संसाधन आवंटित न करें।

निष्कर्ष

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