Как перенести дамп в 20Гб и не потерять ни бита

— Когда mysqldump уже не вывозит —


TL;DR
mydumper + myloader — интересная альтернатива классическому mysqldump для больших баз. Параллельная выгрузка, дробление таблиц, многопоточный импорт и возможность возобновить восстановление.

Для многих вынос дата-центров яндекса в начале октября обернулся неудобствами. Для кого-то финансовыми потерями и потерей данных. И мне досталось рикошетом и небольшим опытом...

В инфраструктуре яндекса лежала БД с весьма чувствительными данными. И как только сервис стал доступен встала задача извлечь данные из облака и скачать на флешку и положить под матрац и перебраться на резервную площадку. В моём случае — перенести какие-то жалкие 20Гб.

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

Двое из ларца – mydumper/myloader

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

Первая часть марлезонского балета

Снимаем дамп — синтаксис максимально похож на привычный mysqldump:

mydumper \
--host=<DB_HOST> \
--port=3306 \
--user=<DB_USER> \
--ask-password \
--ssl \
--ssl-mode=VERIFY_IDENTITY \
--ca=CA.pem \
--database=<DB_NAME> \
--skip-ddl-locks \
--no-backup-locks \
--sync-thread-lock-mode=LOCK_ALL \
--outputdir=./backup-sql \
--threads=4 \
--rows=100000 \
--trx-tables \
--verbose=3

Из интересных параметров:
--threads=4 — четыре параллельных потока выгрузки.
--rows=100000 — ориентир на 100 тысяч строк в одном фрагменте большой таблицы.
--trx-tables — оптимизация блокировок для транзакционных таблиц, например InnoDB.
--skip-ddl-locks — отключает дополнительные DDL-блокировки.
--no-backup-locks — запрещает использовать backup-locks.
--sync-thread-lock-mode=LOCK_ALL — синхронизирует потоки с помощью блокировок таблиц вместо глобального FLUSH TABLES WITH READ LOCK.

Облачный mysql оказался довольно ревнивым к своим привилегиям: сначала не дал BACKUP_ADMIN, потом отказал в FLUSH TABLES. Поэтому пришлось подбирать режимы синхронизации эмпирически.

Вторая часть марлезонского балета

Когда дамп наконец снялся, выяснилось, что myloader на macOS категорически не желает отключать SSL, которого на целевом сервере не было.

Попытки уговорить его через волшебный --ssl-mode=DISABLED закончились ничем. Оказалось, моя сборка использовала MariaDB Connector/C, с которым возникли проблемы при отключении SSL.

Пришлось доставать docker-образ с mysql-клиентом:

docker pull mydumper/mydumper:latest

И дальше дело пошло веселее. Для импорта через Docker команда получилась такой:

docker run --rm -it \
--entrypoint myloader \
-v "$(pwd)/backup:/backup" \
mydumper/mydumper:latest \
--host=<DB_HOST> \
--port=3306 \
--protocol=tcp \
--user=<DB_USER> \
--ask-password \
--ssl-mode=DISABLED \
--database=<DB_NAME> \
--directory=/backup \
--threads=4

В итоге база переехала, данные остались целы.

Осталось только купить флешку и положить её под матрац.

Так...на всякий случай.

#mysql #mydumper #myloader #devops