Как да персонализирате вашите MySQL и MariaDB архиви с ClusterControl

Функцията за централизирано управление на архивиране на ClusterControl поддържа стандартния mysqldump, Percona Xtrabackup архивиране и Mariabackup, предоставени от MariaDB. Вярваме, че избраните аргументи на командния ред за съответните методи са оптимални за повечето натоварвания на база данни и отговарят на най-добрите практики за архивиране на MySQL. Базираме се на цялата обратна връзка, която сме получили през годините, когато работим с администратори на база данни и системни администратори. Въпреки това, конфигурацията може да не е достатъчна при някои обстоятелства. Все пак може да искате да го персонализирате така, че да отговаря на вашата среда, като използвате съответния метод за архивиране. В тази публикация ще ви покажем как да направите това.

mysqldump

За да извършите архивиране от потребителския интерфейс на ClusterControl, отидете на ClusterControl -> Изберете Cluster -> Backup section. Тук можете да видите генерираните архиви и можете да създадете или планирате ново.

От потребителския интерфейс на ClusterControl имаме няколко различни опции за архивиране. Можем да създадем един дъмп файл за всяка база данни, да активираме частично архивиране, да съхраняваме архива на възела или на сървъра на ClusterControl; можем да посочим директорията и поддиректорията за архивиране или можем автоматично да архивираме архива в облака (AWS, Google Cloud или Azure) с помощта на функцията за качване в облак.

Също така можем да използваме компресия, да криптираме резервното си копие и да посочим периода на запазване.

По подразбиране ClusterControl ни позволява да избираме между 4 различни типа дъмпи, за да извършим архивирането:

• Схема и данни:Схема и данни на базата данни
• Само схема:Схема на база данни
• Само данни:Данни от базата данни
• Само MySQL Db:MySQL системна база данни

Да кажем, че имаме 5 бази данни и избрахме да архивираме всички от тях. Ето какво ClusterControl ще изпълни при извършване на архивиране с помощта на метода mysqldump (командите са изрязани с обратна наклонена черта за четливост):

• Схема и данни

  $ /usr/bin/mysqldump \
  --defaults-file=/etc/my.cnf \
  --flush-privileges \
  --hex-blob \
  --opt \
  --single-transaction \
  --skip-lock-tables \
  --triggers \
  --routines \
  --events \
  --set-gtid-purged=OFF \
  --databases mysql proxydemo sakila sbtest mydb \
  --ignore-table='mysql.innodb_index_stats' \
  --ignore-table='mysql.innodb_table_stats' \
  |gzip -6 -c > /root/backups/BACKUP-1/mysqldump_2018-11-06_203010_schemaanddata.sql.gz'.

• Само схема

  $ /usr/bin/mysqldump \
  --defaults-file=/etc/my.cnf \
  --flush-privileges \
  --hex-blob \
  --opt \
  --no-data \
  --add-drop-table \
  --triggers \
  --routines \
  --events \
  --single-transaction \
  --skip-comments \
  --skip-lock-tables \
  --set-gtid-purged=OFF \
  --databases mysql proxydemo sakila sbtest mydb \
  |gzip -6 -c > /root/backups/BACKUP-2/mysqldump_2018-11-06_210040_schemaonly.sql.gz'.

• Само данни

  $ /usr/bin/mysqldump \
  --defaults-file=/etc/my.cnf \
  --flush-privileges \
  --hex-blob \
  --opt \
  --no-create-info \
  --single-transaction \
  --skip-comments \
  --skip-lock-tables \
  --skip-triggers \
  --skip-add-locks \
  --set-gtid-purged=OFF \
  --databases mysql proxydemo sakila sbtest mydb \
  --ignore-table='mysql.innodb_index_stats' \
  --ignore-table='mysql.innodb_table_stats' \
  |gzip -6 -c > /root/backups/BACKUP-3/mysqldump_2018-11-06_210445_dataonly.sql.gz'.

• Само за MySQL DB

  $ /usr/bin/mysqldump \
  --defaults-file=/etc/my.cnf \
  --flush-privileges \
  --hex-blob \
  --opt \
  --single-transaction \
  --skip-comments \
  --skip-lock-tables \
  --skip-add-locks \
  --set-gtid-purged=OFF mysql \
  |gzip -6 -c > /root/backups/BACKUP-5/mysqldump_2018-11-06_211135_mysqldbonly.sql.gz'.

Ако нашият MySQL възел генерира двоични регистрационни файлове, ще имаме параметъра master-data=2, включен в командите по-горе и наличен 1 допълнителен тип изхвърляне:

• Пълен PITR-съвместим

  $ /usr/bin/mysqldump \
  --defaults-file=/etc/my.cnf \
  --flush-privileges \
  --hex-blob \
  --opt \
  --master-data=1 \
  --single-transaction \
  --skip-lock-tables \
  --skip-lock-tables \
  --triggers \
  --routines \
  --events \
  --all-databases \
  |gzip -6 -c > /root/backups/BACKUP-6/mysqldump_2018-11-06_211451_complete.sql.gz'.

От горните командни редове можем да видим, че при всяка команда mysqldump ClusterControl включва конфигурационния файл на MySQL в своя аргумент --defaults-file. Притежавайки това, процесът mysqldump може да чете съдържанието на директивата mysqldump. По подразбиране ClusterControl конфигурира резервните потребителски идентификационни данни в отделен файл в /etc/my.cnf.d/secrets-backup.cnf и max_allowed_packet в my.cnf, подобно на следното:

$ my.cnf

[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8

$ secrets-backup.cnf

[mysqldump]
user=backupuser
password=ETgAG5VnpvuyXniE

Предимството на това е, че можем да включим някои допълнителни опции за mysqldump. За съжаление аргументът --defaults-file може да бъде посочен само като основен аргумент. Обърнете внимание, че последните аргументи на командния ред имат предимство пред това, което е конфигурирано в my.cnf под [mysqldump] директива въз основа на реда, в който се появяват. Например, ако добавим skip-comments=0 в my.cnf, докато в края на командата mysqldump има --skip-comments (или --skip-comments=1), първото ще бъде игнорирано и последният ще бъде използван.

Независимо от това, ние все още можем да го използваме като част от нашата персонализация на архивиране, като използваме други опции за архивиране на mysqldump. Например, можем да изключим таблици, които не искаме да архивираме, като използваме параметър ignore-table (с форматиране на „database.table“). Добавете следните редове в конфигурационния файл на MySQL:

[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8
ignore-table=sbtest.sbtest9
ignore-table=sbtest.sbtest10
ignore-table=sbtest.sbtest1

Веднъж конфигурирани, можем просто да задействаме нова работа на mysqldump от ClusterControl и тези таблици ще бъдат пропуснати от mysqldump. Не се изисква рестартиране на MySQL.

Можете да проверите документацията на mysqldump за повече информация.

Percona Xtrabackup

ClusterControl изпълнява Xtrabackup в зависимост от опциите, които сте избрали. Тя може да бъде пълна или инкрементална и можете да изберете няколко променливи от потребителския интерфейс на ClusterControl. Помислете за следното:

В тази стъпка можете да изберете някои променливи, които споменахме по-рано в секцията mysqldump, и след това:

Можем да посочим някои подробности като възел за десинхронизиране по време на архивиране, нишки за паралелно копиране на Xtrabackup и други.

Въз основа на горните опции, пълната команда Xtrabackup ще бъде:

$ ulimit -n 256000 && LC_ALL=C /usr/bin/innobackupex --defaults-file=/etc/mysql/my.cnf  --galera-info --parallel 1 --stream=xbstream --no-timestamp . | gzip -6 - | socat - TCP4:192.168.100.110:9999 ) 2>&1.

Първата команда “ulimit -n 256000” е да гарантира, че Percona Xtrabackup има достатъчно права за достъп до огромен брой файлови дескриптори (в случай че базите данни съдържат много таблици). Обърнете внимание на --defaults-file=/etc/mysql/my.cnf, който е подобен на mysqldump, където innobackupex чете съдържанието на MySQL конфигурацията на следните директиви и променливи:

[mysqld]
datadir=[physical path to MySQL data directory]
tmpdir=[path to temporary directory]
[xtrabackup]
user=backupuser
password=[random password]

Ако искате да персонализирате опциите за архивиране за Percona Xtrabackup, можете да ги добавите директно под директивата [xtrabackup]. Например, да кажем, че искаме Xtrabackup да отпечата позицията на двоичния дневник, когато се направи архивиране, можем да добавим нещо подобно:

[xtrabackup]
user=backupuser
password=[random password]
slave-info=1

След това задействането на задачата xtrabackup ще включва файл, наречен xtrabackup_slave_info файл. Не се изисква рестартиране на MySQL.

Можете да проверите документацията на Percona за повече информация как работи.

Mariabackup

Mariabackup е разклонение на Percona XtraBackup с добавена поддръжка за компресиране на MariaDB 10.1 и криптиране на данни в покой. Той е включен в MariaDB 10.1.23 и по-нови версии.

Методът за архивиране може да бъде пълен или инкрементален и можете да изберете същите променливи, които имате за Percona XtraBackup, като компресия, нишки за паралелно копиране на Xtrabackup или криптиране.

Командата Mariabackup ще бъде:

$ /usr/bin/mariabackup \
--defaults-file=/etc/my.cnf \
--backup \
--galera-info \
--parallel 1 \
--stream=xbstream \
--no-timestamp \
| gzip -6 - > /root/backups/BACKUP-8/backup-full-2018-11-07_015807.xbstream.gz ) 2>&1.

Mariabackup се базира на Percona XtraBackup, така че използва същата информация като Percona за извършване на архивирането. По подразбиране ClusterControl добавя следните редове във файла my.cnf:

[xtrabackup]
databases-exclude=lost+found
# ssl_mode = DISABLED
ssl = 0

И идентификационните данни във файла secrets-backup.cnf:

[xtrabackup]
user=backupuser
password=[random password]

Ако искате да добавите някаква променлива, можете да я добавите в секцията [xtrabackup].

Можете да проверите документацията на MariaDB за повече информация кой параметър да добавите.

Във всеки случай можете да проверите вашите архиви от секцията за архивиране на потребителския интерфейс на ClusterControl:

Надяваме се това да ви помогне да конфигурирате по-добре вашите MySQL архиви - можете да изтеглите ClusterControl от нашия уебсайт (безплатно е).