MySQL 8.0 के लिए Percona सर्वर के साथ एक एन्क्रिप्टेड डेटाबेस का बैकअप कैसे लें

उत्पादन में रुकावटें किसी समय में होने की लगभग गारंटी है। हम इसे जानते हैं इसलिए हम बैकअप की योजना बनाते हैं, पुनर्प्राप्ति स्टैंडबाय डेटाबेस बनाते हैं, एकल उदाहरणों को क्लस्टर में परिवर्तित करते हैं।

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

बैकअप प्रबंधन केवल बैकअप कार्य को शेड्यूल करने जितना हल्का नहीं है। विचार करने के लिए कई कारक हैं, जैसे कि अवधारण, भंडारण, सत्यापन, और क्या आप जो बैकअप ले रहे हैं वह भौतिक या तार्किक है और सुरक्षा की अनदेखी करना आसान है।

कई संगठन बैकअप के लिए अपना दृष्टिकोण बदलते हैं, सर्वर छवि बैकअप (स्नैपशॉट्स), तार्किक और भौतिक बैकअप के संयोजन को कई स्थानों पर संग्रहीत करने का प्रयास करते हैं। यह किसी भी स्थानीय या क्षेत्रीय आपदा से बचने के लिए है जो हमारे डेटाबेस और उसी डेटा केंद्र में संग्रहीत बैकअप को मिटा देगा।

हम इसे सुरक्षित बनाना चाहते हैं। डेटा और बैकअप एन्क्रिप्टेड होना चाहिए। लेकिन जब दोनों विकल्प मौजूद होते हैं तो इसके कई निहितार्थ होते हैं। इस लेख में, जब हम एन्क्रिप्टेड डेटाबेस से निपटते हैं तो हम बैकअप प्रक्रियाओं पर एक नज़र डालेंगे।

MySQL 8.0 के लिए Percona सर्वर के लिए एन्क्रिप्शन-एट-रेस्ट

MySQL 5.7.11 से शुरू होकर, MySQL के सामुदायिक संस्करण ने InnoDB टेबलस्पेस एन्क्रिप्शन के लिए समर्थन शुरू किया। इसे ट्रांसपेरेंट टेबलस्पेस एन्क्रिप्शन कहा जाता है या एन्क्रिप्शन-एट-रेस्ट के रूप में संदर्भित किया जाता है।

एंटरप्राइज़ संस्करण की तुलना में मुख्य अंतर कुंजी को संग्रहीत करने के तरीके का है - कुंजी एक सुरक्षित तिजोरी में स्थित नहीं हैं, जो नियामक अनुपालन के लिए आवश्यक है। वही Percona सर्वर पर लागू होता है, संस्करण 5.7.11 से, InnoDB टेबलस्पेस को एन्क्रिप्ट करना संभव है। Percona Server 8.0 में, बाइनरी लॉग को एन्क्रिप्ट करने के लिए समर्थन बहुत बढ़ा दिया गया है। वर्शन 8.0 जोड़ा गया 

(प्रति Percona 8.0 रिलीज़ दस्तावेज़):

• अस्थायी फ़ाइल एन्क्रिप्शन
• InnoDB टेबलस्पेस एन्क्रिप्शन को पूर्ववत करें
• InnoDB सिस्टम टेबलस्पेस एन्क्रिप्शन (InnoDB सिस्टम टेबलस्पेस एन्क्रिप्शन)
• default_table_encryption  =OFF/ON (सामान्य टेबलस्पेस एन्क्रिप्शन)
• table_encryption_privilege_check =OFF/ON (एन्क्रिप्शन सेटिंग्स को सत्यापित करना)
• InnoDB लॉग एन्क्रिप्शन फिर से करें (केवल मास्टर कुंजी एन्क्रिप्शन के लिए) (लॉग एन्क्रिप्शन फिर से करें)
• InnoDB मर्ज फ़ाइल एन्क्रिप्शन (एन्क्रिप्शन सेटिंग सत्यापित करना)
• Percona समानांतर डबलराइट बफर एन्क्रिप्शन (InnoDB टेबलस्पेस एन्क्रिप्शन)

MySQL एंटरप्राइज़ संस्करण से Percona में माइग्रेशन में रुचि रखने वालों के लिए -  Oracle के MySQL एंटरप्राइज़ संस्करण में उपलब्ध सुविधाओं से मेल खाते हुए keyring_vault प्लगइन के माध्यम से Hashicorp Vault सर्वर के साथ एकीकृत करना भी संभव है।

बाकी एन्क्रिप्शन पर डेटा के लिए एक कीरिंग प्लग-इन की आवश्यकता होती है। यहां दो विकल्प हैं:

• keyring_file - एक एन्क्रिप्शन कुंजी के साथ एक फ्लैट फ़ाइल
• कीरिंग वॉल्ट प्लगइन  - एक सेवा

टेबलस्पेस एन्क्रिप्शन कैसे सक्षम करें

एन्क्रिप्शन को सक्षम करने के लिए -- अर्ली-प्लगइन-लोड विकल्प के साथ अपना डेटाबेस शुरू करें:

या तो हाथ से:

$ mysqld --early-plugin-load="keyring_file=keyring_file.so"

या कॉन्फ़िगरेशन फ़ाइल को संशोधित करके:

[mysqld]

early-plugin-load=keyring_file.so

पेरकोना सर्वर 8.0 शुरू करना दो प्रकार के टेबलस्पेस को एन्क्रिप्ट किया जा सकता है। सामान्य टेबलस्पेस और सिस्टम टेबलस्पेस। Sys टेबलस्पेस को पैरामीटर innodb_sys_tablespace_encrypt के माध्यम से नियंत्रित किया जाता है। डिफ़ॉल्ट रूप से, sys टेबलस्पेस एन्क्रिप्ट नहीं किया जाता है, और यदि आपके पास पहले से एक है, तो इसे एन्क्रिप्टेड स्थिति में बदलना संभव नहीं है, एक नया इंस्टेंस बनाया जाना चाहिए (--bootstrap विकल्प के साथ एक इंस्टेंस शुरू करें)।

सामान्य टेबलस्पेस या तो टेबलस्पेस में सभी टेबलों में एन्क्रिप्शन का समर्थन करता है या कोई नहीं। एन्क्रिप्शन को मिश्रित मोड में चलाना संभव नहीं है। एन्क्रिप्शन के साथ एटी टेबल स्पेस बनाने के लिए ENCRYPTION='Y/N' ध्वज का उपयोग करें।

उदाहरण:

mysql> CREATE TABLESPACE severalnines ADD DATAFILE 'severalnines.ibd' ENCRYPTION='Y';

एक एन्क्रिप्टेड डेटाबेस का बैकअप लेना

जब आप एन्क्रिप्टेड टेबलस्पेस जोड़ते हैं तो xtrabackup कमांड में कीरिंग फाइल को शामिल करना जरूरी होता है। ऐसा करने के लिए आपको --keyring-file-data विकल्प के मान के रूप में एक कीरिंग फ़ाइल का पथ निर्दिष्ट करना होगा।

$ xtrabackup --backup --target-dir=/u01/mysql/data/backup/ --user=root --keyring-file-data=/u01/secure_location/keyring_file

कीरिंग फ़ाइल को सुरक्षित स्थान पर रखना सुनिश्चित करें। इसके अलावा, सुनिश्चित करें कि आपके पास हमेशा फ़ाइल का बैकअप है। Xtrabackup बैकअप निर्देशिका में कीरिंग फ़ाइल को कॉपी नहीं करेगा। बैकअप तैयार करने के लिए, आपको कीरिंग फ़ाइल की एक प्रति स्वयं बनानी होगी।

बैकअप तैयार करना

एक बार हमारे पास हमारी बैकअप फ़ाइल हो जाने के बाद हमें इसे पुनर्प्राप्ति के लिए तैयार करना चाहिए। यहां आपको कीरिंग-फाइल-डेटा भी निर्दिष्ट करने की आवश्यकता है।

$ xtrabackup --prepare --target-dir=/u01/mysql/data/backup/ --keyring-file-data=/u01/secure_location/keyring_file

बैकअप अब तैयार है और --कॉपी-बैक विकल्प के साथ पुनर्स्थापित किया जा सकता है। यदि कीरिंग को घुमाया गया है, तो आपको कीरिंग को पुनर्स्थापित करना होगा (जिसका उपयोग बैकअप लेने और तैयार करने के लिए किया गया था)।

बैकअप xtrabackup तैयार करने के लिए, हमें कीरिंग तक पहुंच की आवश्यकता होगी। Xtrabackup सीधे MySQL सर्वर से बात नहीं करता है और तैयारी के दौरान डिफ़ॉल्ट my.cnf कॉन्फ़िगरेशन फ़ाइल नहीं पढ़ता है, कमांड लाइन के माध्यम से कीरिंग सेटिंग्स निर्दिष्ट करें:

$ xtrabackup --prepare --target-dir=/data/backup --keyring-vault-config=/etc/vault.cnf

बैकअप अब तैयार है और --कॉपी-बैक विकल्प के साथ पुनर्स्थापित किया जा सकता है:

$ xtrabackup --copy-back --target-dir=/u01/backup/ --datadir=/u01/mysql/data/

वृद्धिशील बैकअप करना

InnoDB टेबलस्पेस एन्क्रिप्शन के साथ वृद्धिशील बैकअप लेने की प्रक्रिया एक अनएन्क्रिप्टेड टेबलस्पेस के साथ समान वृद्धिशील बैकअप लेने के समान है।

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

सबसे पहले, आपको निम्न आदेश के साथ एक पूर्ण बैकअप बनाने की आवश्यकता है:

$ xtrabackup --backup --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyring

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

$ xtrabackup --backup --target-dir=/data/backups/inc1 \

--incremental-basedir=/data/backups/base \

--keyring-file-data=/var/lib/mysql-keyring/keyring

/data/backups/inc1/ निर्देशिका में अब डेल्टा फ़ाइलें होनी चाहिए, जैसे कि ibdata1.delta और test/table1.ibd.delta।

अर्थ स्वयं स्पष्ट होना चाहिए। अब इस निर्देशिका का उपयोग एक और वृद्धिशील बैकअप के लिए आधार के रूप में करना संभव है:

$ xtrabackup --backup --target-dir=/data/backups/inc2 \

--incremental-basedir=/data/backups/inc1 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

इंक्रीमेंटल बैकअप तैयार करना

अब तक डेटाबेस का बैकअप लेने की प्रक्रिया एक नियमित बैकअप के समान है, केवल उस ध्वज को छोड़कर जहां हमने कीरिंग फ़ाइल का स्थान निर्दिष्ट किया है।

दुर्भाग्य से, वृद्धिशील बैकअप के लिए --prepare चरण सामान्य बैकअप के समान नहीं है।

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

यदि आप रोलबैक चरण को रोकने के लिए --apply-log-only विकल्प का उपयोग नहीं करते हैं, तो आपके वृद्धिशील बैकअप बेकार हो जाएंगे। लेन-देन वापस ले लिए जाने के बाद, आगे वृद्धिशील बैकअप लागू नहीं किए जा सकते।

आपके द्वारा बनाए गए पूर्ण बैकअप के साथ, आप इसे तैयार कर सकते हैं और फिर इसमें वृद्धिशील अंतर लागू कर सकते हैं। याद रखें कि आपके पास निम्नलिखित बैकअप हैं:

/data/backups/base

/data/backups/inc1

/data/backups/inc2

आधार बैकअप तैयार करने के लिए, आपको --prepare हमेशा की तरह चलाने की जरूरत है, लेकिन रोलबैक चरण को रोकें:

$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyring

पूर्ण बैकअप के लिए पहला वृद्धिशील बैकअप लागू करने के लिए, आपको निम्न आदेश का उपयोग करना चाहिए:

$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base \

--incremental-dir=/data/backups/inc1 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

यदि कीरिंग को आधार और वृद्धिशील बैकअप के बीच घुमाया गया है, तो आपको उस कीरिंग का उपयोग करने की आवश्यकता होगी जो पहली वृद्धिशील बैकअप लेने के समय उपयोग में थी।

दूसरा वृद्धिशील बैकअप तैयार करना एक समान प्रक्रिया है

$ xtrabackup --prepare --target-dir=/data/backups/base \

--incremental-dir=/data/backups/inc2 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

नोट; --apply-log-only का उपयोग पिछले एक को छोड़कर सभी वृद्धिशील विलय करते समय किया जाना चाहिए। इसलिए पिछली पंक्ति में --apply-log-only विकल्प नहीं है। भले ही अंतिम चरण में --apply-log-only का उपयोग किया गया हो, बैकअप अभी भी सुसंगत रहेगा लेकिन उस स्थिति में सर्वर रोलबैक चरण निष्पादित करेगा।
अंतिम चरण इसे --copy-back के साथ पुनर्स्थापित करना है विकल्प। यदि कीरिंग को घुमाया गया है तो आपको कीरिंग को पुनर्स्थापित करना होगा जिसका उपयोग बैकअप लेने और तैयार करने के लिए किया गया था।

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

--transition-key= विकल्प का उपयोग xtrabackup के लिए कीरिंग वॉल्ट सर्वर तक पहुंच के बिना बैकअप को संसाधित करना संभव बनाने के लिए किया जाना चाहिए। इस मामले में, xtrabackup निर्दिष्ट पासफ़्रेज़ से AES एन्क्रिप्शन कुंजी प्राप्त करता है और इसका उपयोग उन टेबलस्पेस की टेबलस्पेस कुंजियों को एन्क्रिप्ट करने के लिए करेगा जिनका बैकअप लिया जा रहा है।

पासफ़्रेज़ के साथ बैकअप बनाना

निम्न उदाहरण दिखाता है कि इस मामले में बैकअप कैसे बनाया जा सकता है:

$ xtrabackup --backup --user=root -p --target-dir=/data/backup \

--transition-key=MySecetKey

जेनरेट की गई कुंजी के साथ बैकअप बहाल करना

बैकअप को पुनर्स्थापित करते समय आपको एक नई मास्टर कुंजी जेनरेट करने की आवश्यकता होगी। यहाँ keyring_file के लिए उदाहरण दिया गया है:

$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \

--transition-key=MySecetKey --generate-new-master-key \

--keyring-file-data=/var/lib/mysql-keyring/keyring

कीरिंग_वॉल्ट के मामले में, यह इस तरह दिखेगा:

$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \

--transition-key=MySecetKey --generate-new-master-key \

--keyring-vault-config=/etc/vault.cnf