Перенос таблиц из одной бд в другую в postgresql?

Question

[Wayne1212121]

Всем доброго дня!
Как реализовать перенос схемы таблиц в другую бд?

Например в db1 есть table_user с сотнями данных, а в db2 его нет. Нужно, чтобы table_user перешел в db2, но без данных, нужно чтобы она просто создалась.
И второй вариант событий: в db1 и db2 есть table_user, но у db1 table_user появилось 20 новых колонок, как их передать в более легком виде db2 table_user?

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

Помогите пожалуйста, может есть инфа где можно об этом почитать. Буду благодарен любой помощи!

Comments

[ayazer]

вам про миграции нужно гуглить

[Wayne1212121]

ayazer, можно полезную ссылку, пожалуйста?

[ayazer]

Wayne1212121, щас, я попробую собрать все мысли в кучу и оформить их в виде полноценного ответа

Answer 1

[ayazer]

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

1. можно использовать тулзы для генерации дифоф а-ля https://github.com/djrobstep/migra

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

2. чтоб автоматизировать накатывание дифов на базу - можно использовать flyway (или любой другой аналог). суть проста - оно ведет историю выполненых миграций, при запуске приложение - применяет все новые в правильном порядке

3. в момент когда данных становится много - оно теряет актуальность т.к. на практике все миграции все-равно выполняется ручками (т.е. не запустил-и-забыл). (дальше мой опыт касается больше майскля, т.к. в постгресе у нас нет многотерабайтных таблиц) основная проблема тут - изменения таблицы = лок = аутейдж, чего допускать нельзя. потому для того, чтоб внести изменения - надо создать новую таблицу с новой схемой, перелить в нее все старые данные, синхронизировать все новые данные, поменять таблицы местами и дропнуть старую. тут помогает тулкит перконы и гитхаба (pt-online-schema-change и gh-ost), которые это все автоматизируют. Но обе они заточены под майскл, для постгреса надо искать и тестировать (ну или может кто-то уточнит)

Answer 2

[alexalexes]

В общем случае, вам нужно подучить, чем отличаются
а) запросы, которые модифицируют архитектуру базы (Create table, Alter Table, Create index и т.д.)
б) от запросов, которые работают с данными текущей архитектуры (SELECT, INSERT, UPDATE, DELETE).

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

Например в db1 есть table_user с сотнями данных, а в db2 его нет. Нужно, чтобы table_user перешел в db2, но без данных, нужно чтобы она просто создалась.

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

И второй вариант событий: в db1 и db2 есть table_user, но у db1 table_user появилось 20 новых колонок, как их передать в более легком виде db2 table_user?

Тут посложней.
Изучайте alter table add column и применяйте его для недостающих колонок. Не забудьте из дампа взять запросы, которые создают или модифицируют другие объекты, связанные с новыми колонками.

Comments

[Wayne1212121]

А разве нет решения попроще?
Каждый раз фильтровать sql файл не автономный вариант :)