Перенесення бази даних з іншого сервера
Порядок міграції бази даних на Millida VDS: підготовка, передавання дампа мережею, перевірка цілісності та перемикання застосунку з мінімальним простоєм.
Оновлено 23 серпня 2026 р.
Міграція бази даних ламається не на командах, а на порядку кроків: люди спершу перемикають домен і лише потім виявляють, що половина даних не переїхала. Нижче — послідовність, яка цього не допускає.
Підготовка
На новій машині встановіть ту саму або новішу версію сервера бази даних — PostgreSQL або MySQL. Відкат на старішу версію не підтримується.
psql --version
mysql --version
df -h /
Вам знадобиться приблизно 2,5 обсягу бази даних вільного місця: дамп, розпаковані дані та трохи запасу. На VDS-1 це 40 GB загалом, тож плануйте заздалегідь.
Створіть користувача й порожню базу даних з тим самим кодуванням, що й на старому сервері.
Перенесення даних
Найпростіший шлях — дамп через SSH, без проміжних файлів:
ssh root@OLD 'pg_dump -Fc -U shop shop' > /srv/shop.dump
pg_restore -U postgres -d shop --no-owner --role=shop /srv/shop.dump
Для MySQL:
ssh root@OLD 'mysqldump --single-transaction --routines --events -u root shop' \
| mysql -u root shop
Ролі та користувачі не входять до дампу бази даних — їх експортують окремо: pg_dumpall --roles-only, або створюють вручну — див. користувачі та права.
Пропускна здатність — до 500 Mbps, тож база даних на 20 GB мігрує за лічені хвилини; вузьким місцем зазвичай є запис на диск, який обмежений тарифом.
Перевірка перед перемиканням
Перевіряйте цифри, а не лише те, що «сайт відкрився»:
SELECT relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 20;
SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema='shop';
Порівняйте кількість рядків у ключових таблицях зі старим сервером, переконайтеся, що послідовності не скинулися (SELECT last_value FROM users_id_seq;), і запустіть застосунок на новій базі даних у тестовому режимі.
Перемикання
- Увімкніть режим обслуговування або зупиніть застосунок на старому сервері.
- Зробіть фінальний дамп змін, зроблених під час підготовки.
- Відновіть його на новій машині.
- Перемкніть рядок підключення застосунку та перезапустіть службу.
- Залиште старий сервер працювати ще тиждень, не видаляючи дані.
Не пропускайте п'ятий крок: виявити відсутню таблицю через три дні — цілком звична річ.
Типові помилки
| Симптом | Причина |
|---|---|
role does not exist під час відновлення | Ролі не перенесено — використайте --no-owner разом зі створенням ролей вручну |
| Спотворені символи | Невідповідність кодувань: відновлюйте в базу даних з utf8mb4 або UTF8 |
| Послідовності починаються з 1 | Дамп містив лише дані, без setval |
| Відновлення триває годинами | Індекси будуються на льоту; для великих баз даних використовуйте pg_restore -j 4 |
| Забрав місце посередині | Не враховано обсяг дампу поряд з даними |
Перед міграцією перевірте, що нова база даних слухає лише
127.0.0.1. Немає потреби відкривати її публічно «на час міграції» — перенесення йде через SSH, див. віддалений доступ.