Восстановление MySQL-базы сайта: что проверить после импорта

Восстановить MySQL-базу из дампа — не значит полностью вернуть сайт к жизни. Импорт может пройти без явной ошибки, но потом появляются кракозябры в тексте, не работают автоинкременты, пользователь базы не имеет нужных прав, миграции расходятся с кодом, а часть таблиц восстановилась не в ту кодировку.

После импорта базы нужен короткий технический осмотр. Он часто экономит больше времени, чем повторное восстановление вслепую.

Импорт дампа

Обычный импорт выглядит так:

mysql -u user -p database < backup.sql

Если дамп сжат:

gunzip < backup.sql.gz | mysql -u user -p database

Для больших файлов лучше выполнять импорт в screen или tmux, чтобы процесс не оборвался при разрыве SSH.

tmux new -s restore

Проверить размер и количество таблиц

После импорта стоит сравнить количество таблиц и примерный размер базы с исходными данными, если они есть.

mysql -u user -p -e "SHOW TABLES FROM database;"
mysql -u user -p -e "SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema = 'database';"

table_rows для InnoDB может быть приблизительным, но для быстрой проверки этого обычно достаточно.

Кодировка и collation

Если после восстановления появились неправильные символы, нужно проверить кодировку базы, таблиц и подключения. Для современных проектов чаще используют utf8mb4.

SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';
SHOW CREATE TABLE blog_posts;

В Yii2 подключение к базе обычно явно задаёт charset:

'db' => [
    'class' => 'yii\db\Connection',
    'dsn' => 'mysql:host=localhost;dbname=database',
    'username' => 'user',
    'password' => 'password',
    'charset' => 'utf8mb4',
],

Если проект старый, там может быть utf8. Менять кодировку без проверки данных не стоит, но нужно понимать фактическое состояние.

Права пользователя базы

Сайт может подключаться к базе, но не иметь прав на запись, создание временных таблиц или выполнение нужных операций. После переноса это встречается часто.

SHOW GRANTS FOR 'user'@'localhost';

Для обычного сайта пользователю обычно нужны SELECT, INSERT, UPDATE, DELETE. Для миграций дополнительно нужны ALTER, CREATE, DROP, INDEX.

AUTO_INCREMENT

Если после восстановления новые записи конфликтуют с существующими ID, нужно проверить AUTO_INCREMENT. Обычно MySQL восстанавливает его корректно, но после ручных операций бывают исключения.

SHOW TABLE STATUS LIKE 'blog_posts';

Если нужно выставить значение вручную:

ALTER TABLE blog_posts AUTO_INCREMENT = 1000;

Делать это нужно только после проверки максимального id:

SELECT MAX(id) FROM blog_posts;

Миграции и версия кода

База должна соответствовать версии кода. Если восстановили старый дамп, а код уже новый, приложение может ожидать колонки, которых нет.

php yii migrate/history
php yii migrate/new

Если есть новые миграции, их нужно выполнить или откатить код до версии, соответствующей дампу.

php yii migrate --interactive=0

Проверить критичные таблицы

После восстановления не нужно вручную пересматривать всю базу. Достаточно проверить таблицы, без которых сайт точно не работает: пользователи, настройки, контент, заказы, связи many-to-many, очереди.

SELECT COUNT(*) FROM users;
SELECT COUNT(*) FROM blog_posts;
SELECT COUNT(*) FROM blog_categories;

Если в проекте есть таблицы связей, важно убедиться, что они не пустые после частичного импорта.

Логи приложения после восстановления

После первого открытия сайта нужно смотреть логи. Ошибки базы обычно появляются сразу: неизвестная таблица, неизвестная колонка, неверная кодировка, нет прав.

tail -n 150 runtime/logs/app.log
tail -n 150 /var/log/nginx/error.log

Очистить schema cache

Если база восстановлена или изменена, а Yii2 использует schema cache, приложение может видеть старую структуру таблиц.

php yii cache/flush-schema

Или полная очистка:

php yii cache/flush-all

Чек-лист после импорта

  1. Импорт завершился без ошибок.
  2. Количество таблиц похоже на ожидаемое.
  3. Кодировка и charset подключения проверены.
  4. Права пользователя базы подходят для сайта.
  5. AUTO_INCREMENT не конфликтует с существующими ID.
  6. История миграций соответствует коду.
  7. Критичные таблицы не пустые.
  8. Schema cache очищен.
  9. Логи проверены после открытия сайта.

Восстановление базы лучше считать завершённым только после проверки сайта и логов. Сам факт успешного импорта ещё не гарантирует, что приложение работает с данными корректно.

Комментарии (0)

Пока нет комментариев. Будьте первым!