Re: [pgsql-ru-general] Мультимастер репликация
| От | Alexey Klyukin |
|---|---|
| Тема | Re: [pgsql-ru-general] Мультимастер репликация |
| Дата | |
| Msg-id | CAAS3tyJN6tPksviWyVJJgzN61S7RTJzJiwk8CDvH43xEM=AMEA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Мультимастер репликация (Alexander Bruy <voltron@ua.fm>) |
| Список | pgsql-ru-general |
Добрый день,
- 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 по дате отправления: