#Как выглядит неисправность
После смены образа контейнерной БД служба не стартует или пишет об несовместимости файлов данных. Чаще всего проблема в несовпадении версии движка и формата каталога, неподходящем каталоге тома или изменённых параметрах запуска.
#Причины и признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Новая основная версия не читает старый каталогОбраз БД обновлён с одного основного выпуска на другой | Журнал сообщает incompatible data directory или mismatch | Восстановить совместимый образ на копии и спланировать миграцию |
| Изменились точка монтирования или праваОбраз ищет данные в ином каталоге | permission denied либо пустая новая база | Сверить Mounts и путь данных для конкретной СУБД |
#Пошаговое устранение
- 1. Зафиксируйте прежний и новый образыИз каталога Compose выполните docker compose config и docker compose ps -a. Запишите точные image:tag или image@sha256 и имя сервиса; не используйте плавающий latest при разборе проблемы.Linux · Терминал (Bash)КомандаПоказывает текущее и остановленное состояние сервиса.
docker compose ps -a
- 2. Прочитайте сообщения БДВыполните docker compose logs --tail 120 ИМЯ_БД. Ищите явное сообщение конкретной СУБД: версия каталога, формат WAL, права или отсутствие таблиц. Пришлите администратору только обезличенные строки без паролей.Linux · Терминал (Bash)КомандаТолько чтение журналов; данные могут содержать секреты.
docker compose logs --tail 120 ИМЯ_БД
- 3. Проверьте том и источник данныхЗапустите docker inspect --format ... ИМЯ_КОНТЕЙНЕРА и посмотрите Mounts. Сопоставьте Destination с путём данных, который использует именно образ PostgreSQL/MySQL/MariaDB. Наличие тома не гарантирует, что служба смотрит в правильный каталог.Linux · Терминал (Bash)КомандаЧтение конфигурации томов.
docker inspect --format '{{json .Mounts}}' ИМЯ_КОНТЕЙНЕРА
- 4. Проверьте доступность резервной копииНайдите последний дамп и подтвердите, что он открывается в изолированной тестовой БД. Для активной базы файловое копирование тома без согласованной остановки/снимка не гарантирует согласованность данных.
- 5. На копии сравните версии образаСоздайте тестовую копию данных (не оригинальный том), запустите образ прежней версии из своего манифеста. Если копия работает на старой версии, причина может быть в несовместимой миграции; обновляйте по официальной инструкции конкретной СУБД, а не переименованием каталогов.
- 6. Возобновите работу только по согласованному плануДля PostgreSQL может потребоваться pg_upgrade или логический экспорт/импорт; для MySQL и MariaDB — собственные процедуры перехода и совместимости. Выберите способ по точным версиям и проведите испытание восстановления. Не подставляйте чужие универсальные команды миграции.
- 7. Проверьте данные и приложение после запускаНа тестовой БД убедитесь, что количество таблиц и контрольные запросы совпадают с резервной копией. Затем проверьте приложение и свежие логи; если есть ошибки схемы или кодировки, миграцию нельзя считать успешной.
#Как проверить результат
Результат принят только после успешного запуска тестовой БД, проверки таблиц и приложения, а также утверждённого плана перехода на рабочей системе.
#Если проблема осталась
Не повторяйте опасные действия на рабочем окружении. Сравните первоначальный симптом с новым состоянием, сохраните обезличенные сообщения и версии компонентов, проверьте резервную копию; перед изменением общей истории Git или данных/сети Docker обратитесь к ответственному администратору проекта.