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

बैकअप से एक MySQL या MariaDB गैलेरा क्लस्टर की पूर्ण पुनर्स्थापना

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

बैकअप के लिए सर्वोत्तम अभ्यास

एक अच्छी अनुसूचित बैकअप व्यवस्था के लिए विचार करने के लिए कुछ सिफारिशें:

  • आप कम से कम पिछले दो पूर्ण बैकअप से एक भयावह विफलता से पूरी तरह से उबरने में सक्षम होना चाहिए। बस हाल ही में पूर्ण बैकअप क्षतिग्रस्त, खो जाने या दूषित होने की स्थिति में,
  • आपके बैकअप में एक चुने हुए चक्र में कम से कम एक पूर्ण बैकअप होना चाहिए, आमतौर पर साप्ताहिक,
  • बैकअप को वर्तमान डेटा स्थान से दूर स्टोर करें, अधिमानतः साइट से बाहर,
  • अतिरिक्त सुरक्षा के लिए mysqldump और Xtrabackup के मिश्रण का उपयोग करें, और किसी एक विधि पर निर्भर न रहें,
  • अपने बैकअप को नियमित रूप से पुनर्स्थापित करने का परीक्षण करें, उदा. हर दो महीने में।

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

mysqldump या Xtrabackup

mysqldump संभवतः MySQL का बैकअप लेने का सबसे लोकप्रिय तरीका है। यह डेटा का तार्किक बैकअप करता है, SQL स्टेटमेंट का उपयोग करके प्रत्येक तालिका से पढ़ता है और फिर डेटा को टेक्स्ट फ़ाइलों में निर्यात करता है। एक mysqldump . की बहाली डंप फ़ाइल बनाने जितना आसान है। मुख्य दोष यह है कि यह बड़े डेटाबेस के लिए बहुत धीमा है, यह 'हॉट' नहीं है और यह InnoDB बफर पूल को मिटा देता है।

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

ClusterControl mysqldump और Xtrabackup (पूर्ण और वृद्धिशील) दोनों के शेड्यूलिंग का समर्थन करता है, साथ ही UI से बैकअप बहाली का भी समर्थन करता है।

बैकअप से पूर्ण पुनर्स्थापना

इस पोस्ट में, हम आपको दिखाएंगे कि मारियाडीबी गैलेरा क्लस्टर पर चल रहे एक खाली क्लस्टर पर एक्स्ट्राबैकअप (पूर्ण + वृद्धिशील) को कैसे पुनर्स्थापित किया जाए। इन चरणों को कोडरशिप से MySQL के लिए Percona XtraDB क्लस्टर या Galera Cluster पर भी काम करना चाहिए।

हमारे मूल क्लस्टर में, हमारे पास प्रतिदिन एक पूर्ण एक्स्ट्राबैकअप शेड्यूल किया गया था, जिसमें हर घंटे वृद्धिशील बैकअप बनाए गए थे। बैकअप को क्लस्टरकंट्रोल पर संग्रहीत किया जाता है जैसा कि निम्न स्क्रीनशॉट में दिखाया गया है:

अब, मान लेते हैं कि हमने अपना मूल क्लस्टर खो दिया है और नए क्लस्टर पर पूर्ण पुनर्स्थापना करना है। चरणों में शामिल हैं:

  1. नया ClusterControl सर्वर सेट करें।
  2. एक नया मारियाडीबी क्लस्टर सेट करें।
  3. बैकअप रिकॉर्ड और फ़ाइलों को नए ClusterControl सर्वर पर निर्यात करें।
  4. पुनर्स्थापन प्रक्रिया प्रारंभ करें।
  5. शेष नोड्स प्रारंभ करें।

निम्नलिखित आरेख इस अभ्यास के लिए हमारी वास्तुकला को दर्शाता है:

चरण 1 - नया मारियाडीबी क्लस्टर सेट करें

ClusterControl स्थापित करें और एक नया MariaDB क्लस्टर परिनियोजित करें। ClusterControl -> Deploy -> Deploy Database Cluster -> MySQL Galera पर जाएँ और डिप्लॉयमेंट डायलॉग में आवश्यक जानकारी निर्दिष्ट करें:

परिनियोजन बटन पर क्लिक करें और परिनियोजन प्रारंभ करें। चूंकि हमारे पास पुराने सर्वर पर केवल एक क्लस्टर है, इसलिए इस नए उदाहरण में क्लस्टर आईडी समान होना चाहिए (क्लस्टर आईडी:1)।

चरण 2 - बैकअप फ़ाइलों को निर्यात और आयात करें एक बार क्लस्टर परिनियोजित हो जाने के बाद, हमें पुराने ClusterControl सर्वर से बैकअप को नए सर्वर में आयात करना होगा। सबसे पहले, फ़ाइलों को डंप करने के लिए cmon.backup_records की सामग्री को निर्यात करें। चूंकि पुराना क्लस्टर आईडी और नया एक समान है, इसलिए हमें डंप फ़ाइल को नए आईपी पते के साथ संशोधित करने और इसे नए क्लस्टर कंट्रोल नोड में आयात करने की आवश्यकता है। यदि क्लस्टर आईडी अलग है, तो आपको नए नोड पर सीएमओएन डीबी में आयात करने से पहले डंप फाइलों के अंदर तदनुसार "सीआईडी" मान बदलना होगा। साथ ही, बैकअप संग्रहण स्थान को पुराने सर्वर की तरह रखना आसान है ताकि नया ClusterControl नए सर्वर में बैकअप फ़ाइलों का पता लगा सके।

पुराने ClusterControl सर्वर पर, backup_records तालिका को डंप फ़ाइलों में निर्यात करें:

$ mysqldump -uroot -p --single-transaction --no-create-info cmon backup_records > backup_records.sql

फिर, पुराने सर्वर से बैकअप फ़ाइलों की दूरस्थ प्रतिलिपि नए ClusterControl सर्वर में निष्पादित करें:

$ scp -r /root/backups 192.168.55.150:/root/
$ scp ~/backup_records.sql 192.168.55.150:~

अगला नया ClusterControl सर्वर IP पता दर्शाने के लिए डंप फ़ाइलों को संशोधित करना है। आईपी ​​​​एड्रेस में डॉट से बचना न भूलें:

$ sed -i "s/192\.168\.55\.170/192\.168\.55\.150/g" backup_records.sql

नए ClusterControl सर्वर पर, डंप फ़ाइलें आयात करें:

$ mysql -uroot -p cmon < backup_records.sql

पुष्टि करें कि नए ClusterControl सर्वर में बैकअप सूची सही है:

जैसा कि आप देख सकते हैं, पिछले आईपी पते (192.168.55.170) की सभी घटनाओं को नए आईपी पते (192.168.55.150) से बदल दिया गया है। अब हम नए सर्वर में बहाली करने के लिए तैयार हैं।

चरण 3 - बहाली करें

ClusterControl UI के माध्यम से पुनर्स्थापना करना एक सरल बिंदु-और-क्लिक चरण है। पुनर्स्थापित करने के लिए कौन सा बैकअप चुनें और "पुनर्स्थापना" बटन पर क्लिक करें। हम उपलब्ध नवीनतम वृद्धिशील बैकअप को पुनर्स्थापित करने जा रहे हैं (बैकअप:9)। बैकअप नाम के ठीक नीचे "पुनर्स्थापना" बटन पर क्लिक करें और आपको निम्नलिखित पूर्व-बहाली संवाद के साथ प्रस्तुत किया जाएगा:

ऐसा लगता है कि बैकअप आकार बहुत छोटा है (165.6 kB)। यह वास्तव में कोई मायने नहीं रखता क्योंकि क्लस्टरकंट्रोल बैकअप सेट 6 के तहत समूहीकृत सभी वृद्धिशील बैकअप तैयार करेगा, जिसमें पूर्ण एक्स्ट्राबैकअप होता है। आपके पास कई पोस्ट-बहाली विकल्प भी हैं:

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

Percona Xtrabackup बहाली के कारण क्लस्टर बंद हो जाएगा। ClusterControl होगा:

  1. क्लस्टर में सभी नोड्स बंद करें।
  2. चयनित नोड पर बैकअप पुनर्स्थापित करें।
  3. चयनित नोड को बूटस्ट्रैप करें।

बहाली की प्रगति देखने के लिए, गतिविधि -> नौकरियां -> बैकअप पुनर्स्थापित करें पर जाएं और "पूर्ण नौकरी विवरण" बटन पर क्लिक करें। आपको कुछ इस तरह दिखना चाहिए:

एक महत्वपूर्ण चीज जो आपको करने की आवश्यकता है वह है बहाली प्रक्रिया के दौरान लक्ष्य नोड (192.168.55.151) पर MySQL त्रुटि लॉग के आउटपुट की निगरानी करना। पुनर्स्थापना पूर्ण होने के बाद और बूटस्ट्रैपिंग प्रक्रिया के दौरान, आपको निम्न पंक्तियाँ दिखाई देने लगेंगी:

Version: '10.1.22-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:52 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:53 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:54 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:55 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)

घबड़ाएं नहीं। यह एक अपेक्षित व्यवहार है क्योंकि यह बैकअप सेट नए ClusterControl cmon पासवर्ड के cmon लॉगिन क्रेडेंशियल को संग्रहीत नहीं करता है। इसने इसके बजाय पुराने cmon उपयोगकर्ता को पुनर्स्थापित/प्रतिस्थापित किया है। आपको यह करने की आवश्यकता है कि इस DB नोड पर निम्नलिखित कथन चलाकर cmon उपयोगकर्ता को सर्वर पर वापस भेज दिया जाए:

GRANT ALL PRIVILEGES ON *.* to [email protected]'192.168.55.150' IDENTIFIED BY 'mynewCMONpassw0rd' WITH GRANT OPTION;
FLUSH PRIVILEGES;

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. SQL ALTER DATABASE Syntax - DBMS द्वारा सूचीबद्ध

  2. MySQL में 2 स्ट्रिंग्स की तुलना करने के लिए STRCMP () का उपयोग कैसे करें

  3. MySQL में SUBDATE() बनाम DATE_SUB():क्या अंतर है?

  4. Oracle से MySQL में माइग्रेट करें

  5. SQLAlchemy ORM के साथ बल्क इंसर्ट