Thread: Мультимастер репликация

Мультимастер репликация

From
Alexander Bruy
Date:
Здравствуйте,

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

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

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

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

Спасибо

-- реклама -----------------------------------------------------------
Изысканное нижнее бельё от 50 грн!
Anabel Arto со скидкой 75% по ссылке http://bit.ly/anabelMK


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

From
Borodin Vladimir
Date:
Доброго времени суток.

Почему нельзя писать исключительно в центр, а читать из реплики филиала? Кажется, эта схема сильно проще той, что вы описали.

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




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

From
Alexander Bruy
Date:
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

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

From
Alexander Bruy
Date:
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] Мультимастер репликация

From
Aln Kapa
Date:
связь плохая это проблема, синхронизация будет постоянно рваться, а восстанавливать придется иногда и полными дампами, чудес не бывает.
А 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
>
>

Из их документации:

Syncing all nodes

Pending.


То есть самое интересное отсутствует?

С уважением,
 Константин Токар
 ФГУП "Морсвязьспутник"
 7 (495) 967-18-50 доб.528


11 июля 2014 г., 18:17 пользователь Oleg Bartunov <obartunov@gmail.com> написал:
А BDR не смотрели ?
http://us4.campaign-archive2.com/?u=46877e21b2a3b51f2f7e32d71&id=73c639b7bf

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

From
Alexey Klyukin
Date:
Добрый день,

Собственно если решать задачу в лоб, то есть 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