Бэкапы MySQL быстро: mydumper/myloader против mysqldump, практики и бенчмарки

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

Почему mysqldump тормозит на больших базах

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

• Однопоточный дамп: один поток читает, один пишет. Диск и CPU часто простаивают.
• Долгое восстановление: миллионы INSERT подряд через одно соединение — худший сценарий для InnoDB.
• Блокировки: без --single-transaction возможен FLUSH TABLES WITH READ LOCK и заморозка записи (особенно больно для OLTP).
• Долгий парсинг единого файла при восстановлении, отсутствие гибкого распараллеливания.

Если вы используете только mysqldump и никогда не упирались во время бэкапа и восстановления — вероятно, база ещё мала или бэкапы делаются не на пике нагрузки.

Что такое mydumper/myloader и почему они быстрее

mydumper — параллельный дампер для MySQL/MariaDB, myloader — его парный инструмент для параллельного восстановления. По сути, вместо одного огромного SQL-файла вы получаете каталог с множеством файлов по таблицам и чанкам. Это позволяет:

• Читать разные таблицы (и разные диапазоны одной таблицы) одновременно в нескольких потоках.
• Сохранять консистентный снимок через транзакцию (REPEATABLE READ) без глобальной блокировки записи.
• Сильно ускорять восстановление: каждую таблицу (или её чанк) грузят отдельные потоки.
• Точечно переиспользовать части дампа (например, восстановить одну таблицу).

Ключевая идея — параллелизм плюс грамотная нарезка больших таблиц по первичному ключу или размеру файла. В результате производительность упирается в реальную пропускную способность диска/CPU и сетевые лимиты, а не в одно «бутылочное горлышко» процесса.

Когда выбирать mysqldump, а когда mydumper

• Малые базы (до 2–5 ГБ), редкие изменения: mysqldump остаётся достаточно быстрым и удобным.
• Средние и крупные базы (10–500 ГБ): почти всегда выигрывает mydumper/myloader, особенно на SSD и при наличии нескольких CPU-ядер.
• Сильный OLTP-трафик 24/7: параллельный дамп с транзакционной консистентностью и ограничением «длинных запросов» у mydumper даёт меньше побочных эффектов.
• MyISAM и смешанные движки: аккуратнее с блокировками. mydumper снижает влияние транзакциями для InnoDB, но для MyISAM блокировки неизбежны.

Физические бэкапы (на уровне файлов) хороши на очень больших объёмах, но логические дампы остаются удобными для точечного восстановления таблиц, миграций и тестов.

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

mysqldump

• Используйте --single-transaction для InnoDB, чтобы избежать глобальных блокировок.
• Добавляйте --routines --triggers --events, иначе вы потеряете процедуры/события/триггеры.
• Для PITR сохраняйте координаты бинарных логов: --master-data=2 встроит их в дамп как комментарий.
• Сжимайте потоком, чтобы не плодить гигантские файлы: ... | gzip -1 > dump.sql.gz снижает I/O.
• Исключайте служебные базы: --ignore-table=mysql.slow_log --ignore-table=mysql.general_log и т.п.

mysqldump --single-transaction --routines --triggers --events --master-data=2 --hex-blob --default-character-set=utf8mb4 --databases appdb authdb | gzip -1 > /backups/2025-10-21.sql.gz

mydumper

• Включайте транзакционную консистентность, чтобы обойтись без глобальной блокировки (снимок на уровне REPEATABLE READ).
• Используйте многопоточность: 4–8 потоков — хорошая стартовая точка для 4–8 vCPU.
• Для крупных таблиц задайте нарезку по размеру файла или строкам, чтобы все потоки работали равномерно.
• Сохраняйте метаданные с координатами binlog/GTID — они попадут в файл metadata для PITR.
• Включайте дамп триггеров/процедур/событий: иначе восстановление будет неполным.

mydumper --host=127.0.0.1 --user=backup --password='secret' --threads=8 --compress --outputdir=/backups/myd-2025-10-21 --triggers --routines --events --chunk-filesize=256 --long-query-guard=5 --kill-long-queries --verbose=3

Флаги могут отличаться по версиям, но общий смысл такой: максимальный параллелизм без токсичных блокировок, плюс метаданные для дальнейшего PITR.

Восстановление: ускоряем по максимуму

mysqldump

Классический путь — распаковать и скормить SQL-файл серверу. Ускорения достигаются настройками InnoDB и пакетными вставками.

zcat /backups/2025-10-21.sql.gz | mysql --default-character-set=utf8mb4

• На время восстановления можно временно увеличить innodb_buffer_pool_size, уменьшить innodb_flush_log_at_trx_commit до 2 (с пониманием рисков) и отключить binlog на стенде (если это не прод).
• Следите за unique_checks и foreign_key_checks: в дампе они, как правило, уже оптимизированы опциями mysqldump.

myloader

myloader умеет загружать данные параллельно, полностью раскрывая преимущества раздельных файлов дампа.

myloader --directory=/backups/myd-2025-10-21 --threads=8 --overwrite-tables --disable-foreign-key-checks --verbose=3

• --overwrite-tables полезен при повторном восстановлении.
• --disable-foreign-key-checks ускоряет загрузку зависимых таблиц (порядок вставок не всегда идеален).
• --queries-per-transaction настраивает размер транзакций при восстановлении.

Для тестов восстановления удобно поднимать отдельный стенд на выделенном VDS с теми же версиями MySQL и параметрами InnoDB, чтобы реплицировать производительность и выявить узкие места до инцидента.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Бенчмарки: методология и цифры

Железо: 4 vCPU, 8 ГБ RAM, NVMe SSD. Софт: MySQL 8.0, mysqldump из дистрибутива, mydumper/myloader свежей стабильной версии. База: ~80 ГБ InnoDB (5 крупных таблиц по 10–20 ГБ, ~40 мелких), нормальная OLTP-нагрузка. Тестировали ночью, но с живым трафиком. Дамп на локальный диск, восстановление на отдельный инстанс той же конфигурации.

Сценарии

1. mysqldump: --single-transaction --routines --triggers --events --master-data=2, вывод в gzip -1.
2. mydumper: 4 потока, --compress, --chunk-filesize=256.
3. mydumper: 8 потоков, те же параметры.

Результаты (средние из 3 прогонов)

• Дамп 80 ГБ:
  • mysqldump: ~2 ч 40 мин, итоговый архив ~42 ГБ (сжатие ~1.9×).
  • mydumper 4 потока: ~54 мин, общий объём ~41 ГБ.
  • mydumper 8 потоков: ~37 мин, общий объём ~41 ГБ.
• Восстановление 80 ГБ:
  • mysql < dump.sql: ~3 ч 55 мин.
  • myloader 4 потока: ~1 ч 35 мин.
  • myloader 8 потоков: ~1 ч 8 мин.
• Нагрузка на прод во время дампа:
  • mysqldump: рост p95 задержек запросов на 20–35% на отдельных эндпоинтах.
  • mydumper: 4 потока — +8–12%, 8 потоков — +12–18% (за счёт более краткого окна дампа суммарное влияние ниже).

Главный выигрыш в реальной жизни — время восстановления. Параллельный myloader сокращает RTO в разы по сравнению с одиночным mysql < dump.sql.

Гид по ключевым настройкам

Для mydumper

• --threads: начните с количества vCPU; следите, чтобы не забить диск random I/O.
• --chunk-filesize или --rows: равномерная нарезка больших таблиц, чтобы все потоки работали.
• --long-query-guard и --kill-long-queries: защита от подвисающих SELECT-ов, которые портят окно консистентности.
• --compress: снижает I/O, почти всегда окупается на современных CPU.
• --no-schemas / --no-data: выборочно дампить только структуру или только данные.
• --triggers --routines --events: не забывайте про полный перенос логики.

Для myloader

• --threads: баланс между CPU и I/O; на быстрых NVMe 8–16 потоков часто оптимально.
• --disable-foreign-key-checks: ускоряет вставки, включайте, если порядок загрузки не гарантирован.
• --queries-per-transaction: 500–2000 — частая настройка для снижения нагрузки на REDO и уменьшения блокировок.
• --overwrite-tables: удобен при повторных прогонах стенда.

Для mysqldump

• --single-transaction: must-have для InnoDB.
• --master-data=2: координаты binlog для PITR в комментариях.
• --hex-blob: корректная выгрузка бинарных полей.
• --set-gtid-purged=OFF: при необходимости избежать автоуправления GTID в дампе (зависит от вашей топологии).

Типичные ошибки и как их избежать

• Забыли про процедуры/события/триггеры. Итог — функционал теряется после восстановления. Решение: всегда добавляйте соответствующие флаги.
• Не исключили шумные или служебные таблицы. Дамп раздулся, восстановление долгое. Решение: используйте --ignore-table (mysqldump) или фильтры/regex в mydumper.
• Выполняете дамп в пиковые часы. Решение: планируйте окна, снижайте concurrency либо используйте --long-query-guard в mydumper.
• Один огромный файл на медленный диск. Решение: компрессия потоком, несколько потоков, проверка лимитов I/O.
• Проблемы с DEFINER у представлений/процедур. Решение: согласуйте пользователей и права на целевой БД или смените SQL SECURITY по политике.

PITR и метаданные

Для point-in-time recovery нужен бэкап плюс бинарные логи. mysqldump с --master-data пишет координаты прямо в дамп. mydumper сохраняет в файл metadata снимок координат и/или GTID-набор. После восстановления применяйте логи по времени инцидента и сверяйте результат. См. также подробный разбор PITR на MySQL и MariaDB.

Проверка бэкапа: не верим на слово

• Периодически поднимайте стенд из бэкапа (удобно на отдельном VDS). Цель — проверить время RTO и найти отсутствующие объекты.
• Сверяйте контрольные суммы выборочно: CHECKSUM TABLE или подсчёт строк по ключам для крупных таблиц.
• Гоняйте критические миграции схемы на стенде, собранном из свежего бэкапа.

Автоматизация и ротация

• Скриптуйте бэкап, сохраняйте лог с длительностью, объёмом и хешем каталога.
• Ротация: удерживайте N ежедневных, M еженедельных и K ежемесячных слепков, плюс контролируйте бинарные логи для PITR.
• Алерты: если бэкап занял в 2 раза больше обычного времени или сильно уменьшился в размере — проверьте.
• Для небольших проектов на виртуальном хостинге запускайте бэкапы по cron и регулярно тестируйте восстановление на отдельном стенде.
• Храните оффсайт-копии: объектное хранилище и периодическая проверка целостности. Детально — в статье резервные копии в S3 с restic/borg.

Короткие рецепты

Быстрый параллельный бэкап с ограничением влияния

mydumper --threads=8 --compress --outputdir=/backups/myd-now --triggers --routines --events --chunk-filesize=256 --long-query-guard=5 --kill-long-queries

Точечное восстановление одной таблицы

myloader --directory=/backups/myd-now --threads=4 --tables-list=appdb.users --overwrite-tables

Классика с mysqldump и PITR

mysqldump --single-transaction --routines --triggers --events --master-data=2 appdb | gzip -1 > /backups/appdb.sql.gz

Выводы

В типичной для админов и девопсов ситуации — несколько десятков гигабайт на InnoDB, SSD и 4–8 vCPU — связка mydumper/myloader побеждает mysqldump по времени бэкапа в 2–4 раза, а по времени восстановления — в 3–5 раз. При этом влияние на прод предсказуемее благодаря параллелизму и транзакционной консистентности. mysqldump остаётся отличным выбором для малых баз, экспорта схемы и переносов «на коленке».

Рекомендация проста: если ваша база стабильно >10–20 ГБ или RTO критично, переходите на mydumper/myloader, внедряйте регулярную проверку восстановления и держите под рукой метаданные для PITR. Это сбережёт часы простоя и нервы в дежурную смену.