Re: [pgsql-ru-general] Мультимастер репликация - Mailing list pgsql-ru-general

From Alexey Klyukin
Subject Re: [pgsql-ru-general] Мультимастер репликация
Date
Msg-id CAAS3tyJN6tPksviWyVJJgzN61S7RTJzJiwk8CDvH43xEM=AMEA@mail.gmail.com
Whole thread Raw
In response to Мультимастер репликация  (Alexander Bruy <voltron@ua.fm>)
List pgsql-ru-general
Добрый день,

Собственно если решать задачу в лоб, то есть 2 технологии:

- Bi-directional replication от 2ndQuadrant, которая работает как с модификациями данных, так и с модификацией схемы. Преимущества - должна быть настолько же проста, как и streaming replication, возможность реплицировать только одну базу. Недостатки - пока что продукт не предназначен для production, ориентирован на еще не вышедшую 9.4 с патчами от 2ndQ, то есть придется мигрировать на 9.4 beta + custom patches.

- Bucardo 5. Асинхронная мультимастер репликация, построенная на тригерах. Написан на Perl, слабо документирован, вышел пару месяцев назад.

Из двух решений на мой взгляд Bucardo обладает меньшим потенциалом потери данных и более приспособлена к слабым ненадежным каналам связи.

Насколько я помню Bucardo поддерживет промежуточные узлы: http://bucardo.org/wiki/Bucardo/makedelta

Я бы попробовал обойтись без репликации, тем более асинхронной мульти-мастер если возможно. Например, сделать данными с оновной базы доступной для филиалов с помощью postgresql fdw (как foreign tables), в 9.3 в них можно  записывать как на мастере, так и на филиалах.

2014-07-10 14:34 GMT+02:00 Alexander Bruy <voltron@ua.fm>:
Здравствуйте,

имеем следующую ситуацию. Есть некая территориально распределенная сеть
«филиалов» и один «центр». Связи между «филиалами» нет, но все они связаны
с «центром». На всех узлах этой звезды есть база данных, которую надо
поддерживать в максимально синхронном состоянии. Т.е.изменения, сделанные
в одном из «филиалов» должны попасть как в «центр», так и в другие «филиалы».
Аналогично, изменения из «центра» должны разойтись по всем «филиалам».

Как понимаю, из-за отсутствия связи между «филиалами», все измения должны
сначала приходить в «центр», а потом рассылаться на остальные узлы. Думали
ещё о варианте с настройкой маршрутизации так, чтобы все «филиалы» могли
видеть друг-друга через канал центра, но есть сомнения в целесообразности,
т.к. филиалов достаточно много, около 40.

Вопросов несколько:
 1. можно ли реализовать подобное на PostgreSQL, если да, то какими средствами?
     Сейчас присматриваемся к Bucardo, но может лучше взять что-то другое?
 2. можно ли пакеты изменений посылать не напрямую «филиал → центр» или наборот,
     а через промежуточные узлы «филиал → посредник 1 → посредник 2 → центр»?

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

--
Regards,
Alexey Klyukin

pgsql-ru-general by date:

Previous
From: Konstantin Tokar
Date:
Subject: Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] Мультимастер репликация
Next
From: Aleksey Smart
Date:
Subject: Замороженные соединения: postgres_fdw, dblink