#database #postgresql #migration #flyway
#База данных #postgresql #миграция #пролетный путь
Вопрос:
В настоящее время у меня есть 2 базы данных, используемые 2 службами (назовем их database / service A и database / service B), обе со своими собственными схемами.
Мне нужно перенести некоторые таблицы из базы данных A в базу данных B, как только все будет завершено, перенаправьте службу A на службу B. Я знаю, что можно легко выполнить миграцию схемы с помощью утилиты pg_dump, и это кажется «легким».
Проблема, с которой я сталкиваюсь, заключается в том, что обе службы используют пролетный путь для управления версиями базы данных, поэтому, когда я переназначаю службу A в DB B, возникает множество миграций, которые сталкиваются с одним и тем же номером версии из-за несоответствия контрольной суммы.
Я видел, что в Flyway есть «базовая» функциональность (https://flywaydb.org/documentation/command/baseline ), но на первый взгляд кажется, что это не то, что мне нужно.
Как я мог решить эту проблему?
Комментарии:
1. Это также связано с другой интересной задачей … как обрабатывать 2 разных набора миграций
Ответ №1:
При первом рассмотрении этой проблемы немедленный ответ заключается в том, что ваш переход от DbB к DbA выполняется с помощью одной миграции поверх существующих миграций в DbA. Вы не пытаетесь изменить базу данных вне процесса пролетного пути. Вместо этого вы включаете процесс пролетного пути в изменение своей базы данных. Flyway не зависит от набора вносимых вами изменений. Итак, вы просто добавляете еще одно изменение в существующий набор. Это не должно приводить к восстановлению или базовой линии для достижения требуемой точки.
Допустим, последняя миграция для администратора базы данных — V6.3__XXX, мы просто добавляем V6.4__MigratingDbB в нашу цепочку изменений. В этом скрипте есть необходимый набор изменений. Это должно сработать.
Комментарии:
1. Спасибо, Грант, теперь я думаю, что это, вероятно, лучший вариант, меня больше беспокоило, как сохранить 2 набора миграций в 2 службах, но я не думаю, что это хорошая идея. Что я собираюсь сделать, так это: создать новую миграцию (в службе B), содержащую все изменения схемы DB A, для репликации таблиц, которые мне нужны в DB B, применить миграцию, удалить данные из этих таблиц, отключить пролет в службе A, перенаправить службу A в DB B.
2. Мне кажется, это правильный подход. Я бы на всякий случай некоторое время сохранял историю в БД A в системе управления версиями.
3. Я согласен, это тоже был мой план. Сохранение истории всех примененных миграций не повредит.
Ответ №2:
Ответ Гранта, безусловно, лучший, но альтернативное решение, если объекты базы данных для двух служб полностью независимы, состоит в том, чтобы иметь две конфигурации пролетных путей, которые ссылаются на коллекции сценариев для каждой службы и имеют разные таблицы истории. Проблема в том, что между двумя службами существуют зависимости; тогда при миграции из одной службы потребуется знать текущее состояние игры в другой, что может привести к путанице при их фактическом выполнении.
Комментарии:
1. Да, Джулия, к сожалению, это ситуация, или лучше, она станет такой, как вы говорите. Я объясняю: причина слияния заключается в том, что службы A и B независимы (как и схемы БД, которые они используют). Однако причина этого «слияния схем» заключается в том, что нам нужно объединить базы данных, а также службы, чтобы они стали одним сервисом. В конце концов, рефакторинг таблиц так, чтобы они имели отношения друг к другу. Следовательно, мне нужно иметь только одну коллекцию сценариев и фактически одну таблицу истории.