इस ब्लॉग के पहले भाग में, हमने MySQL InnoDB क्लस्टर के परिनियोजन वॉकथ्रू को एक उदाहरण के साथ कवर किया है कि कैसे एप्लिकेशन एक समर्पित रीड/राइट पोर्ट के माध्यम से क्लस्टर से जुड़ सकते हैं।
इस ऑपरेशन वॉकथ्रू में, हम चल रहे क्लस्टर रखरखाव कार्यों के हिस्से के रूप में इनो डीबी क्लस्टर की निगरानी, प्रबंधन और स्केल करने के उदाहरण दिखाने जा रहे हैं। हम उसी क्लस्टर का उपयोग करेंगे जिसे हमने ब्लॉग के पहले भाग में तैनात किया था। निम्नलिखित आरेख हमारी वास्तुकला को दर्शाता है:
हमारे पास एक तीन-नोड MySQL समूह प्रतिकृति और एक एप्लिकेशन सर्वर चल रहा है MySQL राउटर। सभी सर्वर उबंटू 18.04 बायोनिक पर चल रहे हैं।
MySQL InnoDB क्लस्टर कमांड विकल्प
इससे पहले कि हम कुछ उदाहरणों और स्पष्टीकरणों के साथ आगे बढ़ें, यह जानना अच्छा है कि आप सहायता () फ़ंक्शन का उपयोग करके क्लस्टर घटक के लिए MySQL क्लस्टर में प्रत्येक फ़ंक्शन का स्पष्टीकरण प्राप्त कर सकते हैं, जैसा कि नीचे दिखाया गया है:
$ mysqlsh
MySQL|localhost:3306 ssl|JS> shell.connect("[email protected]:3306");
MySQL|db1:3306 ssl|JS> cluster = dba.getCluster();
<Cluster:my_innodb_cluster>
MySQL|db1:3306 ssl|JS> cluster.help()निम्न सूची MySQL सामुदायिक सर्वर 8.0.18 के लिए MySQL शेल 8.0.18 पर उपलब्ध कार्यों को दिखाती है:
- addInstance(instance[, options])- क्लस्टर में एक इंस्टेंस जोड़ता है।
- checkInstanceState(instance)- क्लस्टर के संबंध में उदाहरण gtid स्थिति की पुष्टि करता है।
- वर्णन करें()- क्लस्टर की संरचना का वर्णन करें।
- डिस्कनेक्ट()- क्लस्टर ऑब्जेक्ट द्वारा उपयोग किए जाने वाले सभी आंतरिक सत्रों को डिस्कनेक्ट करता है।
- dissolve([options])- प्रतिकृति को निष्क्रिय करता है और क्लस्टर से रेप्लिकासेट को अपंजीकृत करता है।
- forceQuorumUsingPartitionOf(instance[, password])- क्लस्टर को कोरम के नुकसान से बचाता है।
- getName()- क्लस्टर का नाम प्राप्त करता है।
- help([सदस्य])- इस वर्ग और इसके सदस्यों के बारे में सहायता प्रदान करता है
- Options([options])- क्लस्टर कॉन्फ़िगरेशन विकल्पों को सूचीबद्ध करता है।
- rejoinInstance(instance[, options])- एक उदाहरण को क्लस्टर में फिर से शामिल करता है।
- removeInstance(instance[, options])- क्लस्टर से एक इंस्टेंस हटाता है।
- rescan([options])- क्लस्टर को फिर से स्कैन करता है।
- resetRecoveryAccountsPassword(Options)- क्लस्टर के पुनर्प्राप्ति खातों का पासवर्ड रीसेट करें।
- setInstanceOption(instance, option, value)- क्लस्टर सदस्य में कॉन्फ़िगरेशन विकल्प के मान को बदलता है।
- setOption(Option, value)- पूरे क्लस्टर के लिए कॉन्फ़िगरेशन विकल्प के मान को बदलता है।
- setPrimaryInstance(instance)- एक विशिष्ट क्लस्टर सदस्य को नए प्राथमिक के रूप में चुनता है।
- status([options])- क्लस्टर की स्थिति का वर्णन करें।
- switchToMultiPrimaryMode()- क्लस्टर को मल्टी-प्राइमरी मोड में स्विच करता है।
- switchToSinglePrimaryMode([instance])- क्लस्टर को सिंगल-प्राइमरी मोड में स्विच करता है।
हम क्लस्टर की निगरानी, प्रबंधन और स्केलिंग में सहायता के लिए उपलब्ध अधिकांश कार्यों पर गौर करने जा रहे हैं।
MySQL InnoDB क्लस्टर संचालन की निगरानी
क्लस्टर स्थिति
क्लस्टर स्थिति की जांच करने के लिए, पहले MySQL शेल कमांड लाइन का उपयोग करें और फिर [email protected]{one-of-the-db-nodes}:
के रूप में कनेक्ट करें।$ mysqlsh
MySQL|localhost:3306 ssl|JS> shell.connect("[email protected]:3306");फिर, "क्लस्टर" नामक एक ऑब्जेक्ट बनाएं और इसे "dba" वैश्विक ऑब्जेक्ट के रूप में घोषित करें जो AdminAPI का उपयोग करके InnoDB क्लस्टर प्रशासन कार्यों तक पहुंच प्रदान करता है (MySQL शेल एपीआई डॉक्स देखें):
MySQL|db1:3306 ssl|JS> cluster = dba.getCluster();
<Cluster:my_innodb_cluster>फिर, हम "dba" ऑब्जेक्ट के लिए API फ़ंक्शन को कॉल करने के लिए ऑब्जेक्ट नाम का उपयोग कर सकते हैं:
MySQL|db1:3306 ssl|JS> cluster.status(){
"clusterName": "my_innodb_cluster",
"defaultReplicaSet": {
"name": "default",
"primary": "db1:3306",
"ssl": "REQUIRED",
"status": "OK",
"statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
"topology": {
"db1:3306": {
"address": "db1:3306",
"mode": "R/W",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.18"
},
"db2:3306": {
"address": "db2:3306",
"mode": "R/O",
"readReplicas": {},
"replicationLag": "00:00:09.061918",
"role": "HA",
"status": "ONLINE",
"version": "8.0.18"
},
"db3:3306": {
"address": "db3:3306",
"mode": "R/O",
"readReplicas": {},
"replicationLag": "00:00:09.447804",
"role": "HA",
"status": "ONLINE",
"version": "8.0.18"
}
},
"topologyMode": "Single-Primary"
},
"groupInformationSourceMember": "db1:3306"
}आउटपुट काफी लंबा है लेकिन हम मैप संरचना का उपयोग करके इसे फ़िल्टर कर सकते हैं। उदाहरण के लिए, यदि हम केवल db3 के लिए प्रतिकृति लैग देखना चाहते हैं, तो हम निम्न कार्य कर सकते हैं:
MySQL|db1:3306 ssl|JS> cluster.status().defaultReplicaSet.topology["db3:3306"].replicationLag
00:00:09.447804ध्यान दें कि प्रतिकृति अंतराल कुछ ऐसा है जो समूह प्रतिकृति में होगा, जो प्रतिकृति सेट में प्राथमिक सदस्य की लेखन तीव्रता और group_replication_flow_control_* चर पर निर्भर करता है। हम यहां इस विषय को विस्तार से कवर नहीं करने जा रहे हैं। समूह प्रतिकृति प्रदर्शन और प्रवाह नियंत्रण पर आगे समझने के लिए इस ब्लॉग पोस्ट को देखें।
एक अन्य समान कार्य वर्णन () फ़ंक्शन है, लेकिन यह थोड़ा अधिक सरल है। यह क्लस्टर की संरचना का वर्णन करता है जिसमें इसकी सभी जानकारी, प्रतिकृति सेट और उदाहरण शामिल हैं:
MySQL|db1:3306 ssl|JS> cluster.describe(){
"clusterName": "my_innodb_cluster",
"defaultReplicaSet": {
"name": "default",
"topology": [
{
"address": "db1:3306",
"label": "db1:3306",
"role": "HA"
},
{
"address": "db2:3306",
"label": "db2:3306",
"role": "HA"
},
{
"address": "db3:3306",
"label": "db3:3306",
"role": "HA"
}
],
"topologyMode": "Single-Primary"
}
}इसी तरह, हम मानचित्र संरचना का उपयोग करके JSON आउटपुट को फ़िल्टर कर सकते हैं:
MySQL|db1:3306 ssl|JS> cluster.describe().defaultReplicaSet.topologyMode
Single-Primaryजब प्राथमिक नोड नीचे चला गया (इस मामले में, db1 है), आउटपुट ने निम्नलिखित लौटाया:
MySQL|db1:3306 ssl|JS> cluster.status(){
"clusterName": "my_innodb_cluster",
"defaultReplicaSet": {
"name": "default",
"primary": "db2:3306",
"ssl": "REQUIRED",
"status": "OK_NO_TOLERANCE",
"statusText": "Cluster is NOT tolerant to any failures. 1 member is not active",
"topology": {
"db1:3306": {
"address": "db1:3306",
"mode": "n/a",
"readReplicas": {},
"role": "HA",
"shellConnectError": "MySQL Error 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 104",
"status": "(MISSING)"
},
"db2:3306": {
"address": "db2:3306",
"mode": "R/W",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.18"
},
"db3:3306": {
"address": "db3:3306",
"mode": "R/O",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.18"
}
},
"topologyMode": "Single-Primary"
},
"groupInformationSourceMember": "db2:3306"
}OK_NO_TOLERANCE की स्थिति पर ध्यान दें, जहां क्लस्टर अभी भी चल रहा है और चल रहा है लेकिन एक से अधिक तीन नोड उपलब्ध नहीं होने के बाद यह और विफलता बर्दाश्त नहीं कर सकता है। प्राथमिक भूमिका स्वचालित रूप से db2 द्वारा ले ली गई है, और यदि वे MySQL राउटर के माध्यम से जुड़ते हैं तो एप्लिकेशन से डेटाबेस कनेक्शन सही नोड पर फिर से भेज दिए जाएंगे। एक बार जब db1 ऑनलाइन वापस आ जाता है, तो हमें निम्न स्थिति देखनी चाहिए:
MySQL|db1:3306 ssl|JS> cluster.status(){
"clusterName": "my_innodb_cluster",
"defaultReplicaSet": {
"name": "default",
"primary": "db2:3306",
"ssl": "REQUIRED",
"status": "OK",
"statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
"topology": {
"db1:3306": {
"address": "db1:3306",
"mode": "R/O",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.18"
},
"db2:3306": {
"address": "db2:3306",
"mode": "R/W",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.18"
},
"db3:3306": {
"address": "db3:3306",
"mode": "R/O",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.18"
}
},
"topologyMode": "Single-Primary"
},
"groupInformationSourceMember": "db2:3306"
}यह दिखाता है कि db1 अब उपलब्ध है लेकिन केवल-पढ़ने के लिए सक्षम के साथ द्वितीयक के रूप में कार्य करता है। प्राथमिक भूमिका तब तक db2 को सौंपी जाती है जब तक कि नोड में कुछ गलत न हो जाए, जहां यह स्वचालित रूप से अगले उपलब्ध नोड पर विफल हो जाएगा।
इंस्टेंस स्थिति जांचें
चेकइनस्टेंसस्टेट() फ़ंक्शन का उपयोग करके हम इसे क्लस्टर में जोड़ने की योजना बनाने से पहले एक MySQL नोड की स्थिति की जांच कर सकते हैं। यह क्लस्टर पर निष्पादित/शुद्ध किए गए GTID के साथ निष्पादित GTID के उदाहरण का विश्लेषण करता है ताकि यह निर्धारित किया जा सके कि उदाहरण क्लस्टर के लिए मान्य है या नहीं।
निम्नलिखित db3 की इंस्टेंस स्थिति दिखाता है जब यह क्लस्टर के भाग से पहले स्टैंडअलोन मोड में था:
MySQL|db1:3306 ssl|JS> cluster.checkInstanceState("db3:3306")
Cluster.checkInstanceState: The instance 'db3:3306' is a standalone instance but is part of a different InnoDB Cluster (metadata exists, instance does not belong to that metadata, and Group Replication is not active).यदि नोड पहले से ही क्लस्टर का हिस्सा है, तो आपको निम्नलिखित मिलना चाहिए:
MySQL|db1:3306 ssl|JS> cluster.checkInstanceState("db3:3306")
Cluster.checkInstanceState: The instance 'db3:3306' already belongs to the ReplicaSet: 'default'.किसी भी "क्वेरी करने योग्य" स्थिति की निगरानी करें
MySQL शेल के साथ, अब हम वास्तविक समय में किसी भी प्रशासनिक क्वेरी की निगरानी के लिए बिल्ट-इन \show और \watch कमांड का उपयोग कर सकते हैं। उदाहरण के लिए, हम निम्न का उपयोग करके जुड़े हुए थ्रेड्स का रीयल-टाइम मान प्राप्त कर सकते हैं:
MySQL|db1:3306 ssl|JS> \show query SHOW STATUS LIKE '%thread%';या वर्तमान MySQL प्रक्रिया सूची प्राप्त करें:
MySQL|db1:3306 ssl|JS> \show query SHOW FULL PROCESSLISTतब हम रिपोर्ट को चलाने के लिए \watch कमांड का उपयोग \show कमांड की तरह ही कर सकते हैं, लेकिन यह नियमित अंतराल पर परिणामों को रीफ्रेश करता है जब तक कि आप Ctrl + C का उपयोग करके कमांड को रद्द नहीं करते हैं। जैसा कि में दिखाया गया है निम्नलिखित उदाहरण:
MySQL|db1:3306 ssl|JS> \watch query SHOW STATUS LIKE '%thread%';
MySQL|db1:3306 ssl|JS> \watch query --interval=1 SHOW FULL PROCESSLISTडिफ़ॉल्ट ताज़ा अंतराल 2 सेकंड है। आप --interval फ़्लैग का उपयोग करके मान बदल सकते हैं और 0.1 से 86400 तक मान निर्दिष्ट कर सकते हैं।
MySQL InnoDB क्लस्टर प्रबंधन संचालन
प्राथमिक स्विचओवर
प्राथमिक उदाहरण वह नोड है जिसे प्रतिकृति समूह में नेता के रूप में माना जा सकता है, जिसमें पढ़ने और लिखने के संचालन करने की क्षमता होती है। एकल-प्राथमिक टोपोलॉजी मोड में प्रति क्लस्टर केवल एक प्राथमिक उदाहरण की अनुमति है। इस टोपोलॉजी को रेप्लिका सेट के रूप में भी जाना जाता है और यह समूह प्रतिकृति के लिए अनुशंसित टोपोलॉजी मोड है जो लॉकिंग विरोधों से सुरक्षा प्रदान करता है।
प्राथमिक इंस्टेंस स्विचओवर करने के लिए, क्लस्टरडमिन उपयोगकर्ता के रूप में डेटाबेस नोड्स में से किसी एक में लॉगिन करें और उस डेटाबेस नोड को निर्दिष्ट करें जिसे आप setPrimaryInstance() फ़ंक्शन का उपयोग करके प्रचारित करना चाहते हैं:
MySQL|db1:3306 ssl|JS> shell.connect("[email protected]:3306");
MySQL|db1:3306 ssl|JS> cluster.setPrimaryInstance("db1:3306");
Setting instance 'db1:3306' as the primary instance of cluster 'my_innodb_cluster'...
Instance 'db2:3306' was switched from PRIMARY to SECONDARY.
Instance 'db3:3306' remains SECONDARY.
Instance 'db1:3306' was switched from SECONDARY to PRIMARY.
WARNING: The cluster internal session is not the primary member anymore. For cluster management operations please obtain a fresh cluster handle using <Dba>.getCluster().
The instance 'db1:3306' was successfully elected as primary.हमने अभी-अभी db1 को नए प्राथमिक घटक के रूप में प्रचारित किया है, db2 को प्रतिस्थापित किया है जबकि db3 द्वितीयक नोड के रूप में बना हुआ है।
क्लस्टर बंद करना
एप्लिकेशन सर्वर पर पहले MySQL राउटर सेवा (यदि यह चल रही है) को रोककर क्लस्टर को इनायत से बंद करने का सबसे अच्छा तरीका है:
$ myrouter/stop.shउपरोक्त चरण अनुप्रयोगों द्वारा आकस्मिक लेखन के खिलाफ क्लस्टर सुरक्षा प्रदान करता है। फिर मानक MySQL स्टॉप कमांड का उपयोग करके एक समय में एक डेटाबेस नोड को बंद करें, या अपनी इच्छानुसार सिस्टम शटडाउन करें:
$ systemctl stop mysqlशटडाउन के बाद क्लस्टर प्रारंभ करना
यदि आपका क्लस्टर पूरी तरह से बंद हो गया है या आप क्लीन शटडाउन के बाद क्लस्टर शुरू करना चाहते हैं, तो आप यह सुनिश्चित कर सकते हैं कि dba.rebootClusterFromCompleteOutage() फ़ंक्शन का उपयोग करके इसे सही ढंग से पुन:कॉन्फ़िगर किया गया है। जब सभी सदस्य ऑफ़लाइन होते हैं तो यह केवल एक क्लस्टर को ऑनलाइन वापस लाता है। इस घटना में कि एक क्लस्टर पूरी तरह से बंद हो गया है, उदाहरणों को शुरू किया जाना चाहिए और उसके बाद ही क्लस्टर शुरू किया जा सकता है।
इस प्रकार, सुनिश्चित करें कि सभी MySQL सर्वर प्रारंभ और चल रहे हैं। प्रत्येक डेटाबेस नोड पर देखें कि क्या mysqld प्रक्रिया चल रही है:
$ ps -ef | grep -i mysqlफिर, प्राथमिक नोड होने के लिए एक डेटाबेस सर्वर चुनें और इसे MySQL शेल के माध्यम से कनेक्ट करें:
MySQL|JS> shell.connect("[email protected]:3306");उन्हें शुरू करने के लिए उस होस्ट से निम्न कमांड चलाएँ:
MySQL|db1:3306 ssl|JS> cluster = dba.rebootClusterFromCompleteOutage()आपको निम्नलिखित प्रश्नों के साथ प्रस्तुत किया जाएगा:
उपरोक्त पूर्ण होने के बाद, आप क्लस्टर स्थिति सत्यापित कर सकते हैं:
MySQL|db1:3306 ssl|JS> cluster.status()इस बिंदु पर, db1 प्राथमिक नोड और लेखक है। शेष माध्यमिक सदस्य होंगे। यदि आप प्राथमिक के रूप में db2 या db3 के साथ क्लस्टर शुरू करना चाहते हैं, तो आप संबंधित नोड से कनेक्ट करने के लिए shell.connect() फ़ंक्शन का उपयोग कर सकते हैं और उस विशेष नोड से रीबूटक्लस्टरफ्रॉमकंपलेटऑउटेज() निष्पादित कर सकते हैं।
फिर आप MySQL राउटर सेवा शुरू कर सकते हैं (यदि यह शुरू नहीं हुई है) और एप्लिकेशन को फिर से क्लस्टर से कनेक्ट होने दें।
सदस्य और क्लस्टर विकल्प सेट करना
क्लस्टर-व्यापी विकल्प प्राप्त करने के लिए, बस दौड़ें:
MySQL|db1:3306 ssl|JS> cluster.options()उपरोक्त प्रतिकृति सेट के लिए वैश्विक विकल्पों और क्लस्टर में प्रति सदस्य व्यक्तिगत विकल्पों की सूची देगा। यह फ़ंक्शन क्लस्टर के सभी सदस्यों में एक InnoDB क्लस्टर कॉन्फ़िगरेशन विकल्प को बदलता है। समर्थित विकल्प हैं:
- clusterName:क्लस्टर नाम को परिभाषित करने के लिए स्ट्रिंग मान।
- exitStateAction:समूह प्रतिकृति निकास स्थिति क्रिया को इंगित करने वाला स्ट्रिंग मान।
- MemberWeight:फ़ेलओवर पर स्वचालित प्राथमिक चुनाव के लिए प्रतिशत भार के साथ पूर्णांक मान।
- failoverConsistency:स्ट्रिंग मान जो क्लस्टर द्वारा प्रदान की जाने वाली निरंतरता की गारंटी देता है।
- संगति: स्ट्रिंग मान जो क्लस्टर द्वारा प्रदान की जाने वाली निरंतरता की गारंटी देता है।
- expelTimeout:समयावधि को सेकंड में परिभाषित करने के लिए पूर्णांक मान, जिसे क्लस्टर सदस्यों को क्लस्टर से बेदखल करने से पहले किसी गैर-प्रतिसाद देने वाले सदस्य की प्रतीक्षा करनी चाहिए।
- autoRejoinTries:पूर्णांक मान यह परिभाषित करने के लिए कि कोई इंस्टेंस कितनी बार निष्कासित होने के बाद क्लस्टर में फिर से शामिल होने का प्रयास करेगा।
- disableClone:बूलियन मान क्लस्टर पर क्लोन उपयोग को अक्षम करने के लिए उपयोग किया जाता है।
अन्य फ़ंक्शन के समान, आउटपुट को मानचित्र संरचना में फ़िल्टर किया जा सकता है। निम्न कमांड केवल db2 के विकल्पों की सूची देगा:
MySQL|db1:3306 ssl|JS> cluster.options().defaultReplicaSet.topology["db2:3306"]आप सहायता () फ़ंक्शन का उपयोग करके भी उपरोक्त सूची प्राप्त कर सकते हैं:
MySQL|db1:3306 ssl|JS> cluster.help("setOption")निम्न आदेश सभी सदस्यों के लिए एक विकल्प सेट करने के लिए एक उदाहरण दिखाता है जिसे MemberWeight 60 (50 से) कहा जाता है:
MySQL|db1:3306 ssl|JS> cluster.setOption("memberWeight", 60)
Setting the value of 'memberWeight' to '60' in all ReplicaSet members ...
Successfully set the value of 'memberWeight' to '60' in the 'default' ReplicaSet.हम सेटइंस्टेंसऑप्शन () फ़ंक्शन का उपयोग करके MySQL शेल के माध्यम से स्वचालित रूप से कॉन्फ़िगरेशन प्रबंधन भी कर सकते हैं और डेटाबेस होस्ट, विकल्प का नाम और उसके अनुसार मान पास कर सकते हैं:
MySQL|db1:3306 ssl|JS> cluster = dba.getCluster()
MySQL|db1:3306 ssl|JS> cluster.setInstanceOption("db1:3306", "memberWeight", 90)समर्थित विकल्प हैं:
- exitStateAction: स्ट्रिंग मान समूह प्रतिकृति निकास स्थिति क्रिया को दर्शाता है।
- MemberWeight:फ़ेलओवर पर स्वचालित प्राथमिक चुनाव के लिए प्रतिशत भार के साथ पूर्णांक मान।
- autoRejoinTries:पूर्णांक मान यह परिभाषित करने के लिए कि कोई इंस्टेंस कितनी बार निष्कासित होने के बाद क्लस्टर में फिर से शामिल होने का प्रयास करेगा।
- उदाहरण के लिए एक स्ट्रिंग पहचानकर्ता को लेबल करें।
बहु-प्राथमिक/एकल-प्राथमिक मोड में स्विच करना
डिफ़ॉल्ट रूप से, InnoDB क्लस्टर एकल-प्राथमिक के साथ कॉन्फ़िगर किया गया है, केवल एक सदस्य एक समय में पढ़ने और लिखने में सक्षम है। यह क्लस्टर चलाने का सबसे सुरक्षित और अनुशंसित तरीका है और अधिकांश कार्यभार के लिए उपयुक्त है।
हालाँकि, यदि अनुप्रयोग तर्क वितरित लेखन को संभाल सकता है, तो बहु-प्राथमिक मोड पर स्विच करना शायद एक अच्छा विचार है, जहाँ क्लस्टर के सभी सदस्य एक ही समय में पढ़ने और लिखने की प्रक्रिया करने में सक्षम होते हैं। एकल-प्राथमिक से बहु-प्राथमिक मोड में स्विच करने के लिए, बस switchToMultiPrimaryMode() फ़ंक्शन का उपयोग करें:
MySQL|db1:3306 ssl|JS> cluster.switchToMultiPrimaryMode()
Switching cluster 'my_innodb_cluster' to Multi-Primary mode...
Instance 'db2:3306' was switched from SECONDARY to PRIMARY.
Instance 'db3:3306' was switched from SECONDARY to PRIMARY.
Instance 'db1:3306' remains PRIMARY.
The cluster successfully switched to Multi-Primary mode.इसके साथ सत्यापित करें:
MySQL|db1:3306 ssl|JS> cluster.status(){
"clusterName": "my_innodb_cluster",
"defaultReplicaSet": {
"name": "default",
"ssl": "REQUIRED",
"status": "OK",
"statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
"topology": {
"db1:3306": {
"address": "db1:3306",
"mode": "R/W",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.18"
},
"db2:3306": {
"address": "db2:3306",
"mode": "R/W",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.18"
},
"db3:3306": {
"address": "db3:3306",
"mode": "R/W",
"readReplicas": {},
"replicationLag": null,
"role": "HA",
"status": "ONLINE",
"version": "8.0.18"
}
},
"topologyMode": "Multi-Primary"
},
"groupInformationSourceMember": "db1:3306"
}बहु-प्राथमिक मोड में, सभी नोड प्राथमिक होते हैं और पढ़ने और लिखने की प्रक्रिया करने में सक्षम होते हैं। सिंगल-राइटर पोर्ट (6446) पर MySQL राउटर के माध्यम से एक नया कनेक्शन भेजते समय, कनेक्शन केवल एक नोड को भेजा जाएगा, जैसा कि इस उदाहरण में है, db1:
(app-server)$ for i in {1..3}; do mysql -usbtest -p -h192.168.10.40 -P6446 -e 'select @@hostname, @@read_only, @@super_read_only'; done
+------------+-------------+-------------------+
| @@hostname | @@read_only | @@super_read_only |
+------------+-------------+-------------------+
| db1 | 0 | 0 |
+------------+-------------+-------------------+
+------------+-------------+-------------------+
| @@hostname | @@read_only | @@super_read_only |
+------------+-------------+-------------------+
| db1 | 0 | 0 |
+------------+-------------+-------------------+
+------------+-------------+-------------------+
| @@hostname | @@read_only | @@super_read_only |
+------------+-------------+-------------------+
| db1 | 0 | 0 |
+------------+-------------+-------------------+यदि एप्लिकेशन मल्टी-राइटर पोर्ट (6447) से कनेक्ट होता है, तो कनेक्शन सभी सदस्यों के लिए राउंड रॉबिन एल्गोरिथम के माध्यम से संतुलित लोड किया जाएगा:
(app-server)$ for i in {1..3}; do mysql -usbtest -ppassword -h192.168.10.40 -P6447 -e 'select @@hostname, @@read_only, @@super_read_only'; done
+------------+-------------+-------------------+
| @@hostname | @@read_only | @@super_read_only |
+------------+-------------+-------------------+
| db2 | 0 | 0 |
+------------+-------------+-------------------+
+------------+-------------+-------------------+
| @@hostname | @@read_only | @@super_read_only |
+------------+-------------+-------------------+
| db3 | 0 | 0 |
+------------+-------------+-------------------+
+------------+-------------+-------------------+
| @@hostname | @@read_only | @@super_read_only |
+------------+-------------+-------------------+
| db1 | 0 | 0 |
+------------+-------------+-------------------+जैसा कि आप ऊपर दिए गए आउटपुट से देख सकते हैं, सभी नोड्स read_only =OFF के साथ रीड और राइट को प्रोसेस करने में सक्षम हैं। आप मल्टी-राइटर पोर्ट (6447) से कनेक्ट करके सभी सदस्यों को सुरक्षित राइट्स वितरित कर सकते हैं, और सिंगल-राइटर पोर्ट (6446) पर परस्पर विरोधी या भारी राइट्स भेज सकते हैं।
एकल-प्राथमिक मोड पर वापस जाने के लिए, स्विचटॉसिंगल प्राइमरीमोड () फ़ंक्शन का उपयोग करें और एक सदस्य को प्राथमिक नोड के रूप में निर्दिष्ट करें। इस उदाहरण में, हमने db1 को चुना:
MySQL|db1:3306 ssl|JS> cluster.switchToSinglePrimaryMode("db1:3306");
Switching cluster 'my_innodb_cluster' to Single-Primary mode...
Instance 'db2:3306' was switched from PRIMARY to SECONDARY.
Instance 'db3:3306' was switched from PRIMARY to SECONDARY.
Instance 'db1:3306' remains PRIMARY.
WARNING: Existing connections that expected a R/W connection must be disconnected, i.e. instances that became SECONDARY.
The cluster successfully switched to Single-Primary mode.इस बिंदु पर, db1 अब केवल-पढ़ने के लिए अक्षम के साथ कॉन्फ़िगर किया गया प्राथमिक नोड है और बाकी को केवल-पढ़ने के लिए सक्षम के साथ द्वितीयक के रूप में कॉन्फ़िगर किया जाएगा।
MySQL InnoDB क्लस्टर स्केलिंग ऑपरेशंस
बढ़ाना (एक नया DB नोड जोड़ना)
एक नया उदाहरण जोड़ते समय, प्रतिकृति समूह के साथ भाग लेने की अनुमति देने से पहले एक नोड को पहले प्रावधान किया जाना चाहिए। प्रावधान प्रक्रिया को MySQL द्वारा स्वचालित रूप से नियंत्रित किया जाएगा। साथ ही, आप पहले बताए गए तरीके से checkInstanceState() फ़ंक्शन का उपयोग करके पहले उदाहरण स्थिति की जांच कर सकते हैं कि नोड क्लस्टर में शामिल होने के लिए मान्य है या नहीं।
एक नया DB नोड जोड़ने के लिए, addInstances () फ़ंक्शन का उपयोग करें और होस्ट निर्दिष्ट करें:
MySQL|db1:3306 ssl|JS> cluster.addInstance("db3:3306")नया इंस्टेंस जोड़ने पर आपको निम्नलिखित मिलेगा:
इसके साथ नया क्लस्टर आकार सत्यापित करें:
MySQL|db1:3306 ssl|JS> cluster.status() //or cluster.describe()MySQL राउटर स्वचालित रूप से जोड़े गए नोड, db3 को लोड बैलेंसिंग सेट में शामिल कर लेगा।
स्केलिंग डाउन (नोड को हटाना)
एक नोड को हटाने के लिए, किसी भी डीबी नोड से कनेक्ट करें, सिवाय इसके कि हम हटाने जा रहे हैं और डेटाबेस इंस्टेंस नाम के साथ रिमूव इंस्टेंस () फ़ंक्शन का उपयोग करें:
MySQL|db1:3306 ssl|JS> shell.connect("[email protected]:3306");
MySQL|db1:3306 ssl|JS> cluster = dba.getCluster()
MySQL|db1:3306 ssl|JS> cluster.removeInstance("db3:3306")किसी इंस्टेंस को हटाते समय आपको निम्नलिखित मिलेगा:
इसके साथ नया क्लस्टर आकार सत्यापित करें:
MySQL|db1:3306 ssl|JS> cluster.status() //or cluster.describe()MySQL राउटर स्वचालित रूप से हटाए गए नोड, db3 को लोड बैलेंसिंग सेट से बाहर कर देगा।
एक नया प्रतिकृति दास जोड़ना
हम किसी भी क्लस्टर नोड से अतुल्यकालिक प्रतिकृति दास प्रतिकृति के साथ InnoDB क्लस्टर को स्केल कर सकते हैं। एक गुलाम क्लस्टर के साथ शिथिल रूप से जुड़ा होता है, और क्लस्टर के प्रदर्शन को प्रभावित किए बिना भारी भार को संभालने में सक्षम होगा। आपदा पुनर्प्राप्ति उद्देश्यों के लिए दास डेटाबेस की लाइव कॉपी भी हो सकता है। मल्टी-प्राइमरी मोड में, आप स्लेव को समर्पित MySQL रीड-ओनली प्रोसेसर के रूप में रीड वर्कलोड को स्केल करने, एनालिटिक्स ऑपरेशन करने, या एक समर्पित बैकअप सर्वर के रूप में उपयोग कर सकते हैं।
स्लेव सर्वर पर, नवीनतम एपीटी कॉन्फ़िगरेशन पैकेज डाउनलोड करें, इसे इंस्टॉल करें (कॉन्फ़िगरेशन विज़ार्ड में MySQL 8.0 चुनें), एपीटी कुंजी इंस्टॉल करें, रेपोलिस्ट अपडेट करें और MySQL सर्वर इंस्टॉल करें।
$ wget https://repo.mysql.com/apt/ubuntu/pool/mysql-apt-config/m/mysql-apt-config/mysql-apt-config_0.8.14-1_all.deb
$ dpkg -i mysql-apt-config_0.8.14-1_all.deb
$ apt-key adv --recv-keys --keyserver ha.pool.sks-keyservers.net 5072E1F5
$ apt-get update
$ apt-get -y install mysql-server mysql-shellप्रतिकृति दास के लिए सर्वर तैयार करने के लिए MySQL कॉन्फ़िगरेशन फ़ाइल को संशोधित करें। टेक्स्ट एडिटर के माध्यम से कॉन्फ़िगरेशन फ़ाइल खोलें:
$ vim /etc/mysql/mysql.conf.d/mysqld.cnfऔर निम्नलिखित पंक्तियाँ संलग्न करें:
server-id = 1044 # must be unique across all nodes
gtid-mode = ON
enforce-gtid-consistency = ON
log-slave-updates = OFF
read-only = ON
super-read-only = ON
expire-logs-days = 7परिवर्तन लागू करने के लिए दास पर MySQL सर्वर को पुनरारंभ करें:
$ systemctl restart mysqlएक InnoDB क्लस्टर सर्वर पर (हमने db3 को चुना), एक प्रतिकृति स्लेव उपयोगकर्ता बनाएं और उसके बाद एक पूर्ण MySQL डंप बनाएं:
$ mysql -uroot -p
mysql> CREATE USER 'repl_user'@'192.168.0.44' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'192.168.0.44';
mysql> exit
$ mysqldump -uroot -p --single-transaction --master-data=1 --all-databases --triggers --routines --events > dump.sqlडंप फ़ाइल को db3 से स्लेव में स्थानांतरित करें:
$ scp dump.sql [email protected]:~और दास पर बहाली करें:
$ mysql -uroot -p < dump.sqlमास्टर-डेटा =1 के साथ, हमारी MySQL डंप फ़ाइल स्वचालित रूप से GTID निष्पादित और शुद्ध मान को कॉन्फ़िगर कर देगी। हम पुनर्स्थापना के बाद दास सर्वर पर निम्नलिखित कथन के साथ इसे सत्यापित कर सकते हैं:
$ mysql -uroot -p
mysql> show global variables like '%gtid_%';
+----------------------------------+----------------------------------------------+
| Variable_name | Value |
+----------------------------------+----------------------------------------------+
| binlog_gtid_simple_recovery | ON |
| enforce_gtid_consistency | ON |
| gtid_executed | d4790339-0694-11ea-8fd5-02f67042125d:1-45886 |
| gtid_executed_compression_period | 1000 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | d4790339-0694-11ea-8fd5-02f67042125d:1-45886 |
+----------------------------------+----------------------------------------------+अछा लगता है। फिर हम प्रतिकृति लिंक को कॉन्फ़िगर कर सकते हैं और दास पर प्रतिकृति थ्रेड शुरू कर सकते हैं:
mysql> CHANGE MASTER TO MASTER_HOST = '192.168.10.43', MASTER_USER = 'repl_user', MASTER_PASSWORD = 'password', MASTER_AUTO_POSITION = 1;
mysql> START SLAVE;प्रतिकृति स्थिति सत्यापित करें और सुनिश्चित करें कि निम्न स्थिति 'हां' लौटाए:
mysql> show slave status\G
...
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
...इस समय, हमारी वास्तुकला अब इस तरह दिख रही है:
MySQL InnoDB क्लस्टर के साथ सामान्य समस्याएं
स्मृति थकावट
MySQL 8.0 के साथ MySQL शेल का उपयोग करते समय, इंस्टेंसेस को 1GB RAM के साथ कॉन्फ़िगर किए जाने पर हमें लगातार निम्न त्रुटि मिल रही थी:
Can't create a new thread (errno 11); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug (MySQL Error 1135)प्रत्येक होस्ट की RAM को 2GB RAM में अपग्रेड करने से समस्या हल हो गई। स्पष्ट रूप से, MySQL 8.0 घटकों को कुशलतापूर्वक संचालित करने के लिए अधिक RAM की आवश्यकता होती है।
Lost Connection to MySQL Server
In case the primary node goes down, you would probably see the "lost connection to MySQL server error" when trying to query something on the current session:
MySQL|db1:3306 ssl|JS> cluster.status()
Cluster.status: Lost connection to MySQL server during query (MySQL Error 2013)
MySQL|db1:3306 ssl|JS> cluster.status()
Cluster.status: MySQL server has gone away (MySQL Error 2006)The solution is to re-declare the object once more:
MySQL|db1:3306 ssl|JS> cluster = dba.getCluster()
<Cluster:my_innodb_cluster>
MySQL|db1:3306 ssl|JS> cluster.status()At this point, it will connect to the newly promoted primary node to retrieve the cluster status.
Node Eviction and Expelled
In an event where communication between nodes is interrupted, the problematic node will be evicted from the cluster without any delay, which is not good if you are running on a non-stable network. This is what it looks like on db2 (the problematic node):
2019-11-14T07:07:59.344888Z 0 [ERROR] [MY-011505] [Repl] Plugin group_replication reported: 'Member was expelled from the group due to network failures, changing member status to ERROR.'
2019-11-14T07:07:59.371966Z 0 [ERROR] [MY-011712] [Repl] Plugin group_replication reported: 'The server was automatically set into read only mode after an error was detected.'Meanwhile from db1, it saw db2 was offline:
2019-11-14T07:07:44.086021Z 0 [Warning] [MY-011493] [Repl] Plugin group_replication reported: 'Member with address db2:3306 has become unreachable.'
2019-11-14T07:07:46.087216Z 0 [Warning] [MY-011499] [Repl] Plugin group_replication reported: 'Members removed from the group: db2:3306'
To tolerate a bit of delay on node eviction, we can set a higher timeout value before a node is being expelled from the group. The default value is 0, which means expel immediately. Use the setOption() function to set the expelTimeout value:
Thanks to Frédéric Descamps from Oracle who pointed this out:
Instead of relying on expelTimeout, it's recommended to set the autoRejoinTries option instead. The value represents the number of times an instance will attempt to rejoin the cluster after being expelled. A good number to start is 3, which means, the expelled member will try to rejoin the cluster for 3 times, which after an unsuccessful auto-rejoin attempt, the member waits 5 minutes before the next try.
To set this value cluster-wide, we can use the setOption() function:
MySQL|db1:3306 ssl|JS> cluster.setOption("autoRejoinTries", 3)
WARNING: Each cluster member will only proceed according to its exitStateAction if auto-rejoin fails (i.e. all retry attempts are exhausted).
Setting the value of 'autoRejoinTries' to '3' in all ReplicaSet members ...
Successfully set the value of 'autoRejoinTries' to '3' in the 'default' ReplicaSet.
निष्कर्ष
For MySQL InnoDB Cluster, most of the management and monitoring operations can be performed directly via MySQL Shell (only available from MySQL 5.7.21 and later).
