Как работает Mariabackup

Это описание различных этапов Mariabackup, их функций и необходимости.

Обратите внимание, что некоторые пункты помечены как TODO; это элементы, над которыми мы работаем, и они будут включены в следующую версию Mariabackup.

Этапы выполнения

Фаза инициализации

• Подключение к экземпляру mysqld, выявление важных переменных (datadir, InnoDB pagesize, ключи шифрования, плагин шифрования и т. д.)
• Сканирование каталога базы данных, datadir, поиск табличных пространств InnoDB, загрузка табличных пространств (по сути, это «открытие» в смысле InnoDB)
• Если используется --lock-ddl-per-table:
  • Выполнение блокировок MDL для табличных пространств InnoDB, которые мы хотим скопировать. Это необходимо для обеспечения отсутствия операций ALTER, RENAME, TRUNCATE или DROP TABLE для любых таблиц, которые мы хотим скопировать.
  • Это реализовано с помощью:

BEGIN
For each affected table
SELECT 1 from <table> LIMIT 0

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

Обработка журнала переигрывания

Запуск отдельной нити в Mariabackup для копирования журнала переигрывания InnoDB (ib_logfile*).

• Это необходимо для записи всех изменений, внесённых во время выполнения резервного копирования. (Журнал переигрывания логически представляет собой единственный циклический файл, разделённый на файлы innodb_log_files_in_group.)
• Журнал также используется для обнаружения использования операций truncate или online alter table.
• Предполагается, что нить копирования сможет успевать за сервером. Она всегда должна успевать, если журнал переигрывания достаточно велик.

Фаза копирования табличных пространств InnoDB

• Копирование всех выбранных табличных пространств, файл за файлом, в отдельных нитях в Mariabackup без участия сервера mysqld.
• Это специальное «осторожное» копирование, оно проверяет целостность на уровне страницы, проверяя контрольную сумму.
• Файлы не соответствуют состоянию в определённый момент времени, так как данные могут изменяться во время копирования.
• Идея заключается в том, что восстановление InnoDB сделает его согласованным в определённый момент времени.
• Копирование файлов журнала Aria (TODO)

Создание согласованной точки резервного копирования

• Выполнение команды FLUSH TABLE WITH READ LOCK. Это значение по умолчанию, но может быть опущено с помощью параметра -–no-lock. Причина, по которой FLUSH необходима, заключается в обеспечении того, чтобы все таблицы находились в согласованном состоянии в точный момент времени, независимо от используемого движка хранилища.
• Если используется --lock-ddl-per-table, и есть ожидающий запрос пользователя для MDL, запрос пользователя будет убит для разрешения тупика. Обратите внимание, что это только запросы типа ALTER, DROP, TRUNCATE или RENAME TABLE. (MDEV-15636)

Последняя фаза копирования

• Копирование .frm, MyISAM, Aria и других файлов движка хранилища
• Если используется MyRocks, создание контрольной точки rocksdb с помощью команды "set rocksdb_create_checkpoint=$rocksdb_data_dir/mariabackup_rocksdb_checkpoint ". Результатом является каталог с жёсткими ссылками на файлы MyRocks. Скопируйте каталог контрольной точки в резервную копию (или создайте жёсткие ссылки в каталоге резервной копии, если он находится на той же раздела, что и каталог данных). Удалите каталог контрольной точки.
• Копирование таблиц, созданных во время выполнения резервного копирования, и переименование файлов, изменённых во время резервного копирования (с MDEV-16791)
• Копирование остальной части журнала переигрывания InnoDB, остановка нити копирования журнала переигрывания
• Копирование изменений в файлы журнала Aria (они являются только для добавления, поэтому это легко сделать) (TODO)
• Запись некоторых метаданных (позиция binlog)

Освобождение блокировок

• Если была выполнена FLUSH TABLE WITH READ LOCK:
  • выполнить: UNLOCK TABLES
• Если было выполнено --lock-ddl-per-table:
  • выполнить COMMIT

Обработка таблиц журнала (TODO)

• Если таблицы журнала существуют:
  • Взять блокировку MDL для таблиц журнала
  • Скопировать часть таблиц журнала, которые не были скопированы ранее
  • Разблокировать таблицы журнала

Примечания

• Если FLUSH TABLE WITH READ LOCK не используется, тогда только таблицы InnoDB будут согласованными (не таблицы привилегий в базе данных mysql или бинарный журнал). Точка резервного копирования зависит от содержимого журнала переигрывания в самой резервной копии.