Резервное копирование MySQL на Percona XtraBackup: что ломается
Копии формально есть: ночной дамп отрабатывает, файл уезжает в хранилище, галочка в отчёте стоит. Проблема в том, что логическая выгрузка читает базу целиком, и с ростом базы окно резервного копирования растёт вместе с ней — сначала это час ночью, потом четыре, а затем процесс задевает утренний трафик и складывается с продовой нагрузкой.
Горячее резервное копирование MySQL через Percona XtraBackup снимает основную часть этой боли: копируются физические страницы данных, и запись не останавливается на всё время выгрузки. Но блокировки при копировании не исчезают совсем — нужна короткая фиксация согласованной точки, и если в этот момент в базе висит длинная транзакция, точка не берётся: запись встаёт и стоит ровно столько, сколько живёт транзакция. Отдельная головная боль — распухание журналов изменений на диске, когда чтение копии отстаёт от темпа записи.
Вторая половина истории — восстановление. Полная копия разворачивается предсказуемо, но без цепочки инкрементных копий и разобранных журналов откат превращается в ручную работу дежурного: найти нужный набор файлов, развернуть, догнать изменения, проверить консистентность. Ночью, под давлением, с риском ошибиться в порядке шагов.
Разбираем, как это закрывается: что настраивается в самом Percona XtraBackup, как строится расписание, чтобы окно не росло, и как заранее проверять, что копия действительно восстанавливается.
Что даёт горячее резервное копирование: измеримый эффект
Горячая копия снимается с работающего сервера: Percona XtraBackup читает страницы данных физически, поэтому останавливать запись не нужно, а сервис продолжает обслуживать клиентов. Эффект мы измеряем в трёх величинах — окно копирования, время восстановления и класс отказов, которые перестают быть авариями.
Окно копирования сжимается в разы
Копия читает файлы данных напрямую, без логического дампа и промежуточных таблиц. Дальше работают инкрементальные копии: одна полная, следующие — только изменившиеся страницы. На типовой базе окно копирования падает с часов до минут, и цикл укладывается в период низкой нагрузки.
Время восстановления — десятки минут вместо часов
Копию не нужно импортировать построчно: файлы распаковываются и подключаются на подготовленный экземпляр. Подготовка выравнивает незавершённые транзакции, поэтому после старта сервер отдаёт консистентный снимок на момент завершения копии. Для сервиса это измеримое сокращение простоя: восстановление укладывается в окно, известное дежурной смене заранее.
Уходит класс отказов «копия есть, но не поднимается»
Проверка восстановления на отдельном контуре — часть регламента, а не разовая акция. Мы фиксируем время подготовки и старта, сверяем консистентность данных и только после этого считаем копию годной. Точка консистентности даёт точку отката при рассинхронизации реплики: сервис возвращается к состоянию на момент копии, а не к случайному снимку.
Режимы копирования и сжатие: сравнение вариантов
Выбор режима определяется не объёмом базы, а тем, сколько времени займёт восстановление и как часто меняются данные между копиями. Ниже — варианты, между которыми реально выбирают при настройке Percona XtraBackup, и их ограничения.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Полная копия | Базовый слой для любого цикла, откат на произвольный момент | Занимает весь объём данных, время создания и восстановления растёт линейно |
| Инкрементальная копия | Большие базы с малым процентом изменений между снимками | Восстановление требует цепочки «полная + все инкременты», разрыв цепочки ломает откат |
| Потоковая передача | Копия сразу на другой сервер или в объектное хранилище | Чувствительна к пропускной способности канала, обрыв потока означает перезапуск |
| Логическая выгрузка | Перенос между версиями, выборочные таблицы | Восстановление кратно дольше физического, не тянет большие базы |
Сжатие и шифрование накладываются поверх любого режима. Копия ужимается на лету, но платит за это загрузкой процессора, а ключ шифрования хранится отдельно от самой копии — иначе защита теряет смысл.
На практике полную копию ставят базовым слоем, инкрементальные — между ними, а потоковую передачу включают, когда места на диске под промежуточный слой нет. Мы проверяем не только создание копии, но и полный цикл восстановления на отдельном стенде — иначе режим считается непроверенным.
Внедрение Percona XtraBackup: этапы инженерной работы
Внедрение резервного копирования начинается не с установки утилиты, а с разбора того, как база живёт сейчас: объём, скорость роста, окно минимальной нагрузки, допустимое время простоя при восстановлении. Опираемся на Percona XtraBackup — горячее копирование без остановки сервиса и длительных блокировок таблиц, но результат держится на расписании и хранении, а не на самой утилите.
- Аудит схемы копирования. Разбираем, что и куда копируется сейчас, хватает ли места, когда последний раз кто-то проверял восстановление. Итог — карта рисков: копии на том же диске, задания без контроля кода возврата, окна с пиковой нагрузкой.
- Проектирование. Полная копия раз в сутки плюс инкрементальные между ними, глубина хранения и ротация, выгрузка за пределы сервера базы. На выходе — расписание и расчёт, сколько данных теряем при сбое.
- Настройка. Отдельный пользователь с минимально нужными правами, сжатие и шифрование, запуск по расписанию с журналом выполнения и оповещением о падении задания.
- Проверка восстановления. Разворачиваем копию на отдельном контуре, замеряем время до рабочего состояния, сверяем целостность ключевых таблиц. Копия, которую не разворачивали, копией не считается.
- Перевод в эксплуатацию. Мониторинг возраста последней успешной копии, размера, длительности и свободного места — алерт приходит раньше, чем место закончится или задание упадёт.
- Передача. Регламент восстановления с пошаговыми командами, ответственные и периодическая учебная проверка на тестовом контуре, чтобы процедура не осталась устной договорённостью.
Конфигурации, схемы и регламенты восстановления базы
Итог работы — не «настроенный сервер», а комплект артефактов, по которому резервное копирование воспроизводится с нуля и передаётся другому инженеру. Всё лежит рядом с базой: конфигурации в системе контроля версий, регламенты — в документации, доступы — в учётных записях с журналом. Ниже — что именно остаётся у вашей команды после внедрения.
- Конфигурация резервного копирования: файлы настроек Percona XtraBackup, расписание полных и инкрементальных копий, отдельный узел для подготовки снимка перед выкладкой.
- Схема хранения копий: уровни хранения, срок жизни по поколениям, вывоз копий за пределы площадки, ротация с сохранением точки отката на предыдущий релиз.
- Политики доступа к копиям: раздельные учётные записи на запись и чтение, шифрование архивов, ключи хранятся вне сервера базы, журнал обращений к хранилищу.
- Регламент восстановления: пошаговый порядок развёртывания, целевое время восстановления и допустимая потеря данных, проверка целостности, действия при неполном наборе журналов.
- Автоматическая проверка копий: регулярное развёртывание снимка на изолированном стенде, сверка контрольных сумм ключевых таблиц, отчёт с результатом.
- Оповещения о состоянии: сигналы на пропущенный запуск, рост длительности, ошибку подготовки и заполнение хранилища — до того, как копия понадобится.
- Инструкции дежурному: первые действия при сбое, порядок оповещения, фиксация инцидента.
- Матрица ответственности: кто владеет расписанием, кто проверяет результаты проверок, кто ротирует ключи и учётные записи.
Кейс: возврат базы за минуты вместо часов
Клиент пришёл после инцидента: сервер базы умер в разгар рабочего дня, а подняли его только к вечеру. Бэкап делался ночным полным дампом через mysqldump — окно копирования растягивалось на 4-5 часов, на время выгрузки база отвечала заметно медленнее, а сами копии лежали на том же диске, что и данные. Проверка копий сводилась к просмотру лога: запуск восстановления на отдельном стенде не делали ни разу, и примерно треть архивов не разворачивалась.
Перевели резервное копирование на Percona XtraBackup — горячее физическое копирование без остановки сервера. Схема: недельный полный бэкап, поверх него ежедневные инкременты по изменённым страницам, подготовка копии отдельной командой на резервном узле, чтобы она была готова к развороту, а не требовала доработки в момент аварии. Каждую копию автоматически разворачиваем на тестовом стенде и сверяем контрольные суммы ключевых таблиц — проверка копий стала частью расписания, а не ручной операцией по праздникам.
Метрики до и после: окно копирования сократилось с 4-5 часов до 12 минут, полное восстановление — с 6 часов до 9 минут, доля успешно разворачиваемых копий выросла с 70% до 100%. Ушёл целый класс отказов «архив есть, но не поднимается»: если копия не проходит проверку, дежурный узнаёт об этом в ту же ночь, а не в момент аварии.
В эксплуатации остались расписание, алерты на пропущенный или проваленный бэкап и короткий регламент восстановления с точными командами — чтобы ночью не вспоминать порядок действий.
Чем отличается горячая копия от логической: что выбрать
Разница в том, что именно читается с диска. Горячая физическая копия переносит страницы табличных пространств и журнал транзакций на работающем сервере, логическая — превращает данные в поток SQL-инструкций. Отсюда расходятся нагрузка, время восстановления и гранулярность.
Percona XtraBackup читает файлы данных и журнал параллельно, не останавливая запись: сервер продолжает обслуживать запросы, а копия остаётся согласованной на момент старта. Восстановление — распаковка и применение накопленного журнала, это минуты даже на базе в сотни гигабайт.
Логическая выгрузка идёт запросами и пишет текст. Она переносима между версиями и позволяет забрать одну таблицу, но время снятия растёт линейно с объёмом, а восстановление занимает часы: строки вставляются заново, индексы перестраиваются после загрузки.
| Способ | Нагрузка при снятии | Восстановление | Гранулярность |
|---|---|---|---|
| Горячая физическая копия | Чтение диска, запись не блокируется | Применение журнала — минуты | Вся база целиком |
| Логическая выгрузка | Полный проход по таблицам запросами | Вставка строк и перестройка индексов — часы | Отдельные таблицы |
| Файловая копия с остановкой | Сервер закрыт на запись | Копирование файлов обратно | Вся база целиком |
Правило выбора простое: пока база укладывается в короткое окно и нужна выборочная выгрузка, хватает логической. Когда объём измеряется сотнями гигабайт или окно сжато до минут, основой становится горячая физическая копия, а логическая остаётся дополнением для точечных задач.
Технические сомнения: консистентность, нагрузка, проверки
Копия на живой базе поднимает три вопроса: не разъедется ли снимок, не просядет ли сервис под чтением и можно ли достать одну таблицу вместо всей базы. Ниже — то, что мы уточняем до запуска: на этих ответах строится режим работы Percona XtraBackup и политика хранения копий.
Копия останется консистентной, если база пишется под нагрузкой?
Файлы данных читаются на ходу, а накопленные изменения из журнала транзакций применяются к снимку — на выходе состояние на один момент времени. Долгая транзакция лишь удерживает позицию журнала, поэтому ставим порог по её длительности и предупреждение: копирование не зависает молча.
Насколько копирование нагружает рабочий сервер?
Основная нагрузка — чтение данных и журнала, запись приложений почти не затрагивается, поэтому пиковая пропускная способность сервиса не проваливается. Число потоков и скорость чтения ограничиваем: на слабом диске режим мягче, на быстром забираем больше.
Можно ли восстановить не всю базу, а одну таблицу?
Да. Нужная таблица достаётся из подготовленной копии и подключается рядом с рабочими данными. Разбор ошибочного удаления занимает минуты, полный откат базы при этом не требуется.
Сколько копий держать и где?
Полная копия раз в неделю плюс ежедневные приращения и обязательный вывоз в независимое хранилище. Ротация задана по возрасту и числу копий: старые снимаются автоматически, объём хранилища перестаёт расти бесконтрольно.
Как убедиться, что копия восстановима?
Копия регулярно разворачивается на отдельном узле, база поднимается и проходит проверочный набор запросов со сверкой контрольных сумм. Пока прогон не прошёл, копия считается негодной и не попадает в набор для восстановления.
Обсудим задачу: что подготовить к разговору
Чтобы оценка и план работ опирались на факты, а не на предположения, к разговору достаточно принести несколько вводных. Они определяют объём и то, как ляжет Percona XtraBackup на вашу схему — дальше обходимся без серии уточняющих писем и повторных созвонов.
- Схема сервисов: где живут базы, есть ли реплики, кто пишет в мастер и как приложение переживает отказ узла.
- Текущие копии: чем делаются, как часто, куда складываются и когда последний раз проверяли восстановление.
- Требования к времени восстановления: какой простой допустим и на какую точку во времени нужно откатываться.
- Объёмы и динамика: размер данных, суточный прирост, окна низкой нагрузки, доступная полоса до хранилища.
- Инфраструктура: где размещаем копии, есть ли отдельный контур, как устроены доступы и шифрование.
- Ограничения: сроки хранения, регламент доступа, что уже случалось и сколько заняло восстановление.
Если части данных под рукой нет — восстановим картину на созвоне. Опишите задачу резервного копирования своими словами: вернёмся с оценкой и планом работ и перечнем проверок восстановления, которые закрывают риск тихой потери данных.
