Обзор резервного копирования MariaDB для пользователей SQL Server

MariaDB поддерживает следующие типы резервного копирования:

• Логическое резервное копирование (дампы).
• Горячее резервное копирование с Mariabackup.
• Снимки.
• Инкрементные резервные копии.

Логическое резервное копирование (дампы)

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

Совместимость между различными версиями и технологиями достигается с помощью выполняемых комментариев, но мы должны понимать, как они работают. Если мы используем функцию, добавленную в версии 11.1, например, она будет включена в дамп внутри исполняемого комментария. Если мы восстановим это резервное копирование на сервере с MariaDB 10.11, функция 11.1 будет проигнорирована. Это единственный способ восстановить резервные копии в более старых версиях MariaDB.

mariadb-dump

Логические резервные копии обычно создаются с помощью mariadb-dump (ранее называлось mysqldump).

mariadb-dump позволяет создать дамп всех баз данных, одной базы данных или набора таблиц из базы данных. Возможна даже спецификация WHERE определения, что в определенных случаях позволяет получить инкрементные дампы.

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

Опция --master-data добавляет команды для настройки сервера-следующего за дампом.

MariaDB также поддерживает команды, которые упрощают создание приложений для получения пользовательских типов дампов. Для большинства CREATE <object_type> существует соответствующая SHOW CREATE <object_type> . Например, SHOW CREATE TABLE возвращает CREATE TABLE команду, которая может быть использована для восстановления определённой таблицы без данных.

mydumper

mydumper — это инструмент сторонних разработчиков для создания дампов баз данных MariaDB и MySQL. Он намного быстрее, чем mariadb-dump, поскольку создает резервные копии с несколькими потоками, обычно по одному потоку на каждый доступный процессор. Он создаёт несколько файлов, которые можно использовать для восстановления базы данных с помощью соответствующего инструмента myloader.

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

Горячее резервное копирование (mariabackup)

Mariabackup — инструмент для создания резервных копий файлов MariaDB во время работы MariaDB. Блокировка активна только в течение короткого промежутка времени, что делает его подходящим для резервного копирования сервера без сбоев. Он работает, беря поврежденные резервные копии и затем приводи их в согласованное состояние, используя InnoDB-журнал отката. Mariabackup также правильно создает резервные копии таблиц MyRocks и таблиц с нетранзакционными движками хранения.

Холодное резервное копирование и снимки

Копия всех файлов MariaDB является рабочим резервным копированием. Таким образом, самый простой способ создания резервной копии набора данных — остановить сервер и скопировать все его файлы. Полностью возможно запустить другой сервер с копией этих файлов. Это часто называют холодным резервным копированием. Однако в большинстве случаев этого делать не нужно, так как это приводит к простою сервера: он не будет работать, по крайней мере, в течение времени, необходимого для копирования файлов.

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

Снимок файлов может быть сделан на нескольких уровнях: на уровне файловой системы, если файловая система поддерживает снимки, например, zfs; Linux Logical Volume Manager (LVM) также поддерживает снимки; виртуальные машины также позволяют создавать снимки. Снимки Windows также являются снимками с преимуществом: можно восстановить один файл из снимка. Снимок не является дорогостоящей операцией, поскольку он не предполагает копирование файлов. Текущие файлы больше не будут изменяться, а изменения в них будут записываться в отдельные места.

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

В случае таблиц с нетранзакционными типами данных обычно теряются некоторые данные. Изменения данных, присутствующие в буфере перед созданием снимка, но не записанные на диск, не могут быть восстановлены. Изменения данных в транзакционных таблицах, таких как InnoDB, всегда могут быть восстановлены после восстановления снимка (или после сбоя), если была выполнена операция подтверждения. Таблицы всё равно придётся восстановить, как это происходит после сбоя SQL Server.

Снимки могут создаваться, когда MariaDB работает. Для их восстановления сначала необходимо остановить MariaDB — или убить процесс, поскольку в этом случае последствия не важны. Затем восстановите снимок и перезапустите MariaDB.

Дополнительную информацию о снимках см. в документации вашей файловой системы, LVM или виртуальной машины.

Инкрементные резервные копии

Термин «инкрементное резервное копирование» в MariaDB соответствует тому, что SQL Server называет дифференциальным резервным копированием. Важное отличие состоит в том, что в SQL Server такие резервные копии основаны на журналах транзакций, что было бы невозможно в MariaDB, поскольку журналы транзакций обрабатываются на уровне движка хранения.

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

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

Воспроизведение бинарного журнала

Страница Использование mariadb-binlog демонстрирует, как использовать утилиту mariadb-binlog для воспроизведения файла бинарного журнала.

Страница также показывает, как редактировать бинарный журнал перед его воспроизведением. Это позволяет отменить выполнение SQL-команды, которая была выполнена ошибочно, например, DROP TABLE для неправильной таблицы. Общий алгоритм действий следующий:

• Восстановите резервную копию, которая старше, чем SQL-команда, которую нужно отменить.
• Используйте mariadb-binlog для создания файла с SQL-командами, которые были выполнены после резервной копии.
• Отредактируйте SQL-файл, удалив нежелаемую команду.
• Выполните SQL-файл.

Инкрементные резервные копии с mariabackup

Самый простой способ создания инкрементной резервной копии — использовать Mariabackup. Этот инструмент может создавать и восстанавливать инкрементные резервные копии. Полную процедуру использования см. в Инкрементное резервное копирование и восстановление с Mariabackup.

Mariabackup может работать как в Linux, так и в Windows.

Flashback

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

Копирование отдельных таблиц

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

С движком хранения MyISAM было очень просто перемещать таблицы между различными серверами, если версия MySQL или MariaDB была одинаковой.

InnoDB в настоящее время является движком хранения по умолчанию и является более сложным, так как поддерживает транзакции. Он по-прежнему поддерживает восстановление таблицы из физического файла; эта функция называется переносимые табличные пространства. Необходимо следовать определённой процедуре и есть некоторые ограничения. В основном это эквивалент отделения и повторного подключения таблиц в SQL Server.

Дополнительную информацию см. в InnoDB File-Per-Table Tablespaces.

По умолчанию все файлы таблиц находятся в каталоге данных, который определяется системной переменной datadir. Могут быть исключения, так как файлы таблиц могут быть расположены в другом месте с помощью опций DATA DIRECTORY и INDEX DIRECTORY в CREATE TABLE.

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

Файлы, используемые для разделенных таблиц, отличаются от файлов, используемых для неразделенных таблиц. Подробности см. в разделе Файлы разделов.