Производствените прекъсвания са почти гарантирани в даден момент. Ние го знаем, така че планираме архивиране, създаваме резервни бази данни за възстановяване, преобразуваме единични екземпляри в клъстери.
Признавайки необходимостта от подходящ сценарий за възстановяване, ние трябва да анализираме възможния график за бедствие и сценарии за отказ и да приложим стъпки за извеждане на вашата база данни. Изпълнението на планирано прекъсване може да помогне за подготовката, диагностицирането и възстановяването от следващото. За да смекчат въздействието от престоя, организациите се нуждаят от подходящ план за възстановяване, който да включва всички фактори, необходими за въвеждането на услугата в живот.
Управлението на архивиране не е толкова меко, колкото просто насрочване на задача за архивиране. Има много фактори, които трябва да вземете предвид, като задържане, съхранение, проверка и дали резервните копия, които правите, са физически или логически и какво е лесно да се пренебрегне сигурността.
Много организации променят подхода си към архивирането, опитвайки се да имат комбинация от резервни копия на сървърни изображения (моментни снимки), логически и физически архиви, съхранявани на множество места. Целта е да се избегнат всякакви местни или регионални бедствия, които биха изтрили нашите бази данни и резервни копия, съхранявани в същия център за данни.
Искаме да го направим защитен. Данните и архивите трябва да бъдат криптирани. Но има много последици, когато и двете опции са налице. В тази статия ще разгледаме процедурите за архивиране, когато работим с криптирани бази данни.
Шифроване в покой за Percona Server за MySQL 8.0
Започвайки от MySQL 5.7.11, общностната версия на MySQL започна поддръжка за криптиране на пространството за таблици InnoDB. Нарича се шифроване на прозрачно таблично пространство или се нарича криптиране в покой.
Основната разлика в сравнение с корпоративната версия е начинът, по който ключовете се съхраняват – ключовете не се намират в защитен хранилище, което е необходимо за спазване на нормативните изисквания. Същото се отнася и за Percona Server, като се започне от версия 5.7.11, възможно е да се криптира пространството за таблици InnoDB. В Percona Server 8.0 поддръжката за криптиране на двоични регистрационни файлове е значително разширена. Добавена е версия 8.0
(документ за версията на Percona 8.0):
- Временно криптиране на файлове
- InnoDB Отмяна на шифроването на пространството за таблици
- Шифроване на пространството за таблици на системата InnoDB (шифроване на пространството за таблици на системата InnoDB)
- default_table_encryption =ИЗКЛ./ВКЛ. (Общо шифроване на пространството за таблици)
- table_encryption_privilege_check =OFF/ON (Проверка на настройките за шифроване)
- Криптиране на регистрационния файл за повторно изпълнение на InnoDB (само за криптиране с основен ключ) (Повторно шифроване на регистрационния файл)
- Криптиране на файлове за сливане на InnoDB (Проверка на настройката за криптиране)
- Percona Parallel буферно криптиране с двойно записване (InnoDB Tablespace Encryption)
За тези, които се интересуват от миграция от версията на MySQL Enterprise към Percona - също е възможно да се интегрира със сървъра на Hashicorp Vault чрез плъгин keyring_vault, съответстващ на функциите, налични в изданието MySQL Enterprise на Oracle.
Криптирането на данни в покой изисква приставка за ключодържател. Тук има две опции:
- keyring_file - плосък файл с ключ за криптиране
- Плъгин Keyring Vault – услуга
Как да активирате шифроването на пространството за таблици
За да активирате криптирането, стартирайте вашата база данни с опцията --early-plugin-load:
или на ръка:
$ mysqld --early-plugin-load="keyring_file=keyring_file.so"или чрез промяна на конфигурационния файл:
[mysqld]
early-plugin-load=keyring_file.soСтартирането на Percona Server 8.0 два типа пространства за таблици могат да бъдат криптирани. Общо таблично пространство и системно пространство за таблици. Sys пространството за таблици се контролира чрез параметър innodb_sys_tablespace_encrypt. По подразбиране пространството за таблици sys не е криптирано и ако вече имате такова, не е възможно да го преобразувате в криптирано състояние, трябва да се създаде нов екземпляр (стартирайте екземпляр с опция --bootstrap).
Общото пространство за таблици поддържа криптиране или на всички таблици в пространството за таблици, или на нито една. Не е възможно да се стартира криптиране в смесен режим. За да създадете ate tablespace с криптиране, използвайте флаг 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Архивът вече е подготвен и може да бъде възстановен с опцията --copy-back. В случай, че ключодържателят е завъртян, ще трябва да възстановите ключодържателя (който е бил използван за вземане и подготовка на резервното копие).
За да подготвим резервното xtrabackup, ще ни трябва достъп до ключодържателя. Xtrabackup не говори директно със сървъра MySQL и не чете конфигурационния файл по подразбиране my.cnf по време на подготовката, посочете настройките на ключодържателя чрез командния ред:
$ xtrabackup --prepare --target-dir=/data/backup --keyring-vault-config=/etc/vault.cnfАрхивът вече е подготвен и може да бъде възстановен с опцията --copy-back:
$ 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 --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В случай на keyring_vault, той ще изглежда така:
$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \
--transition-key=MySecetKey --generate-new-master-key \
--keyring-vault-config=/etc/vault.cnf
