Обзор резервного копирования и восстановления

В этой статье кратко рассматриваются основные способы резервного копирования MariaDB. Для подробных описаний и синтаксиса см. отдельные страницы. Дополнительная информация добавляется в процессе.

Логическое и физическое резервное копирование

Логическое резервное копирование состоит из SQL-запросов, необходимых для восстановления данных, таких как CREATE DATABASE, CREATE TABLE и INSERT.

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

Основные различия следующие:

• Логическое резервное копирование более гибкое, поскольку данные можно восстановить на других конфигурациях оборудования, версиях MariaDB или даже в другой СУБД, в то время как физическое резервное копирование не может быть импортировано на существенно отличающееся оборудование, в другую СУБД или потенциально даже в другую версию MariaDB.
• Логическое резервное копирование может выполняться на уровне базы данных и таблицы, а физическое — на уровне каталогов и файлов. В хранилищах MyISAM и InnoDB каждая таблица имеет эквивалентный набор файлов. (В версиях до MariaDB 5.5 по умолчанию несколько таблиц InnoDB хранятся в одном файле, в этом случае резервное копирование по таблицам невозможно. См. innodb_file_per_table.)
• Логическое резервное копирование имеет больший размер, чем эквивалентное физическое резервное копирование.
• Логическое резервное копирование занимает больше времени как для резервного копирования, так и для восстановления, чем эквивалентное физическое резервное копирование.
• Файлы журналов и конфигурационные файлы не входят в состав логического резервного копирования.

Инструменты резервного копирования

Mariadb-backup

Mariadb-backup — это форк Percona XtraBackup с добавленной поддержкой MariaDB 10.1 сжатия и шифрования данных. Он включен в MariaDB 10.1.23 и более поздние версии.

mariadb-dump

mariadb-dump (ранее mysqldump) выполняет логическое резервное копирование. Это наиболее гибкий способ резервного копирования и восстановления, и хороший выбор, когда размер данных относительно невелик.

Для больших наборов данных файл резервной копии может быть большим, а время восстановления — длительным.

mariadb-dump экспортирует данные в формате SQL (он также может экспортировать в другие форматы, такие как CSV или XML), который затем можно легко импортировать в другую базу данных. Данные можно импортировать в другие версии MariaDB, MySQL или даже в другую СУБД, если в дампе нет специфичных для версии или СУБД запросов.

mariadb-dump экспортирует триггеры вместе с таблицами, так как они являются частью определения таблицы. Однако хранимые процедуры, представления и события нет, и для их явного восстановления требуются дополнительные параметры (например, --routines и --events). Процедуры и функции также являются частью системных таблиц (например, mysql.proc).

Логическое резервное копирование InnoDB

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

Легкий способ избежать этого — увеличить значение системной переменной innodb_old_blocks_time. Она представляет количество миллисекунд, которое должно пройти, прежде чем недавно использованная страница может быть помещена в подсписок «новые» в кэше-памяти буфера. Данные, которые используются только один раз, должны оставаться в подсписке «старые». Это означает, что они вскоре будут удалены из кэш-памяти буфера. Поскольку во время процесса резервного копирования подсписок «старые» вероятно будет хранить данные, которые бесполезны, можно также рассмотреть возможность изменения его размера, изменив значение системной переменной innodb_old_blocks_pct.

Также можно явно выгрузить кэш-память буфера на диск перед запуском логического резервного копирования и восстановить ее после процесса. Это позволит отменить любые негативные изменения в кэш-памяти буфера, которые произошли во время резервного копирования. Для выгрузки кэш-памяти буфера системную переменную innodb_buffer_pool_dump_now можно установить в ON. Для восстановления системную переменную innodb_buffer_pool_load_now можно установить в ON.

Примеры

Резервное копирование одной базы данных

shell> mariadb-dump db_name > backup-file.sql

Восстановление или загрузка базы данных

shell> mariadb db_name < backup-file.sql

Подробный синтаксис и примеры см. на странице mariadb-dump.

mariadb-hotcopy

mariadb-hotcopy выполняет физическое резервное копирование и работает только для резервного копирования таблиц MyISAM и ARCHIVE. Он может запускаться только на том же компьютере, что и расположение каталогов базы данных.

Примеры

shell> mariadb-hotcopy db_name [/path/to/new_directory]
shell> mariadb-hotcopy db_name_1 ... db_name_n /path/to/new_directory

Percona XtraBackup

Percona XtraBackup — инструмент для быстрого резервного копирования в режиме работы. Он был разработан специально для баз данных XtraDB/InnoDB, но может использоваться с любым хранилищем (хотя и не с MariaDB 10.1 шифрованием и сжатием). Он не включен по умолчанию в MariaDB.

Снимки файловой системы

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

• Из клиента mariadb выполните FLUSH TABLES WITH READ LOCK. Клиент должен оставаться открытым.
• Из командной строки выполните mount vxfs snapshot
• Клиент может выполнить UNLOCK TABLES.
• Скопируйте файлы снимка.
• Из командной строки размонтируйте снимок с помощью umount snapshot.

LVM

Широко используемый физический метод резервного копирования с использованием Perl-скрипта в качестве оболочки. См. http://www.lenzg.net/mylvmbackup/.

Percona TokuBackup

Подробную информацию см.:

• TokuDB Hot Backup — Часть 1
• TokuDB Hot Backup — Часть 2
• TokuDB Hot Backup теперь плагин MySQL

dbForge Studio для MySQL

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

Модуль резервного копирования и восстановления Studio позволяет точно настроить и управлять полными и частичными резервными копиями до конкретных объектов базы данных. Функция планирования регулярных резервных копий предлагает специфические настройки для обработки ошибок и ведения журнала об ошибках. Кроме того, настройки и конфигурации можно сохранить для последующего использования.

Эти операции осуществляются с помощью мастера, позволяющего пользователям настраивать все задачи в визуальном режиме.

См. также

• Потоковое резервное копирование MariaDB в облаке (блог mariadb.com)