Дам баз: чек-лист проверки целостности перед миграцией
Перед миграцией базы данных недостаточно убедиться, что дамп создался и файл открывается. Нужно подтвердить, что данные полностью перенесены, ограничения схемы соблюдены, а приложение после восстановления получает ожидаемые результаты.
Иначе успешный деплой может закончиться потерянными строками, ошибками внешних ключей или расхождением между старой и новой системами.
Запрос «дам баз» неоднозначен. В контексте миграции обычно имеют в виду дамп базы данных и его проверку перед восстановлением. Ниже речь именно об этом: как построить проверку целостности, какие ограничения учесть и где заканчиваются гарантии конкретных инструментов.
1. Сначала определите способ переноса
Порядок проверок зависит от того, что именно переносится. Логический дамп, физические файлы каталога PostgreSQL и потоковая репликация создают разные условия для совместимости и валидации. Смешивать их в один сценарий нельзя.
Для переноса файлов PGDATA, то есть каталога с данными PostgreSQL, критичны параметры исходной и целевой среды. В документации Percona для таких способов переноса указано совпадение архитектуры процессора и основной версии PostgreSQL. Если эти условия не соблюдаются, следует выбирать логический перенос через pg_dump и pg_restore, а не пытаться повторно использовать файлы кластера.
Логический дамп переносит данные и структуру средствами PostgreSQL. Это не снимает вопрос совместимости: версию исходной и целевой СУБД, расширения, кодировки, типы и поведение приложения всё равно нужно сверить заранее. Физический перенос, напротив, теснее связан с конкретным кластером и его окружением.
До создания копии зафиксируйте исходное состояние:
- версию СУБД и её основную версию;
- архитектуру CPU, если переносите файлы каталога данных;
- состав баз, схем, таблиц и расширений;
- наличие первичных и уникальных ключей;
- способ фиксации изменений, которые продолжат поступать во время миграции;
- требования приложения к транзакциям, ограничениям и порядку обновления данных.
Последний пункт часто определяет саму схему переключения. Если система продолжает принимать записи, сравнение исходной и целевой баз в один произвольный момент может показать расхождения, вызванные обычной активностью приложения. Для таких сценариев нужен согласованный момент сравнения или механизм доставки последующих изменений. В AWS DMS, например, при сценарии CDC проверка может сравнивать изменения по мере их поступления. Это помогает отслеживать репликацию, но не отменяет проверки состояния после полной загрузки.
Способ переноса задаёт границы совместимости. Сначала фиксируют эти границы, потом выбирают инструмент проверки.
2. Проверяйте дамп и восстановление, а не только файл
Дамп базы данных — артефакт для восстановления. Его наличие на диске не доказывает, что восстановление завершится и даст корректное состояние. Проверяемый процесс включает создание копии, восстановление в отдельную среду и сравнение результатов.
Для дампа через CLI полезно сохранять не только файл, но и сведения о его происхождении: дату создания, источник, версии утилит и СУБД, параметры запуска, статус завершения операции. Это часть аудита миграции. Если при создании дампа произошёл сбой, один файл без журнала не даст надёжного ответа, на каком этапе он появился и что в него попало.
Проверка должна пройти как минимум по четырём слоям:
1. Файл и операция. Убедитесь, что команда создания дампа завершилась штатно, файл доступен для чтения, а журналы не содержат ошибок. Размер файла сам по себе не подтверждает полноту данных.
2. Восстановление. Разверните копию в отдельной тестовой базе. Зафиксируйте ошибки импорта, пропущенные объекты и несовместимости функций или расширений.
3. Структура. Сверьте таблицы, индексы, ограничения и другие объекты, которые нужны приложению. Наличие таблицы ещё не гарантирует, что на месте её ключи и ограничения.
4. Данные и поведение. Сравните содержимое и выполните запросы, отражающие реальные сценарии приложения: чтение, выборки по ключам, проверки связей и операции записи в контролируемой среде.
Если восстановление прерывается, не считайте частично заполненную базу кандидатом на переключение. Сначала установите, где возникла ошибка, исправьте причину и повторите восстановление либо явно определите процедуру продолжения. Иначе повторный запуск может наложить новые данные на остатки неудачной попытки.
Заранее подготовьте перечень контрольных запросов. В нём могут быть агрегаты по ключевым таблицам, проверки диапазонов дат, поиск строк без связанных записей и выборки по бизнес-критичным идентификаторам. Универсальный набор запросов не существует: запрос должен соответствовать модели данных и правилам конкретного приложения.
Результаты сравнения следует сохранять вместе с параметрами запуска. Это позволяет отличить реальное расхождение от разницы в моменте снимка, фильтрах, преобразованиях или окружении. Если запросы выполняются на живой системе, отдельно учитывайте, что новые транзакции способны изменить результат уже после снятия показаний.
3. Контрольные суммы PostgreSQL: что они подтверждают
В PostgreSQL контрольные суммы данных по умолчанию выключены. При включении контрольная сумма записывается для каждой страницы данных и проверяется при чтении. Настройка действует на уровне всего кластера.
Для проверки контрольных сумм кластера используется pg_checksums. Сервер должен быть корректно остановлен. В PostgreSQL 17 код завершения утилиты равен нулю, если ошибок не обнаружено, и ненулевому значению, если найдена хотя бы одна ошибка.
Это полезная проверка физической целостности страниц, но её нельзя трактовать как полную валидацию миграции. Она не подтверждает корректность бизнес-данных, наличие всех ожидаемых строк, совместимость схемы и успешную работу приложения. Контрольные суммы также не следует представлять как проверку всех файлов и структур СУБД: область их действия ограничена страницами данных, а внутренние структуры и временные файлы не входят в эту гарантию.
Перед использованием pg_checksums определите, включены ли контрольные суммы в исходном кластере и какие именно данные проверяются. Включить контрольные суммы для существующего кластера можно офлайн с помощью pg_checksums --enable, однако такое включение не выявит повреждения, возникшие до момента его запуска. Для страниц, записанных без защиты, история их повреждений уже не поддаётся ретроспективной проверке. При переносе важно отдельно установить, на какой стороне запускается утилита и соответствует ли проверяемый каталог конкретному кластеру, а также зафиксировать, был ли кластер переведён в режим контрольных сумм до или после записи проблемных страниц.
В практическом плане результат pg_checksums отвечает на узкий вопрос: обнаружены ли ошибки контрольных сумм у проверяемых страниц. Для полной проверки рядом нужны другие методы:
- сравнение строк или агрегатов между источником и целью;
- проверка ключей и ограничений;
- выполнение контрольных SQL-запросов;
- восстановление копии и тестирование приложения;
- проверка журналов миграционного инструмента.
Один зелёный статус утилиты не заменяет эту цепочку.
4. Сверка через AWS DMS и её ограничения
AWS DMS умеет сравнивать строки исходной и целевой баз и сообщать о несовпадениях. При полной загрузке проверка начинается после загрузки таблицы; в CDC-сценарии изменения могут проверяться по мере поступления.
Для работы проверки таблице нужен первичный ключ или уникальный индекс. Кроме того, проверка значений NULL в колонках первичного или уникального ключа не поддерживается. Это ограничение важно обнаружить до запуска, а не после того, как часть таблиц уже проверена, а часть осталась без валидации.
У ключевых колонок типов VARCHAR или CHAR длина должна быть меньше 1024, причём длина типа должна быть указана. Поддержка зависит от типа данных и конфигурации. Поэтому перед массовым запуском следует составить перечень таблиц, которые инструмент сможет проверять, и отдельно отметить таблицы с неподдерживаемыми или неподходящими ключами.
Сверка создаёт дополнительные запросы к обеим базам. Она расходует вычислительные и сетевые ресурсы и увеличивает общее время миграции. Это нужно включать в план нагрузки. Если сравнение запущено на загруженной системе без оценки влияния, проверка может конкурировать с рабочими запросами за ресурсы.
В AWS DMS действует и порог остановки: если обнаружено более 10 000 записей с ошибкой проверки или приостановленной проверкой, сервис прекращает проверку. Это особенность AWS DMS, а не общий предел миграций или других продуктов. При достижении порога следует найти первопричину и исправить основные проблемы с данными до продолжения.
Проверяйте результаты не только по общему статусу задачи. Разбирайте расхождения по таблицам и типам ошибок. Большое число несовпадений может указывать на неверное сопоставление схем, неполную загрузку, активные записи на источнике или особенности преобразования данных. Повторный запуск без диагностики способен лишь увеличить нагрузку, не исправив источник проблемы.
5. Изолированное тестирование и производительность
Запросы для проверки лучше подготовить до миграции и выполнить в изолированной тестовой среде. Такой подход рекомендует Microsoft: сравнивать результаты на исходной и целевой базах, анализировать их и отдельно оценивать производительность.
Изоляция нужна по двум причинам. Во-первых, тесты не должны создавать побочные изменения в рабочей базе. Во-вторых, результаты сравнения должны быть воспроизводимыми. Если на одном окружении запрос выполняется по рабочим данным, которые меняются каждую секунду, а на другом по снимку после миграции, расхождение может быть вызвано разницей во времени, а не потерей данных.
Подготовьте матрицу проверок с одинаковыми входными условиями для обеих сторон:
| Проверка | Что сравнивать | Что может объяснить расхождение |
|---|---|---|
| Число строк | Количество записей в выбранных таблицах | Фильтры, неполная загрузка, новые записи |
| Ключевые выборки | Наличие конкретных идентификаторов и связанных объектов | Пропуск строки, преобразование ключа, отличие момента снимка |
| Ограничения | Первичные и уникальные ключи, внешние связи | Не загруженные зависимости, различие схем |
| Агрегаты | Суммы, минимальные и максимальные значения, распределение по датам | Ошибка преобразования типа, округление, различие набора строк |
| Запросы приложения | Результаты типовых чтений и операций | Несовместимость схемы, индексов или логики |
Эта таблица не задаёт универсальных допусков. Для всех СУБД и инструментов единого порога расхождений нет. Допустимое значение определяется бизнес-правилами: в одной таблице любая потерянная запись критична, в другой допустима задержка доставки событий. Такой порог нужно согласовать до переключения, иначе команда будет трактовать результаты постфактум.
Отдельно сравните производительность. Один и тот же SQL-запрос может возвращать идентичные строки, но выполняться на целевой базе существенно дольше из-за различий в индексах, статистике, настройках или ресурсах. Зафиксируйте время выполнения и нагрузку в одинаковых условиях. Если замеры делались на разных объёмах данных или при разной конкурирующей нагрузке, прямое сравнение будет слабым доказательством.
6. Как разбирать ошибки и принимать решение о переключении
Проверка целостности полезна только тогда, когда у ошибки есть владелец и следующий шаг. Для каждого типа расхождения задайте процедуру: остановить проверку, собрать детали, классифицировать проблему, исправить её и повторить соответствующую проверку. Не сводите все ошибки к одному статусу «миграция не прошла».
При расхождении строк проверьте, совпадают ли условия сравнения и момент фиксации данных. При нарушении ограничений разберите порядок загрузки зависимых таблиц и соответствие схем. При ошибке контрольной суммы остановите использование повреждённого состояния и исследуйте конкретный кластер. При несовпадении результатов приложения проверьте запросы, расширения и преобразования, а не только перенос записей.
Для AWS DMS превышение порога в 10 000 ошибок или приостановленных проверок означает, что сервис остановит проверку. Не следует пытаться обходить этот предел дроблением задачи без понимания причины. Сначала определите, какие таблицы и ошибки формируют счётчик, устраните системную причину и только после этого продолжайте. Иначе повторная проверка снова упрётся в тот же предел.
К моменту переключения должны быть готовы подтверждения по нескольким независимым направлениям: восстановление завершилось, критичные таблицы сверены, ограничения не нарушены, запросы приложения прошли, а измерения производительности укладываются в требования системы. Ни один отдельный инструмент не выдаёт универсальный сертификат корректности. Доказательство складывается из результатов разных проверок и их воспроизводимости.
Перед миграцией зафиксируйте итоговый список ограничений:
- физический перенос файлов PostgreSQL требует совместимости архитектуры CPU и основной версии; при несовпадении используйте логический перенос;
pg_checksumsпроверяет контрольные суммы страниц данных, но не бизнес-логику и не все внутренние структуры, причём офлайн-включение контрольных сумм не покрывает повреждения, возникшие до его запуска;- проверка AWS DMS требует первичного ключа или уникального индекса и имеет ограничения по типам и конфигурации;
- автоматическая сверка создаёт дополнительную нагрузку и увеличивает время миграции;
- успешное сравнение данных не подтверждает автоматически совместимость приложения и производительность;
- универсального допустимого порога расхождений для всех баз нет.
Решение о переключении должно опираться на спецификацию проверок, результаты восстановления и согласованные критерии расхождения. Если команда не может объяснить обнаруженное отличие, целевая база ещё не готова к роли рабочей.