ClusterControl का उपयोग करके स्पाइडर के साथ मारियाडीबी शेयरिंग को तैनात करना

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

इस ब्लॉग पोस्ट में, हम आपको ClusterControl का उपयोग करते हुए दो MariaDB शार्क के क्लस्टर के परिनियोजन के बारे में बताने जा रहे हैं। हम चयनित शार्ड कुंजी की श्रेणी के आधार पर विभाजित तालिका को होस्ट करने के लिए मुट्ठी भर मारियाडीबी सर्वर (अतिरेक और उपलब्धता के लिए) को तैनात करने जा रहे हैं। चुनी गई शार्द कुंजी मूल रूप से एक स्तंभ है जो निम्न और ऊपरी सीमा के साथ मूल्यों को संग्रहीत करता है, जैसा कि इस मामले में, पूर्णांक मान 0 से 1,000,000 के बीच होता है, जो इसे दो शार्क के बीच डेटा वितरण को संतुलित करने के लिए सबसे अच्छा उम्मीदवार कुंजी बनाता है। इसलिए, हम श्रेणियों को दो भागों में विभाजित करेंगे:

0 - 499999:Shard 1
500000 - 1000000:Shard 2

निम्न आरेख हमारे उच्च-स्तरीय आर्किटेक्चर को दिखाता है कि हम क्या परिनियोजित करने जा रहे हैं:

आरेख के कुछ स्पष्टीकरण:

mariadb-gw-1:MariaDB उदाहरण जो स्पाइडर स्टोरेज इंजन चलाता है, एक शार्ड राउटर की तरह काम करता है। हम इस होस्ट को मारियाडीबी गेटवे 1 के रूप में एक नाम देते हैं और यह शार्क तक पहुंचने के लिए प्राथमिक (सक्रिय) मारियाडीबी सर्वर होने जा रहा है। एप्लिकेशन इस होस्ट से एक मानक मारियाडीबी कनेक्शन की तरह कनेक्ट होगा। यह नोड 127.0.0.1 पोर्ट 3307 (shard1) और 3308 (shard2) पर सुनकर HAProxy के माध्यम से शार्क से जुड़ता है।
mariadb-gw-2:MariaDB उदाहरण जो स्पाइडर स्टोरेज इंजन चलाता है, एक शार्ड राउटर की तरह काम करता है। हम इस होस्ट को मारियाडीबी गेटवे 2 के रूप में एक नाम देते हैं और यह शार्क तक पहुंचने के लिए द्वितीयक (निष्क्रिय) मारियाडीबी सर्वर होने जा रहा है। इसका सेटअप mariadb-gw-1 जैसा ही होगा। एप्लिकेशन इस होस्ट से तभी कनेक्ट होगा जब प्राथमिक मारियाडीबी डाउन हो। यह नोड 127.0.0.1 पोर्ट 3307 (shard1) और 3308 (shard2) पर सुनकर HAProxy के माध्यम से शार्क से जुड़ता है।
mariadb-shard-1a:MariaDB मास्टर जो पहले विभाजन के लिए प्राथमिक डेटा नोड के रूप में कार्य करता है। मारियाडीबी गेटवे सर्वर को केवल शार्ड के मास्टर को ही लिखना चाहिए।
mariadb-shard-1b:MariaDB प्रतिकृति जो पहले विभाजन के लिए द्वितीयक डेटा नोड के रूप में कार्य करती है। यदि शार्ड का मास्टर नीचे चला जाता है (स्वचालित विफलता ClusterControl द्वारा प्रबंधित की जाती है) तो यह मास्टर की भूमिका निभाएगा।
mariadb-shard-2a:MariaDB मास्टर जो दूसरे विभाजन के लिए प्राथमिक डेटा नोड के रूप में कार्य करता है। मारियाडीबी गेटवे सर्वर केवल शार्ड के मास्टर को लिखते हैं।
mariadb-shard-2b:MariaDB प्रतिकृति जो दूसरे विभाजन के लिए द्वितीयक डेटा नोड के रूप में कार्य करती है। यदि शार्ड का मास्टर नीचे चला जाता है (स्वचालित विफलता ClusterControl द्वारा प्रबंधित की जाती है) तो यह मास्टर की भूमिका निभाएगा।
ClusterControl:हमारे MariaDB शार्क/क्लस्टर के लिए एक केंद्रीकृत परिनियोजन, प्रबंधन और निगरानी उपकरण।

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

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

1) ClusterControl स्थापित करें।

2) पासवर्ड रहित SSH को ClusterControl सर्वर से सभी डेटाबेस नोड्स में कॉन्फ़िगर करें। ClusterControl नोड पर:

(clustercontrol)$ whoami
root
$ ssh-keygen -t rsa
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]
$ ssh-copy-id [email protected]

3) चूंकि हम क्लस्टर के 4 सेट तैनात करने जा रहे हैं, इसलिए इस विशेष कार्य के लिए क्लस्टरकंट्रोल सीएलआई टूल का उपयोग करना एक अच्छा विचार है ताकि परिनियोजन प्रक्रिया को तेज और सरल बनाया जा सके। आइए पहले सत्यापित करें कि क्या हम निम्न कमांड चलाकर डिफ़ॉल्ट क्रेडेंशियल से जुड़ सकते हैं (डिफ़ॉल्ट क्रेडेंशियल /etc/s9s.conf पर स्वतः कॉन्फ़िगर किया गया है):

(clustercontrol)$ s9s cluster --list --long
Total: 0

अगर हमें कोई त्रुटि नहीं मिलती है और ऊपर जैसा आउटपुट दिखाई देता है, तो हम जाने के लिए अच्छे हैं।

4) ध्यान दें कि चरण 4,5,6 और 7 को एक साथ निष्पादित किया जा सकता है क्योंकि ClusterControl समानांतर परिनियोजन का समर्थन करता है। हम ClusterControl CLI का उपयोग करते हुए पहले MariaDB गेटवे सर्वर को तैनात करके शुरू करेंगे:

(clustercontrol)$ s9s cluster --create \
        --cluster-type=mysqlreplication \
        --nodes="192.168.22.101?master" \
        --vendor=mariadb \
        --provider-version=10.5 \
        --os-user=root \
        --os-key-file=/root/.ssh/id_rsa \
        --db-admin="root" \
        --db-admin-passwd="SuperS3cr3tPassw0rd" \
        --cluster-name="MariaDB Gateway 1"

5) दूसरा मारियाडीबी गेटवे सर्वर तैनात करें:

(clustercontrol)$ s9s cluster --create \
        --cluster-type=mysqlreplication \
        --nodes="192.168.22.102?master" \
        --vendor=mariadb \
        --provider-version=10.5 \
        --os-user=root \
        --os-key-file=/root/.ssh/id_rsa \
        --db-admin="root" \
        --db-admin-passwd="SuperS3cr3tPassw0rd" \
        --cluster-name="MariaDB Gateway 2"

6) पहले शार्ड के लिए 2-नोड मारियाडीबी प्रतिकृति तैनात करें:

(clustercontrol)$ s9s cluster --create \
        --cluster-type=mysqlreplication \
        --nodes="192.168.22.111?master;192.168.22.112?slave" \
        --vendor=mariadb \
        --provider-version=10.5 \
        --os-user=root \
        --os-key-file=/root/.ssh/id_rsa \
        --db-admin="root" \
        --db-admin-passwd="SuperS3cr3tPassw0rd" \
        --cluster-name="MariaDB - Shard 1"

7) दूसरे शार्ड के लिए 2-नोड MariaDB प्रतिकृति परिनियोजित करें:

(clustercontrol)$ s9s cluster --create \
        --cluster-type=mysqlreplication \
        --nodes="192.168.22.121?master;192.168.22.122?slave" \
        --vendor=mariadb \
        --provider-version=10.5 \
        --os-user=root \
        --os-key-file=/root/.ssh/id_rsa \
        --db-admin="root" \
        --db-admin-passwd="SuperS3cr3tPassw0rd" \
        --cluster-name="MariaDB - Shard 2"

जबकि परिनियोजन जारी है, हम सीएलआई से जॉब आउटपुट की निगरानी कर सकते हैं:

(clustercontrol)$ s9s job --list --show-running
ID CID STATE   OWNER GROUP  CREATED  RDY TITLE
25   0 RUNNING admin admins 07:19:28  45% Create MySQL Replication Cluster
26   0 RUNNING admin admins 07:19:38  45% Create MySQL Replication Cluster
27   0 RUNNING admin admins 07:20:06  30% Create MySQL Replication Cluster
28   0 RUNNING admin admins 07:20:14  30% Create MySQL Replication Cluster

और ClusterControl UI से भी:

एक बार परिनियोजन पूरा हो जाने पर, आपको कुछ ऐसा दिखना चाहिए जो डेटाबेस क्लस्टर सूचीबद्ध हैं ClusterControl डैशबोर्ड में इस तरह:

हमारे क्लस्टर अब तैनात हैं और नवीनतम मारियाडीबी 10.5 चला रहे हैं। इसके बाद, हमें HAProxy को MariaDB शार्क को एकल समापन बिंदु प्रदान करने के लिए कॉन्फ़िगर करने की आवश्यकता है।

HAProxy कॉन्फ़िगर करें

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

127.0.0.1:3307 -> Shard1 (बैकएंड सर्वर mariadb-shard-1a और mariadb-shard- 1बी)
127.0.0.1:3308 -> Shard2 (बैकएंड सर्वर mariadb-shard-2a और mariadb-shard- 2बी)

शार्ड के मास्टर के नीचे जाने की स्थिति में, क्लस्टर कंट्रोल नए मास्टर के रूप में शार्ड के दास को विफल कर देगा और HAProxy तदनुसार नए मास्टर के लिए कनेक्शन को फिर से रूट करेगा। हम ClusterControl का उपयोग करके गेटवे सर्वर (mariadb-gw-1 और mariadb-gw-2) पर HAProxy स्थापित करने जा रहे हैं क्योंकि यह स्वचालित रूप से बैकएंड सर्वर (mysqlchk सेटअप, उपयोगकर्ता अनुदान, xinetd स्थापना) को कुछ ट्रिक्स के साथ कॉन्फ़िगर करेगा जैसा कि नीचे दिखाया गया है।

सबसे पहले, ClusterControl UI पर, पहला शार्प चुनें, MariaDB - Shard 1 -> मैनेज करें -> लोड बैलेंसर्स -> HAProxy -> HAProxy को डिप्लॉय करें और सर्वर एड्रेस को 192.168.22.101 के रूप में निर्दिष्ट करें ( mariadb-gw-1), निम्न स्क्रीनशॉट के समान:

इसी तरह, लेकिन यह shard 2 के लिए, MariaDB - Shard 2 पर जाएं -> मैनेज करें -> लोड बैलेंसर्स -> HAProxy -> HAProxy को डिप्लॉय करें और सर्वर एड्रेस को 192.168.22.102 (mariadb-gw-2) के रूप में निर्दिष्ट करें। दोनों HAProxy नोड्स के लिए परिनियोजन समाप्त होने तक प्रतीक्षा करें।

अब हमें mariadb-gw-1 और mariadb-gw-2 पर HAProxy सर्विस को कॉन्फिगर करने की जरूरत है ताकि बैलेंस सभी शार्ड्स को एक साथ लोड किया जा सके। टेक्स्ट एडिटर (या ClusterControl UI -> मैनेज -> कॉन्फ़िगरेशन) का उपयोग करके, /etc/haproxy/haproxy.cfg के अंतिम 2 "सुनो" निर्देशों को इस तरह दिखने के लिए संपादित करें:

listen  haproxy_3307_shard1
        bind *:3307
        mode tcp
        timeout client  10800s
        timeout server  10800s
        tcp-check connect port 9200
        tcp-check expect string master\ is\ running
        balance leastconn
        option tcp-check
        default-server port 9200 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
        server 192.168.22.111 192.168.22.111:3306 check # mariadb-shard-1a-master
        server 192.168.22.112 192.168.22.112:3306 check # mariadb-shard-1b-slave

listen  haproxy_3308_shard2
        bind *:3308
        mode tcp
        timeout client  10800s
        timeout server  10800s
        tcp-check connect port 9200
        tcp-check expect string master\ is\ running
        balance leastconn
        option tcp-check
        default-server port 9200 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
        server 192.168.22.121 192.168.22.121:3306 check # mariadb-shard-2a-master
        server 192.168.22.122 192.168.22.122:3306 check # mariadb-shard-2b-slave

परिवर्तनों को लोड करने के लिए HAProxy सेवा को पुनरारंभ करें (या ClusterControl -> Nodes -> HAProxy -> Restart Node) का उपयोग करें:

$ systemctl restart haproxy

ClusterControl UI से, हम सत्यापित कर सकते हैं कि प्रति शार्क केवल एक बैकएंड सर्वर सक्रिय है (हरे रंग की रेखाओं द्वारा दर्शाया गया है), जैसा कि नीचे दिखाया गया है:

इस बिंदु पर, हमारा डेटाबेस क्लस्टर परिनियोजन अब पूरा हो गया है। हम स्पाइडर स्टोरेज इंजन का उपयोग करके मारियाडीबी शार्डिंग को कॉन्फ़िगर करने के लिए आगे बढ़ सकते हैं।

मारियाडीबी गेटवे सर्वर तैयार करना

MariaDB गेटवे सर्वर (mariadb-gw-1 और mariadb-gw-2) दोनों पर, निम्न कार्य करें:

स्पाइडर प्लग इन इंस्टॉल करें:

MariaDB> INSTALL PLUGIN spider SONAME 'ha_spider.so';

सत्यापित करें कि क्या स्टोरेज इंजन समर्थित है:

MariaDB> SELECT engine,support FROM information_schema.engines WHERE engine = 'spider';
+--------+---------+
| engine | support |
+--------+---------+
| SPIDER | YES     |
+--------+---------+

वैकल्पिक रूप से, हम यह भी सत्यापित कर सकते हैं कि प्लगइन info_schema डेटाबेस से सही ढंग से लोड किया गया है या नहीं:

MariaDB> SELECT PLUGIN_NAME,PLUGIN_VERSION,PLUGIN_STATUS,PLUGIN_TYPE FROM information_schema.plugins WHERE plugin_name LIKE 'SPIDER%';
+--------------------------+----------------+---------------+--------------------+
| PLUGIN_NAME              | PLUGIN_VERSION | PLUGIN_STATUS | PLUGIN_TYPE        |
+--------------------------+----------------+---------------+--------------------+
| SPIDER                   | 3.3            | ACTIVE        | STORAGE ENGINE     |
| SPIDER_ALLOC_MEM         | 1.0            | ACTIVE        | INFORMATION SCHEMA |
| SPIDER_WRAPPER_PROTOCOLS | 1.0            | ACTIVE        | INFORMATION SCHEMA |
+--------------------------+----------------+---------------+--------------------+

मारियाडीबी कॉन्फ़िगरेशन फ़ाइल के अंदर [mysqld] अनुभाग के अंतर्गत निम्न पंक्ति जोड़ें:

plugin-load-add = ha_spider

पहले शार्ड के लिए पहला "डेटा नोड" बनाएं जो पोर्ट 3307 पर HAProxy 127.0.0.1 के माध्यम से सुलभ होना चाहिए:

MariaDB> CREATE OR REPLACE SERVER Shard1 
FOREIGN DATA WRAPPER mysql
OPTIONS (
   HOST '127.0.0.1',
   DATABASE 'sbtest',
   USER 'spider',
   PASSWORD 'SpiderP455',
   PORT 3307);

दूसरे शार्ड के लिए दूसरा "डेटा नोड" बनाएं जो पोर्ट 3308 पर HAProxy 127.0.0.1 के माध्यम से सुलभ होना चाहिए:

CREATE OR REPLACE SERVER Shard2 
FOREIGN DATA WRAPPER mysql
OPTIONS (
   HOST '127.0.0.1',
   DATABASE 'sbtest',
   USER 'spider',
   PASSWORD 'SpiderP455',
   PORT 3308);

अब हम एक स्पाइडर टेबल बना सकते हैं जिसे विभाजित करने की आवश्यकता है। इस उदाहरण में, हम डेटाबेस sbtest के अंदर sbtest1 नामक एक तालिका बनाने जा रहे हैं, और कॉलम 'k' में पूर्णांक मान द्वारा विभाजित किया गया है:

MariaDB> CREATE SCHEMA sbtest;
MariaDB> CREATE TABLE sbtest.sbtest1 (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `k` int(11) NOT NULL DEFAULT '0',
  `c` char(120) NOT NULL DEFAULT '',
  `pad` char(60) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`, `k`)
)
  ENGINE=Spider
  COMMENT 'wrapper "mysql", table "sbtest1"'
  PARTITION BY RANGE (k) (
    PARTITION shard1 VALUES LESS THAN (499999) COMMENT = 'srv "Shard1"',
    PARTITION shard2 VALUES LESS THAN MAXVALUE COMMENT = 'srv "Shard2"'
);

ध्यान दें कि CREATE TABLE स्टेटमेंट के COMMENT ='srv "ShardX"' क्लॉज महत्वपूर्ण हैं, जहां हम रिमोट सर्वर के बारे में कनेक्शन जानकारी पास करते हैं। मान सर्वर नाम के समान होना चाहिए जैसा कि CREATE SERVER कथन में है। जैसा कि नीचे दिखाया गया है, हम Sysbench लोड जनरेटर का उपयोग करके इस तालिका को भरने जा रहे हैं।

डेटाबेस तक पहुंचने के लिए एप्लिकेशन डेटाबेस उपयोगकर्ता बनाएं, और इसे एप्लिकेशन सर्वर से अनुमति दें:

MariaDB> CREATE USER [email protected]'192.168.22.%' IDENTIFIED BY 'passw0rd';
MariaDB> GRANT ALL PRIVILEGES ON sbtest.* TO [email protected]'192.168.22.%';

इस उदाहरण में, चूंकि यह एक विश्वसनीय आंतरिक नेटवर्क है, इसलिए हम स्टेटमेंट में वाइल्डकार्ड का उपयोग उसी श्रेणी में किसी भी IP पते की अनुमति देने के लिए करते हैं, 192.168.22.0/24।

अब हम अपने डेटा नोड्स को कॉन्फ़िगर करने के लिए तैयार हैं।

मारियाडीबी शार्ड सर्वर तैयार करना

MariaDB Shard मास्टर सर्वर (mariadb-shard-1a और mariadb-shard-2a) दोनों पर, निम्न कार्य करें:

1) गंतव्य डेटाबेस बनाएं:

MariaDB> CREATE SCHEMA sbtest;

2) 'स्पाइडर' उपयोगकर्ता बनाएं और गेटवे सर्वर (mariadb-gw-1 और mariadb-gw2) से कनेक्शन की अनुमति दें। इस उपयोगकर्ता के पास शार्प टेबल और MySQL सिस्टम डेटाबेस पर सभी विशेषाधिकार होने चाहिए:

MariaDB> CREATE USER 'spider'@'192.168.22.%' IDENTIFIED BY 'SpiderP455';
MariaDB> GRANT ALL PRIVILEGES ON sbtest.* TO [email protected]'192.168.22.%';
MariaDB> GRANT ALL ON mysql.* TO [email protected]'192.168.22.%';

3) स्पाइडर स्टोरेज इंजन के माध्यम से हमारे गेटवे सर्वर से डेटा प्राप्त करने वाली तालिका बनाएं। यह "रिसीवर" तालिका मारियाडीबी द्वारा समर्थित किसी भी स्टोरेज इंजन पर हो सकती है। इस उदाहरण में, हम InnoDB स्टोरेज इंजन का उपयोग करते हैं:

MariaDB> CREATE TABLE sbtest.sbtest1 (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `k` int(11) NOT NULL DEFAULT '0',
  `c` char(120) NOT NULL DEFAULT '',
  `pad` char(60) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`, `k`)
) ENGINE = INNODB;

बस। दूसरे शार्ड पर चरणों को दोहराना न भूलें।

परीक्षण

एप्लिकेशन सर्वर पर कुछ डेटाबेस वर्कलोड उत्पन्न करने के लिए Sysbench का उपयोग करके परीक्षण करने के लिए, हमें पहले Sysbench इंस्टॉल करना होगा:

$ yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install -y sysbench

कुछ परीक्षण कार्यभार उत्पन्न करें और उन्हें पहले गेटवे सर्वर, mariadb-gw-1 (192.168.11.101) पर भेजें:

$ sysbench \
/usr/share/sysbench/oltp_insert.lua \
--report-interval=2 \
--threads=4 \
--rate=20 \
--time=9999 \
--db-driver=mysql \
--mysql-host=192.168.11.101 \
--mysql-port=3306 \
--mysql-user=sbtest \
--mysql-db=sbtest \
--mysql-password=passw0rd \
--tables=1 \
--table-size=1000000 \
run

आप उपरोक्त परीक्षण को mariadb-gw-2 (192.168.11.102) पर दोहरा सकते हैं और डेटाबेस कनेक्शन को तदनुसार सही शार्ड पर रूट किया जाना चाहिए।

पहले शार्प (mariadb-shard-1a या mariadb-shard-1b) को देखते समय, हम बता सकते हैं कि यह विभाजन केवल उन पंक्तियों को रखता है जहाँ shard key (कॉलम k) 500000 से छोटी है:

MariaDB [sbtest]> SELECT MIN(k),MAX(k) FROM sbtest1;
+--------+--------+
| min(k) | max(k) |
+--------+--------+
| 200175 | 499963 |
+--------+--------+

दूसरे शार्ड (mariadb-shard-2a या mariadb-shard-2b) पर, यह उम्मीद के मुताबिक 500000 से 999999 तक का डेटा रखता है:

MariaDB [sbtest]> SELECT MIN(k),MAX(k) FROM sbtest1;
+--------+--------+
| min(k) | max(k) |
+--------+--------+
| 500067 | 999948 |
+--------+--------+

जबकि मारियाडीबी गेटवे सर्वर (mariadb-gw-1 या mariadb-gw-2) के लिए, हम सभी पंक्तियों को इसी तरह देख सकते हैं जैसे कि तालिका इस MariaDB उदाहरण के अंदर मौजूद है:

MariaDB [sbtest]> SELECT MIN(k),MAX(k) FROM sbtest1;
+--------+--------+
| min(k) | max(k) |
+--------+--------+
| 200175 | 999948 |
+--------+--------+

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

ERROR 1429 (HY000) at line 1: Unable to connect to foreign data source: Shard2

और इसकी अनुपलब्धता के दौरान, आपको निम्नलिखित त्रुटि प्राप्त होगी:

ERROR 1158 (08S01) at line 1: Got an error reading communication packets

हमारे माप में, फ़ेलओवर शुरू होने के बाद फ़ेलओवर में लगभग 23 सेकंड का समय लगा और एक बार नए मास्टर का प्रचार हो जाने के बाद, आपको हमेशा की तरह गेटवे सर्वर से तालिका में लिखने में सक्षम होना चाहिए।

निष्कर्ष

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