Rinka777Melkij,
я правильно поняла, что логическая реплика только insert update delete переносит? alter table не переносит?

Да.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

Rinka777Maxim Boguk, какой ужас.

А 10 postgresql не полегчало?

И не полегчает. Можно или все таблицы с структурой реплицировать на физическом уровне или данные на логическом уровне (но тогда синхронизация структуры - на админах).
В этом нет ничего странного там просто проблема в общем случае неразрешимая (репликация DDL).

Как правило никаких проблем это не устраивает кроме случая очень ленивых DBA и/или отсутствия формализованного процесса внесения изменений в структуру базы.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

Rinka777Maxim Boguk, да написала уже скрипты на сравнение и исправление структуры. Смущает только возможная рассинхронность действий.


"отсутствия формализованного процесса внесения изменений в структуру базы" - вот это оно и есть.
Откуда и кто мимо DBA может вносить изменения в структуру базы? И почему эти шаловливые ручки не оторвать.
Если у вас логическая или триггерная репликация - все изменения в структуру должны вносится с учетом этого.

Вот внес кто то alter sometable add column somecolumn1 integer default 10;
А потом кто то другой внес
alter sometable add column somecolumn2 integer;
alter sometable alter somecolumn2 set default 10;

Вот как ваш скрипт будет определять какой из 2х вариантов использовался (структура на выходе одна а вот данные в колонках совсем разные будут)?

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

PS: а еще есть милейшая конструкция типа
alter table sometable add column SOMECOLUMN default random();
которую никаким внятным методом нельзя отреплицировать кроме как на физическом уровне.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

Rinka777Maxim Boguk,

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

Ну вот я и пишу вам что после:
alter sometable add column somecolumn integer default 10;

и после

alter sometable add column somecolumn integer;
alter sometable alter somecolumn set default 10;

Метаданные строго одинаковы будут, а вот данные в таблице совсем разные будут.
И таких сценариев с метаданными - можно быстро сотню набросать.

Т.е. не будет этот велосипед работать с разумной надежностью.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

SeventhSonавтори после
alter sometable add column somecolumn integer;

выдаст ошибку что somecolumn уже есть.
придётся его дропнуть и ... далее по тексту.
или я чего-то не понимаю?
что же мешает реплицировать DDL? может это просто стереотип мышления? "нельзя, никто так раньше не делал" ;)


Нет я имел в виду что вот эти два варианта команд дают одинаковые метаданные на выходе.
Но совсем разные данные в таблице по итогам выполнения.
И на уровне метаданных отличить одно от другого - не возможно.

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

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

Rinka777Maxim Boguk,

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

Вот вам еще пример последовательности команд которые вы по сравнению метаданных не разрулите.



И расскажите как ваше сравнение метаинформации будет с такими случаями справляться.
А если там оно то работает то нет и надо все время руками смотреть не сломалось ли чего - проще требовать все изменения таблиц соответствующих к вам отправлять (все вносимые DDL на prod) - и вы уже будете смотреть что вносить на вашу реплику.

PS: я еще раз обьясняю что это ОРГАНИЗАЦИОННЫЙ блин вопрос а не технологический.

SeventhSonМаксим,

а если DDL заложено в архитектуру приложения и никак это не выпилить? ну вот так извратились девелоперы.
мало того, даже create database есть.
разве нельзя последний пример завернуть в одну транзакцию и отправить на реплику как есть, логической командой?

Логическая репликация в postgresql - это не репликация sql команд с мастера (потому что это не работает) а репликация изменений в конкретных строках конкретной таблицы.
В итоге когда есть каша из DML и DDL - ее и как единую транзакцию не передать и как изменения строк не передать.

Ну и пример - в эту миграцию добавлено еще изменения какой то второй таблицы которой на реплике просто нет (не реплицируется она туда) - как вы предлагаете это на реплике проигрывать?

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

Dimitry SibiryakovMaxim BogukВ этом нет ничего странного там просто проблема в общем случае неразрешимая (репликация DDL).
Ну, не всё так страшно, хотя подводных граблей немало. Всё в основном упирается в CDC.

Упирается в возможность использования volatile функций в DDL (помимо всего прочего).
Предложите внятый алгоритм репликации вот такого DDL:
alter table sometable add column SOMECOLUMN default random() ;

:)

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru

Rinka777а вот такая мысль... в порядке бреда...

есть ли такая функция в postgres которая на лету делает вертикальную структуру? Что-то типа Pivot, Unpivot
можно было бы все это складывать в вертикальную таблицу а потом разворачивать назад. без велосипедов самодельных.

что скажете, опытные товарищи?

Вам для хранения данных или для отображения надо?
Если для хранения то citus (только он не бесплатный местами).
Если для отображения то https://www.postgresql.org/docs/10/static/tablefunc.html

PS: такие вопросы надо отдельным топиком задавать.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru