पोस्ट/पूर्व स्क्रिप्ट हुक का उपयोग करके उन्नत विफलता

$ systemctl पुनरारंभ cmon

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

क्लस्टर फेलओवर प्रतिकृति पूर्व/पोस्ट स्क्रिप्ट समर्थन

जैसा कि पहले उल्लेख किया गया है, MySQL वेरिएंट जो एसिंक्रोनस (सेमी-सिंक्रोनस सहित) प्रतिकृति का उपयोग करते हैं और PostgreSQL/TimescaleDB के लिए स्ट्रीमिंग प्रतिकृति इस तंत्र का समर्थन करते हैं। ClusterControl में निम्नलिखित कॉन्फ़िगरेशन विकल्प हैं जिनका उपयोग स्क्रिप्ट के पूर्व और बाद के हुक के लिए किया जा सकता है। मूल रूप से, इन कॉन्फ़िगरेशन विकल्पों को उनकी कॉन्फ़िगरेशन फ़ाइलों के माध्यम से सेट किया जा सकता है या वेब UI के माध्यम से सेट किया जा सकता है (हम इस पर बाद में विचार करेंगे)।

हमारे दस्तावेज़ में कहा गया है कि ये निम्नलिखित कॉन्फ़िगरेशन विकल्प हैं जो स्क्रिप्ट के पूर्व/पोस्ट हुक का उपयोग करके विफलता तंत्र को बदल सकते हैं:

तकनीकी रूप से, एक बार जब आप अपनी /etc/cmon.d/cmon_

$ systemctl restart cmon

वैकल्पिक रूप से, आप <अपना क्लस्टर चुनें> → सेटिंग्स → रनटाइम कॉन्फ़िगरेशन पर जाकर कॉन्फ़िगरेशन विकल्प भी सेट कर सकते हैं। नीचे स्क्रीनशॉट देखें:

इस दृष्टिकोण के लिए अभी भी cmon सेवा को फिर से शुरू करने की आवश्यकता होगी, इससे पहले कि यह प्रतिबिंबित कर सके स्क्रिप्ट के पूर्व/पोस्ट हुक के लिए इन कॉन्फ़िगरेशन विकल्पों के लिए किए गए परिवर्तन।

पूर्व/पोस्ट स्क्रिप्ट हुक का उदाहरण

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

आइए इसे अपने उदाहरण में करते हैं और प्रदर्शित करते हैं कि आप इससे कैसे लाभ उठा सकते हैं।

सर्वर विवरण और स्क्रिप्ट

इस उदाहरण में, मैं केवल एक प्राथमिक और एक प्रतिकृति के साथ एक मारियाडीबी प्रतिकृति क्लस्टर का उपयोग कर रहा हूं। विफलता को प्रबंधित करने के लिए ClusterControl द्वारा प्रबंधित।

ClusterControl =192.168.40.110

प्राथमिक (debnode5) =192.168.30.50

प्रतिकृति (debnode9) =192.168.30.90

प्राथमिक नोड में, नीचे बताए अनुसार स्क्रिप्ट बनाएं,

[email protected]:~# cat /opt/pre_failover.sh
#!/bin/bash

date -u +%s | ssh -i /home/vagrant/.ssh/id_rsa [email protected] -T "cat >> /tmp/debnode5.tmp"

सुनिश्चित करें कि /opt/pre_failover.sh निष्पादन योग्य है, अर्थात

$ chmod +x /opt/pre_failover.sh

फिर क्रॉन के माध्यम से शामिल होने के लिए इस स्क्रिप्ट का उपयोग करें। इस उदाहरण में, मैंने एक फ़ाइल /etc/cron.d/ccfailover बनाई है और इसमें निम्नलिखित सामग्री है:

[email protected]:~# cat /etc/cron.d/ccfailover
#!/bin/bash

* * * * * vagrant /opt/pre_failover.sh

अपनी प्रतिकृति में, होस्टनाम बदलने के अलावा, प्राथमिक के लिए किए गए निम्न चरणों का उपयोग करें। मेरी प्रतिकृति में मेरे पास जो कुछ है, उसे नीचे देखें:

[email protected]:~# tail -n+1 /etc/cron.d/ccfailover /opt/pre_failover.sh
==> /etc/cron.d/ccfailover <==
#!/bin/bash
* * * * * vagrant /opt/pre_failover.sh

==> /opt/pre_failover.sh <==
#!/bin/bash

date -u +%s | ssh -i /home/vagrant/.ssh/id_rsa [email protected] -T "cat > /tmp/debnode9.tmp"

और सुनिश्चित करें कि हमारे क्रॉन में लागू की गई स्क्रिप्ट निष्पादन योग्य है,

[email protected]:~# ls -alth /opt/pre_failover.sh
-rwxr-xr-x 1 root root 104 Jun 14 05:09 /opt/pre_failover.sh

ClusterControl प्री/पोस्ट स्क्रिप्ट

इस प्रदर्शन में, मेरा क्लस्टर_आईडी 3 है। जैसा कि पहले हमारे दस्तावेज़ीकरण में कहा गया है, यह आवश्यक है कि ये स्क्रिप्ट हमारे सीसी नियंत्रक होस्ट में रहें। तो मेरे /etc/cmon.d/cmon_3.cnf में, मेरे पास निम्नलिखित हैं:

[[email protected] cmon.d]# tail -n3 /etc/cmon.d/cmon_3.cnf
replication_pre_failover_script = /etc/cmon.d/failover/replication_failover_pre_clus3.sh
replication_post_failover_script = /etc/cmon.d/failover/replication_failover_post_clus3.sh
replication_post_unsuccessful_failover_script = /etc/cmon.d/failover/replication_unsuccessful_failover_post_clus3.sh

जबकि, निम्न "पूर्व" विफलता स्क्रिप्ट निर्धारित करती है कि दोनों नोड सीसी नियंत्रक होस्ट तक पहुंचने में सक्षम थे या नहीं। निम्नलिखित देखें:

[[email protected] cmon.d]# tail -n+1 /etc/cmon.d/failover/replication_failover_pre_clus3.sh
#!/bin/bash

arg1=$1
debnode5_tstamp=$(tail /tmp/debnode5.tmp)
debnode9_tstamp=$(tail /tmp/debnode9.tmp)
cc_tstamp=$(date -u +%s)
diff_debnode5=$(expr $cc_tstamp - $debnode5_tstamp)
diff_debnode9=$(expr $cc_tstamp - $debnode5_tstamp)

if [[ "$diff_debnode5" -le  60 && "$diff_debnode9" -le 60 ]]; then
   echo "failover cannot proceed. It's just a false alarm. Checkout the firewall in your CC host";
   exit 1;
elif [[ "$diff_debnode5" -gt 60 || "$diff_debnode9" -gt 60 ]]; then
        echo "Either both nodes ($arg1) or one of them  were not able to connect the CC host. One can be unreachable. Failover proceed!";
    exit 0;
else
   echo "false alarm. Failover discarded!"
   exit 1;
fi
Whereas my post scripts just simply echoes and redirects the output to a file, just for the test.
[[email protected] failover]# tail -n+1 replication_*_post*3.sh
==> replication_failover_post_clus3.sh <==
#!/bin/bash
echo "post failover script on cluster 3 with args: [email protected]" > /tmp/post_failover_script_cid3.txt
==> replication_unsuccessful_failover_post_clus3.sh <==
#!/bin/bash
echo "post unsuccessful  failover script on cluster 3 with args: [email protected]" > /tmp/post_unsuccessful_failover_script_cid3.txt

विफलता का प्रदर्शन करें

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

[email protected]:~# ip link set enp0s8 down

असफलता के पहले प्रयास के दौरान, सीसी मेरी पूर्व स्क्रिप्ट चलाने में सक्षम था जो /etc/cmon.d/failover/replication_failover_pre_clus3.sh पर स्थित है। नीचे देखें कि यह कैसे काम करता है:

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

विफलता के हमारे दूसरे प्रयास में, चूंकि टाइमस्टैम्प 60 सेकंड से अधिक तक पहुंच जाता है, तो यह एक वास्तविक सकारात्मक माना जाता है, और इसका मतलब है कि हमें इरादा के अनुसार विफल होना है। सीसी इसे पूरी तरह से निष्पादित करने में सक्षम है और यहां तक ​​​​कि पोस्ट स्क्रिप्ट को भी निष्पादित करने में सक्षम है। इसे जॉब लॉग में देखा जा सकता है। नीचे स्क्रीनशॉट देखें:

यह सत्यापित करना कि मेरी पोस्ट स्क्रिप्ट चलाई गई थी, यह लॉग बनाने में सक्षम थी CC /tmp निर्देशिका में अपेक्षित रूप से फ़ाइल करें,

[[email protected] tmp]# cat /tmp/post_failover_script_cid3.txt

आर्ग के साथ क्लस्टर 3 पर पोस्ट फेलओवर स्क्रिप्ट:192.168.30.50 192.168.30.90  192.168.30.50 192.168.30.90 192.168.30.90

अब, मेरी टोपोलॉजी बदल दी गई है और विफलता सफल रही!

निष्कर्ष

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