Краткий ответ: Для MySQL/MariaDB используйте mysqldump--single-transaction для InnoDB) и импорт на цели; для PostgreSQL — pg_dump/pg_restore. Сжимайте дампы для передачи, сверяйте количество строк после импорта, а для больших или нагруженных баз сделайте полную копию заранее плюс финальную дельту внутри короткого freeze записей.

Обзор

Базы данных — та часть миграции, где «почти идентично» недостаточно: полуимпортированная таблица или потерянный день строк болит сильнее любого конфига. Инструменты зрелые; планирования требуют консистентность (никаких записей посреди дампа) и размер (время передачи и импорта больших данных).

Что нужно иметь

  • Учётные данные базы на обоих серверах и соответствующую (или новее) версию движка на цели.
  • Достаточно свободного диска с обеих сторон для файла дампа — проверьте через df -h.
  • Представление о размере базы: SELECT table_schema, ROUND(SUM(data_length+index_length)/1024/1024) AS mb FROM information_schema.tables GROUP BY table_schema;

Пошаговая инструкция

  1. Дамп (MySQL/MariaDB):
    mysqldump --single-transaction --routines --triggers dbname | gzip > dbname.sql.gz
  2. Передача: rsync -a dbname.sql.gz user@NEW_IP:/root/
  3. Импорт на цели:
    gunzip -c dbname.sql.gz | mysql -u user -p dbname
  4. Эквивалент для PostgreSQL: pg_dump -Fc dbname > dbname.dump, затем pg_restore -d dbname dbname.dump.
  5. Проверка: сравните количество таблиц и выборочные количества строк с обеих сторон; протестируйте приложение с новой базой.
  6. Для переключения: повторите дамп/импорт во время freeze записей, чтобы переехало финальное состояние — для очень больших баз рассмотрите дамп только изменённых таблиц.

Типичные проблемы

  • Дамп без --single-transaction: на живой InnoDB-базе это риск неконсистентного снимка — всегда добавляйте эту опцию.
  • Сюрпризы с кодировкой: держите utf8mb4 насквозь; обход через latin1 портит эмодзи и кириллицу.
  • Импорт значительно медленнее дампа: это нормально — на импорте перестраиваются индексы. Большие импорты запускайте внутри screen/tmux, чтобы обрыв SSH их не убил.
  • Пользователи и права: дампы переносят данные, а не пользователей базы — создайте пользователей и GRANT-ы на цели заново.

Когда обращаться в поддержку

Базы на сотни ГБ, репликационные конфигурации или требования минимального freeze — именно те случаи для бесплатной ассистированной миграции: опишите размеры и допустимое окно в тикете.

Частые вопросы

Зачем --single-transaction в mysqldump?

Опция снимает консистентный снимок InnoDB, пока приложение продолжает писать, поэтому дамп не является смесью старых и новых строк. Без неё дамп живого сайта может быть незаметно неконсистентным.

Как перенести базу на сотни гигабайт?

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

Почему импорт настолько медленнее дампа?

На импорте сервер перестраивает индексы и применяет ограничения для каждой строки. Это нормально; запускайте большие импорты в screen или tmux, чтобы обрыв SSH-сессии их не прервал.

Похожие статьи

Готовы начать? Заказать VPS в Cloud2Y →

Помог ли вам данный ответ? 0 Пользователи нашли это полезным (0 голосов)