Резервное копирование базы данных MySQL с помощью снимков ZFS

Я обнаружил, что многие сайты говорят именно об этом, но мне не хватает нескольких важных деталей. Основные шаги

• Бегать FLUSH TABLES WITH READ LOCK
• Сделайте снимок ZFS
• Бегать UNLOCK TABLES

Различные источники сообщают, что InnoDB, который я использую, на самом деле не соблюдает FLUSH. Руководство пользователя MySQL отмечает, что есть FLUSH TABLES...FOR EXPORTвариант для использования с InnoDB, но для этого необходимо указывать каждую таблицу отдельно, а не выполнять резервное копирование всей базы данных. Я бы предпочел не указывать каждую таблицу по отдельности, потому что вполне вероятно, что список таблиц будет не синхронизирован с реально существующими таблицами.

Другая проблема, которую я имею, - я планировал сделать что-то подобное mysql -h"$HOST" -u"$USERNAME" -p"$PASSWORD" --execute="FLUSH TABLES WITH READ LOCK". Однако это снимает блокировку сразу после выхода из сеанса. Это имеет смысл, но также довольно раздражает, поскольку мне нужно удерживать блокировку чтения, когда я делаю свой снимок.

Моя другая идея - сделать горячее резервное копирование с помощью такого инструмента, как Percona XtraBackup, и сделать моментальные снимки резервной копии, но я бы предпочел не платить стоимость, чтобы записать все мои данные во второе место, просто чтобы сделать снимок.

Если вы используете InnoDB только для всех таблиц и установите innodb_flush_log_at_trx_commit:

• 1 (содержимое буфера журнала InnoDB записывается в файл журнала при каждой фиксации транзакции, а файл журнала записывается на диск) или,
• 2 (содержимое буфера журнала InnoDB записывается в файл журнала после каждой фиксации транзакции, а файл журнала записывается на диск примерно раз в секунду),

тогда вам не нужны FLUSH TABLES перед созданием снимка, просто запустите снимок ZFS напрямую. InnoDB может восстанавливать данные из журналов транзакций без потери данных.

Ссылка: https://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit

Вам необходима полная блокировка базы данных для последовательного резервного копирования (большинства) баз данных.

В руководстве https://dev.mysql.com/doc/refman/5.5/en/backup-methods.html говорится, что FLUSH TABLES WITH READ LOCK подходит для снимков ZFS.

Создание резервных копий с использованием снимка файловой системы

Если вы используете файловую систему Veritas, вы можете сделать резервную копию следующим образом:

1. Выполните из клиентской программы FLUSH TABLES WITH READ LOCK.
2. Из другой оболочки выполните команду mount vxfssnapshot.
3. С первого клиента выполните UNLOCK TABLES.
4. Скопируйте файлы из снимка.
5. Размонтировать снимок.

Подобные возможности моментальных снимков могут быть доступны в других файловых системах, таких как LVM или ZFS.

Это отчасти смешно , что они вышли из того факта , что вам нужно FLUSH TABLES table_a, table_b, table_c FOR EXPORTдля InnoDB из этих инструкций. Также глупо указывать каждую таблицу таким образом. Но, как говорит EEAA, вы можете создать список таблиц, если начнете резервное копирование довольно легко.

Что касается удержания блокировки, вы должны поддерживать соединение БД во время выполнения снимка

Обычно я использую что-то вроде Perl или другого языка программирования, который может подключаться, блокировать БД и, сохраняя соединение БД, делать снимок, а затем разблокировать и отключить. Это не сложно. Держу пари, что есть инструменты, которые уже делают это, но написать один легко.

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

Я сорвал и адаптировал концептуально простой скрипт на Bash, который я нашел в другом сообщении о сбое сервера от Tobia . Это должно пройти около 90% пути.

mysql_locked=/var/run/mysql_locked

# flush & lock MySQL, touch mysql_locked, and wait until it is removed
mysql -hhost -uuser -ppassword -NB <<-EOF &
    flush tables with read lock;
    delimiter ;;
    system touch $mysql_locked
    system while test -e $mysql_locked; do sleep 1; done
    exit
EOF

# wait for the preceding command to touch mysql_locked
while ! test -e $mysql_locked; do sleep 1; done

# take a snapshot of the filesystem, while MySQL is being held locked
zfs snapshot zpool/$dataset@$(date +"%Y-%m-%d_%H:%M")

# unlock MySQL
rm -f $mysql_locked

Здесь используемая mysqlвами команда запускается в фоновом режиме и касается файла. Он ждет в фоновом режиме, чтобы файл исчез, прежде чем выйти и, таким образом, разблокировать таблицы. Тем временем основной сценарий ожидает, пока файл не существует, затем создает снимок и удаляет файл.

Файл, на который указывает указатель, $mysql_lockedдолжен быть доступен для обеих машин, что вы должны сделать достаточно легко, так как они могут обращаться к общему набору данных (хотя они могут использовать разные пути, и вы должны учитывать это).

Для myisam вам нужны FLUSH TABLES WITH READ LOCK, потому что это не ведение журнала.

Вам вообще ничего не нужно для innodb, IMO, потому что это ведение журнала. В любом случае это будет согласованно, просто автоматически откатывается журнал, если что-то происходит в атомный момент, когда вы делаете снимок.

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

Это моё решение, как создать снимок ZFS с сохранением блокировки:

mysql << EOF
    FLUSH TABLES WITH READ LOCK;
    system zfs snapshot data/db@snapname
    UNLOCK TABLES;
EOF