Периодическое резервное копирование MySQL с помощью xtrabackup
Содержание
Введение
Периодическое резервное копирования баз данных позволяет восстановить данные в случае сбоя аппаратного или программного обеспечения, а также в случае ошибок системного администратора. В подобных случаях удобно иметь свежую резервную копию баз данных, готовую к немедленному использованию.
Подобную резервную копию можно сделать при помощи мгновенных снимков файловой системы, обновляя изменившиеся файлы с помощью утилиты rsync. Этот метод резервного копирования в целом совпадает с процедурой настройки реплики MySQL, описанной в статье Резервное копирование и настройка репликации MySQL с помощью LVM.
Также подобную резервную копию можно подготовить с помощью утилиты xtrabackup.
Полное резервное копирование
Создаём полную резервную копию:
# xtrabackup --backup --open-files-limit=100000 --target-dir=/backup/db
Готовим полную резервную копию:
# xtrabackup --prepare --apply-log-only --target-dir=/backup/db
К сожалению, подготовка полной резервной копии с помощью утилиты xtrabackup занимает больше времени, чем обновление резервной копии описанным выше способом.
Обновление полной резервной копии
Утилита xtrabackup позволяет создавать не только полную резервную копию, но и инкрементную, в которую будут помещены только те страницы, которые изменились в текущих файлах баз данных по сравнению с резервной копией. Затем эту инкрементную резервную копию можно использовать для обновления полной резервной копии. Подробнее создание инкрементных резервных копий описано в статье Incremental Backup.
Делаем инкрементальную резервную копию в отдельный каталог:
# xtrabackup --backup --open-files-limit=100000 --target-dir=/backup/inc --incremental-basedir=/backup/db
Применяем инкрементальную резервную копию к полной подготовленной:
# xtrabackup --prepare --apply-log-only --target-dir=/backup/db --incremental-dir=/backup/inc
Однако проблема в том, что для создания инкрементной резервной копии xtrabackup фактически выполняет сравнение файлов в существующей резервной копии с текущими файлами баз данных, что занимает почти столько же времени, сколько требуется для создания полной резервной копии.
Ускорение обновления полной резервной копии
К счастью, для ускорения периодического резервного копирования можно воспользоваться битовыми картами для отслеживания изменённых страниц, которые описаны в статьях XtraDB changed page tracking и XtraDB changed page tracking.
Для этого нужно прописать в файл конфигурации Percona Server опцию:
innodb_track_changed_pages = ON
Для вступления настроек в силу потребуется перезапустить сервер MySQL:
# systemctl restart mysql
При включении этой опции в каталоге с данными начнут создаваться файлы с именами вида ib_modified_log_<seq>_<startlsn>.xdb, где seq - порядковый номер файла, а startlsn соответствует номеру транзакции в журнале изменений. По умолчанию эти файлы будут иметь размер до 100 мегабайт. Чтобы уменьшить их количество, я прописал в файл конфигурации дополнительную опцию:
innodb_max_bitmap_file_size = 512M
К сожалению файлы битовых карт изменённых страниц не удаляются автоматически. Чтобы не засорять диск, нужно периодически удалять файлы, ставшие ненужными.
Удаление устаревших файлов битовых карт
В каталоге с резервной копией имеется файл xtrabackup_checkpoints, в котором имеются строка следующего вида:
to_lsn = 1291135
Число в этой строке соответствует номеру последней транзакции в журнале изменений, которая была зафиксирована в резервной копии. Все файлы битовых карт до этого номера можно удалить без ущерба для создания последующих инкрементных резервных копий.
Для этого после выполнения резервного копирования можно выполнить команду следующего вида:
# awk '/^to_lsn = / { print "PURGE CHANGED_PAGE_BITMAPS BEFORE " $3 ";"; }' /backup/db/xtrabackup_checkpoints | mysql
Скрипт резервного копирования
Для автоматизации резервного копирования описанным выше способом я написал скрипт xtrabackup2.sh. Настроить скрипт можно с помощью файла конфигурации /etc/xtrabackup2.conf, внутри которого имеются следующие настройки:
BACKUP_PATH- путь к каталогу с полной резервной копией,EXCLUDE_TABLES- список таблиц, которые не следует помещать в резервную копию,RSERVER- доменное имя или IP-адрес удалённого сервера, на который нужно скопировать архив с резервной копией,RPATH- путь к файлу архива на удалённом сервере,RUSER- имя пользователя на удалённом сервере,RKEY- путь к приватному ключу пользователя на удалённом сервере для подключения по SSH,DAYS- сколько архивов с резервной копией необходимо сохранять локально.
Внутри каталога, заданного переменной BACKUP_PATH, создаётся подкаталог db с резервной копией базы данных. При обновлении этой резервной копии создаётся каталог inc, в котором размещается инкрементальная резервная копия. Если резервная копия создана или обновлена успешно, то внутри каталога создаётся файл ok. Перед резервным копированием файл ok удаляется, в процессе резервного копирования вывод утилиты xtrabackup помещается в файл log. Если xtrabackup завершился успешно, то файл log удаляется и создаётся файл ok. В противном случае файл log остаётся для выяснения причин проблемы резервного копирования, а файл ok не создаётся. При отсутствии файла ok выполняется полное резервное копирование.
Архив с резервной копией отправляется на удалённый сервер только если определены все четыре опции RSERVER, RPATH, RUSER и RKEY.
Опция DAYS используется только в том случае, если архив с резервной копией не отправляется на удалённый сервер. В этом случае в каталоге BACKUP_PATH поддерживается указанное в переменной количество архивов с содержимым каталога db, имеющих имена вида db_YYYYMMDD.tbz, где символы YYYY соответствуют году, MM - номеру месяца, DD - числу месяца создания архива. Впрочем, логику работы скрипта можно поменять, отредактировав его.