Порядок дій, який не кладе сайт
Перенесення бази даних — це не «вивантажив-завантажив», а послідовність із точками перевірки. Якщо змінити порядок, сайт або ляже на час перенесення, або почне писати дані в базу, яка скоро зникне.
- Переведіть сайт у режим лише для читання або попередьте користувачів про технічні роботи — нові записи, зроблені під час експорту, у дамп не потраплять.
- Зробіть дамп на старому сервері командою
mysqldumpіз прапорцем узгодженості. - Передайте файл на новий сервер і імпортуйте його у порожню базу.
- Перевірте базу на новому сервері через файл
hosts, не чіпаючи DNS домену. - Лише після успішної перевірки перемикайте домен і оновлюйте конфіг сайту.
Експорт: mysqldump із потрібними прапорцями
База менша за 1 ГБ
mysqldump -u user -p --single-transaction --routines --triggers database_name > dump.sql--single-transaction робить знімок без блокування таблиць (важливо для InnoDB), --routines і --triggers додають збережені процедури та тригери, які звичайний дамп пропускає.
База понад 5 ГБ
mysqldump -u user -p --single-transaction --quick --compress database_name | gzip > dump.sql.gz--quick читає рядки по одному, а не завантажує всю таблицю в пам'ять, --compress стискає трафік між клієнтом і сервером MySQL, а зовнішній gzip зменшує сам файл у 5–10 разів.
Лише потрібні таблиці
mysqldump -u user -p database_name table1 table2 > partial.sqlПередавання дампу на новий сервер
Через scp
scp dump.sql.gz root@new-server-ip:/root/Напряму через SSH, без файлу на диску
mysqldump -u user -p --single-transaction database_name | gzip | ssh root@new-server-ip "gunzip | mysql -u user -p database_name"Такий конвеєр економить місце на обох серверах і час: не треба чекати, поки файл повністю запишеться, перш ніж почати передавання.
Імпорт на новому сервері
gunzip < dump.sql.gz | mysql -u user -p database_nameПорівняння способів перенесення
| Спосіб | Практична межа | Простій сайту | Коли використовувати |
|---|---|---|---|
| phpMyAdmin (експорт/імпорт файлу) | до 50–100 МБ | хвилини | малі сайти, немає доступу до SSH |
| mysqldump у файл + scp | до кількох ГБ | хвилини — години | є SSH, база помірного розміру |
| Прямий pipe через SSH | обмежений лише швидкістю каналу | хвилини — години | великі бази, мало місця на диску |
Перевірка на новому сервері до перемикання DNS
Перед зміною DNS перевірте сайт на новій IP-адресі, підмінивши адресу домену лише на своєму комп'ютері.
echo "203.0.113.10 example.com www.example.com" | sudo tee -a /etc/hostsПісля цього відкрийте сайт у браузері як завжди — він звернеться за доменом, але отримає відповідь із нового сервера. Так само можна перевірити без правки hosts, передавши заголовок Host напряму:
curl -H "Host: example.com" http://203.0.113.10/Не забудьте видалити рядок з /etc/hosts після перевірки, інакше продовжите бачити стару версію навіть після реального перемикання DNS.
Типові помилки під час імпорту
| Повідомлення | Причина та рішення |
|---|---|
| ERROR 1044 (42000): Access denied for user | Користувач MySQL не має прав на цільову базу — видайте GRANT ALL на неї потрібному користувачу |
| ERROR 2006 (HY000): MySQL server has gone away | Дамп містить рядок більший за max_allowed_packet — збільшіть параметр у my.cnf на новому сервері |
| ERROR 1046 (3D000): No database selected | У дампі немає USE database_name — створіть базу заздалегідь і імпортуйте з явним зазначенням її імені |
| Unknown collation: 'utf8mb4_0900_ai_ci' | Версія MySQL на новому сервері старша — або оновіть сервер, або замініть назву collation у дампі на підтримувану |
Відкат, якщо щось пішло не так
- Не видаляйте стару базу і старий сервер, поки новий не відпрацював щонайменше добу під реальним навантаженням.
- Якщо після перемикання DNS сайт поводиться нестабільно, поверніть старі A-записи — вони почнуть діяти в міру закінчення TTL.
- Розберіться з проблемою на новому сервері у спокійному режимі, потім повторіть міграцію.
Коли цей спосіб не підходить
Для баз більших за 20–30 ГБ звичайний mysqldump займає години і тримає сайт у простої весь цей час. У такому разі використовуйте реплікацію master-slave для первинної синхронізації без зупинки сайту, а mysqldump — лише для фінальної звірки невеликої кількості змінених рядків.
Перевірка результату
- Порівняйте кількість таблиць:
SHOW TABLES;на старому і новому сервері має дати однаковий список. - Порівняйте кількість рядків у ключових таблицях:
SELECT COUNT(*) FROM orders;і аналогічно для інших важливих таблиць. - Запустіть
mysqlcheck -u user -p --all-databasesна новому сервері — команда перевіряє цілісність таблиць. - Відкрийте сайт через підміну hosts і перевірте ключові сторінки: логін, оформлення замовлення, адмінку.
Детальний чек-лист загальної перевірки сайту після перенесення — у статті перевірка після міграції, а порядок безпечного відкату — у статті план відкату міграції.
Часті питання
Чи обов'язково повністю зупиняти сайт на час перенесення бази, чи досить режиму лише для читання?
Режиму лише для читання зазвичай досить: головне, щоб нові записи не створювалися під час зняття дампу, інакше вони не потраплять в експорт і загубляться під час перемикання. Повна зупинка потрібна рідко — хіба що сайт активно пише дані майже в кожну таблицю, і саме лише читання цього не запобігає.
Що робити, якщо зняття дампу триває занадто довго і заважає бойовій базі працювати нормально?
Прапорець узгодженого знімка знімає блокування таблиць під час дампу, тож сам експорт зазвичай не заважає паралельним запитам, а довгий час роботи частіше пов'язаний із великим обсягом даних. Якщо база настільки велика, що навіть такий дамп розтягується на години, розумніше перейти на реплікацію для первинної синхронізації, залишивши дамп лише для фінальної звірки.
Чи можна перенести лише частину таблиць бази, а не всю базу цілком?
Так, mysqldump уміє вивантажувати окремі таблиці за іменем, не чіпаючи решту бази, що зручно, коли переноситься один модуль сайту або треба відновити конкретні дані після помилки. При цьому зв'язки між таблицями варто перевірити окремо: якщо перенесена таблиця посилається на дані, яких на новому сервері ще немає, такі зовнішні ключі доведеться створювати вже після імпорту.
Що робити, якщо після перенесення кількість рядків у таблицях на новому сервері не збігається зі старим?
Спершу звірте перелік таблиць і кількість рядків у ключових із них на обох серверах — розбіжність зазвичай означає, що частина даних записалася на старій базі вже після зняття дампу, поки сайт ще приймав запити. Якщо старий сервер ще живий, зробіть дамп заново з урахуванням нових записів і повторіть імпорт, не видаляючи стару базу завчасно.