MySQL
2 July 2009

Средства создания горячих BackUp`ов MySQL

Доброго времени суток. Недавно я задался вопросом о том, как делать горячие BackUp`ы MySQL-серверов — ниже компиляция из прочитанного. Заранее хочу сказать, что данный пост является скорее большой заметкой, чем полноценной статьёй. Я намеренно уклоняюсь от описания синтаксиса — на эту тему уже немало написано — я же ставил перед собой другую цель — составить краткий обзор основных методов с характерными особенностями:

1. C помощью утилиты mysqldump. Данная программка крайне популярна среди пользователей веб-хостингов. Читая содержимое таблиц, она создаёт файл с SQL-инструкциями для последующего заполнения. Но, как правило, при использовании люди забывают про три ключевых момента:
  • Если не использовать блокировку таблиц, вполне можно получить нарушение логических связей между содержимым таблиц(если в процессе создания копии кто-то решит оставить запись в базе). Здесь косвенно может помочь накатывание части bin-log`a после восстановления из дампа. Так что если по каким-то причинам не блокируете таблицы — применяйте ключ --flush-log — при его использовании старый лог будет закрыт и начат новый. Если кто-то что-то запишет в процессе создания бэкапа — это отразится в начале журнала и вы без проблем перенесёте это изменение в базу. Я бы советовал после окончания бэкапа так же выполнить mysqladmin -flush-logs и положить в бэкап помимо dump-файла предпоследний бинарный журнал.
  • При использовании ключа --lock-tables все таблицы получают блокировку записи, запросы встают в очередь. Это может привести к таймаутам на стороне клиента.
  • Стоит так же иметь ввиду, что подъём(как и создание дампа) большой базы, сохраненной таким образом может изрядно затянуться — в первом случае вы сгребаете из базы все записи, а при обратном варианте — скармливаете их ей. Тем не менее, это один из немногих способов сбэкапить базу из консоли, не имея root-доступа.

Восстановление: путём скармливания dump-файла утилите mysql через STDIN.

2. С помощью утилиты mysqlhotcopy. Еще одно средство из штатного набора MySQL. Идея такова: база ставится на блокировку, после чего средствами cp или scp её файлы копируются в другое место.
  • В отличие от предыдущего варианта сохраняются именно табличные файлы, а не набор инструкций по воссозданию базы, то есть скорость ограничивается лишь операционной системой и вашими железками.
  • По моему разумению — вполне подойдёт для бэкапа больших баз.
  • Работает только с MyISAM и ARCHIVE-таблицами.
  • Выполняется только с сервера на котором лежит база, при условии наличия прав к файлам с таблицами MySQL.

Восстановление: путём копирования сохраненных файлов в каталог данных MySQL.

3. С помощью LVM.
LVM — дополнительный слой между файловой системой и самим жестким диском. Одной из примечательных особенностей LVM является возможность снять на лету образ с тома. Схема действий будет следующей: заблокировать все таблицы базы, снять snapshot с тома, разблокировать таблицы.
  • Данный метод подразумевает предварительный FLUSH с блокировкой всех таблиц(лучше скриптик написать для этих целей).
  • Для применения этого метода необходимо, чтобы данные MySQL(для Linux они скорее всего будут храниться в директории /var/lib/mysql) находились на LVM-томе(желательно отдельном, дабы не бэкапить лишнее).
  • Учитывая, что мы говорим о горячем бэкапе — если вы собираетесь применять данный метод — решение о размещении лучше принять на этапе конфигурации сервера.

Восстановление: путём копирования сохраненных с образа файлов в каталог данных MySQL.

4. С помощью репликации. Несмотря на то, что этот вариант многие считают геморроем, мне такой способ резервирования кажется самым правильным. Логика такого подхода заключается в постоянной синхронизации основного(master) сервера с вторичным(slave). Подробней о репликации можно почитать здесь.
  • Требуется конфигурация отдельного MySQL-сервера. Причем желательно — на автономном железе.
  • Остановка slave-сервера не сыграет никакой роли на master`е — можно делать «холодный» бэкап.
  • В случае падения master`a можно в кратчайшие сроки(было бы разумно автоматизировать этот процесс) перевести всю нагрузку на slave, а после восстановления отсинхронизировать с ним master и вернуть всё на прежние места.
  • Slave может стать по совместительству площадкой для хранения бэкапов.
  • Важно! Существование реплики не освобождает вас от создания бэкапов. Выполнение какого-нибудь DROP'а коснётся обоих серверов!

Восстановление: вывод slave-сервера на место master`a, либо восстановление одним из вышеуказанных методов(в зависимости от выбранного).

Итого: Как видно, у каждого метода есть свои плюсы и минусы: вряд ли есть смысл бэкапить маленький форум с применением реплик, а базы, где счет идёт на гигабайты вряд ли будет удобно поднимать из файлов, сделанных mysqldump`ом — каждый метод хорош в определенных условиях.

На этом этом я заканчиваю своё повествование, надеюсь оно будет вам полезно. Спасибо за внимание и до новых встреч в эфире. :)

+49
27.6k 192
Comments 49
Top of the day