एमएचए के साथ शीर्ष सामान्य मुद्दे और उन्हें कैसे ठीक करें

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

गृह मंत्रालय का संक्षिप्त परिचय (मास्टर उच्च उपलब्धता)

MHA का अर्थ है (मास्टर उच्च उपलब्धता) आज भी प्रासंगिक है और व्यापक रूप से आज भी उपयोग किया जाता है, विशेष रूप से गैर-GTID प्रतिकृति पर आधारित मास्टर-स्लेव सेटअप में। गृह मंत्रालय एक विफलता या मास्टर-स्विच अच्छा प्रदर्शन करता है, लेकिन यह कुछ नुकसान और सीमाओं के साथ आता है। एक बार जब एमएचए मास्टर फेलओवर और स्लेव प्रमोशन करता है, तो यह स्वचालित रूप से ~ 30 सेकंड के भीतर अपने डेटाबेस फेलओवर ऑपरेशन को पूरा कर सकता है, जो उत्पादन वातावरण में स्वीकार्य हो सकता है। एमएचए डेटा की निरंतरता सुनिश्चित कर सकता है। यह सब शून्य प्रदर्शन गिरावट के साथ है, और इसके लिए आपके मौजूदा परिनियोजन या सेटअप में किसी अतिरिक्त समायोजन या परिवर्तन की आवश्यकता नहीं है। इसके अलावा, एमएचए को पर्ल के शीर्ष पर बनाया गया है और यह एक ओपन-सोर्स एचए समाधान है - इसलिए हेल्पर्स बनाना या अपने इच्छित सेटअप के अनुसार टूल का विस्तार करना अपेक्षाकृत आसान है। अधिक जानकारी के लिए इस प्रस्तुति को देखें।

एमएचए सॉफ्टवेयर में दो घटक होते हैं, आपको इसकी टोपोलॉजी भूमिका के अनुसार निम्नलिखित पैकेजों में से एक को स्थापित करने की आवश्यकता है:

एमएचए मैनेजर नोड =एमएचए मैनेजर (मैनेजर)/एमएचए नोड (डेटा नोड)

मास्टर/स्लेव नोड्स =एमएचए नोड (डेटा नोड)

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

ध्यान दें कि एमएचए वर्तमान में सक्रिय रूप से बनाए नहीं रखा गया है, लेकिन वर्तमान संस्करण स्वयं स्थिर है और उत्पादन के लिए "काफी अच्छा" हो सकता है। कुछ मुद्दों को हल करने या सॉफ़्टवेयर को पैच प्रदान करने के लिए आप अभी भी जीथब के माध्यम से अपनी आवाज़ को प्रतिध्वनित कर सकते हैं।

प्रमुख सामान्य समस्याएं

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

दास पिछड़ रहा है, गैर-संवादात्मक/स्वचालित विफलता विफल!

यह एक सामान्य समस्या है जिसके कारण स्वचालित विफलता निरस्त या विफल हो जाती है। यह सरल लग सकता है लेकिन यह केवल एक विशिष्ट समस्या की ओर इशारा नहीं करता है। दास अंतराल के अलग-अलग कारण हो सकते हैं:

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

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

[email protected]:~$ masterha_manager --conf=/etc/app1.cnf --remove_dead_master_conf --ignore_last_failover
Mon May  6 08:43:46 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon May  6 08:43:46 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Mon May  6 08:43:46 2019 - [info] Reading server configuration from /etc/app1.cnf..
…
Mon May  6 08:43:57 2019 - [info] Checking master reachability via MySQL(double check)...
Mon May  6 08:43:57 2019 - [info]  ok.
Mon May  6 08:43:57 2019 - [info] Alive Servers:
Mon May  6 08:43:57 2019 - [info]   192.168.10.50(192.168.10.50:3306)
Mon May  6 08:43:57 2019 - [info]   192.168.10.70(192.168.10.70:3306)
Mon May  6 08:43:57 2019 - [info] Alive Slaves:
Mon May  6 08:43:57 2019 - [info]   192.168.10.50(192.168.10.50:3306)  Version=5.7.23-23-log (oldest major version between slaves) log-bin:enabled
Mon May  6 08:43:57 2019 - [info]     Replicating from 192.168.10.60(192.168.10.60:3306)
Mon May  6 08:43:57 2019 - [info]     Primary candidate for the new Master (candidate_master is set)
Mon May  6 08:43:57 2019 - [info]   192.168.10.70(192.168.10.70:3306)  Version=5.7.23-23-log (oldest major version between slaves) log-bin:enabled
Mon May  6 08:43:57 2019 - [info]     Replicating from 192.168.10.60(192.168.10.60:3306)
Mon May  6 08:43:57 2019 - [info]     Not candidate for the new Master (no_master is set)
Mon May  6 08:43:57 2019 - [info] Starting Non-GTID based failover.
….
Mon May  6 08:43:59 2019 - [info] * Phase 3.4: New Master Diff Log Generation Phase..
Mon May  6 08:43:59 2019 - [info] 
Mon May  6 08:43:59 2019 - [info] Server 192.168.10.50 received relay logs up to: binlog.000004:106167341
Mon May  6 08:43:59 2019 - [info] Need to get diffs from the latest slave(192.168.10.70) up to: binlog.000005:240412 (using the latest slave's relay logs)
Mon May  6 08:43:59 2019 - [info] Connecting to the latest slave host 192.168.10.70, generating diff relay log files..
Mon May  6 08:43:59 2019 - [info] Executing command: apply_diff_relay_logs --command=generate_and_send --scp_user=vagrant --scp_host=192.168.10.50 --latest_mlf=binlog.000005 --latest_rmlp=240412 --target_mlf=binlog.000004 --target_rmlp=106167341 --server_id=3 --diff_file_readtolatest=/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506084355.binlog --workdir=/tmp --timestamp=20190506084355 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --relay_dir=/var/lib/mysql --current_relay_log=relay-bin.000007 
Mon May  6 08:44:00 2019 - [info] 
    Relay log found at /var/lib/mysql, up to relay-bin.000007
 Fast relay log position search failed. Reading relay logs to find..
Reading relay-bin.000007
 Binlog Checksum enabled
 Master Version is 5.7.23-23-log
 Binlog Checksum enabled
…
…...
 Target relay log file/position found. start_file:relay-bin.000004, start_pos:106167468.
 Concat binary/relay logs from relay-bin.000004 pos 106167468 to relay-bin.000007 EOF into /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506084355.binlog ..
 Binlog Checksum enabled
 Binlog Checksum enabled
  Dumping binlog format description event, from position 0 to 361.. ok.
  Dumping effective binlog data from /var/lib/mysql/relay-bin.000004 position 106167468 to tail(1074342689)..Out of memory!
Mon May  6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1090]  Generating diff files failed with return code 1:0.
Mon May  6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1584] Recovering master server failed.
Mon May  6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/ManagerUtil.pm, ln178] Got ERROR:  at /usr/local/bin/masterha_manager line 65.
Mon May  6 08:44:00 2019 - [info] 

----- Failover Report -----

app1: MySQL Master failover 192.168.10.60(192.168.10.60:3306)

Master 192.168.10.60(192.168.10.60:3306) is down!

Check MHA Manager logs at testnode20 for details.

Started automated(non-interactive) failover.
Invalidated master IP address on 192.168.10.60(192.168.10.60:3306)
The latest slave 192.168.10.70(192.168.10.70:3306) has all relay logs for recovery.
Selected 192.168.10.50(192.168.10.50:3306) as a new master.
Recovering master server failed.
Got Error so couldn't continue failover from here.

इस प्रकार, विफलता विफल रही। ऊपर दिए गए इस उदाहरण से पता चलता है कि नोड 192.168.10.70 में सबसे अद्यतन रिले लॉग हैं। हालाँकि, इस उदाहरण परिदृश्य में, नोड 192.168.10.70 को no_master के रूप में सेट किया गया है क्योंकि इसकी मेमोरी कम है। 192.168.10.50 गुलाम को वापस पाने की कोशिश करने पर यह विफल हो जाता है!

समाधान/समाधान:

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

/usr/local/bin/masterha_check_repl --conf=/etc/app1.cnf

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

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

असंगत दास, अंतर लागू करना विफल रहा!

स्लेव लैग की प्रासंगिकता में, चूंकि MHA एक उम्मीदवार मास्टर के साथ रिले लॉग को सिंक करने का प्रयास करेगा, सुनिश्चित करें कि आपका डेटा सिंक में है। नीचे एक उदाहरण के लिए कहें:

...
 Concat succeeded.
 Generating diff relay log succeeded. Saved at /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog .
 scp testnode7:/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog to [email protected](22) succeeded.
Mon May  6 05:43:53 2019 - [info]  Generating diff files succeeded.
Mon May  6 05:43:53 2019 - [info] 
Mon May  6 05:43:53 2019 - [info] * Phase 3.5: Master Log Apply Phase..
Mon May  6 05:43:53 2019 - [info] 
Mon May  6 05:43:53 2019 - [info] *NOTICE: If any error happens from this phase, manual recovery is needed.
Mon May  6 05:43:53 2019 - [info] Starting recovery on 192.168.10.50(192.168.10.50:3306)..
Mon May  6 05:43:53 2019 - [info]  Generating diffs succeeded.
Mon May  6 05:43:53 2019 - [info] Waiting until all relay logs are applied.
Mon May  6 05:43:53 2019 - [info]  done.
Mon May  6 05:43:53 2019 - [info] Getting slave status..
Mon May  6 05:43:53 2019 - [info] This slave(192.168.10.50)'s Exec_Master_Log_Pos equals to Read_Master_Log_Pos(binlog.000010:161813650). No need to recover from Exec_Master_Log_Pos.
Mon May  6 05:43:53 2019 - [info] Connecting to the target slave host 192.168.10.50, running recover script..
Mon May  6 05:43:53 2019 - [info] Executing command: apply_diff_relay_logs --command=apply --slave_user='cmon' --slave_host=192.168.10.50 --slave_ip=192.168.10.50  --slave_port=3306 --apply_files=/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog --workdir=/tmp --target_version=5.7.23-23-log --timestamp=20190506054328 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --slave_pass=xxx
Mon May  6 05:43:53 2019 - [info] 
MySQL client version is 5.7.23. Using --binary-mode.
Applying differential binary/relay log files /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog on 192.168.10.50:3306. This may take long time...
mysqlbinlog: Error writing file 'UNOPENED' (Errcode: 32 - Broken pipe)
FATAL: applying log files failed with rc 1:0!
Error logs from testnode5:/tmp/relay_log_apply_for_192.168.10.50_3306_20190506054328_err.log (the last 200 lines)..
ICwgMmM5MmEwZjkzY2M5MTU3YzAxM2NkZTk4ZGQ1ODM0NDEgLCAyYzkyYTBmOTNjYzkxNTdjMDEz
….
…..
M2QxMzc5OWE1NTExOTggLCAyYzkyYTBmOTNjZmI1YTdhMDEzZDE2NzhiNDc3NDIzNCAsIDJjOTJh
MGY5M2NmYjVhN2EwMTNkMTY3OGI0N2Q0MjMERROR 1062 (23000) at line 72: Duplicate entry '12583545' for key 'PRIMARY'
5ICwgMmM5MmEwZjkzY2ZiNWE3YTAxM2QxNjc4YjQ4
OTQyM2QgLCAyYzkyYTBmOTNjZmI1YTdhMDEzZDE2NzhiNDkxNDI1MSAsIDJjOTJhMGY5M2NmYjVh
N2EwMTNkMTczN2MzOWM3MDEzICwgMmM5MmEwZjkzY2ZiNWE3YTAxM2QxNzM3YzNhMzcwMTUgLCAy
…
--------------

Bye
 at /usr/local/bin/apply_diff_relay_logs line 554.
    eval {...} called at /usr/local/bin/apply_diff_relay_logs line 514
    main::main() called at /usr/local/bin/apply_diff_relay_logs line 121
Mon May  6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1399]  Applying diffs failed with return code 22:0.
Mon May  6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1584] Recovering master server failed.
Mon May  6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/ManagerUtil.pm, ln178] Got ERROR:  at /usr/local/bin/masterha_manager line 65.
Mon May  6 05:43:53 2019 - [info]

एक असंगत क्लस्टर वास्तव में खराब है, खासकर जब स्वचालित विफलता सक्षम होती है। इस मामले में, फ़ेलओवर आगे नहीं बढ़ सकता क्योंकि यह प्राथमिक कुंजी '12583545 के लिए डुप्लिकेट प्रविष्टि का पता लगाता है। '।

समाधान/समाधान:

अपने क्लस्टर की असंगत स्थिति से बचने के लिए आप यहां कई चीजें कर सकते हैं।

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

मास्टर पर हार्डवेयर की विफलता लेकिन दास अभी तक पकड़ में नहीं आए हैं

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

समाधान/समाधान

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

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

वीआईपी (वर्चुअल आईपी) फेलओवर के कारण स्प्लिट-ब्रेन होता है

गृह मंत्रालय, डिफ़ॉल्ट रूप से, किसी भी वीआईपी प्रबंधन को नहीं संभालता है। हालांकि, एमएचए के कॉन्फ़िगरेशन के साथ इसे शामिल करना आसान है और विफलता के दौरान एमएचए को आप जो करना चाहते हैं उसके अनुसार हुक असाइन करें। आप अपनी खुद की स्क्रिप्ट सेट कर सकते हैं और इसे पैरामीटर मास्टर_आईपी_फेलओवर_स्क्रिप्ट या मास्टर_आईपी_ऑनलाइन_चेंज_स्क्रिप्ट से जोड़ सकते हैं। नमूना स्क्रिप्ट भी हैं जो /samples/scripts/ निर्देशिका में स्थित हैं। लेकिन आइए मुख्य मुद्दे पर वापस जाएं और वह है फेलओवर के दौरान मस्तिष्क का विभाजन।

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

समाधान/समाधान:

जैसा कि पहले कहा गया है, कुछ स्वचालित विफलता से बचना पसंद कर सकते हैं जब तक कि चेक ने यह निर्धारित नहीं किया है कि मास्टर पूरी तरह से नीचे है (जैसे हार्डवेयर विफलता), यानी स्लेव नोड्स भी उस तक पहुंचने में सक्षम नहीं हैं। विचार यह है कि एमएचए नोड कंट्रोलर और मास्टर के बीच एक नेटवर्क गड़बड़ के कारण एक गलत सकारात्मक हो सकता है, इसलिए इस मामले में एक मानव बेहतर अनुकूल हो सकता है कि यह निर्णय लेने के लिए कि फेलओवर करना है या नहीं।

झूठे अलार्म से निपटने के दौरान, MHA का एक पैरामीटर होता है जिसे माध्यमिक_चेक_स्क्रिप्ट कहा जाता है। यहां रखा गया मान आपकी कस्टम स्क्रिप्ट हो सकता है या आप अंतर्निहित स्क्रिप्ट का उपयोग कर सकते हैं /usr/local/bin/masterha_secondary_check जिसे एमएचए मैनेजर पैकेज के साथ भेज दिया जाता है। यह अतिरिक्त जांच जोड़ता है जो वास्तव में झूठी सकारात्मकता से बचने के लिए अनुशंसित दृष्टिकोण है। अपने स्वयं के सेटअप से नीचे दिए गए उदाहरण में, मैं अंतर्निहित स्क्रिप्ट का उपयोग कर रहा हूं masterha_secondary_check :

secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.10.50 --user=root --master_host=testnode6 --master_ip=192.168.10.60 --master_port=3306

उपरोक्त उदाहरण में, MHA प्रबंधक दास नोड्स (-s तर्क द्वारा निर्दिष्ट) की सूची के आधार पर एक लूप करेगा जो MySQL मास्टर (192.168.10.60) होस्ट के खिलाफ कनेक्शन की जांच करेगा। ध्यान दें कि, उदाहरण में ये स्लेव नोड्स कुछ बाहरी रिमोट नोड हो सकते हैं जो क्लस्टर के भीतर डेटाबेस नोड्स से कनेक्शन स्थापित कर सकते हैं। यह विशेष रूप से उन सेटअपों के लिए एक अनुशंसित दृष्टिकोण है जहां एमएचए प्रबंधक डेटाबेस नोड्स की तुलना में एक अलग डेटासेंटर या अलग नेटवर्क पर चल रहा है। नीचे दिया गया क्रम बताता है कि यह चेक के साथ कैसे आगे बढ़ता है:

एमएचए होस्ट से -> पहले स्लेव नोड (आईपी:192.168.10.50) के लिए टीसीपी कनेक्शन की जांच करें। आइए इसे कनेक्शन ए कहते हैं। फिर स्लेव नोड से, मास्टर नोड के लिए टीसीपी कनेक्शन की जांच करता है (192.168.10.60)। आइए इस कनेक्शन बी को कॉल करें।

यदि "कनेक्शन ए" सफल रहा लेकिन "कनेक्शन बी" दोनों मार्गों में असफल रहा, तो masterha_secondary_check स्क्रिप्ट रिटर्न कोड 0 के साथ बाहर निकलती है और एमएचए मैनेजर तय करता है कि MySQL मास्टर वास्तव में मर चुका है, और फेलओवर शुरू कर देगा। अगर "कनेक्शन ए" असफल रहा, तो masterha_secondary_check रिटर्न कोड 2 के साथ बाहर निकलता है और एमएचए मैनेजर का अनुमान है कि नेटवर्क की समस्या है और यह फेलओवर शुरू नहीं करता है। अगर "कनेक्शन बी" सफल रहा, तो masterha_secondary_check रिटर्न कोड 3 के साथ बाहर निकलता है और एमएचए मैनेजर समझता है कि MySQL मास्टर सर्वर वास्तव में जीवित है, और फेलओवर शुरू नहीं करता है।

लॉग के आधार पर विफलता के दौरान यह कैसे प्रतिक्रिया करता है इसका एक उदाहरण,

Tue May  7 05:31:57 2019 - [info]  OK.
Tue May  7 05:31:57 2019 - [warning] shutdown_script is not defined.
Tue May  7 05:31:57 2019 - [info] Set master ping interval 1 seconds.
Tue May  7 05:31:57 2019 - [info] Set secondary check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306
Tue May  7 05:31:57 2019 - [info] Starting ping health check on 192.168.10.60(192.168.10.60:3306)..
Tue May  7 05:31:58 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May  7 05:31:58 2019 - [warning] Connection failed 1 time(s)..
Tue May  7 05:31:58 2019 - [info] Executing SSH check script: exit 0
Tue May  7 05:31:58 2019 - [info] Executing secondary network check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306  --user=vagrant  --master_host=192.168.10.60  --master_ip=192.168.10.60  --master_port=3306 --master_user=cmon [email protected] --ping_type=SELECT
Master is reachable from 192.168.10.50!
Tue May  7 05:31:58 2019 - [warning] Master is reachable from at least one of other monitoring servers. Failover should not happen.
Tue May  7 05:31:59 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May  7 05:31:59 2019 - [warning] Connection failed 2 time(s)..
Tue May  7 05:32:00 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May  7 05:32:00 2019 - [warning] Connection failed 3 time(s)..
Tue May  7 05:32:01 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May  7 05:32:01 2019 - [warning] Connection failed 4 time(s)..
Tue May  7 05:32:03 2019 - [warning] HealthCheck: Got timeout on checking SSH connection to 192.168.10.60! at /usr/local/share/perl/5.26.1/MHA/HealthCheck.pm line 343.
Tue May  7 05:32:03 2019 - [warning] Secondary network check script returned errors. Failover should not start so checking server status again. Check network settings for details.
Tue May  7 05:32:04 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May  7 05:32:04 2019 - [warning] Connection failed 1 time(s)..
Tue May  7 05:32:04 2019 - [info] Executing secondary network check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306  --user=vagrant  --master_host=192.168.10.60  --master_ip=192.168.10.60  --master_port=3306 --master_user=cmon [email protected] --ping_type=SELECT
Tue May  7 05:32:04 2019 - [info] Executing SSH check script: exit 0

जोड़ने के लिए एक और चीज शटडाउन_स्क्रिप्ट पैरामीटर के लिए एक मान निर्दिष्ट कर रही है। यह स्क्रिप्ट विशेष रूप से उपयोगी है यदि आपको उचित स्टोनिथ या नोड फेंसिंग को लागू करना है ताकि यह मृतकों में से न उठे। यह डेटा असंगति से बच सकता है।

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

गृह मंत्रालय में SPOF से बचना

MHA विभिन्न कारणों से क्रैश हो सकता है, और दुर्भाग्य से, इसे ठीक करने के लिए कोई अंतर्निहित सुविधा नहीं है, अर्थात MHA के लिए उच्च उपलब्धता। हालांकि, जैसा कि हमने अपने पिछले ब्लॉग में चर्चा की है "मास्टर उच्च उपलब्धता प्रबंधक (एमएचए) क्रैश हो गया है! अब मैं क्या करूं?", एमएचए के लिए एसपीओएफ से बचने का एक तरीका है।

समाधान/समाधान:

आप क्लस्टर संसाधन प्रबंधक (सीआरएम) द्वारा संचालित सक्रिय/स्टैंडबाय नोड्स बनाने के लिए पेसमेकर का लाभ उठा सकते हैं। वैकल्पिक रूप से, आप MHA प्रबंधक नोड के स्वास्थ्य की जांच करने के लिए एक स्क्रिप्ट बना सकते हैं। उदाहरण के लिए, आप एक स्टैंड-बाय नोड का प्रावधान कर सकते हैं जो अंतर्निहित स्क्रिप्ट को चलाने के लिए ssh'ing द्वारा सक्रिय रूप से एमएचए प्रबंधक नोड की जांच करता है masterha_check_status बिल्कुल नीचे की तरह:

[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf
app1 is stopped(2:NOT_RUNNING).

फिर कुछ नोड फेंसिंग करें यदि वह नियंत्रक बोर्क है। आप एक सहायक स्क्रिप्ट के साथ एमएचए टूल का विस्तार भी कर सकते हैं जो क्रॉन जॉब के माध्यम से चलती है और मास्टरहा_मैनेजर स्क्रिप्ट की सिस्टम प्रक्रिया की निगरानी करती है और प्रक्रिया समाप्त होने पर इसे फिर से शुरू करती है।

विफलता के दौरान डेटा हानि

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

एमएचए के साथ डेटा हानि के साथ ध्यान देने वाली एक और महत्वपूर्ण बात यह है कि जब जीटीआईडी का उपयोग बिना सेमी-सिंक सक्षम किए किया जाता है। GTID के साथ MHA ssh के माध्यम से मास्टर से कनेक्ट नहीं होगा, लेकिन पहले दास के साथ नोड पुनर्प्राप्ति के लिए बाइनरी लॉग को सिंक करने का प्रयास करेगा। यह संभावित रूप से एमएचए गैर-जीटीआईडी की तुलना में अधिक डेटा हानि का कारण बन सकता है जिसमें सेमी-सिंक सक्षम नहीं है।

समाधान/समाधान

स्वचालित फ़ेलओवर करते समय, उन परिदृश्यों की सूची बनाएँ जब आप अपने MHA के फ़ेलओवर की अपेक्षा करते हैं। चूंकि एमएचए मास्टर-स्लेव प्रतिकृति से निपट रहा है, तो डेटा हानि से बचने के लिए हमारी सलाह निम्नलिखित है:

दोषरहित सेमी-सिंक प्रतिकृति सक्षम करें (संस्करण MySQL 5.7 में मौजूद है)
GTID-आधारित प्रतिकृति का उपयोग करें। बेशक, आप बिनलॉग के x और y निर्देशांकों का उपयोग करके पारंपरिक प्रतिकृति का उपयोग कर सकते हैं। हालाँकि, यह चीजों को और अधिक कठिन और समय लेने वाला बनाता है जब आपको एक विशिष्ट बाइनरी लॉग प्रविष्टि का पता लगाने की आवश्यकता होती है जिसे दास पर लागू नहीं किया गया था। इसलिए, MySQL में GTID के साथ, गलत लेनदेन का पता लगाना आसान है।
आपके MySQL मास्टर-स्लेव प्रतिकृति के ACID अनुपालन के लिए, इन विशिष्ट चरों को सक्षम करें:sync_binlog =1, innodb_flush_log_at_trx_commit =1. यह महंगा है क्योंकि जब MySQL fsync() फ़ंक्शन को कॉल करता है, और प्रदर्शन के लिए इसे अधिक प्रोसेसिंग पावर की आवश्यकता होती है। अधिक संख्या में लिखने के मामले में डिस्क बाध्य किया जा सकता है। हालांकि, बैटरी-बैकअप कैश के साथ RAID का उपयोग करने से आपकी डिस्क I/O की बचत होती है। इसके अतिरिक्त, MySQL ने स्वयं बाइनरी लॉग ग्रुप कमिट के साथ सुधार किया है लेकिन फिर भी बैकअप कैश का उपयोग करने से कुछ डिस्क सिंक को बचाया जा सकता है।
समानांतर प्रतिकृति या बहु-थ्रेडेड दास प्रतिकृति का लाभ उठाएं। यह आपके दासों को अधिक प्रदर्शनकारी बनने में मदद कर सकता है, और स्वामी के खिलाफ गुलामों से बचा जा सकता है। आप नहीं चाहते कि आपका स्वचालित फ़ेलओवर तब हो जब मास्टर ssh या tcp कनेक्शन के माध्यम से बिल्कुल भी उपलब्ध न हो, या यदि उसे डिस्क विफलता का सामना करना पड़ा, और आपके दास पिछड़ रहे हों। इससे डेटा हानि हो सकती है।
ऑनलाइन या मैन्युअल फ़ेलओवर करते समय, यह सबसे अच्छा है कि आप इसे गैर-पीक अवधि के दौरान कर रहे हैं ताकि अप्रत्याशित दुर्घटना से बचा जा सके जिससे डेटा हानि हो सकती है। या जब बहुत सारी गतिविधि चल रही हो, तो समय लेने वाली खोजों से बचने के लिए जो आपके बाइनरी लॉग्स के माध्यम से पकड़ में आती हैं।

MHA का कहना है कि APP नहीं चल रहा है, या फ़ेलओवर काम नहीं कर रहा है। मुझे क्या करना चाहिए?

बिल्ट-इन स्क्रिप्ट का उपयोग करते हुए रनिंग चेक मास्टरहा_चेक_स्टैटस यह जांच करेगा कि क्या मास्ट्रेहा_मैनेजर स्क्रिप्ट चल रही है। अन्यथा, आपको नीचे की तरह एक त्रुटि मिलेगी:

[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf                                                                                                                       app1 is stopped(2:NOT_RUNNING).

हालांकि, कुछ ऐसे मामले हैं जहां masterha_manager होने पर भी आपको NOT_RUNNING प्राप्त हो सकता है। चल रहा है। यह आपके द्वारा सेट किए गए ssh_user के विशेषाधिकार के कारण हो सकता है, या आप किसी भिन्न सिस्टम उपयोगकर्ता के साथ masterha_manager चलाते हैं, या ssh उपयोगकर्ता को अनुमति से इनकार किया गया है।

समाधान/समाधान:

गृह मंत्रालय ssh_user . का उपयोग करेगा यदि निर्दिष्ट किया गया है तो कॉन्फ़िगरेशन में परिभाषित किया गया है। अन्यथा, वर्तमान सिस्टम उपयोगकर्ता का उपयोग करेगा जिसका उपयोग आप MHA कमांड को लागू करने के लिए करते हैं। स्क्रिप्ट चलाते समय masterha_check_status उदाहरण के लिए, आपको यह सुनिश्चित करने की आवश्यकता है कि Masterha_manager उसी उपयोगकर्ता के साथ चलता है जो ssh_user में निर्दिष्ट है आपकी कॉन्फ़िगरेशन फ़ाइल में, या उपयोगकर्ता जो क्लस्टर में अन्य डेटाबेस नोड्स के साथ इंटरफ़ेस करेगा। आपको यह सुनिश्चित करने की आवश्यकता है कि इसमें पासवर्ड-रहित, कोई पासफ़्रेज़ SSH कुंजियाँ नहीं हैं, इसलिए MHA को उन नोड्स से कनेक्शन स्थापित करते समय कोई समस्या नहीं होगी जिन पर MHA निगरानी कर रहा है।

ध्यान दें कि आपको ssh_user . की आवश्यकता है निम्नलिखित तक पहुंच प्राप्त करने के लिए:

MHA द्वारा मॉनिटर किए जा रहे MySQL नोड्स के बाइनरी और रिले लॉग को पढ़ सकते हैं
एमएचए निगरानी लॉग तक पहुंच होनी चाहिए। गृह मंत्रालय में इन मापदंडों को देखें:Master_binlog_dir, Manager_workdir, और manager_log
एमएचए कॉन्फ़िगरेशन फ़ाइल तक पहुंच होनी चाहिए। यह भी बहुत महत्वपूर्ण है। एक फ़ेलओवर के दौरान, फ़ेलओवर समाप्त होने के बाद, यह कॉन्फ़िगरेशन फ़ाइल को अद्यतन करने और मृत मास्टर की प्रविष्टि को निकालने का प्रयास करेगा। यदि कॉन्फ़िगरेशन फ़ाइल ssh_user . को अनुमति नहीं देती है या जिस OS उपयोगकर्ता का आप वर्तमान में उपयोग कर रहे हैं, वह कॉन्फ़िगरेशन फ़ाइल को अपडेट नहीं करेगा, जिससे यदि फिर से आपदा आती है तो समस्या बढ़ जाती है।

उम्मीदवार मास्टर पिछड़ता है, कैसे मजबूर करें और असफल विफलता से बचें

गृह मंत्रालय के विकी के संदर्भ में, डिफ़ॉल्ट रूप से, यदि कोई दास 100MB से अधिक रिले लॉग के मास्टर को पीछे छोड़ देता है (=100MB से अधिक रिले लॉग लागू करने की आवश्यकता होती है), MHA दास को नए मास्टर के रूप में नहीं चुनता है क्योंकि इसे पुनर्प्राप्त करने में बहुत लंबा समय लगता है। ।

समाधान/समाधान

एमएचए में, पैरामीटर check_repl_delay=0 सेट करके इसे ओवरराइड किया जा सकता है। एक विफलता के दौरान, MHA एक नए मास्टर का चयन करते समय प्रतिकृति विलंब को अनदेखा करता है और लापता लेनदेन को निष्पादित करेगा। यह विकल्प तब उपयोगी होता है जब आप किसी विशिष्ट होस्ट पर उम्मीदवार_मास्टर=1 सेट करते हैं और आप यह सुनिश्चित करना चाहते हैं कि होस्ट नया मास्टर हो सकता है।

आप दास अंतराल की सटीकता प्राप्त करने के लिए पीटी-दिल की धड़कन के साथ भी एकीकृत कर सकते हैं (देखें यह पोस्ट और यह एक)। लेकिन इसे समानांतर प्रतिकृति या बहु-थ्रेडेड प्रतिकृति दासों के साथ भी कम किया जा सकता है, जो MySQL 5.6 के बाद से मौजूद हैं या मारियाडीबी 10 के साथ - समानांतर प्रतिकृति और बहु-थ्रेडेड दासों में 10x सुधार के साथ बढ़ावा देने का दावा करते हैं। यह आपके दासों को तेज़ी से दोहराने में मदद कर सकता है।

MHA पासवर्ड उजागर हो गए हैं

पासवर्ड सुरक्षित या एन्क्रिप्ट करना कुछ ऐसा नहीं है जिसे MHA द्वारा नियंत्रित किया जाता है। The parameters password or repl_password will be exposed via the configuration file. So your system administrator or security architect must evaluate the grants or privileges of this file as you don’t want to expose valuable database/SSH credentials.

Fixes/Resolution:

MHA has an optional parameter init_conf_load_script. This parameter can be used to have a custom script load your MHA config that will interface to e.g. a database, and retrieve the user/password credentials of your replication setup.

Of course, you can also limit the file attribute of the configuration and the user you are using, and limit the access to the specific Ops/DBA's/Engineers that will handle MHA.

MHA is Not My Choice, What Are the Alternatives for replication failover?

MHA is not a one-size-fits-all solution, it has its limitations and may not fit your desired setup. However, here's a list of variants that you can try.

PRM
Maxscale with Mariadb Monitor or MariaDB Replication Manager (MRM)
Orchestrator
ClusterControl