ClusterControl का बैकअप और रिस्टोर कैसे करें

ClusterControl 1.7.1 ने एक नई सुविधा पेश की जो आपको अपने ClusterControl सर्वर का बैकअप लेने और इसे (अपने प्रबंधित डेटाबेस के बारे में मेटाडेटा के साथ) दूसरे सर्वर पर पुनर्स्थापित करने की अनुमति देती है। यह ClusterControl एप्लिकेशन के साथ-साथ इसके सभी कॉन्फ़िगरेशन डेटा का बैकअप लेता है। ClusterControl को एक नए सर्वर पर माइग्रेट करना एक दर्द हुआ करता था, लेकिन अब और नहीं।

यह ब्लॉग पोस्ट आपको इस नई सुविधा के बारे में बताता है।

हम सभी कॉन्फ़िगरेशन और सेटिंग्स को संरक्षित करते हुए, ClusterControl को एक सर्वर से दूसरे सर्वर पर माइग्रेट करेंगे।

हम आपको यह भी दिखाएंगे कि एक क्लस्टर के प्रबंधन को एक ClusterControl इंस्टेंस से दूसरे में कैसे स्थानांतरित किया जाए।

हमारा उदाहरण आर्किटेक्चर दो प्रोडक्शन क्लस्टर के साथ शुरू हुआ (नीचे स्क्रीनशॉट में दिखाया गया है):

• क्लस्टर आईडी 1:3 गैलेरा नोड्स (पीएक्ससी) + 1 हैप्रोक्सी + 1 प्रॉक्सीएसक्यूएल (5 नोड्स)
• क्लस्टर आईडी 2:1 MySQL मास्टर + 2 MySQL दास + 1 ProxySQL (4 नोड्स)

परिचय

ClusterControl CLI (s9s) ClusterControl प्लेटफॉर्म का उपयोग करके डेटाबेस क्लस्टर्स को इंटरैक्ट करने, नियंत्रित करने और प्रबंधित करने के लिए एक कमांड लाइन इंटरफ़ेस टूल है। संस्करण 1.4.1 से शुरू होकर, इंस्टॉलर स्क्रिप्ट इस पैकेज को ClusterControl नोड पर स्वचालित रूप से स्थापित कर देगी।

"s9s बैकअप" कमांड के तहत मूल रूप से 4 नए विकल्प पेश किए गए हैं, जिनका उपयोग हमारे उद्देश्य को प्राप्त करने के लिए किया जा सकता है:

यह ब्लॉग पोस्ट उन विकल्पों का उपयोग करने के उदाहरण के मामलों को कवर करेगा। फिलहाल, वे रिलीज उम्मीदवार चरण में हैं और केवल ClusterControl CLI टूल के माध्यम से उपलब्ध हैं।

ClusterControl का बैकअप लेना

ऐसा करने के लिए, ClusterControl सर्वर कम से कम v1.7.1 और बाद के संस्करण पर होना चाहिए। ClusterControl कंट्रोलर का बैकअप लेने के लिए, बस रूट यूजर (या sudo के साथ) के रूप में ClusterControl नोड पर निम्न कमांड चलाएँ:

$ s9s backup \
--save-controller \
--backup-directory=$HOME/ccbackup \
--output-file=controller.tar.gz \
--log

--आउटपुट-फ़ाइल एक फ़ाइल नाम या भौतिक पथ होना चाहिए (यदि आप --बैकअप-निर्देशिका ध्वज को छोड़ना चाहते हैं), और फ़ाइल पहले से मौजूद नहीं होनी चाहिए। यदि यह पहले से मौजूद है तो ClusterControl आउटपुट फ़ाइल को प्रतिस्थापित नहीं करेगा। --log निर्दिष्ट करके, यह कार्य निष्पादित होने तक प्रतीक्षा करेगा और कार्य लॉग टर्मिनल में दिखाए जाएंगे। गतिविधि -> कार्य -> ​​नियंत्रक सहेजें के अंतर्गत ClusterControl UI के माध्यम से समान लॉग तक पहुँचा जा सकता है :

'नियंत्रक सहेजें' कार्य मूल रूप से निम्नलिखित प्रक्रियाएं करता है:

1. नियंत्रक कॉन्फ़िगरेशन पुनर्प्राप्त करें और इसे JSON पर निर्यात करें
2. सीएमओएन डेटाबेस को MySQL डंप फ़ाइल के रूप में निर्यात करें
3. हर डेटाबेस क्लस्टर के लिए:
   1. क्लस्टर कॉन्फ़िगरेशन पुनर्प्राप्त करें और इसे JSON पर निर्यात करें

आउटपुट में, आप देख सकते हैं कि पाया गया कार्य N + 1 . है क्लस्टर, उदाहरण के लिए "सेव करने के लिए 3 क्लस्टर मिले" भले ही हमारे पास केवल दो डेटाबेस क्लस्टर हों। इसमें क्लस्टर आईडी 0 शामिल है, जो वैश्विक आरंभिक क्लस्टर के रूप में क्लस्टरकंट्रोल में विशेष अर्थ रखता है। हालांकि, यह CmonCluster घटक से संबंधित नहीं है, जो ClusterControl प्रबंधन के तहत डेटाबेस क्लस्टर है।

ClusterControl को नए ClusterControl सर्वर पर पुनर्स्थापित करना

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

सबसे पहले, पुराने सर्वर से बैकअप को नए सर्वर में स्थानांतरित करें:

$ scp $HOME/ccbackup/controller.tar.gz 192.168.0.190:~

पुनर्स्थापना करने से पहले, हमें नए ClusterControl सर्वर से सभी नोड्स में पासवर्ड रहित SSH सेट करना होगा:

$ ssh-copy-id 192.168.0.11 #proxysql cluster 1
$ ssh-copy-id 192.168.0.12 #proxysql cluster 1
$ ssh-copy-id 192.168.0.21 #pxc cluster 1
$ ssh-copy-id 192.168.0.22 #pxc cluster 1
$ ssh-copy-id 192.168.0.23 #pxc cluster 1
$ ssh-copy-id 192.168.0.30 #proxysql cluster 2
$ ssh-copy-id 192.168.0.31 #mysql cluster 2
$ ssh-copy-id 192.168.0.32 #mysql cluster 2
$ ssh-copy-id 192.168.0.33 #mysql cluster 2

फिर, नए सर्वर पर, पुनर्स्थापना करें:

$ s9s backup \
--restore-controller \
--input-file=$HOME/controller.tar.gz \
--debug \
--log

फिर हमें वैश्विक सेटिंग्स -> क्लस्टर पंजीकरण -> क्लस्टर को सिंक्रनाइज़ करें पर जाकर UI में क्लस्टर को सिंक करना होगा। . फिर यदि आप ClusterControl के मुख्य डैशबोर्ड पर वापस जाते हैं, तो आपको निम्नलिखित दिखाई देंगे:

घबड़ाएं नहीं। नया ClusterControl UI गलत RPC API टोकन के कारण निगरानी और प्रबंधन डेटा पुनर्प्राप्त करने में सक्षम नहीं है। हमें बस उसी के अनुसार इसे अपडेट करने की जरूरत है। सबसे पहले, संबंधित क्लस्टर के लिए rpc_key मान प्राप्त करें:

$ cat /etc/cmon.d/cmon_*.cnf | egrep 'cluster_id|rpc_key'
cluster_id=1
rpc_key=8fgkzdW8gAm2pL4L
cluster_id=2
rpc_key=tAnvKME53N1n8vCC

UI में, "यहां RPC API टोकन बदलें" लाइन के अंत में "यहां" लिंक पर क्लिक करें। यह निम्नलिखित डायलॉग को पॉप अप करेगा:

टेक्स्ट फ़ील्ड में संबंधित rpc_key मान पेस्ट करें और सहेजें पर क्लिक करें। अगले क्लस्टर के लिए दोहराएं। एक क्षण के लिए प्रतीक्षा करें और क्लस्टर सूची स्वचालित रूप से ताज़ा हो जानी चाहिए।

अंतिम चरण नए ClusterControl IP पता परिवर्तन, 192.168.0.190 के लिए MySQL cmon उपयोगकर्ता विशेषाधिकारों को ठीक करना है। पीएक्ससी नोड में से किसी एक में लॉग इन करें और निम्नलिखित चलाएँ:

$ mysql -uroot -p -e 'GRANT ALL PRIVILEGES ON *.* TO [email protected]"192.168.0.190" IDENTIFIED BY "<password>" WITH GRANT OPTION';

** <पासवर्ड> को समान cmon MySQL पासवर्ड से बदलें जैसा कि /etc/cmon.cnf के अंदर mysql_password मान में है। दूसरे क्लस्टर, MySQL प्रतिकृति पर एक ही चरण दोहराएं लेकिन इसे केवल एक बार मास्टर नोड पर निष्पादित करें।

एक बार विशेषाधिकार सेट हो जाने के बाद, आप देखेंगे कि क्लस्टर सूची पुराने के समान हरे रंग में है:

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

हमारा प्रवास अब पूरा हो गया है। पुराने सर्वर से सभी कॉन्फ़िगरेशन और सेटिंग्स को संरक्षित किया जाता है और नए सर्वर पर स्थानांतरित किया जाता है।

क्लस्टर के प्रबंधन को दूसरे क्लस्टर कंट्रोल सर्वर में माइग्रेट करना

क्लस्टर जानकारी का बैकअप लेना

यह क्लस्टर मेटाडेटा और जानकारी का बैकअप लेने के बारे में है ताकि हम इसे किसी अन्य ClusterControl सर्वर पर स्थानांतरित कर सकें, जिसे आंशिक बैकअप के रूप में भी जाना जाता है। अन्यथा, हमें उन्हें नए ClusterControl में पुनः आयात करने के लिए "मौजूदा सर्वर/क्लस्टर आयात करें" करना होगा, जिसका अर्थ है कि आप पुराने सर्वर से निगरानी डेटा खो देंगे। यदि आपके पास लोड बैलेंसर या एसिंक्रोनस स्लेव इंस्टेंस हैं, तो क्लस्टर के आयात होने के बाद, एक बार में एक नोड को आयात करना होगा। इसलिए यदि आपके पास प्रोडक्शन सेटअप का पूरा सेट है तो यह थोड़ा परेशानी भरा है।

क्लस्टर "प्रबंधक" प्रवासन अभ्यास निम्नलिखित आरेख में दिखाया गया है:

मूल रूप से, हम अपने MySQL प्रतिकृति (क्लस्टर आईडी:2) को किसी अन्य ClusterControl उदाहरण द्वारा प्रबंधित करने के लिए माइग्रेट करना चाहते हैं। हम इसके लिए --save-cluster-info और --restore-cluster-info विकल्पों का उपयोग करने जा रहे हैं। --save-cluster-info विकल्प संबंधित क्लस्टर जानकारी को कहीं और सहेजने के लिए निर्यात करेगा। आइए हमारे MySQL प्रतिकृति क्लस्टर (क्लस्टर आईडी:2) को निर्यात करें। वर्तमान ClusterControl सर्वर पर, करें:

$ s9s backup \
--save-cluster-info \
--cluster-id=2 \
--backup-directory=$HOME/ccbackup \
--output-file=cc-replication-2.tar.gz \
--log

आपको टर्मिनल में मुद्रित नई लाइनों का एक गुच्छा दिखाई देगा, जो दर्शाता है कि बैकअप कार्य चल रहा है (आउटपुट ClusterControl -> गतिविधि -> जॉब के माध्यम से भी पहुंच योग्य है। ):

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

क्लस्टर जानकारी बहाल करना

यहां बताए गए चरण ClusterControl पूर्ण बैकअप के लिए पुनर्स्थापना चरणों के समान हैं। बैकअप को वर्तमान सर्वर से दूसरे ClusterControl सर्वर में स्थानांतरित करें:

$ scp $HOME/ccbackup/cc-replication-2.tar.gz 192.168.0.190:~

पुनर्स्थापना करने से पहले, हमें नए ClusterControl सर्वर से सभी नोड्स में पासवर्ड रहित SSH सेट करना होगा:

$ ssh-copy-id 192.168.0.30 #proxysql cluster 2
$ ssh-copy-id 192.168.0.31 #mysql cluster 2
$ ssh-copy-id 192.168.0.32 #mysql cluster 2
$ ssh-copy-id 192.168.0.33 #mysql cluster 2
$ ssh-copy-id 192.168.0.19 #prometheus cluster 2

फिर, नए सर्वर पर, हमारे MySQL प्रतिकृति के लिए क्लस्टर सूचना पुनर्स्थापन निष्पादित करें:

$ s9s backup \
--restore-cluster-info \
--input-file=$HOME/cc-replication-2.tar.gz \
--log

आप गतिविधि -> कार्य -> ​​क्लस्टर पुनर्स्थापित करें . के अंतर्गत प्रगति सत्यापित कर सकते हैं :

यदि आप नौकरी के संदेशों को करीब से देखते हैं, तो आप देख सकते हैं कि ClusterControl इस नए इंस्टेंस पर क्लस्टर आईडी को स्वचालित रूप से 1 को फिर से असाइन करता है (यह पुराने इंस्टेंस पर क्लस्टर आईडी 2 था)।

फिर वैश्विक सेटिंग -> क्लस्टर पंजीकरण -> क्लस्टर सिंक्रनाइज़ करें पर जाकर क्लस्टर को UI में सिंक करें . यदि आप ClusterControl के मुख्य डैशबोर्ड पर वापस जाते हैं, तो आपको निम्नलिखित दिखाई देंगे:

त्रुटि का अर्थ है कि नया ClusterControl UI गलत RPC API टोकन के कारण निगरानी और प्रबंधन डेटा प्राप्त करने में सक्षम नहीं है। हमें बस उसी के अनुसार इसे अपडेट करने की जरूरत है। सबसे पहले, हमारे क्लस्टर आईडी 1 के लिए rpc_key मान प्राप्त करें:

$ cat /etc/cmon.d/cmon_1.cnf | egrep 'cluster_id|rpc_key'
cluster_id=1
rpc_key=tAnvKME53N1n8vCC

UI में, "यहां RPC API टोकन बदलें" लाइन के अंत में "यहां" लिंक पर क्लिक करें। यह निम्नलिखित डायलॉग को पॉप अप करेगा:

टेक्स्ट फ़ील्ड में संबंधित rpc_key मान पेस्ट करें और सहेजें पर क्लिक करें। एक क्षण के लिए प्रतीक्षा करें और क्लस्टर सूची स्वचालित रूप से ताज़ा हो जानी चाहिए।

अंतिम चरण नए ClusterControl IP पता परिवर्तन, 192.168.0.190 के लिए MySQL cmon उपयोगकर्ता विशेषाधिकारों को ठीक करना है। मास्टर नोड में लॉगिन करें (192.168.0.31) और निम्न कथन चलाएँ:

$ mysql -uroot -p -e 'GRANT ALL PRIVILEGES ON *.* TO [email protected]"192.168.0.190" IDENTIFIED BY "<password>" WITH GRANT OPTION';

** <पासवर्ड> को समान cmon MySQL पासवर्ड से बदलें जैसा कि /etc/cmon.cnf के अंदर mysql_password मान में है।

आप पुराने उपयोगकर्ता विशेषाधिकारों को भी रद्द कर सकते हैं (निरस्त उपयोगकर्ता को हटा नहीं देगा) या पुराने उपयोगकर्ता को छोड़ दें:

$ mysql -uroot -p -e 'DROP USER [email protected]"192.168.0.19"'

एक बार विशेषाधिकार सेट हो जाने के बाद, आपको यह देखना चाहिए कि सब कुछ हरा है:

इस समय, हमारी वास्तुकला कुछ इस तरह दिख रही है:

हमारा प्रवासन अभ्यास अब पूरा हो गया है।

अंतिम विचार

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