Коротка відповідь: Для 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;
Покрокова інструкція
- Дамп (MySQL/MariaDB):
mysqldump --single-transaction --routines --triggers dbname | gzip > dbname.sql.gz - Передача:
rsync -a dbname.sql.gz user@NEW_IP:/root/ - Імпорт на цілі:
gunzip -c dbname.sql.gz | mysql -u user -p dbname - Еквівалент для PostgreSQL:
pg_dump -Fc dbname > dbname.dump, потімpg_restore -d dbname dbname.dump. - Перевірка: порівняйте кількість таблиць і вибіркові кількості рядків з обох боків; протестуйте застосунок із новою базою.
- Для перемикання: повторіть дамп/імпорт під час freeze записів, щоб переїхав фінальний стан — для дуже великих баз розгляньте дамп лише змінених таблиць.
Типові проблеми
- Дамп без
--single-transaction: на живій InnoDB-базі це ризик неконсистентного знімка — завжди додавайте цю опцію. - Сюрпризи з кодуванням: тримайте utf8mb4 наскрізь; обхід через latin1 псує емодзі та кирилицю.
- Імпорт значно повільніший за дамп: це нормально — на імпорті перебудовуються індекси. Великі імпорти запускайте всередині
screen/tmux, щоб обрив SSH їх не вбив. - Користувачі та права: дампи переносять дані, а не користувачів бази — створіть користувачів і GRANT-и на цілі заново.
Коли звертатися в підтримку
Бази на сотні ГБ, реплікаційні конфігурації чи вимоги мінімального freeze — саме ті випадки для безкоштовної асистованої міграції: опишіть розміри та допустиме вікно в тикеті.
Часті запитання
Навіщо --single-transaction у mysqldump?
Опція знімає консистентний знімок InnoDB, поки застосунок продовжує писати, тож дамп не є сумішшю старих і нових рядків. Без неї дамп живого сайту може бути непомітно неконсистентним.
Як перенести базу на сотні гігабайт?
Зробіть повний дамп та імпорт заздалегідь, за кілька днів до перемикання, а під час freeze перенесіть лише дельту: змінені таблиці або свіжий дамп, якщо обсяг записів невеликий.
Чому імпорт настільки повільніший за дамп?
На імпорті сервер перебудовує індекси й застосовує обмеження для кожного рядка. Це нормально; запускайте великі імпорти в screen або tmux, щоб обрив SSH-сесії їх не перервав.
Схожі статті
- Як мігрувати від іншого VPS-провайдера
- Як перенести WooCommerce без втрати замовлень
- Як уникнути простою під час міграції
- Як відновити сайт із бекапу
Готові почати? Замовити VPS у Cloud2Y →
