Настройка резервного копирования MySQL через mysqldump

Почему mysqldump перестаёт спасать на растущей базе

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

Коварство в том, что сбой копирования не всегда заметен. Процесс возвращает успешный код, файл на месте, размер ненулевой — отчёт зелёный, и дежурный не идёт смотреть, что выгрузка оборвалась на середине или снята в момент активной записи. Ошибка вскрывается ровно тогда, когда нужно восстановление базы данных: импорт доходит до середины, падает на повреждённом участке, а у вас нет ни целой копии, ни времени разбирать, каких транзакций не хватает.

Цена такого сценария — не неудачная команда, а отсутствие точки отката. Восстановление перестаёт быть предсказуемой операцией на десятки минут и превращается в ручной разбор, пока сервис лежит. Резервное копирование MySQL на растущей базе требует другого режима и проверки, что копия действительно восстанавливается, — разбираем, как это закрывается.

Что даёт управляемое резервное копирование MySQL

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

Предсказуемое время восстановления

Мы заранее определяем, за какое время база поднимается из копии, и держим это время стабильным: точка восстановления известна, сценарий развёртывания отработан и повторяется без импровизации в момент аварии. Регламент прогоняется на отдельном стенде — от поднятия структуры до переключения сервиса на восстановленный узел. Стоимость простоя сервиса становится предсказуемой: окно недоступности известно заранее, а не выясняется по ходу инцидента.

Устранённый класс отказов: тихие сбои копирования

Тихий сбой — это когда задача завершается без ошибки, а копия оказывается неполной или пустой, и выясняется это в самый неудачный момент. Поэтому проверка резервных копий встроена в процесс: структура и размер дампа сверяются с ожидаемыми, выполняется тестовое восстановление, а мониторинг копирования сигналит о пропущенном запуске, аномальной длительности или расхождении контрольных сумм. Класс отказов «повезло — не повезло» превращается в обычный алерт, а восстановление перестаёт быть проверкой на прочность.

mysqldump, физическая копия или реплика: что выбрать

Логический дамп — это SQL-текст: слепок переносится между версиями и платформами, из него достаётся одна таблица, его можно прочитать и выправить руками. Плата за это — восстановление идёт запрос за запросом, и на большой базе оно занимает часы. Физическая копия снимает файлы данных и журналов целостно и поднимается быстро, реплика держит постоянный дубль для отказоустойчивости и отчётов.

Выбор определяется тем, что критичнее: переносимость, время подъёма или горячая замена. Ниже — границы каждого варианта.

Ограничения логического дампа на больших таблицах

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

Когда одного способа недостаточно

На практике способы совмещают: дамп по расписанию даёт переносимый слепок и выборочное восстановление, физический снимок — быстрый подъём всей базы, реплика — отказоустойчивость и отчётные запросы. Тогда у каждого класса отказов есть свой инструмент: испорченная строка лечится дампом, упавший узел поднимается из снимка.

Порядок работ: от инвентаризации баз до регламентов

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

Инвентаризация и приоритеты баз

1. Собираем перечень баз: размер, тип таблиц, скорость роста, связанные сервисы и владельцы.
2. Размечаем приоритеты — критичные для выручки, справочные, временные. Для каждой группы свой срок хранения и частота копий.
3. Выбираем схему резервного копирования: полный дамп плюс журналы изменений для восстановления на момент сбоя, отдельная выгрузка для крупных таблиц.
4. Настраиваем расписание копирования в окна вне пиковой нагрузки, с выгрузкой на отдельный том, сжатием, шифрованием и ротацией по правилу хранения.
5. Автоматизируем запуск: код возврата, уведомление при сбое, запись в журнал каждого прогона и контроль размера файла копии.

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

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

После этого расписание считается рабочим — документируем его и пересматриваем при появлении новых баз.

Что остаётся у вашей команды после внедрения

После внедрения у команды остаётся не набор разовых действий, а воспроизводимый контур резервного копирования. Любой инженер поднимает копию по инструкции, не собирая контекст из переписки, а mysqldump отрабатывает по расписанию и сам сообщает о сбое. Передаём всё, что нужно для самостоятельной эксплуатации и спокойной передачи задачи новому сотруднику.

Скрипты и конфигурации копирования

• Скрипты запуска с логированием кода возврата: видно, что именно упало и на каком шаге.
• Конфигурация копирования: перечень баз, расписание, глубина слепка, параметры консистентности.
• Политика хранения копий: сколько держим суточных, недельных и месячных наборов и когда чистим старое.
• Задания в планировщике с защитой от перекрытия прогонов, чтобы две копии одной базы не шли одновременно.
• Автопроверки после прогона: размер архива, контрольная сумма, тестовое восстановление в отдельную схему.
• Схема инфраструктуры: где лежат копии, как переносятся на резервный узел, какие сервисы задействованы.

Документация и регламенты восстановления

• Документация резервного копирования: что копируется, в каком объёме, куда попадает и как долго живёт.
• Регламент восстановления: пошаговый порядок подъёма из архива с точками, где нужно решение инженера.
• Инструкция по развёртыванию копии на другой сервер и на другую ветку сервера баз.
• Целевые сроки восстановления и допустимый объём потери данных, зафиксированные с заказчиком.
• Журнал учений: даты проверок восстановления, что сработало, что поправили после.
• Памятка дежурному: что делать при отказе ночью, куда смотреть в первую очередь и кого подключать.

Из практики: восстановление базы интернет-магазина

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

Как было: копия есть, восстановление не проверялось

Дамп снимался без ключа --single-transaction: пока утилита читала таблицы, в них продолжали идти записи, и согласованность данных на выходе никто не гарантировал. Отдельно выяснилось, что часть копий обрывалась по таймауту, а отчёт об успехе приходил по факту запуска, а не завершения. Авария на основном сервере обернулась простоем в шесть часов: два ушли на поиск актуального файла и разбор ошибок, ещё четыре — на ручную сверку заказов, платежей и остатков, разошедшихся между таблицами.

Как стало: восстановление по расписанию и на стенде

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

Сам дамп перевели на --single-transaction со сжатием: размер артефакта упал втрое, срок хранения вырос, откат на предыдущий срез остаётся возможным. Время восстановления базы сократилось с шести часов до сорока минут, большая часть пути проходит по прогнанному на стенде сценарию.

mysqldump уже настроен, а восстановление не проверялось?

Да, копирование работает — но mysqldump, который ни разу не разворачивали, это не резервная копия, а надежда. Риски непроверенных копий почти никогда не в том, что файл не создаётся: он создаётся, только неполным — без триггеров, хранимых процедур и событий, либо со срезом таблиц, разъехавшимся при активной записи. Выясняется это ровно в тот момент, когда база нужна целиком, а рядом нет ничего, кроме дампа неизвестного качества.

Действующее копирование при этом ломать не нужно — проверка восстановления дампа ставится поверх. Свежий архив разворачивается в изолированный экземпляр, после чего сверяются состав объектов схемы, число строк по ключевым таблицам и контрольные суммы по нескольким крупным таблицам. Расхождение даёт оповещение до того, как испортится следующий архив, а заодно измеряется реальное время восстановления — цифра, от которой зависит допустимый простой.

Сам дамп снимается в согласованном режиме: --single-transaction для InnoDB и флаги --routines --triggers --events, иначе восстановление формально проходит, а часть логики в схеме отсутствует. Передача копий идёт на отдельную площадку или во внешнее хранилище с шифрованием и ротацией по сроку — копия, лежащая на том же диске, что и база, отказа не переживает.

План перехода строится так, чтобы ничего не останавливать: сначала включаем ежедневную проверку на текущих архивах и наблюдаем, затем добавляем выгрузку за пределы площадки и только потом меняем расписание и параметры самого копирования. На выходе — восстанавливаемый дамп с известным временем развёртывания и процедура отката, которую можно показать и повторить на любой копии.

Частые технические сомнения по копированию MySQL

Основное сомнение — нагрузка от копирования: дамп читает все страницы таблиц и на большой базе надолго занимает диск. Режим согласованного снимка в mysqldump не блокирует запись в InnoDB, а пауза между порциями и пониженный приоритет процесса убирают пик по дисковым операциям — копия снимается дольше, но рабочая база не проваливается по задержкам.

Второй слой вопросов — где хранить копии, как ротировать и с какой частотой запускать.

Как хранить и ротировать копии?

Полный дамп раз в сутки, между ними — журналы для восстановления на точку во времени. Ротация оставляет последние несколько копий и месячные: хранилище не растёт бесконечно, а откат на нужный день остаётся возможным.

Можно ли снимать копию с реплики?

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

Что делать с большими таблицами?

Их выносят отдельными потоками или разбивают по диапазонам ключа: одна гигантская таблица в общем дампе растягивает окно копирования и усложняет восстановление. Сжатие потока на лету уменьшает артефакт.

Обсудим вашу задачу с резервным копированием

Чтобы вернуться с оценкой работ и планом резервного копирования, нам нужен короткий срез по инфраструктуре: где живут базы, какой объём данных и что критично сохранить при сбое. Обычно хватает одного разговора с инженером — дальше мы считаем объём работ и присылаем документ с расписанием и порядком проверки копий.

Что стоит подготовить к обсуждению задачи:

• Список баз и серверов: сколько экземпляров обслуживаем, где размещены, есть ли реплики.
• Объём и характер данных: полный размер, доля таблиц разных типов, крупные бинарные поля.
• Требования к точке восстановления: сколько данных допустимо потерять при аварии и за какое время база должна вернуться в строй.
• Окно копирования: когда нагрузка минимальна и можно ли снимать полный дамп mysqldump без влияния на отзывчивость сервиса.
• Хранение копий: локальные диски, отдельный сервер или объектное хранилище, сколько копий держим и на какой срок.
• Регламент проверки: как часто разворачиваем копию на тестовом контуре и кто подтверждает результат.
• Доступы и ограничения: сервисные учётные записи, сетевые правила, требования к шифрованию выгрузок.
• Текущий процесс: что уже настроено, какие сбои были, нужно ли переносить существующие скрипты.
• Передача на поддержку: кто из команды принимает регламент и нужен ли инструктаж дежурных.

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