रिले नोड का उपयोग करके MySQL गैलेरा क्लस्टर के साथ शून्य डाउनटाइम नेटवर्क माइग्रेशन

गैलेरा क्लस्टर का स्वचालित नोड प्रावधान गारंटीकृत डेटा स्थिरता के साथ डेटाबेस क्लस्टर को स्केल करने की जटिलता को सरल बनाता है। SST और IST डेटाबेस को मैन्युअल रूप से बैकअप करने और इसे नए नोड में कॉपी करने की आवश्यकता के बिना प्रारंभिक डेटा सिंक्रनाइज़ेशन की उपयोगिता में सुधार करते हैं। इसे अलग-अलग नेटवर्क सेटअप (जैसे, WAN प्रतिकृति) को सहन करने की गैलेरा की क्षमता के साथ मिलाएं, अब हम शून्य सेवा व्यवधान के साथ अलग-अलग नेटवर्क के बीच डेटाबेस को माइग्रेट कर सकते हैं।

इस ब्लॉग पोस्ट में, हम यह देखने जा रहे हैं कि बिना डाउनटाइम के हमारे MySQL गैलेरा क्लस्टर को कैसे माइग्रेट किया जाए। हम रिले नोड की मदद से डेटाबेस को Amazon Web Service (AWS) EC2 से Google Cloud Platform (GCP) कंप्यूट इंजन में स्थानांतरित कर देंगे। ध्यान दें कि हमारे पास अतीत में एक समान ब्लॉग पोस्ट था, लेकिन यह एक अलग दृष्टिकोण का उपयोग करता है।

निम्नलिखित आरेख हमारी प्रवासन योजना को सरल बनाता है:

पुरानी साइट की तैयारी

चूंकि दोनों साइटें सुरक्षा समूह या वीपीसी अलगाव के कारण एक दूसरे के साथ संवाद नहीं कर सकती हैं, इसलिए हमें इन दोनों साइटों को एक साथ जोड़ने के लिए एक रिले नोड की आवश्यकता है। यह नोड किसी भी साइट पर स्थित हो सकता है, लेकिन पोर्ट 3306 (MySQL), 4444 (SST), 4567 (gcomm) और 4568 (IST) पर दूसरी तरफ एक या अधिक नोड्स से कनेक्ट करने में सक्षम होना चाहिए। यहां हमारे पास पहले से मौजूद है, और हम पुरानी साइट को कैसे मापेंगे:

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

इसलिए, हम चौथे नोड का उपयोग करने जा रहे हैं, ताकि दूसरी तरफ सिंक करते समय वर्तमान उत्पादन क्लस्टर पर जोखिम कम किया जा सके। सबसे पहले, सार्वजनिक आईपी पते के साथ एडब्ल्यूएस डैशबोर्ड में एक नया उदाहरण बनाएं (ताकि यह बाहरी दुनिया से बात कर सके) और आवश्यक गैलेरा संचार पोर्ट (टीसीपी 3306, 4444, 4567-4568) की अनुमति दें।

पुरानी साइट पर चौथा नोड (रिले नोड) तैनात करें। यदि आप ClusterControl का उपयोग कर रहे हैं, तो आप क्लस्टर को स्केल करने के लिए बस "नोड जोड़ें" सुविधा का उपयोग कर सकते हैं (पहले से इस चौथे होस्ट के लिए ClusterControl नोड से पासवर्ड रहित SSH सेटअप करना न भूलें):

सुनिश्चित करें कि रिले नोड वर्तमान क्लस्टर के साथ समन्वयित है और दूसरी तरफ से संचार करने में सक्षम है।

नई साइट से, हम रिले नोड से जुड़ने जा रहे हैं क्योंकि यह एकमात्र ऐसा नोड है जिसकी बाहरी दुनिया से कनेक्टिविटी है।

नई साइट परिनियोजन

नई साइट पर, हम एक समान सेटअप को एक क्लस्टरकंट्रोल नोड और तीन-नोड गैलेरा क्लस्टर के साथ तैनात करेंगे। दोनों साइटों को एक ही MySQL संस्करण का उपयोग करना चाहिए। यहाँ नई साइट पर हमारा आर्किटेक्चर है:

ClusterControl के साथ, नया क्लस्टर परिनियोजन बस कुछ ही क्लिक दूर है और सामुदायिक संस्करण में एक निःशुल्क सुविधा है। ClusterControl पर जाएँ -> डेटाबेस क्लस्टर परिनियोजित करें -> MySQL Galera और परिनियोजन विज़ार्ड का पालन करें:

गतिविधि -> नौकरियां -> क्लस्टर बनाएं के अंतर्गत परिनियोजित करें और प्रगति की निगरानी करें पर क्लिक करें। एक बार हो जाने के बाद, आपके पास डैशबोर्ड पर निम्नलिखित होना चाहिए:

इस समय, आपके पास दो अलग गैलेरा क्लस्टर हैं - पुरानी साइट पर 4 नोड और नई साइट पर 3 नोड।

दोनों साइटों को जोड़ना

नई साइट (जीसीपी) पर, पुरानी साइट पर रिले नोड के साथ संचार करने के लिए एक नोड चुनें। हम galera-gcp1 को रिले नोड (galera-aws4) के कनेक्टर के रूप में चुनने जा रहे हैं। निम्नलिखित आरेख हमारी ब्रिजिंग योजना को दर्शाता है:

कॉन्फ़िगर करने के लिए महत्वपूर्ण चीजें निम्नलिखित पैरामीटर हैं:

• wsrep_sst_donor :wsrep_node_name दाता नोड के। galera-gcp1 पर, दाता को galera-aws4 पर सेट करें।
• wsrep_sst_auth :उपयोगकर्ता नाम में एसएसटी उपयोगकर्ता क्रेडेंशियल:पासवर्ड प्रारूप को पुरानी साइट (एडब्ल्यूएस) का पालन करना चाहिए।
• wsrep_sst_receive_address :IP पता जो जॉइनर नोड पर SST प्राप्त करेगा। galera-gcp1 पर इसे इस नोड के सार्वजनिक आईपी पते पर सेट करें।
• wsrep_cluster_address :गैलेरा कनेक्शन स्ट्रिंग। galera-gcp1 पर galera-aws4 का सार्वजनिक IP पता जोड़ें।
• wsrep_provider_options :
  • gmcast.segment:डिफ़ॉल्ट 0 है। GCP में सभी नोड्स पर एक अलग पूर्णांक सेट करें।

1. रिले नोड (galera-aws4) पर, wsrep_node_name पुनर्प्राप्त करें:

   $ mysql -uroot -p -e 'SELECT @@wsrep_node_name'
   Enter password:
   +-------------------+
   | @@wsrep_node_name |
   +-------------------+
   | 10.0.0.13         |
   +-------------------+

2. galera-gcp1 के my.cnf पर, wsrep_sst_donor सेट करें रिले नोड के wsrep_node_name . का मान और wsrep_sst_receive_address galera-gcp1 के सार्वजनिक आईपी पते पर:

   wsrep_sst_donor=10.0.0.13
   wsrep_sst_receive_address=35.197.136.232

3. GCP पर सभी नोड्स पर, सुनिश्चित करें कि wsrep_sst_auth मान पुरानी साइट (एडब्ल्यूएस) के बाद समान है और गैलेरा सेगमेंट को 1 में बदलें (इसलिए गैलेरा को पता है कि दोनों साइटें अलग-अलग नेटवर्क में हैं):

   wsrep_sst_auth=backupuser:mysecretP4ssW0rd
   wsrep_provider_options="base_port=4567; gcache.size=512M; gmcast.segment=1"

4. galera-gcp1 पर, wsrep_cluster_address सेट करें रिले नोड का सार्वजनिक आईपी पता शामिल करने के लिए:

   wsrep_cluster_address=gcomm://10.148.0.2,10.148.0.3,10.148.0.4,13.229.247.149

   **केवल wsrep_cluster_address को संशोधित करें गैलेरा-gcp1. इस पैरामीटर को galera-gcp2 और galera-gcp3 पर संशोधित न करें।

5. GCP पर सभी नोड्स रोकें। यदि आप ClusterControl का उपयोग कर रहे हैं, तो Cluster Actions ड्रॉपडाउन -> स्टॉप क्लस्टर पर जाएँ। आपको क्लस्टर और नोड दोनों स्तरों पर स्वचालित पुनर्प्राप्ति को बंद करने की भी आवश्यकता है, इसलिए ClusterControl विफल नोड्स को पुनर्प्राप्त करने का प्रयास नहीं करेगा।

6. अब सिंकिंग पार्ट। गैलेरा-gcp1 प्रारंभ करें। आप डोनर नोड पर MySQL त्रुटि लॉग से देख सकते हैं कि SST रिले नोड (10.0.0.13) के बीच galera-gcp1 (35.197.136.232) पर एक सार्वजनिक पते का उपयोग करके शुरू किया गया है:

   2017-12-19T13:58:04.765238Z 0 [Note] WSREP: Initiating SST/IST transfer on DONOR side (wsrep_sst_xtrabackup-v2 --role 'donor' --address '35.197.136.232:4444/xtrabackup_sst//1' --socket '/var/lib/mysql/m
   ysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix ''   '' --gtid 'df23adb8-b567-11e7-8c50-a386c8cc7711:151181')
   2017-12-19T13:58:04.765468Z 5 [Note] WSREP: DONOR thread signaled with 0
           2017-12-19T13:58:15.158757Z WSREP_SST: [INFO] Streaming the backup to joiner at 35.197.136.232 4444
   2017-12-19T13:58:52.512143Z 0 [Note] WSREP: 1.0 (10.0.0.13): State transfer to 0.0 (10.148.0.2) complete.

   ध्यान दें कि, इस समय, galera-gcp1 निम्नलिखित पंक्तियों से भर जाएगा:

   2017-12-19T13:32:47.111002Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.118:4567 timed out, no messages seen in PT3S
   2017-12-19T13:32:48.111123Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.90:4567 timed out, no messages seen in PT3S
   2017-12-19T13:32:50.611462Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.25:4567 timed out, no messages seen in PT3S

   आप इस चेतावनी को सुरक्षित रूप से अनदेखा कर सकते हैं क्योंकि galera-gcp1 AWS पर रिले नोड से परे शेष नोड्स को देखने का प्रयास करता रहता है।

7. galera-gcp1 पर SST पूरा होने के बाद, GCE पर ClusterControl डेटाबेस नोड्स को जोड़ने में सक्षम नहीं होगा, अनुपलब्ध GRANT के कारण (मौजूदा GRANT को AWS से सिंक करने के बाद ओवरराइड कर दिया गया है)। तो गैलेरा-जीसीपी1 पर एसएसटी पूरा होने के बाद हमें यहां क्या करना होगा:

   mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'10.148.0.5' IDENTIFIED BY 'cmon' WITH GRANT OPTION;

   एक बार यह हो जाने के बाद, ClusterControl galera-gcp1 की स्थिति की सही रिपोर्ट करेगा जैसा कि नीचे दिया गया है:

   

8. अंतिम भाग शेष galera-gcp2 और galera-gcp3, एक समय में एक नोड को प्रारंभ करना है। ClusterControl पर जाएँ -> Nodes -> नोड चुनें -> Node. एक बार सभी नोड्स सिंक हो जाने के बाद, आपको क्लस्टर आकार के रूप में 7 मिलना चाहिए:

   

क्लस्टर अब दोनों साइटों पर काम कर रहा है और स्केलिंग आउट पूरा हो गया है।

डीकमिशनिंग

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

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

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

galera-gcp1 पर निम्नलिखित पैरामीटर को तदनुसार अपडेट करना न भूलें:

• wsrep_cluster_address - रिले नोड सार्वजनिक आईपी पता निकालें।
• wsrep_sst_donor - इस लाइन पर कमेंट करें। गैलेरा को दाता को स्वतः चुनने दें।
• wsrep_sst_receive_address - इस लाइन पर कमेंट करें। गैलेरा को रिसीविंग इंटरफेस को अपने आप चुनने दें।

आपका गैलेरा क्लस्टर अब पूरी तरह से नए प्लेटफॉर्म, होस्ट और नेटवर्क पर चल रहा है और माइग्रेशन के दौरान आपकी डेटाबेस सेवा में एक सेकंड का भी डाउनटाइम नहीं है। वह कितना अच्छा है?