Міграція бази даних при переїзді хостингу: як не втратити жодного рядка і зберегти нерви

Уявіть: ви переїжджаєте в нову квартиру. Меблі, одяг, техніка - все пакується акуратно. Але хтось забув коробку зі старими фотографіями, записами, документами. Саме так виглядає переїзд хостингу, коли база даних переноситься з помилками. Файли сайту - це меблі. А база даних - це пам'ять вашого проєкту. Без неї сайт стає порожньою оболонкою, красивою, але мертвою. І найгірше? Помилки при міграції бази часто проявляються не одразу. Через день, два, тиждень - коли клієнт намагається оформити замовлення, а кошик порожній. Або коли автор бачить, що пів року його статей просто зникли.

Цей гайд - про те, як перенести базу даних між хостингами так, щоб потім не прокидатися вночі від думки "а чи все я перевірив".

Чому база даних - найвразливіше місце при переїзді

Файли сайту - це статичні об'єкти. Картинки, скрипти, шаблони. Вони або є, або їх нема. З базою все інакше. MySQL, MariaDB чи PostgreSQL - це живий організм, де кожна таблиця пов'язана з іншими через зовнішні ключі, індекси, тригери. Один зламаний зв'язок - і весь сайт "сиплеться" як картковий будинок.

Ось типові проблеми, з якими стикаються під час міграції бази:

• Різна кодировка - старий хостинг використовував latin1, новий очікує utf8mb4, і ваші кирилічні тексти перетворюються на "??????"
• Невідповідність версій СУБД - функції, що працювали в MySQL 5.7, можуть поводитись інакше в MySQL 8.0
• Обмеження нового хостингу - максимальний розмір імпорту, таймаути з'єднання, ліміти на кількість запитів
• Захардкоджені URL - у WordPress, Joomla та інших CMS абсолютні шляхи зберігаються прямо в базі
• Серіалізовані дані - простий пошук-заміна ламає серіалізовані масиви PHP, і плагіни перестають працювати

Кожен з цих пунктів здатний перетворити двогодинну задачу на двотижневий кошмар. Тому підготовка до міграції бази важливіша за саму міграцію.

Три підходи до експорту бази: від простого до параноїдального

Є кілька способів витягнути базу зі старого хостингу. Вибір залежить від розміру бази, вашого досвіду і рівня тривожності.

1. phpMyAdmin - класика. Заходите в панель старого хостингу, обираєте базу, тиснете "Експорт", отримуєте SQL-файл. Для баз до 50-100 МБ працює чудово. Для більших - починаються таймаути і обрізані дампи.
2. Командний рядок (mysqldump) - золотий стандарт. Одна команда: mysqldump -u user -p database_name > backup.sql. Працює з базами будь-якого розміру, дає повний контроль. Можна додати прапорці --single-transaction і --routines, щоб захопити все - від процедур до подій.
3. Плагіни CMS - Duplicator, All-in-One WP Migration, Akeeba Backup. Вони пакують файли разом з базою, але мають обмеження на розмір. І головне - ви довіряєте свою базу стороннім розробникам, які можуть "оптимізувати" експорт по-своєму.

"Якщо ваша база перевищує 500 МБ, забудьте про веб-інтерфейси. SSH і mysqldump - єдиний надійний спосіб. Все інше - це рулетка з таймаутами сервера." - Percona Database Performance Blog

Мій досвід підказує: навіть якщо ви використовуєте плагін, завжди робіть паралельний дамп через mysqldump. Це ваша страховка. Як запасний парашут - може, не знадобиться, але спати будете краще.

Підводні камені імпорту, про які мовчать туторіали

Окей, у вас є SQL-файл. Тепер потрібно залити його на новий хостинг. І тут починається найцікавіше.

Проблема номер один - розмір файлу. phpMyAdmin на більшості shared-хостингів має ліміт імпорту 50-100 МБ. Ваша база - 300 МБ. Що робити? Або розбивати файл утилітою на частини (наприклад, BigDump), або використовувати SSH з командою mysql -u user -p database_name < backup.sql.

Друга пастка - кодування. Перед імпортом перевірте, що у файлі дампу є рядок:

SET NAMES utf8mb4;

Без нього MySQL може інтерпретувати кирилицю як набір символів, і ваші статті перетворяться на абракадабру. Я бачив це десятки разів, і кожен раз власник сайту думав, що дані втрачені назавжди. Насправді - ні. Але відновлення займає набагато більше часу, ніж правильний імпорт з самого початку.

Заміна URL у базі: проста задача, яка вбиває більше сайтів, ніж хакери

Це пункт, на якому ламається кожен другий переїзд WordPress-сайту. Серйозно. Кожен. Другий.

У базі WordPress зберігаються абсолютні URL. Не відносні, а повні - з доменом, протоколом, іноді зі шляхом до підкаталогу. Якщо ви переїхали з oldsite.com на newsite.com або навіть просто з HTTP на HTTPS - потрібна заміна.

І ось головна пастка: не можна робити звичайний SQL-запит типу UPDATE wp_options SET option_value = REPLACE(option_value, 'old', 'new'). Ну, технічно можна. Але ви зламаєте серіалізовані масиви PHP, де довжина рядка прописана явно. Наприклад:

s:19:"http://oldsite.com/";

Після заміни домену довжина рядка зміниться, а число 19 залишиться. PHP не зможе десеріалізувати дані. Результат - злетять налаштування теми, зникнуть віджети, плагіни "забудуть" свої конфігурації.

Правильний підхід:

• WP-CLI: команда wp search-replace 'oldsite.com' 'newsite.com' --all-tables - коректно обробляє серіалізовані дані
• Search Replace DB від interconnect/it - веб-інтерфейс, який робить те саме, але без командного рядка
• Duplicator Pro - виконує заміну в процесі розгортання бекапу

Критично важливо: після використання Search Replace DB видаліть скрипт з сервера. Він дає повний доступ до бази. Залишити його - все одно що залишити ключі від квартири під килимком з надписом "ключі тут".

Чек-лист перевірки після міграції бази

Імпорт пройшов без помилок? Чудово. Але це не фініш. Це навіть не середина дистанції. Потрібна верифікація.

1. Порівняйте кількість таблиць - на старому і новому хостингу їх має бути однакова кількість. Банально, але ефективно.
2. Перевірте кількість записів у ключових таблицях - wp_posts, wp_users, wp_options. Різниця навіть в одному рядку - сигнал тривоги.
3. Відкрийте сайт і пройдіться по 10-15 сторінках - головна, кілька статей, кошик, сторінка контактів. Шукайте зламану кирилицю, відсутні зображення, помилки 500.
4. Перевірте форми зворотного зв'язку - вони часто "тихо" ламаються при міграції.
5. Тестуйте авторизацію - залогіньтесь як адмін, як звичайний юзер. Перевірте ролі і права.
6. Подивіться логи помилок PHP - вони покажуть проблеми, які не видно з фронтенду.

Я веду Google-таблицю з цим чек-листом і відмічаю кожен пункт при кожній міграції. Виглядає нудно. Зате за останні три роки - нуль втрачених даних.

Коли варто віддати міграцію бази професіоналам

Не все потрібно робити самостійно. Ось чесні маркери того, що краще залучити спеціаліста:

• База більша за 1 ГБ і містить кастомні таблиці за межами стандартної CMS
• У вас кілька баз, які взаємодіють між собою (основний сайт + форум + CRM)
• Міграція передбачає зміну СУБД - наприклад, з MySQL на PostgreSQL
• Сайт генерує дохід 24/7, і навіть година простою коштує відчутних грошей

Більшість хостинг-провайдерів пропонують безкоштовну міграцію. Це не благодійність - це маркетинг. Вони хочуть вашу щомісячну оплату. Але якість такої міграції буває дуже різною. Перед тим як погодитись, запитайте конкретно: "Чи обробляєте ви серіалізовані дані при заміні домену?" Якщо у відповідь тиша або "що ви маєте на увазі?" - краще робіть самі. Або наймайте незалежного DevOps-спеціаліста.

А ось головне питання, яке варто задати собі ще до початку переїзду: чи маєте ви актуальний бекап, який ви особисто перевірили на відновлення? Не "мабуть є десь на хостингу", а конкретний файл, скачаний на локальний диск, протестований на локальному сервері. Якщо ні - починайте не з міграції. Починайте з бекапу. Бо переїзд без перевіреного бекапу - це не оптимізм. Це безвідповідальність.