Skip to content
VDS · Бази даних

Перенесення бази даних з іншого сервера

Порядок міграції бази даних на 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;), і запустіть застосунок на новій базі даних у тестовому режимі.

Перемикання

  1. Увімкніть режим обслуговування або зупиніть застосунок на старому сервері.
  2. Зробіть фінальний дамп змін, зроблених під час підготовки.
  3. Відновіть його на новій машині.
  4. Перемкніть рядок підключення застосунку та перезапустіть службу.
  5. Залиште старий сервер працювати ще тиждень, не видаляючи дані.

Не пропускайте п'ятий крок: виявити відсутню таблицю через три дні — цілком звична річ.

Типові помилки

СимптомПричина
role does not exist під час відновленняРолі не перенесено — використайте --no-owner разом зі створенням ролей вручну
Спотворені символиНевідповідність кодувань: відновлюйте в базу даних з utf8mb4 або UTF8
Послідовності починаються з 1Дамп містив лише дані, без setval
Відновлення триває годинамиІндекси будуються на льоту; для великих баз даних використовуйте pg_restore -j 4
Забрав місце посерединіНе враховано обсяг дампу поряд з даними

Перед міграцією перевірте, що нова база даних слухає лише 127.0.0.1. Немає потреби відкривати її публічно «на час міграції» — перенесення йде через SSH, див. віддалений доступ.