अपने पिछले ब्लॉगों में, हमने आपको डेटाबेस फ़ेलओवर की आवश्यकता के लिए औचित्य दिया था और बताया था कि फ़ेलओवर तंत्र कैसे काम करता है। मैं इसे साझा कर रहा हूं यदि आपके पास प्रश्न हैं कि आपको अपने MySQL डेटाबेस के लिए एक विफलता तंत्र क्यों स्थापित करना चाहिए। यदि आप करते हैं, तो कृपया हमारे पिछले ब्लॉग पोस्ट पढ़ें।
स्वचालित विफलता कैसे सेटअप करें
अपने फ़ेलओवर को स्वचालित रूप से प्रबंधित करने के लिए MySQL या MariaDB का उपयोग करने का लाभ यह है कि ऐसे उपलब्ध उपकरण हैं जिनका आप अपने परिवेश में उपयोग और कार्यान्वयन कर सकते हैं। ओपन सोर्स वाले से लेकर एंटरप्राइज ग्रेड सॉल्यूशंस तक। अधिकांश उपकरण न केवल विफल होने में सक्षम हैं, स्विचओवर, निगरानी और उन्नत सुविधाएं जैसी अन्य सुविधाएं हैं जो आपके MySQL डेटाबेस क्लस्टर के लिए अधिक प्रबंधन क्षमताओं की पेशकश कर सकती हैं। नीचे, हम आपके द्वारा उपयोग किए जा सकने वाले सबसे सामान्य लोगों के बारे में जानेंगे।
एमएचए (मास्टर उच्च उपलब्धता) का उपयोग करना
हमने गृह मंत्रालय के साथ इस विषय को सबसे आम मुद्दों और उन्हें ठीक करने के तरीके के साथ उठाया है। हमने एमएचए की तुलना एमआरएम या मैक्सस्केल से भी की है।
उच्च उपलब्धता के लिए एमएचए के साथ स्थापित करना आसान नहीं हो सकता है, लेकिन यह उपयोग करने के लिए कुशल और लचीला है क्योंकि ऐसे ट्यून करने योग्य पैरामीटर हैं जिन्हें आप अपने फ़ेलओवर को अनुकूलित करने के लिए परिभाषित कर सकते हैं। एमएचए का परीक्षण और उपयोग किया गया है। लेकिन जैसे-जैसे प्रौद्योगिकी आगे बढ़ती है, MHA पिछड़ रहा है क्योंकि यह मारियाडीबी के लिए GTID का समर्थन नहीं करता है और यह पिछले 2 या 3 वर्षों से किसी भी अपडेट को आगे नहीं बढ़ा रहा है।
masterha_manager स्क्रिप्ट चलाकर,
masterha_manager --conf=/etc/app1.cnfजहां एक नमूना /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नो_मास्टर और कैंडिडेट_मास्टर जैसे पैरामीटर महत्वपूर्ण होंगे क्योंकि आप श्वेतसूची में वांछित नोड्स को अपना लक्षित मास्टर और नोड्स के रूप में सेट करते हैं जिन्हें आप मास्टर नहीं बनना चाहते हैं।
एक बार सेट हो जाने पर, प्राथमिक या मास्टर पर विफलता होने की स्थिति में आप अपने MySQL डेटाबेस के लिए फ़ेलओवर के लिए तैयार हैं। स्क्रिप्ट मास्टरहा_मैनेजर फ़ेलओवर (स्वचालित या मैनुअल) का प्रबंधन करता है, फ़ेलओवर कब और कहाँ करना है, इस पर निर्णय लेता है, और डिफरेंशियल रिले लॉग को लागू करने के लिए उम्मीदवार मास्टर के प्रचार के दौरान स्लेव रिकवरी का प्रबंधन करता है। यदि मास्टर डेटाबेस मर जाता है, तो एमएचए प्रबंधक एमएचए नोड एजेंट के साथ समन्वय करेगा क्योंकि यह उन दासों के लिए अंतर रिले लॉग लागू करता है जिनके पास मास्टर से नवीनतम बिनलॉग ईवेंट नहीं हैं।
चेकआउट करें कि एमएचए नोड एजेंट क्या करता है और इसकी स्क्रिप्ट में क्या शामिल है। मूल रूप से, यह वह स्क्रिप्ट है जिसे MHA प्रबंधक फेलओवर होने पर लागू करेगा। यह एमएचए प्रबंधक से अपने जनादेश की प्रतीक्षा करेगा क्योंकि यह नवीनतम दास की खोज करता है जिसमें बिनलॉग ईवेंट होते हैं और scp का उपयोग करके दास से लापता घटनाओं की प्रतिलिपि बनाते हैं और उन्हें स्वयं पर लागू करते हैं। जैसा कि उल्लेख किया गया है, यह रिले लॉग लागू करता है, रिले लॉग को शुद्ध करता है, या बाइनरी लॉग को सहेजता है।
यदि आप ट्यून करने योग्य पैरामीटर के बारे में और अपने फ़ेलओवर प्रबंधन को कस्टमाइज़ करने के तरीके के बारे में अधिक जानना चाहते हैं, तो MHA के लिए पैरामीटर्स विकी पृष्ठ देखें।
ऑर्केस्ट्रेटर का उपयोग करना
ऑर्केस्ट्रेटर एक MySQL और MariaDB उच्च उपलब्धता और प्रतिकृति प्रबंधन उपकरण है। इसे श्लोमी नोच द्वारा अपाचे लाइसेंस, संस्करण 2.0 की शर्तों के तहत जारी किया गया है। यह एक ओपन सोर्स सॉफ़्टवेयर है और स्वचालित फ़ेलओवर को संभालता है लेकिन पुनर्प्राप्ति या स्वचालित फ़ेलओवर के अलावा आप अपने MySQL/MariaDB डेटाबेस को प्रबंधित करने के लिए बहुत सी चीज़ें अनुकूलित कर सकते हैं या कर सकते हैं।
ऑर्केस्ट्रेटर को स्थापित करना आसान या सीधा हो सकता है। एक बार जब आप अपने लक्षित वातावरण के लिए आवश्यक विशिष्ट पैकेज डाउनलोड कर लेते हैं, तो आप ऑर्केस्ट्रेटर द्वारा निगरानी के लिए अपने क्लस्टर और नोड्स को पंजीकृत करने के लिए तैयार होते हैं। यह एक यूआई प्रदान करता है जिसके लिए इसे प्रबंधित करना बहुत आसान है लेकिन इसमें बहुत सारे ट्यून करने योग्य पैरामीटर या कमांड का सेट है जिसका उपयोग आप अपने फ़ेलओवर प्रबंधन को प्राप्त करने के लिए कर सकते हैं।
मान लें कि आपने अंतत:सेटअप कर लिया है और हमारे प्राथमिक या मास्टर नोड को जोड़कर क्लस्टर का पंजीकरण नीचे दिए गए कमांड द्वारा किया जा सकता है,
$ orchestrator -c discover -i pupnode21:3306
2021-01-07 12:32:31 DEBUG Hostname unresolved yet: pupnode21
2021-01-07 12:32:31 DEBUG Cache hostname resolve pupnode21 as pupnode21
2021-01-07 12:32:31 DEBUG Connected to orchestrator backend: orchestrator:[email protected](127.0.0.1:3306)/orchestrator?timeout=1s
2021-01-07 12:32:31 DEBUG Orchestrator pool SetMaxOpenConns: 128
2021-01-07 12:32:31 DEBUG Initializing orchestrator
2021-01-07 12:32:31 INFO Connecting to backend 127.0.0.1:3306: maxConnections: 128, maxIdleConns: 32
2021-01-07 12:32:31 DEBUG Hostname unresolved yet: 192.168.40.222
2021-01-07 12:32:31 DEBUG Cache hostname resolve 192.168.40.222 as 192.168.40.222
2021-01-07 12:32:31 DEBUG Hostname unresolved yet: 192.168.40.223
2021-01-07 12:32:31 DEBUG Cache hostname resolve 192.168.40.223 as 192.168.40.223
pupnode21:3306अब, हमने अपना क्लस्टर जोड़ लिया है।
यदि कोई प्राथमिक नोड विफल हो जाता है (हार्डवेयर विफल हो जाता है या दुर्घटनाग्रस्त हो जाता है), तो ऑर्केस्ट्रेटर करेगा प्राथमिक या मास्टर नोड के रूप में प्रचारित किए जाने वाले सबसे उन्नत नोड का पता लगाएं और खोजें।
अब, हमारे पास क्लस्टर में दो नोड शेष हैं जबकि प्राथमिक डाउन है ।
$ orchestrator-client -c topology -i pupnode21:3306
pupnode21:3306 [unknown,invalid,10.3.27-MariaDB-log,rw,ROW,>>,downtimed]
$ orchestrator-client -c topology -i pupnode22:3306
pupnode22:3306 [0s,ok,10.3.27-MariaDB-log,rw,ROW,>>]
+ pupnode23:3306 [0s,ok,10.3.27-MariaDB-log,ro,ROW,>>,GTID]मैक्सस्केल का उपयोग करना
MariaDB MaxScale को डेटाबेस लोड बैलेंसर के रूप में समर्थित किया गया है। पिछले कुछ वर्षों में MaxScale बड़ा हुआ है और परिपक्व हुआ है, कई समृद्ध विशेषताओं के साथ विस्तारित हुआ है और इसमें स्वचालित विफलता भी शामिल है। चूंकि मारियाडीबी मैक्सस्केल 2.2 जारी किया गया था, यह प्रतिकृति क्लस्टर विफलता प्रबंधन सहित कई नई सुविधाओं को पेश करता है। आप हमारे पिछले ब्लॉग को MaxScale विफलता तंत्र के बारे में पढ़ सकते हैं।
MaxScale का उपयोग करना BSL के अंतर्गत आता है, हालांकि सॉफ्टवेयर मुफ्त में उपलब्ध है, लेकिन इसके लिए आपको कम से कम MariaDB के साथ सेवा खरीदने की आवश्यकता है। यह उपयुक्त नहीं हो सकता है, लेकिन यदि आपने मारियाडीबी उद्यम सेवाओं का अधिग्रहण कर लिया है, तो यह एक बहुत बड़ा लाभ हो सकता है यदि आपको फ़ेलओवर प्रबंधन और इसकी अन्य सुविधाओं की आवश्यकता है।
MaxScale की स्थापना आसान है लेकिन आवश्यक कॉन्फ़िगरेशन सेट करना और इसके मापदंडों को परिभाषित करना नहीं है, और इसके लिए आपको सॉफ़्टवेयर को समझना होगा। आप उनकी कॉन्फ़िगरेशन मार्गदर्शिका देख सकते हैं।
त्वरित और तेज़ परिनियोजन के लिए, आप अपने मौजूदा MySQL/MariaDB परिवेश में अपने लिए MaxScale स्थापित करने के लिए ClusterControl का उपयोग कर सकते हैं।
एक बार इंस्टाल हो जाने के बाद, अपना Moodle डेटाबेस सेट करना आपके होस्ट को MaxScale IP या होस्टनाम और रीड-राइट पोर्ट की ओर इंगित करके किया जा सकता है। उदाहरण के लिए,
आपके सेवा श्रोता के लिए आपका रीड-राइट किस पोर्ट 4008 के लिए है। उदाहरण के लिए, मेरे मैक्सस्केल के लिए निम्नलिखित सेवा और श्रोता विन्यास है।
$ cat maxscale.cnf.d/rw-listener.cnf
[rw-listener]
type=listener
protocol=mariadbclient
service=rw-service
address=0.0.0.0
port=4008
authenticator=MySQLAuth
$ cat maxscale.cnf.d/rw-service.cnf
[rw-service]
type=service
servers=DB_123,DB_122,DB_124
router=readwritesplit
user=maxscale_adm
password=42BBD2A4DC1BF9BE05C41A71DEEBDB70
max_slave_connections=100%
max_sescmd_history=15000000
causal_reads=true
causal_reads_timeout=10
transaction_replay=true
transaction_replay_max_size=32Mi
delayed_retry=true
master_reconnection=true
max_connections=0
connection_timeout=0
use_sql_variables_in=master
master_accept_reads=true
disable_sescmd_history=falseअपने मॉनिटर कॉन्फ़िगरेशन में रहते हुए, आपको स्वचालित फ़ेलओवर को सक्षम करना या ऑटो रीजॉइन को सक्षम करना नहीं भूलना चाहिए यदि आप चाहते हैं कि पिछला मास्टर ऑनलाइन वापस जाने पर ऑटो रीजॉइन करने में विफल हो जाए। यह इस प्रकार है,
$ egrep -r 'auto|^\[' maxscale.cnf.d/replication_monitor.cnf
[replication_monitor]
auto_failover=true
auto_rejoin=1ध्यान दें कि मेरे द्वारा बताए गए चर उत्पादन के उपयोग के लिए नहीं हैं, बल्कि केवल इस ब्लॉग पोस्ट और परीक्षण उद्देश्यों के लिए हैं। मैक्सस्केल के साथ अच्छी बात यह है कि एक बार प्राइमरी या मास्टर के नीचे जाने के बाद, मैक्सस्केल मास्टर की भूमिका निभाने के लिए आदर्श या सर्वश्रेष्ठ उम्मीदवार को बढ़ावा देने के लिए पर्याप्त स्मार्ट है। इसलिए, आपके आईपी और पोर्ट को बदलने की कोई आवश्यकता नहीं है क्योंकि हमने अपने मैक्सस्केल नोड के होस्ट/आईपी और मास्टर के नीचे जाने के बाद हमारे समापन बिंदु के रूप में इसके पोर्ट का उपयोग किया है। उदाहरण के लिए,
[192.168.40.223:6603] MaxScale> list servers
┌────────┬────────────────┬──────┬─────────────┬─────────────────┬──────────────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_124 │ 192.168.40.223 │ 3306 │ 0 │ Slave, Running │ 3-2003-876,5-2001-219541 │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_123 │ 192.168.40.221 │ 3306 │ 0 │ Master, Running │ 3-2003-876,5-2001-219541 │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_122 │ 192.168.40.222 │ 3306 │ 0 │ Slave, Running │ 3-2003-876,5-2001-219541 │
└────────┴────────────────┴──────┴─────────────┴─────────────────┴──────────────────────────┘नोड DB_123 जो 192.168.40.221 की ओर इशारा करता है, वर्तमान मास्टर है। नोड DB_123 को समाप्त करने से MaxScale विफल हो जाएगा और यह इस तरह दिखेगा,
[192.168.40.223:6603] MaxScale> list servers
┌────────┬────────────────┬──────┬─────────────┬─────────────────┬──────────────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_124 │ 192.168.40.223 │ 3306 │ 0 │ Slave, Running │ 3-2003-876,5-2001-219541 │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_123 │ 192.168.40.221 │ 3306 │ 0 │ Down │ 3-2003-876,5-2001-219541 │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_122 │ 192.168.40.222 │ 3306 │ 0 │ Master, Running │ 3-2003-876,5-2001-219541 │
└────────┴────────────────┴──────┴─────────────┴─────────────────┴──────────────────────────┘जबकि, हमारा Moodle डेटाबेस अभी भी चालू है और चल रहा है क्योंकि हमारा MaxScale उस नवीनतम मास्टर की ओर इशारा करता है जिसे पदोन्नत किया गया था।
$ mysql -hmaxscale.local.domain -umoodleuser -pmoodlepassword -P4008
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 9
Server version: 10.3.27-MariaDB-log MariaDB Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> select @@hostname;
+------------+
| @@hostname |
+------------+
| 192.168.40.222 |
+------------+
1 row in set (0.001 sec)ClusterControl का उपयोग करना
ClusterControl को स्वतंत्र रूप से डाउनलोड किया जा सकता है और समुदाय, अग्रिम और उद्यम के लिए लाइसेंस प्रदान करता है। स्वचालित विफलता केवल एडवांस और एंटरप्राइज पर उपलब्ध है। स्वचालित विफलता हमारे ऑटो-रिकवरी सुविधा के अंतर्गत आती है जो एक विफल क्लस्टर या एक विफल नोड को पुनर्प्राप्त करने का प्रयास करती है। यदि आप इसे करने के तरीके के बारे में अधिक विवरण चाहते हैं, तो हमारी पिछली पोस्ट देखें कि कैसे ClusterControl स्वचालित डेटाबेस पुनर्प्राप्ति और विफलता को निष्पादित करता है। यह ट्यून करने योग्य पैरामीटर प्रदान करता है जो बहुत सुविधाजनक और उपयोग में आसान हैं। कृपया हमारी पिछली पोस्ट को क्लस्टरकंट्रोल के साथ डेटाबेस विफलता को स्वचालित कैसे करें पर भी पढ़ें।
अपने Moodle डेटाबेस के लिए अपने स्वचालित फ़ेलओवर को प्रबंधित करने के लिए आपके डेटाबेस बैकएंड को इंटरफ़ेस करने वाले आपके Moodle एप्लिकेशन क्लाइंट के लिए आपके समापन बिंदु के रूप में कम से कम एक वर्चुअल IP (VIP) की आवश्यकता होनी चाहिए। ऐसा करने के लिए, आप इसके ऊपर HAProxy (या ProxySQL--आपके लोड बैलेंसर पसंद पर निर्भर करता है) के साथ Keepalived को तैनात कर सकते हैं। इस मामले में, आपका मूडल डेटाबेस एंडपॉइंट वर्चुअल आईपी को इंगित करेगा, जो मूल रूप से आपके द्वारा इसे तैनात करने के बाद Keepalived द्वारा असाइन किया गया है, जैसा कि हमने आपको MaxScale सेट करते समय पहले दिखाया था। आप इस ब्लॉग को यह भी देख सकते हैं कि यह कैसे करना है।
जैसा कि ऊपर उल्लेख किया गया है, ट्यून करने योग्य पैरामीटर उपलब्ध हैं जिन्हें आप अपने /etc/cmon.d/cmon_
- replication_check_binlog_filament_bf_failover
- replication_check_external_bf_failover
- replication_failed_reslave_failover_script
- replication_failover_blacklist
- replication_failover_events
- replication_failover_wait_to_apply_timeout
- replication_failover_whitelist
- replication_onfail_failover_script
- Replication_post_failover_script
- replication_post_unsuccessful_failover_script
- replication_pre_failover_script
- replication_skip_apply_missing_txs
- replication_stop_on_error
विफलता को प्रबंधित करते समय ClusterControl बहुत लचीला होता है ताकि आप कुछ पूर्व-विफलता या विफलता के बाद के कार्य कर सकें।
निष्कर्ष
Moodle के लिए अपने MySQL डेटाबेस के लिए अपने फ़ेलओवर को सेट अप और स्वचालित रूप से प्रबंधित करते समय अन्य बढ़िया विकल्प हैं। यह आपके बजट पर निर्भर करता है और आपको किस चीज के लिए पैसे खर्च करने की संभावना है। ओपन सोर्स वाले का उपयोग करने के लिए विशेषज्ञता की आवश्यकता होती है और परिचित होने के लिए कई परीक्षणों की आवश्यकता होती है क्योंकि समुदाय के अलावा अन्य सहायता की आवश्यकता होने पर आप कोई समर्थन नहीं चला सकते हैं। एंटरप्राइज सॉल्यूशंस के साथ, यह एक कीमत के साथ आता है लेकिन आपको समर्थन और आसानी प्रदान करता है क्योंकि समय लेने वाले काम को कम किया जा सकता है। ध्यान दें कि यदि विफलता का उपयोग गलती से किया जाता है, तो यह आपके डेटाबेस को नुकसान पहुंचा सकता है यदि इसे ठीक से संभाला और प्रबंधित नहीं किया गया है। इस बात पर ध्यान दें कि क्या अधिक महत्वपूर्ण है और आप अपने Moodle डेटाबेस फ़ेलओवर को प्रबंधित करने के लिए उपयोग किए जा रहे समाधानों के लिए कैसे सक्षम हैं।
