Thread: Мультимастер репликация
Здравствуйте, имеем следующую ситуацию. Есть некая территориально распределенная сеть «филиалов» и один «центр». Связи между «филиалами» нет, но все они связаны с «центром». На всех узлах этой звезды есть база данных, которую надо поддерживать в максимально синхронном состоянии. Т.е.изменения, сделанные в одном из «филиалов» должны попасть как в «центр», так и в другие «филиалы». Аналогично, изменения из «центра» должны разойтись по всем «филиалам». Как понимаю, из-за отсутствия связи между «филиалами», все измения должны сначала приходить в «центр», а потом рассылаться на остальные узлы. Думали ещё о варианте с настройкой маршрутизации так, чтобы все «филиалы» могли видеть друг-друга через канал центра, но есть сомнения в целесообразности, т.к. филиалов достаточно много, около 40. Вопросов несколько: 1. можно ли реализовать подобное на PostgreSQL, если да, то какими средствами? Сейчас присматриваемся к Bucardo, но может лучше взять что-то другое? 2. можно ли пакеты изменений посылать не напрямую «филиал → центр» или наборот, а через промежуточные узлы «филиал → посредник 1 → посредник 2 → центр»? Да, ещё, базы содержат пространственные данные (PostGIS), и каждый филиал в основном редактирует только часть, относящуююся к его сфере ответственности. Т.е. теоретически ситуаций, когда в разных филиалах одновременно правят одну и ту же строку таблицы быть не должно Спасибо -- реклама ----------------------------------------------------------- Изысканное нижнее бельё от 50 грн! Anabel Arto со скидкой 75% по ссылке http://bit.ly/anabelMK
Доброго времени суток.
--
Почему нельзя писать исключительно в центр, а читать из реплики филиала? Кажется, эта схема сильно проще той, что вы описали.
10 июля 2014 г., в 16:34, Alexander Bruy <voltron@ua.fm> написал(а):
Здравствуйте,
имеем следующую ситуацию. Есть некая территориально распределенная сеть
«филиалов» и один «центр». Связи между «филиалами» нет, но все они связаны
с «центром». На всех узлах этой звезды есть база данных, которую надо
поддерживать в максимально синхронном состоянии. Т.е.изменения, сделанные
в одном из «филиалов» должны попасть как в «центр», так и в другие «филиалы».
Аналогично, изменения из «центра» должны разойтись по всем «филиалам».
Как понимаю, из-за отсутствия связи между «филиалами», все измения должны
сначала приходить в «центр», а потом рассылаться на остальные узлы. Думали
ещё о варианте с настройкой маршрутизации так, чтобы все «филиалы» могли
видеть друг-друга через канал центра, но есть сомнения в целесообразности,
т.к. филиалов достаточно много, около 40.
Вопросов несколько:
1. можно ли реализовать подобное на PostgreSQL, если да, то какими средствами?
Сейчас присматриваемся к Bucardo, но может лучше взять что-то другое?
2. можно ли пакеты изменений посылать не напрямую «филиал → центр» или наборот,
а через промежуточные узлы «филиал → посредник 1 → посредник 2 → центр»?
Да, ещё, базы содержат пространственные данные (PostGIS), и каждый филиал
в основном редактирует только часть, относящуююся к его сфере ответственности.
Т.е. теоретически ситуаций, когда в разных филиалах одновременно правят одну и
ту же строку таблицы быть не должно
Спасибо
-- реклама -----------------------------------------------------------
Изысканное нижнее бельё от 50 грн!
Anabel Arto со скидкой 75% по ссылке http://bit.ly/anabelMK
--
Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ru-general
--
Vladimir
10.07.2014 15:46, Borodin Vladimir <root@simply.name> > Почему нельзя писать исключительно в центр, а читать из реплики филиала? Кажется, эта схема сильно проще той, что вы описали. Таково требование заказчика, и переубедить его пока никак не удаётся. -- реклама ----------------------------------------------------------- Изысканное нижнее бельё от 50 грн! Anabel Arto со скидкой 75% по ссылке http://bit.ly/anabelMK
"максимально синхронном состоянии" -- это как часто.
"но все они связаны с «центром»" -- по подробнее что за связь.
10 июля 2014 г., 18:02 пользователь Alexander Bruy <voltron@ua.fm> написал:
10.07.2014 15:46, Borodin Vladimir <root@simply.name>> Почему нельзя писать исключительно в центр, а читать из реплики филиала? Кажется, эта схема сильно проще той, что вы описали.Таково требование заказчика, и переубедить его пока никак не удаётся.
-- реклама -----------------------------------------------------------
Изысканное нижнее бельё от 50 грн!
Anabel Arto со скидкой 75% по ссылке http://bit.ly/anabelMK
--
Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ru-general
10.07.2014 15:46, Borodin Vladimir <root@simply.name> > Почему нельзя писать исключительно в центр, а читать из реплики филиала? Кажется, эта схема сильно проще той, что вы описали. Это требование заказчика. Пока переубедить не удается. 10.07.2014 17:08, Aln Kapa <alnkapa@gmail.com> >"максимально синхронном состоянии" -- это как часто. Это максимально одинаковые базы на всех узлах. Временные рамки не оговорены, но небольшое расхождение, скажем пара-тройка транзакций допустимо. > "но все они связаны с «центром»" -- по подробнее что за связь. Связь по слабому интернет-каналу. Центр находится в Москве, а филиалы разнесенны территориально, например, один из них на Камчатке. -- реклама ----------------------------------------------------------- Изысканное нижнее бельё от 50 грн! Anabel Arto со скидкой 75% по ссылке http://bit.ly/anabelMK
связь плохая это проблема, синхронизация будет постоянно рваться, а восстанавливать придется иногда и полными дампами, чудес не бывает.
А 40 филиалов это проблема * 40.
Может есть решение, если к примеру синхронизировать информацию не физикой а логикой. На уровне приложения к примеру.
11 июля 2014 г., 10:18 пользователь Alexander Bruy <voltron@ua.fm> написал:
10.07.2014 15:46, Borodin Vladimir <root@simply.name>Это требование заказчика. Пока переубедить не удается.
> Почему нельзя писать исключительно в центр, а читать из реплики филиала? Кажется, эта схема сильно проще той, что вы описали.
10.07.2014 17:08, Aln Kapa <alnkapa@gmail.com>>"максимально синхронном состоянии" -- это как часто.Это максимально одинаковые базы на всех узлах. Временные рамки не
оговорены, но небольшое расхождение, скажем пара-тройка транзакций
допустимо.Связь по слабому интернет-каналу. Центр находится в Москве, а филиалы
> "но все они связаны с «центром»" -- по подробнее что за связь.
разнесенны территориально, например, один из них на Камчатке.
-- реклама -----------------------------------------------------------
Изысканное нижнее бельё от 50 грн!
Anabel Arto со скидкой 75% по ссылке http://bit.ly/anabelMK
А BDR не смотрели ? http://us4.campaign-archive2.com/?u=46877e21b2a3b51f2f7e32d71&id=73c639b7bf 2014-07-11 10:55 GMT+04:00 Aln Kapa <alnkapa@gmail.com>: > связь плохая это проблема, синхронизация будет постоянно рваться, а > восстанавливать придется иногда и полными дампами, чудес не бывает. > А 40 филиалов это проблема * 40. > > Может есть решение, если к примеру синхронизировать информацию не физикой а > логикой. На уровне приложения к примеру. > > > > > 11 июля 2014 г., 10:18 пользователь Alexander Bruy <voltron@ua.fm> написал: > >> 10.07.2014 15:46, Borodin Vladimir <root@simply.name> >> > Почему нельзя писать исключительно в центр, а читать из реплики филиала? >> > Кажется, эта схема сильно проще той, что вы описали. >> >> Это требование заказчика. Пока переубедить не удается. >> >> 10.07.2014 17:08, Aln Kapa <alnkapa@gmail.com> >> >"максимально синхронном состоянии" -- это как часто. >> >> Это максимально одинаковые базы на всех узлах. Временные рамки не >> оговорены, но небольшое расхождение, скажем пара-тройка транзакций >> допустимо. >> >> > "но все они связаны с «центром»" -- по подробнее что за связь. >> >> Связь по слабому интернет-каналу. Центр находится в Москве, а филиалы >> разнесенны территориально, например, один из них на Камчатке. >> >> -- реклама ----------------------------------------------------------- >> Изысканное нижнее бельё от 50 грн! >> Anabel Arto со скидкой 75% по ссылке http://bit.ly/anabelMK > >
Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [pgsql-ru-general] Мультимастер репликация
From
Konstantin Tokar
Date:
Из их документации:
Syncing all nodes
Pending.
То есть самое интересное отсутствует?
11 июля 2014 г., 18:17 пользователь Oleg Bartunov <obartunov@gmail.com> написал:
А BDR не смотрели ?
http://us4.campaign-archive2.com/?u=46877e21b2a3b51f2f7e32d71&id=73c639b7bf
Добрый день,
- 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