MariaDB
 sql >> डेटाबेस >  >> RDS >> MariaDB

क्लस्टरकंट्रोल के साथ विटेस और माईएसक्यूएल चलाना

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

विटेस में MySQL

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

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

ClusterControl का उपयोग करके एक नया डेटाबेस क्लस्टर परिनियोजित करना

सबसे पहले, आइए एक नया क्लस्टर परिनियोजित करें। ClusterControl के साथ हमेशा की तरह, आपको हार्डवेयर का प्रावधान करना होगा और यह सुनिश्चित करना होगा कि SSH का उपयोग करके ClusterControl उन नोड्स तक पहुंच सके।

सबसे पहले, हमें SSH कनेक्टिविटी को परिभाषित करना होगा।

अगला, हम विक्रेता और संस्करण चुनेंगे। प्रलेखन के अनुसार, विटेस 5.7 और 8.0 संस्करणों में MySQL और Percona सर्वर का समर्थन करता है (हालांकि यह caching_sha2_password पद्धति का समर्थन नहीं करता है, इसलिए आपको उपयोगकर्ता बनाते समय सावधान रहना होगा)। यह 10.3 तक मारियाडीबी का भी समर्थन करता है।

अंत में, हम टोपोलॉजी को परिभाषित करते हैं। "तैनाती" पर क्लिक करने के बाद, ClusterControl क्लस्टर परिनियोजन करेगा।

एक बार जब यह तैयार हो जाए, तो आपको क्लस्टर देखना चाहिए और आप सक्षम होना चाहिए ClusterControl का उपयोग करके इसे प्रबंधित करें। यदि क्लस्टर और नोड के लिए ऑटो रिकवरी सक्षम है, तो क्लस्टरकंट्रोल स्वचालित विफलताओं का प्रदर्शन करेगा, जिसकी आवश्यकता होनी चाहिए।

आपको "डैशबोर्ड" अनुभाग में एजेंट-आधारित निगरानी से भी लाभ होगा ClusterControl UI का।

विटेस को क्लस्टर आयात करना

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

मान लें कि सब कुछ ठीक हो गया है और आपके पास नोड पर एक स्थानीय विटेस परिनियोजन चल रहा है। अगला कदम क्लस्टरकंट्रोल द्वारा तैनात हमारे क्लस्टर को विटेस में आयात करना होगा। उसके लिए हमें दो और VTTablets चलाने होंगे। सबसे पहले, हम उन VTTablets के लिए निर्देशिका बनाएंगे:

[email protected]:~$ cd /home/vagrant/my-vitess-example/
[email protected]:~/my-vitess-example$ source env.sh
[email protected]:~/my-vitess-example$ mkdir $VTDATAROOT/vt_0000000401
[email protected]:~/my-vitess-example$ mkdir $VTDATAROOT/vt_0000000402

फिर, डेटाबेस पर, हम एक उपयोगकर्ता बनाने जा रहे हैं जिसका उपयोग डेटाबेस को जोड़ने और प्रबंधित करने के लिए Vites के लिए किया जाएगा।

mysql> CREATE USER [email protected]'%' IDENTIFIED BY 'pass';
Query OK, 0 rows affected (0.01 sec)
mysql> GRANT ALL ON *.* TO [email protected]'%' WITH GRANT OPTION;
Query OK, 0 rows affected (0.01 sec)

अगर हम चाहें, तो हम और भी उपयोगकर्ता बनाना चाहेंगे। विटेस हमें अलग-अलग एक्सेस विशेषाधिकारों के साथ कुछ उपयोगकर्ताओं को पास करने की अनुमति देता है:एप्लिकेशन उपयोगकर्ता, डीबीए उपयोगकर्ता, प्रतिकृति उपयोगकर्ता, पूरी तरह से विशेषाधिकार प्राप्त उपयोगकर्ता और कुछ और।

आखिरी चीज जो हमें करनी है वह यह है कि सभी MySQL पर super_read_only को निष्क्रिय कर दिया जाए। नोड्स के रूप में विटेस प्रतिकृति पर मेटाडेटा बनाने का प्रयास करेगा, जिसके परिणामस्वरूप vttablet सेवा प्रारंभ करने का असफल प्रयास होगा।

एक बार यह हो जाने के बाद, हमें VTTablets शुरू करना चाहिए। दोनों ही मामलों में हमें यह सुनिश्चित करना होगा कि पोर्ट अद्वितीय हैं और हम डेटाबेस इंस्टेंस तक पहुँचने के लिए सही क्रेडेंशियल पास करते हैं:

vttablet $TOPOLOGY_FLAGS -logtostderr -log_queries_to_file $VTDATAROOT/tmp/vttablet_0000000401_querylog.txt -tablet-path "zone1-0000000401" -init_keyspace clustercontrol -init_shard 0 -init_tablet_type replica -port 15401 -grpc_port 16401 -service_map 'grpc-queryservice,grpc-tabletmanager,grpc-updatestream' -pid_file $VTDATAROOT/vt_0000000401/vttablet.pid -vtctld_addr http://localhost:15000/ -db_host 10.0.0.181 -db_port 3306 -db_app_user vtuser -db_app_password pass -db_dba_user vtuser -db_dba_password pass -db_repl_user vtuser -db_repl_password pass -db_filtered_user vtuser -db_filtered_password pass -db_allprivs_user vtuser -db_allprivs_password pass -init_db_name_override clustercontrol -init_populate_metadata &

vttablet $TOPOLOGY_FLAGS -logtostderr -log_queries_to_file $VTDATAROOT/tmp/vttablet_0000000402_querylog.txt -tablet-path "zone1-0000000402" -init_keyspace clustercontrol -init_shard 0 -init_tablet_type replica -port 15402 -grpc_port 16402 -service_map 'grpc-queryservice,grpc-tabletmanager,grpc-updatestream' -pid_file $VTDATAROOT/vt_0000000402/vttablet.pid -vtctld_addr http://localhost:15000/ -db_host 10.0.0.182 -db_port 3306 -db_app_user vtuser -db_app_password pass -db_dba_user vtuser -db_dba_password pass -db_repl_user vtuser -db_repl_password pass -db_filtered_user vtuser -db_filtered_password pass -db_allprivs_user vtuser -db_allprivs_password pass -init_db_name_override clustercontrol -init_populate_metadata &

एक बार जब यह तैयार हो जाए, तो हम जांच सकते हैं कि Vitess नए VTTablets को कैसे देखता है:

[email protected]:~/my-vitess-example$ mysql

Welcome to the MySQL monitor.  Commands end with ; or \g.

Your MySQL connection id is 10

Server version: 5.7.9-vitess-10.0.2 Version: 10.0.2 (Git revision fc78470 branch 'HEAD') built on Thu May 27 08:45:22 UTC 2021 by [email protected] using go1.15.12 linux/amd64



Copyright (c) 2000, 2021, Oracle and/or its affiliates.



Oracle is a registered trademark of Oracle Corporation and/or its

affiliates. Other names may be trademarks of their respective

owners.



Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.



mysql> SHOW vitess_tablets;

+-------+----------------+-------+------------+---------+------------------+------------+----------------------+

| Cell  | Keyspace       | Shard | TabletType | State   | Alias            | Hostname   | MasterTermStartTime  |

+-------+----------------+-------+------------+---------+------------------+------------+----------------------+

| zone1 | clustercontrol | 0     | REPLICA    | SERVING | zone1-0000000401 | vagrant.vm |                      |

| zone1 | clustercontrol | 0     | REPLICA    | SERVING | zone1-0000000402 | vagrant.vm |                      |

| zone1 | commerce       | 0     | MASTER     | SERVING | zone1-0000000100 | vagrant.vm | 2021-07-08T13:12:21Z |

| zone1 | commerce       | 0     | REPLICA    | SERVING | zone1-0000000101 | vagrant.vm |                      |

| zone1 | commerce       | 0     | RDONLY     | SERVING | zone1-0000000102 | vagrant.vm |                      |

+-------+----------------+-------+------------+---------+------------------+------------+----------------------+

5 rows in set (0.00 sec)

नोड्स हैं लेकिन दोनों को विटेस द्वारा प्रतिकृति के रूप में रिपोर्ट किया गया है। अब हम अपने असली मास्टर के लिए टोपोलॉजी की जांच करने के लिए विटेस को ट्रिगर कर सकते हैं (नोड जिसे हमने 401 की आईडी के साथ आयात किया है)

[email protected]:~/my-vitess-example$ vtctlclient TabletExternallyReparented zone1-401

अब सब सही लग रहा है:

mysql> SHOW vitess_tablets;

+-------+----------------+-------+------------+---------+------------------+------------+----------------------+

| Cell  | Keyspace       | Shard | TabletType | State   | Alias            | Hostname   | MasterTermStartTime  |

+-------+----------------+-------+------------+---------+------------------+------------+----------------------+

| zone1 | clustercontrol | 0     | MASTER     | SERVING | zone1-0000000401 | vagrant.vm | 2021-07-08T13:27:34Z |

| zone1 | clustercontrol | 0     | REPLICA    | SERVING | zone1-0000000402 | vagrant.vm |                      |

| zone1 | commerce       | 0     | MASTER     | SERVING | zone1-0000000100 | vagrant.vm | 2021-07-08T13:12:21Z |

| zone1 | commerce       | 0     | REPLICA    | SERVING | zone1-0000000101 | vagrant.vm |                      |

| zone1 | commerce       | 0     | RDONLY     | SERVING | zone1-0000000102 | vagrant.vm |                      |

+-------+----------------+-------+------------+---------+------------------+------------+----------------------+

5 rows in set (0.00 sec)

ClusterControl स्वचालित विफलता को Vitess में एकीकृत करना

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

सबसे पहले, ClusterControl नोड पर निर्देशिका बनाते हैं:

mkdir -r /usr/local/vitess/bin

फिर, बस फ़ाइल को कॉपी करें:

scp /usr/local/vitess/bin/vtctlclient [email protected]:/usr/local/vitess/bin/

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

उदाहरण स्क्रिप्ट कुछ इस तरह दिख सकती है।

#!/bin/bash

if [[ $3 == 10.0.0.181 ]] ; then tablet="zone1-401" ; fi

if [[ $3 == 10.0.0.182 ]] ; then tablet="zone1-402" ; fi

vitess="10.0.0.50"

/usr/local/vitess/bin/vtctlclient -server ${vitess}:15999 TabletExternallyReparented ${tablet}

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

एक बार जब हम स्क्रिप्ट के साथ तैयार हो जाते हैं, तो हमें इसे ClusterControl द्वारा निष्पादित करने के लिए कॉन्फ़िगर करना चाहिए:

हम प्रतिकृति को मैन्युअल रूप से प्रचारित करके इसका परीक्षण कर सकते हैं। विटेस द्वारा देखी गई प्रारंभिक अवस्था थी:

mysql> SHOW vitess_tablets;

+-------+----------------+-------+------------+---------+------------------+------------+----------------------+

| Cell  | Keyspace       | Shard | TabletType | State   | Alias            | Hostname   | MasterTermStartTime  |

+-------+----------------+-------+------------+---------+------------------+------------+----------------------+

| zone1 | clustercontrol | 0     | MASTER     | SERVING | zone1-0000000401 | vagrant.vm | 2021-07-08T13:27:34Z |

| zone1 | clustercontrol | 0     | REPLICA    | SERVING | zone1-0000000402 | vagrant.vm |                      |

| zone1 | commerce       | 0     | MASTER     | SERVING | zone1-0000000100 | vagrant.vm | 2021-07-08T13:12:21Z |

| zone1 | commerce       | 0     | REPLICA    | SERVING | zone1-0000000101 | vagrant.vm |                      |

| zone1 | commerce       | 0     | RDONLY     | SERVING | zone1-0000000102 | vagrant.vm |                      |

+-------+----------------+-------+------------+---------+------------------+------------+----------------------+

5 rows in set (0.00 sec)

हम 'क्लस्टरकंट्रोल' कीस्पेस में रुचि रखते हैं। 401 (10.0.0.181) मास्टर था और 402 (10.0.0.182) प्रतिकृति थी।

हम एक नए मास्टर बनने के लिए 10.0.0.182 को बढ़ावा दे सकते हैं। कार्य शुरू होता है और हम देख सकते हैं कि हमारी स्क्रिप्ट निष्पादित की गई थी:

आखिरकार, काम पूरा हुआ:

ClusterControl में सब कुछ ठीक रहा। आइए एक नज़र डालते हैं विटेस पर:

mysql> SHOW vitess_tablets;
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| Cell  | Keyspace       | Shard | TabletType | State   | Alias            | Hostname   | MasterTermStartTime  |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
| zone1 | clustercontrol | 0     | MASTER     | SERVING | zone1-0000000402 | vagrant.vm | 2021-07-09T13:38:00Z |
| zone1 | clustercontrol | 0     | REPLICA    | SERVING | zone1-0000000401 | vagrant.vm |                      |
| zone1 | commerce       | 0     | MASTER     | SERVING | zone1-0000000100 | vagrant.vm | 2021-07-08T13:12:21Z |
| zone1 | commerce       | 0     | REPLICA    | SERVING | zone1-0000000101 | vagrant.vm |                      |
| zone1 | commerce       | 0     | RDONLY     | SERVING | zone1-0000000102 | vagrant.vm |                      |
+-------+----------------+-------+------------+---------+------------------+------------+----------------------+
5 rows in set (0.00 sec)

जैसा कि आप देख सकते हैं, यहां भी सब ठीक है। 402 नया मास्टर है और 401 को प्रतिकृति के रूप में चिह्नित किया गया है।

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


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. हमारे अपने कुत्ते का खाना खा रहे हैं - मारियाडीबी पर जीरा चलाना

  2. मारियाडीबी सर्वर के साथ मायरॉक्स स्टोरेज इंजन का उपयोग करना

  3. डेटाबेस सुरक्षा के लिए मारियाडीबी ऑडिट प्लगइन का उपयोग करना

  4. मारियाडीबी में सभी संग्रहित प्रक्रियाओं को कैसे सूचीबद्ध करें

  5. ClusterControl 1.5 की घोषणा - स्वचालित बैकअप सत्यापन और क्लाउड अपलोड की विशेषता