मास्टर उच्च उपलब्धता प्रबंधक (एमएचए) दुर्घटनाग्रस्त हो गया है! अब मैं क्या करू?

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

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

एमएचए को संकलित करना काफी आसान है। GitHub और क्लोन रिपॉजिटरी पर जाएं।

https://github.com/yoshinorim/mha4mysql-manager

https://github.com/yoshinorim/mha4mysql-node

फिर यह सब कुछ है:

perl Makefile.PL
make
make install

यदि आपके पास सभी आवश्यक पैकेज पहले से स्थापित नहीं हैं, तो आपको कुछ पर्ल निर्भरताएँ स्थापित करनी पड़ सकती हैं। हमारे मामले में, उबंटू 16.04 पर, हमें निम्नलिखित स्थापित करना था:

perl -MCPAN -e "install Config::Tiny"
perl -MCPAN -e "install Log::Dispatch"
perl -MCPAN -e "install Parallel::ForkManager"
perl -MCPAN -e "install Module::Install"

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

[email protected]:~# cat /etc/app1.cnf
[server default]
user=cmon
password=pass
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
[server1]
hostname=node1
candidate_master=1
[server2]
hostname=node2
candidate_master=1
[server3]
hostname=node3
no_master=1

अगला कदम यह देखना होगा कि क्या सब कुछ काम करता है और गृह मंत्रालय प्रतिकृति को कैसे देखता है:

[email protected]:~# masterha_check_repl --conf=/etc/app1.cnf
Tue Apr  9 08:17:04 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr  9 08:17:04 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr  9 08:17:04 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr  9 08:17:04 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr  9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln427] Error happened on checking configurations. Redundant argument in sprintf at /usr/local/share/perl/5.22.1/MHA/NodeUtil.pm line 195.
Tue Apr  9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln525] Error happened on monitoring servers.
Tue Apr  9 08:17:05 2019 - [info] Got exit code 1 (Not master dead).

खैर, यह दुर्घटनाग्रस्त हो गया। ऐसा इसलिए है क्योंकि MHA MySQL संस्करण को पार्स करने का प्रयास करता है और इसमें हाइफ़न की अपेक्षा नहीं करता है। सौभाग्य से, समाधान ढूंढना आसान है:https://github.com/yoshinorim/mha4mysql-manager/issues/116.

अब, हमारे पास काम के लिए गृह मंत्रालय तैयार है।

[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr  9 13:00:00 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr  9 13:00:00 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr  9 13:00:00 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr  9 13:00:00 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr  9 13:00:01 2019 - [info] GTID failover mode = 1
Tue Apr  9 13:00:01 2019 - [info] Dead Servers:
Tue Apr  9 13:00:01 2019 - [info] Alive Servers:
Tue Apr  9 13:00:01 2019 - [info]   node1(10.0.0.141:3306)
Tue Apr  9 13:00:01 2019 - [info]   node2(10.0.0.142:3306)
Tue Apr  9 13:00:01 2019 - [info]   node3(10.0.0.143:3306)
Tue Apr  9 13:00:01 2019 - [info] Alive Slaves:
Tue Apr  9 13:00:01 2019 - [info]   node2(10.0.0.142:3306)  Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr  9 13:00:01 2019 - [info]     GTID ON
Tue Apr  9 13:00:01 2019 - [info]     Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr  9 13:00:01 2019 - [info]     Primary candidate for the new Master (candidate_master is set)
Tue Apr  9 13:00:01 2019 - [info]   node3(10.0.0.143:3306)  Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr  9 13:00:01 2019 - [info]     GTID ON
Tue Apr  9 13:00:01 2019 - [info]     Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr  9 13:00:01 2019 - [info]     Not candidate for the new Master (no_master is set)
Tue Apr  9 13:00:01 2019 - [info] Current Alive Master: node1(10.0.0.141:3306)
Tue Apr  9 13:00:01 2019 - [info] Checking slave configurations..
Tue Apr  9 13:00:01 2019 - [info] Checking replication filtering settings..
Tue Apr  9 13:00:01 2019 - [info]  binlog_do_db= , binlog_ignore_db=
Tue Apr  9 13:00:01 2019 - [info]  Replication filtering check ok.
Tue Apr  9 13:00:01 2019 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
Tue Apr  9 13:00:01 2019 - [info] Checking SSH publickey authentication settings on the current master..
Tue Apr  9 13:00:02 2019 - [info] HealthCheck: SSH to node1 is reachable.
Tue Apr  9 13:00:02 2019 - [info]
node1(10.0.0.141:3306) (current master)
 +--node2(10.0.0.142:3306)
 +--node3(10.0.0.143:3306)

Tue Apr  9 13:00:02 2019 - [warning] master_ip_failover_script is not defined.
Tue Apr  9 13:00:02 2019 - [warning] shutdown_script is not defined.
Tue Apr  9 13:00:02 2019 - [info] Set master ping interval 3 seconds.
Tue Apr  9 13:00:02 2019 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.
Tue Apr  9 13:00:02 2019 - [info] Starting ping health check on node1(10.0.0.141:3306)..
Tue Apr  9 13:00:02 2019 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..

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

परिदृश्य 1 - गृह मंत्रालय क्रैश हो गया

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

[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr  9 13:05:38 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr  9 13:05:38 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr  9 13:05:38 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr  9 13:05:38 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr  9 13:05:38 2019 - [warning] /var/log/masterha/app1/app1.master_status.health already exists. You might have killed manager with SIGKILL(-9), may run two or more monitoring process for the same application, or use the same working directory. Check for details, and consider setting --workdir separately.

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

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

परिदृश्य 2 - MHA प्रबंधक नोड ने मास्टर से नेटवर्क कनेक्शन खो दिया

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

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