Comments 4
ощущение некоторой недосказанности.
Что дальше стоит делать с этой инфой? Сюда будут приходить только евенты по таблице с конфигом или вообще всё? Если вообще всё, то по конфигурационному каналу мы получим поток информации о всём потоке данных?
Что дальше стоит делать с этой инфой? Сюда будут приходить только евенты по таблице с конфигом или вообще всё? Если вообще всё, то по конфигурационному каналу мы получим поток информации о всём потоке данных?
Да, будут приходить изменения только по тем нужным таблицам, которые включены в публикацию/publication.
При создании публикации добавляем в нее только нужные таблицы (может быть добавлено несколько таблиц), запускаем репликацию в Erlang, как описано в этой статье.
Далее при любом изменении (insert/update/delete) по заданным таблицам в БД в Erlang будет приходить информация об этих изменениях.
Информацию по изменениям других таблиц, не включенных в публикацию, будет отфильтрована на стороне PostgreSQL.
Этот подход можно использовать для поддержания кэша данных в Erlang в консистентном и актуальном состоянии. PostgreSQL будет посылать изменения сразу как они произошли, в том же порядке, как они происходили. Пример есть в библиотеке, ссылка на которую была в конце статьи
При создании публикации добавляем в нее только нужные таблицы (может быть добавлено несколько таблиц), запускаем репликацию в Erlang, как описано в этой статье.
Далее при любом изменении (insert/update/delete) по заданным таблицам в БД в Erlang будет приходить информация об этих изменениях.
Информацию по изменениям других таблиц, не включенных в публикацию, будет отфильтрована на стороне PostgreSQL.
Этот подход можно использовать для поддержания кэша данных в Erlang в консистентном и актуальном состоянии. PostgreSQL будет посылать изменения сразу как они произошли, в том же порядке, как они происходили. Пример есть в библиотеке, ссылка на которую была в конце статьи
существует подобная реализация на elixir?
Sign up to leave a comment.
Логическая репликация из PostgreSQL в Erlang