Безопасный импорт большого MySQL-дампа на Production-сервере

Импорт большого SQL-дампа на production-сервере может существенно увеличить нагрузку на диск, CPU и MySQL. Особенно это заметно на серверах с HDD или при высокой текущей нагрузке от сайтов.
Во время восстановления базы данных MySQL активно записывает данные, обновляет индексы, работает с redo/undo и выполняет операции синхронизации с диском. В результате PHP-FPM, Nginx и другие сервисы могут начать работать медленнее, а пользователи — получать ошибки 502 и 504.
Чтобы снизить влияние импорта на работающие сайты, можно контролировать скорость подачи данных в MySQL и снизить приоритет клиентского процесса.

Как устроен импорт SQL-дампа

При обычном импорте:
mysql -u root -p database_name < dump.sql
участвуют два основных процесса:
dump.sql
   ↓
mysql
   ↓
mysqld
   ↓
database

Клиент mysql

Клиент отвечает за:

• чтение SQL-файла;
• обработку SQL-команд на клиентской стороне;
• передачу запросов серверу MySQL;
• получение ответов от mysqld.

Сервер mysqld

Именно mysqld выполняет основную работу:

• INSERT, UPDATE, DELETE;
• создание таблиц;
• изменение структуры;
• обновление индексов;
• работу с InnoDB buffer pool;
• запись redo/undo;
• блокировки;
• запись данных на диск;
• fsync и другие операции I/O.

Поэтому важно понимать:
Основная нагрузка при импорте создаётся процессом mysqld, а не клиентом mysql.

Почему импорт может замедлить сайты

Во время восстановления базы mysqld активно использует дисковую подсистему.
На сервере с HDD это особенно критично, поскольку одновременно могут выполняться операции PHP-FPM, Nginx, MySQL и импорт базы данных, конкурируя за дисковые ресурсы.
Если диск не успевает обслуживать все запросы, увеличивается время ожидания операций I/O.
В результате могут появиться:

• высокий iowait;
• высокий await;
• %util, близкий к 100%;
• медленная работа MySQL;
• увеличение времени ответа PHP-FPM;
• ошибки 502 Bad Gateway;
• ошибки 504 Gateway Timeout.

На SSD такая проблема обычно проявляется значительно слабее, но при большом количестве операций или высокой текущей нагрузке также возможна.

Как понять, что узким местом является диск

Во время импорта рекомендуется открыть отдельную SSH-сессию и запустить мониторинг.

Проверка дисковой нагрузки

iostat -xz 1
Основные показатели:

• %util — насколько активно используется устройство;
• await — среднее время ожидания I/O;
• r/s — количество операций чтения;
• w/s — количество операций записи.

Если во время импорта %util длительное время находится около 100%, а await существенно увеличивается, дисковая подсистема становится узким местом.

Проверка процессов, использующих диск

iotop -oPa
Команда позволяет увидеть процессы, которые активно выполняют операции чтения и записи.
Во время импорта основной нагрузкой обычно будет обладать mysqld а не mysql.
Это нормально: именно mysqld выполняет SQL-запросы и записывает результат в базу.

Проверка CPU и I/O wait

vmstat 1
Особое внимание стоит обратить на показатель wa. Высокое значение wa означает, что CPU значительное время ожидает завершения операций ввода-вывода.
Для общей оценки нагрузки можно использовать:
htop

Ограничение скорости импорта с помощью pv

Один из наиболее практичных способов контролировать импорт — использовать pv.
Например:
pv -L 5m dump.sql | mysql -u root -p database_name
Параметр:

-L 5m

ограничивает скорость передачи данных примерно до 5 MB/s.
Схема работы:
dump.sql
   ↓
pv -L 5m
   ↓
mysql
   ↓
mysqld

Это позволяет не отправлять дамп в MySQL на максимально возможной скорости. Начинать рекомендуется с небольшой скорости.
Для HDD можно начать, например, с:
pv -L 2m dump.sql | mysql -u root -p database_name
Если нагрузка остаётся приемлемой, скорость можно увеличить:
pv -L 5m dump.sql | mysql -u root -p database_nameили:
pv -L 10m dump.sql | mysql -u root -p database_name
Конкретное значение зависит от производительности диска, объёма RAM, нагрузки на сервер и структуры самой базы.
Важный момент: pv не ограничивает I/O mysqld напрямую. Это принципиально важно.
Команда:

pv -L 5m

ограничивает скорость чтения и передачи данных клиентом, но не устанавливает ограничение на операции записи, выполняемые mysqld.
Например, один и тот же объём SQL может создавать совершенно разную нагрузку:
INSERT в таблицу без индексов
        ↓
относительно небольшая нагрузка
и:
INSERT в большую таблицу
        ↓
обновление нескольких индексов
        ↓
redo/undo
        ↓
fsync
        ↓
значительно большая нагрузка

Поэтому 5 MB/s входного SQL не означает 5 MB/s дисковой записи.
pv следует рассматривать как ограничитель темпа подачи работы в MySQL, а не как прямой ограничитель дисковой нагрузки.

Использование nice

Можно дополнительно снизить CPU-приоритет клиента:
nice -n 19 mysql -u root -p database_name < dump.sql

nice -n 19

устанавливает низкий CPU-приоритет для процесса mysql.
Однако здесь есть важное ограничение: nice применяется к mysql а не к mysqld. Поэтому он не снижает CPU-приоритет самого MySQL-сервера. На большинстве серверов клиент mysql потребляет значительно меньше ресурсов, чем mysqld, поэтому эффект от nice обычно второстепенный.

Использование ionice

Можно также снизить I/O-приоритет клиента:
ionice -c 3 mysql -u root -p database_name < dump.sql
Класс:

-c 3

соответствует idle I/O class. Это означает, что клиент получает возможность выполнять дисковые операции в первую очередь тогда, когда диск не нужен процессам с более высоким I/O-приоритетом.
Это может быть полезно, если SQL-файл находится на том же диске, что и сайты.
Например:
dump.sql
   ↓
читается mysql
   ↓
HDD
ionice уменьшает конкуренцию этого чтения с другими дисковыми операциями.
Но, как и nice, ionice применяется к клиенту, а не к mysqld.

Комбинирование pv, nice и ionice

Для production-сервера можно использовать:
pv -L 5m dump.sql | nice -n 19 ionice -c 3 mysql -u root -p database_name
Здесь каждый инструмент выполняет свою задачу:

Инструмент	Назначение
pv -L 5m	Ограничивает скорость подачи дампа
nice -n 19	Снижает CPU-приоритет клиента
ionice -c 3	Снижает I/O-приоритет клиента
mysqld	Выполняет сам импорт

При этом основным механизмом контроля темпа импорта является pv.

Почему не стоит понижать приоритет mysqld

Можно изменить приоритет самого процесса MySQL, но для production-сервера это потенциально опасно.
mysqld обслуживает одновременно:

• импорт;
• запросы сайтов;
• фоновые задачи;
• cron;
• административные операции.

То есть невозможно просто сказать: «Понизим приоритет mysqld, чтобы замедлить импорт». Приоритет будет применяться ко всей работе MySQL. В результате вместе с импортом могут замедлиться и обычные запросы сайтов. Поэтому гораздо безопаснее контролировать скорость подачи данных клиентом, а не искусственно ограничивать весь mysqld.

Импорт сжатого дампа

Если дамп имеет формат .gz, его можно импортировать следующим образом:
pv -L 5m dump.sql.gz | gzip -dc | mysql -u root -p database_name
Однако здесь есть нюанс: pv ограничивает скорость чтения сжатого файла.
Например:
5 MB/s .gz
       ↓
gzip
       ↓
может превратиться в значительно больший объём SQL

Поэтому ограничение нужно подбирать по фактической нагрузке на сервер.
На слабом CPU дополнительная нагрузка от распаковки gzip также может быть заметной.

Как определить, что импорт мешает сайтам

Во время импорта необходимо смотреть не только на MySQL, но и на веб-стек.

CPU

htop

RAM

free -h

Диск

iostat -xz 1

I/O процессов

iotop -oPa

I/O wait

vmstat 1

Nginx

tail -100 /var/log/nginx/error.log

Apache

tail -100 /var/log/apache2/error.log

PHP-FPM

systemctl status php8.x-fpm
Если одновременно наблюдаются:

• высокий iowait;
• высокий await;
• %util около 100%;
• рост времени ответа сайтов;
• ошибки 502/504;
• длительные запросы MySQL;

значит, импорт оказывает существенное влияние на production.

Рекомендации

Для безопасного импорта большого дампа на production-сервере:

1. Не запускайте большой импорт без контроля нагрузки.
2. Начинайте с небольшой скорости pv.
3. Следите за iostat, vmstat, iotop и htop.
4. При необходимости используйте nice и ionice для клиентского процесса.
5. Не воспринимайте nice и ionice как ограничители нагрузки mysqld.
6. Учитывайте блокировки таблиц и операции ALTER TABLE.
7. По возможности импортируйте базу в отдельную БД и переключайте приложение после проверки.
8. На HDD особенно внимательно следите за await, %util и iowait.
9. Подбирайте скорость импорта по фактической нагрузке, а не по фиксированному значению MB/s.

Заключение

При большом MySQL-импорте важно различать клиент mysql и сервер mysqld.
mysql читает дамп и передаёт SQL-команды.
mysqld выполняет эти команды и создаёт основную нагрузку на CPU, RAM и дисковую подсистему.
Поэтому:
pv      → контролирует темп подачи данных
nice    → снижает CPU-приоритет клиента
ionice  → снижает I/O-приоритет клиента
mysqld  → выполняет основную работу импорта

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