Как стать автором
Обновить

Комментарии 4

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

Да ну? Само по себе повышение wal_level увеличивает объёмы записи в WAL. Отстающий слот логической репликации будет мешать работать автовакууму, да и logical decoding на хорошем потоке записи ресурсы занимает. Может быть сильно выгоднее именно использовать триггеры, чтобы не декодировать все изменения в СУБД ради отслеживания пары таблиц.
Заострю внимание: если вы хотите сделать CREATE PUBLICATION с всего одной табличкой — logical decoding будет декодировать абсолютно весь поток WAL с этой СУБД и просто отбрасывать изменения не связанные с этой таблицей. Именно так, а не наоборот, когда какой-то магией декодируются только изменения в этой таблице.

Ну а CREATE PUBLICATION и компания для test_decoding не нужны и не важны. Механизм публикаций и изменений работает через pgoutput плагин и именно для pub/sub этот плагин logical decoding и был создан. Предполагается что consumer так же postgresql, поэтому формат протокола бинарный, но, конечно, никто не мешает сделать совместимую реализацию consumer'а.

В целом же штук хороший и вполне удобный. Пожалуй стоит только отдельно упомянуть, что не надо добавлять в подписку таблички без primary key. База будет отвергать update и delete в такой табличке пока руками через создание pk или простановку replica identity не объясните, что делать с данными. Запись данных будет отклоняться именно на стороне publication базы. Нередкая история «как положить сервис»

Почитал оригинальную документацию и эту статью и не понял следующий момент.

Можно ли сделать цепочку логических репликаций? Примерно такую схему:

PG Master - logical replication -> PG Slave - logical replication -> Consumer

Т.е. чтобы репликация шла не с мастера, но со вторичной ноды.

Да, можно.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий