Как реализовать миграцию схемы для базы данных PostgreSQL

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

Например, в первой версии я создал несколько таблиц, затем во второй версии я переименовал некоторые столбцы, а в третьей версии я удалил одну таблицу и создал другую. У меня есть несколько серверов, и на некоторых из них у меня есть версия один, на некоторых версия три и т. д.

Моя идея:

  • Сгенерировать хеш для вывода, произведенного

pg_dump --только схема

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

  • Содержит список исправлений с соответствующим хэшем, к которому они должны применяться.
  • Когда мне нужно обновить мою базу данных, я запускаю приложение, которое будет искать хэш, соответствующий текущей структуре базы данных (путем вычисления хэша локальной базы данных и сравнения его с набором хэшей, который у меня есть) и применяю соответствующий патч.
  • Повторяйте, пока следующий хеш не будет найден.

Не могли бы вы указать какие-либо слабые стороны этого подхода?


person Paul    schedule 25.01.2020    source источник


Ответы (1)


Вы когда-нибудь слышали о https://pgmodeler.io? В компании, где я работаю, мы решили пойти на это, так как она может выполнять сравнение схем даже между локальным и удаленным. Мы очень довольны этим.

В противном случае, если вам больше нравится бесплатное решение, вы можете разработать инструмент миграции, который можно использовать для применения миграций, которые вы храните в одном репо. Кроме того, этот инструмент может полагаться на таблицу migration, которую вы храните в отдельной схеме, чтобы ваши БД всегда знали, какие миграции были применены, а какие нет.

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

Я надеюсь, что это может дать вам некоторые идеи.

person Luke    schedule 25.01.2020
comment
Спасибо за ваше предложение, но мы не можем использовать решение с графическим интерфейсом, и подход с таблицей миграции не дает никаких гарантий: кто-то может что-то изменить, не отражая это изменение в этой таблице. - person Paul; 25.01.2020
comment
Что, если единственный способ применить определенные миграции — это использовать инструмент, который также обновляет эту migration таблицу? Это может заставить протокол в команде :) - person Luke; 25.01.2020
comment
Да, это решило бы проблему, но команда довольно большая, разбросана по разным странам, разрешениями управляют несколько человек, да и уровень навыков тоже разный. Трудно следовать устному правилу. - person Paul; 26.01.2020
comment
Почти похоже на организационную проблему, если слишком многим людям разрешено вносить изменения в схему БД. Извините, что не очень помог, попробуйте эту связанную ссылку: stackoverflow.com/questions/175451/ - person Luke; 26.01.2020