Обзор Mariabackup

Mariabackup — это инструмент с открытым исходным кодом, предоставляемый MariaDB для выполнения физических онлайн-бэкапов таблиц InnoDB, Aria и MyISAM. Для InnoDB возможны «горячие онлайн» бэкапы. Он изначально был разветвлён от Percona XtraBackup 2.3.8. Он доступен на Linux и Windows.

Поддержка бэкапов для функций, уникальных для MariaDB

MariaDB 10.1 представила функции, уникальные для MariaDB, такие как Сжатие страниц InnoDB и Шифрование данных в состоянии покоя. Эти уникальные функции пользуются большой популярностью у пользователей MariaDB. Однако существующие решения для бэкапов из экосистемы MySQL, такие как Percona XtraBackup, не поддерживали полные бэкапы для этих функций.

Для удовлетворения потребностей наших пользователей мы решили разработать решение для бэкапов, которое полностью поддерживало бы эти популярные функции, уникальные для MariaDB. Мы сделали это, создав Mariabackup, основанный на известном и широко используемом инструменте бэкапа — Percona XtraBackup. Mariabackup был изначально расширен с версии 2.3.8.

Поддерживаемые функции

Mariabackup поддерживает все основные функции Percona XtraBackup 2.3.8, а также:

• Бэкап/восстановление таблиц с использованием Шифрования данных в состоянии покоя.
• Бэкап/восстановление таблиц с использованием Сжатия страниц InnoDB.
• Метод SST mariabackup с Galera Cluster.
• Поддержка Microsoft Windows.
• Бэкап/восстановление таблиц, использующих движок хранения MyRocks, начиная с MariaDB 10.2.16 и MariaDB 10.3.8. Дополнительную информацию см. в Файлы, резервируемые Mariabackup: Файлы данных MyRocks.

Поддерживаемые функции в MariaDB Enterprise Backup

MariaDB Enterprise Backup поддерживает некоторые дополнительные функции, такие как:

• Минимизация блокировок во время бэкапа для повышения конкурентности и ускорения бэкапов.
  • Это основано на использовании команд BACKUP STAGE и регистрации DDL.
  • Это включает отсутствие блокировок во время фазы копирования ALTER TABLE инструкций, которая, как правило, является самой длительной фазой этих инструкций.
• Оптимальная поддержка бэкапа для всех движков хранения, сохраняющих данные на локальном диске.

Отличия от Percona XtraBackup

• Percona XtraBackup копирует свои файлы журнала InnoDB redo log в файл xtrabackup_logfile, в то время как Mariabackup использует файл ib_logfile0.

• Шифрование бэкапов Percona XtraBackup, основанное на libgcrypt, не поддерживается Mariabackup.

• Нет символической ссылки от mariabackup к innobackupex, как есть для xtrabackup. Вместо этого mariabackup имеет параметр командной строки --innobackupex для включения совместимых с innobackupex параметров.

• Параметры --compact и --rebuild_indexes не поддерживаются.

• Поддержка --stream=tar была удалена из Mariabackup в MariaDB 10.1.24.

• Утилита xbstream была переименована в mbstream. Однако для выбора этого формата вывода при создании бэкапа, параметр --stream Mariabackup все ещё ожидает значение xbstream.

• Mariabackup не поддерживает бесблочный binlog.

Отличия в схемах версионирования

Каждый релиз Percona XtraBackup имеет два номера версий — номер версии Percona XtraBackup и номер версии релиза MySQL Server, на котором он основан. Например:

xtrabackup version 2.2.8 based on MySQL server 5.6.22

Каждый релиз Mariabackup имеет только один номер версии, и он совпадает с номером версии релиза MariaDB Server, на котором он основан. Например:

mariabackup based on MariaDB server 10.2.15-MariaDB Linux (x86_64)

Дополнительную информацию о версиях Mariabackup см. в разделе Совместимость релизов Mariabackup с релизами MariaDB Server.

Совместимость релизов Mariabackup с релизами MariaDB Server

Версию MariaDB Server часто можно бэкапить с большинством других релизов Mariabackup в той же серии релизов. Например, MariaDB 10.2.21 и MariaDB 10.2.22 находятся в серии релизов MariaDB 10.2, поэтому MariaDB Server из MariaDB 10.2.21 можно бэкапить с помощью Mariabackup из MariaDB 10.2.22, и наоборот.

Однако иногда релиз MariaDB Server или Mariabackup будет содержать исправления ошибок, которые повлияют на совместимость с предыдущими релизами. Например, исправление для MDEV-13564 изменило формат InnoDB redo log в MariaDB 10.2.19, что нарушило совместимость с предыдущими релизами. Для большей безопасности, релиз MariaDB Server, как правило, следует бэкапить с релизом Mariabackup, имеющим тот же номер версии.

Установка Mariabackup

Установка на Linux

Исполняемый файл mariabackup включен в бинарные tar-архивы на Linux.

Установка с помощью менеджера пакетов

Mariabackup также можно установить через менеджер пакетов на Linux. Для этого ваша система должна быть настроена на установку из репозиториев MariaDB.

Вы можете настроить свой менеджер пакетов для установки из репозитория MariaDB Corporation's MariaDB Package Repository с помощью скрипта настройки MariaDB Package Repository setup.

Вы также можете настроить свой менеджер пакетов на установку из MariaDB Foundation's MariaDB Repository с помощью инструмента конфигурации репозитория MariaDB.

Установка с помощью yum/dnf

В RHEL, CentOS, Fedora и других подобных дистрибутивах Linux рекомендуется устанавливать соответствующий пакет RPM из репозитория MariaDB с помощью yum или dnf. Начиная с RHEL 8 и Fedora 22, yum был заменен на dnf, который является следующей основной версией yum. Однако команды yum все еще работают на многих системах, использующих dnf. Например:

sudo yum install MariaDB-backup

Установка с помощью apt-get

В Debian, Ubuntu и других подобных дистрибутивах Linux рекомендуется устанавливать соответствующий пакет DEB из репозитория MariaDB с помощью apt-get. Например:

sudo apt-get install mariadb-backup

Установка с помощью zypper

В SLES, OpenSUSE и других подобных дистрибутивах Linux рекомендуется устанавливать соответствующий пакет RPM из репозитория MariaDB с помощью zypper. Например:

sudo zypper install MariaDB-backup

Установка на Windows

Исполняемый файл mariabackup включен в пакеты MSI и ZIP на Windows.

При использовании установщика Windows MSI mariabackup можно установить, выбрав Утилиты резервного копирования:

Использование Mariabackup

Команда для использования mariabackup и общий синтаксис:

mariabackup <options>

Для подробных объяснений использования Mariabackup см.:

• Полный бэкап и восстановление с Mariabackup
• Инкрементальный бэкап и восстановление с Mariabackup
• Частичный бэкап и восстановление с Mariabackup
• Восстановление отдельных таблиц и разделов с Mariabackup
• Настройка реплицирующего сервера-ведомого с Mariabackup
• Использование инструментов шифрования и сжатия с Mariabackup

Параметры

Параметры, поддерживаемые Mariabackup, можно найти здесь.

mariabackup в настоящее время будет молча игнорировать неизвестные параметры командной строки, поэтому будьте очень внимательны, чтобы случайно не включить опечатки в параметрах или случайно не использовать параметры из более поздних mariabackup версий. Причина в том, что mariabackup в настоящее время рассматривает параметры командной строки и параметры из файлов параметров одинаково. При чтении из этих файлов параметров необходимо прочитать множество параметров из групп параметров сервера, прочитанных mysqld. Однако, mariabackup не знает о многих параметрах, которые он обычно читает в этих группах параметров. Если mariabackup выдавало ошибку или предупреждение при обнаружении неизвестного параметра, этот процесс породил бы большое количество сообщений в журнале при нормальном использовании. Поэтому, mariabackup разработано для молчаливого игнорирования неизвестных параметров. См. MDEV-18215 по этому вопросу.

Файлы параметров

В дополнение к чтению параметров из командной строки, Mariabackup также может читать параметры из файлов параметров.

Следующие параметры относятся к тому, как утилиты MariaDB командной строки обрабатывают файлы параметров. Они должны быть указаны в качестве первого аргумента в командной строке:

Группы параметров сервера

Mariabackup считывает параметры сервера из следующих групп параметров из файлов параметров:

Группы параметров клиента

Mariabackup считывает параметры клиента из следующих групп параметров из файлов параметров:

Аутентификация и привилегии

Mariabackup должен пройти аутентификацию на сервере базы данных при выполнении операции резервного копирования (т. е. когда указан параметр --backup). В большинстве случаев учетная запись пользователя, выполняющая резервное копирование, должна иметь следующие глобальные привилегии на сервере базы данных.

В версии 10.5 и более поздних версиях требуемые привилегии:

CREATE USER 'mariabackup'@'localhost' IDENTIFIED BY 'mypassword';
GRANT RELOAD, PROCESS, LOCK TABLES, BINLOG MONITOR ON *.* TO 'mariabackup'@'localhost';

До версии 10.5 требуемые привилегии:

CREATE USER 'mariabackup'@'localhost' IDENTIFIED BY 'mypassword';
GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'mariabackup'@'localhost';

Если ваш сервер базы данных также использует движок хранения MyRocks, то учетная запись пользователя, выполняющая резервное копирование, также должна иметь привилегию SUPER глобальных привилегий. Это связано с тем, что Mariabackup создает контрольную точку этих данных, устанавливая переменную системы rocksdb_create_checkpoint, которая требует этой привилегии. См. MDEV-20577 для получения дополнительной информации.

Для использования параметра --history пользователю резервного копирования также должны быть предоставлены следующие привилегии:

GRANT CREATE, INSERT ON mysql.* TO 'mariabackup'@'localhost';

До MariaDB 10.11 необходимые разрешения для использования --history были:

GRANT CREATE, INSERT ON PERCONA_SCHEMA.* TO 'mariabackup'@'localhost';

Если вы обновляетесь с более ранней версии и хотите использовать новые таблицы по умолчанию, не потеряв историю резервного копирования, вы можете перенести и переименовать текущую таблицу следующим образом:

RENAME TABLE PERCONA_SCHEMA.xtrabackup_history TO mysql.mariadb_backup_history;

Информация об учетной записи пользователя может быть указана с помощью параметров командной строки --user и --password. Например:

$ mariabackup --backup \
   --target-dir=/var/mariadb/backup/ \
   --user=mariabackup --password=mypassword

Информация об учетной записи пользователя также может быть указана в поддерживаемой группе параметров клиента в файле параметров. Например:

[mariabackup]
user=mariabackup
password=mypassword

Mariabackup не нуждается в аутентификации с сервером базы данных при подготовке или восстановлении резервной копии.

Разрешения файловой системы

Mariabackup должен читать файлы MariaDB из файловой системы. Поэтому, когда вы запускаете Mariabackup как конкретного пользователя операционной системы, вы должны убедиться, что учетная запись этого пользователя имеет достаточные разрешения для чтения этих файлов.

Если вы используете Linux и установили MariaDB с помощью менеджера пакетов, то файлы MariaDB, вероятно, принадлежат пользователю mysql и группе mysql.

Использование Mariabackup с шифрованием данных в состоянии покоя

Mariabackup поддерживает шифрование данных в состоянии покоя.

Mariabackup запросит сервер, чтобы определить, какой управляющий ключ и плагин шифрования используется, а затем загрузит этот плагин сам, что означает, что Mariabackup должен иметь возможность загрузить общую библиотеку управляющего ключа и плагина шифрования.

Mariabackup также запросит сервер, чтобы определить, какие ключи шифрования ему необходимо использовать.

Другими словами, Mariabackup может самостоятельно определить много информации, связанной с шифрованием, поэтому обычно не нужно предоставлять какие-либо дополнительные параметры для резервного копирования или восстановления зашифрованных таблиц.

Mariabackup резервирует зашифрованные и незашифрованные таблицы так, как они находятся на исходном сервере. Если таблица зашифрована, то таблица останется зашифрованной в резервной копии. Аналогично, если таблица незашифрована, то таблица останется незашифрованной в резервной копии.

Основная причина, по которой Mariabackup должен уметь шифровать и расшифровывать данные, заключается в том, что ему необходимо применить записи журнала InnoDB redo log для обеспечения согласованности данных при подготовке резервной копии. Вследствие этого Mariabackup не выполняет многие операции шифрования или расшифровки при первоначальном создании резервной копии. MariaDB выполняет больше операций шифрования и расшифровки при подготовке резервной копии. Это означает, что некоторые проблемы, связанные с шифрованием (например, использование неправильных ключей шифрования), могут проявиться только при подготовке резервной копии.

Использование Mariabackup для Galera SST

Метод SST mariabackup использует утилиту Mariabackup для выполнения SST. Смотрите метод SST mariabackup для получения дополнительной информации.

Файлы, резервируемые Mariabackup

Mariabackup резервирует множество различных файлов для выполнения своей операции резервного копирования. Смотрите Файлы, резервируемые Mariabackup для списка этих файлов.

Файлы, созданные Mariabackup

Mariabackup создает несколько различных типов файлов во время фаз резервного копирования и подготовки. Смотрите Файлы, созданные Mariabackup для списка этих файлов.

Известные проблемы

Неподдерживаемые группы параметров сервера

До MariaDB 10.1.38, MariaDB 10.2.22 и MariaDB 10.3.13, Mariabackup не считывает параметры сервера из всех групп параметров, поддерживаемых сервером. В этих версиях он ищет параметры сервера только в следующих группах параметров сервера:

Эти версии не считывают параметры сервера из следующих поддерживаемых сервером групп параметров:

См. MDEV-18347 для получения дополнительной информации.

Отсутствие каталога данных по умолчанию

До MariaDB 10.1.36, MariaDB 10.2.18 и MariaDB 10.3.10, если вы выполняли операцию --copy-back, и если вы не явно задали значение для параметра datadir ни в командной строке, ни в одной из поддерживаемых групп параметров сервера в файле параметров, то Mariabackup не использовал бы значение datadir по умолчанию сервера. Вместо этого Mariabackup завершался бы с ошибкой. Например:

Error: datadir must be specified.

Решение состоит в том, чтобы явно указать значение для параметра datadir либо в командной строке, либо в одной из поддерживаемых групп параметров сервера в файле параметров. Например:

[mysqld]
datadir=/var/lib/mysql

В MariaDB 10.1.36, MariaDB 10.2.18 и MariaDB 10.3.10 и более поздних версиях Mariabackup будет использовать значение datadir по умолчанию сервера.

См. MDEV-12956 для получения дополнительной информации.

Проблемы одновременного DDL и резервного копирования

До MariaDB 10.2.19 и MariaDB 10.3.10, если одновременный DDL выполнялся во время резервного копирования, это могло привести к различным проблемам.

Например, если DDL изменил какие-либо идентификаторы таблиц (например, TRUNCATE TABLE или RENAME TABLE), это могло привести к несогласованности затронутых таблиц в резервной копии. В этом случае при подготовке резервной копии могут появиться ошибки о несоответствующих идентификаторах таблиц.

Например, ошибки могут выглядеть так:

2018-12-07 07:49:32 7f51b3184820  InnoDB: Error: table 'DB1/TAB_TEMP'
InnoDB: in InnoDB data dictionary has tablespace id 1355633,
InnoDB: but a tablespace with that id does not exist. There is
InnoDB: a tablespace of name DB1/TAB_TEMP and id 1354713, though. Have
InnoDB: you deleted or moved .ibd files?
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.

Или они могут выглядеть так:

2018-07-12 21:24:14 139666981324672 [Note] InnoDB: Ignoring data file 'db1/tab1.ibd' with space ID 200485, since the redo log references db1/tab1.ibd with space ID 200484.

Некоторые проблемы, связанные с одновременным DDL, описаны ниже.

Проблемы, решённые установкой --lock-ddl-per-table (параметр командной строки Mariabackup, добавленный в MariaDB 10.2.9):

• Если таблица удаляется во время резервного копирования, она может всё ещё существовать после подготовки резервной копии.
• Если таблица существует при запуске резервного копирования, но удаляется до того, как резервная копия скопирует её, то файл табличного пространства не может быть скопирован, и резервное копирование завершится неудачей.

Проблемы, решённые установкой innodb_log_optimize_ddl=OFF (переменная системы MariaDB Server, добавленная в MariaDB 10.2.17 и удалённая в 10.6.0):

• Если резервное копирование обнаружило одновременный DDL, оно может завершиться ошибкой "ALTER TABLE or OPTIMIZE TABLE was executed during backup".

Проблемы, решённые innodb_safe_truncate=ON (переменная системы MariaDB Server в MariaDB 10.2.19 и удалённая в 10.3.0):

• Если таблица создаётся во время резервного копирования, она может отсутствовать в резервной копии после подготовки.
• Если таблица переименовывается во время резервного копирования после копирования файла табличного пространства, таблица может отсутствовать после подготовки резервной копии.
• Если таблица удаляется и создаётся заново с тем же именем во время резервного копирования после копирования файла табличного пространства, у таблицы будет неправильный идентификатор табличного пространства при подготовке резервной копии.

Обратите внимание, что с удалением innodb_log_optimize_ddl и innodb_safe_truncate, вышеуказанные проблемы были однозначно решены.

Проблемы, решённые другими исправлениями ошибок:

• Если --lock-ddl-per-table используется, и таблица одновременно удаляется или переименовывается, Mariabackup может не получить блокировку MDL.

Эти проблемы исправлены только в MariaDB 10.2 и более поздних версиях, поэтому не рекомендуется выполнять одновременные DDL-операции при использовании Mariabackup с MariaDB 10.1.

См. MDEV-13563, MDEV-13564, MDEV-16809 и MDEV-16791 для получения дополнительной информации.

Ручное восстановление с предварительно существующими файлами журнала InnoDB Redo

До MariaDB 10.2.10, пользователи Mariabackup могли столкнуться с проблемами при восстановлении резервной копии путём ручного копирования файлов из резервной копии в datadir , если в каталоге всё ещё содержались предварительно существующие файлы журнала InnoDB redo log. Сама резервная копия не содержала файлы InnoDB redo log с традиционными ib_logfileN именами файлов, поэтому предварительно существующие файлы журнала оставались в datadir. Если сервер запускался с этими предварительно существующими файлами журнала, он мог выполнить восстановление после сбоя с их использованием, что могло привести к несогласованности или повреждению базы данных.

В этих версиях MariaDB эту проблему можно было избежать, не восстанавливая резервную копию путём ручного копирования файлов, а вместо этого восстанавливая резервную копию с помощью Mariabackup и предоставления параметра --copy-back, поскольку Mariabackup удаляет предварительно существующие файлы журнала InnoDB redo log из datadir во время процесса восстановления.

В MariaDB 10.2.10 и более поздних версиях Mariabackup предотвращает эту проблему, создавая пустой файл журнала InnoDB redo log с именем ib_logfile0 как часть стадии --prepare. Таким образом, если резервная копия восстанавливается вручную, все предварительно существующие файлы журнала InnoDB redo log будут перезаписаны пустым файлом.

См. MDEV-13311 для получения дополнительной информации.

Слишком много открытых файлов

Если Mariabackup использует больше дескрипторов файлов, чем система настроена позволять, пользователи могут увидеть ошибки, подобные следующим:

2019-02-12 09:48:38 7ffff7fdb820  InnoDB: Operating system error number 23 in a file operation.
InnoDB: Error number 23 means 'Too many open files in system'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
InnoDB: Error: could not open single-table tablespace file ./db1/tab1.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.

До MariaDB 10.1.39, MariaDB 10.2.24 и MariaDB 10.3.14, Mariabackup фактически игнорировал ошибку и продолжал резервное копирование. В некоторых из этих случаев Mariabackup даже сообщал пользователю об успешном завершении резервного копирования. В более поздних версиях Mariabackup будет правильно генерировать ошибку и прерывать процесс при возникновении этой ошибки. См. MDEV-19060 для получения дополнительной информации.

При возникновении этой ошибки одним из решений является явное указание значения для параметра open-files-limit либо в командной строке, либо в одном из поддерживаемых групп параметров сервера в файле параметров. Например:

[mariabackup]
open_files_limit=65535

Альтернативное решение — установить мягкие и жёсткие лимиты для учётной записи пользователя, выполняющей Mariabackup, добавив новые ограничения в /etc/security/limits.conf. Например, если Mariabackup выполняется пользователем mysql, то вы можете добавить такие строки:

mysql soft nofile 65535
mysql hard nofile 65535

После перезагрузки системы вышеуказанная настройка должна установить новые ограничения на открытые файлы для пользователя mysql, и вывод пользователя ulimit должен выглядеть следующим образом:

$ ulimit -Sn
65535
$ ulimit -Hn
65535

Версии

См. также

• mariadb-dump/mysqldump
• Как создавать резервные копии с MariaDB (видео)
• Восстановление MariaDB в определённый момент времени (видео)
• Mariabackup и Restic (видео)
• Резервное копирование MariaDB Enterprise. Обновлённая версия Mariabackup.
• Документация Percona Xtrabackup 2.3