Thread: Асинхронная мульти-мастер репликация. Возможные проблемы и решения

simplevolk@gmail.com wrote:
> Здравствуйте!
> У меня вопрос- как в новой версии PostgreSQL обстоит с мультимастер
> репликацией?

Простите, а зачем?

Имхо - это зло, и поиск приключений на свою жопу.
При интенсивных записях  избыточные  расходы на  синхронизацию
мастер-мастер слишком существенны,
причем растут экспоненциально в зависимости от колличества серверов в
группе репликации.


> Я порыл в инете этот вопрос накопал,что в общем случае проблема не
> решена,решена только в частных.
>
> Накопал также и то,что там есть 3 возможных конфликта репликации-
>
> 1. Ошибка обновления
> 2. Конфликт уникальности.
> 3. Конфликт удаления.
>
> Скажите, эти проблемы до сих пор актуальны?Решены ли они в новой версии?

Никакие  продвинутые механизмы разрешения репликационных конфликтов не
могут гарантировать 100% консистентность данных,
посему не лучше ли избрать по возможности более простую архитектуру?


>
>
> Спасибо.

Successful story подобного?

Отказоустойчивость в режиме мультимастер ? шутить изволите ;)
Мультимастер между различными датацентрами - шутка еще похлеще первой.



Виктор Вислобоков wrote:
> Зачем? Ну например, если вы хотите разнести обслуживание клиентов по
> разным датацентрам, даже если объём записи при этом не очень-то велик.
> Или если вы хотите балансировать нагрузку с одновременным получением
> отказоустойчивости в случае умирания одного сервера.
>
> 18 октября 2010 г. 11:55 пользователь Sergej Kandyla
> <sk.paix@gmail.com <mailto:sk.paix@gmail.com>> написал:
>
>     simplevolk@gmail.com <mailto:simplevolk@gmail.com> wrote:
>
>         Здравствуйте!
>         У меня вопрос- как в новой версии PostgreSQL обстоит с
>         мультимастер репликацией?
>
>
>     Простите, а зачем?
>
>     Имхо - это зло, и поиск приключений на свою жопу.
>     При интенсивных записях  избыточные  расходы на  синхронизацию
>     мастер-мастер слишком существенны,
>     причем растут экспоненциально в зависимости от колличества
>     серверов в группе репликации.
>
>
>
>         Я порыл в инете этот вопрос накопал,что в общем случае
>         проблема не решена,решена только в частных.
>
>         Накопал также и то,что там есть 3 возможных конфликта репликации-
>
>         1. Ошибка обновления
>         2. Конфликт уникальности.
>         3. Конфликт удаления.
>
>         Скажите, эти проблемы до сих пор актуальны?Решены ли они в
>         новой версии?
>
>
>     Никакие  продвинутые механизмы разрешения репликационных
>     конфликтов не могут гарантировать 100% консистентность данных,
>     посему не лучше ли избрать по возможности более простую архитектуру?
>
>
>
>
>         Спасибо.
>
>
>
>     --
>     Sent via pgsql-ru-general mailing list
>     (pgsql-ru-general@postgresql.org
>     <mailto:pgsql-ru-general@postgresql.org>)
>     To make changes to your subscription:
>     http://www.postgresql.org/mailpref/pgsql-ru-general
>
>

Виктор Вислобоков wrote:
> > Successful story подобного?
> Skype. Не знали? :)
> Там именно мультимастер репликация, хотя выполненная конечно же своими
> собственными наработками.

Это кстати очень познавательно - изучать архитектуру успешных проектов.

Но позвольте, в каком месте у них мультимастер репликация?
И мультимастер репликация между разными датацентрами?  :)
(ссылки в студию)

Репликация для fail-over  - вопрос отдельный. Стендбай нода должна
неприменно при этом простаивать,
т.е. запись всегда только в одну мастер-базу.

И насколько мне известно, в skype резервирование реализовано через WAL
http://www.opennet.ru/opennews/art.shtml?num=15290
http://www.highload.ru/papers2008/7171.html

Скайп, вообщето, имхо один из лучших примеров горизонтального
маштабирования из публично известных проектов.
(буду признателен за ссылки на подобные проекты)

Горизонтальное маштабирование как бы с идеей "мультимастер" не слишком
сочетается.



>
> 18 октября 2010 г. 16:22 пользователь Sergej Kandyla
> <sk.paix@gmail.com <mailto:sk.paix@gmail.com>> написал:
>
>     Successful story подобного?
>
>     Отказоустойчивость в режиме мультимастер ? шутить изволите ;)
>     Мультимастер между различными датацентрами - шутка еще похлеще первой.
>
>
>
>     Виктор Вислобоков wrote:
>
>         Зачем? Ну например, если вы хотите разнести обслуживание
>         клиентов по разным датацентрам, даже если объём записи при
>         этом не очень-то велик. Или если вы хотите балансировать
>         нагрузку с одновременным получением отказоустойчивости в
>         случае умирания одного сервера.
>
>         18 октября 2010 г. 11:55 пользователь Sergej Kandyla
>         <sk.paix@gmail.com <mailto:sk.paix@gmail.com>
>         <mailto:sk.paix@gmail.com <mailto:sk.paix@gmail.com>>> написал:
>
>
>            simplevolk@gmail.com <mailto:simplevolk@gmail.com>
>         <mailto:simplevolk@gmail.com <mailto:simplevolk@gmail.com>> wrote:
>
>                Здравствуйте!
>                У меня вопрос- как в новой версии PostgreSQL обстоит с
>                мультимастер репликацией?
>
>
>            Простите, а зачем?
>
>            Имхо - это зло, и поиск приключений на свою жопу.
>            При интенсивных записях  избыточные  расходы на  синхронизацию
>            мастер-мастер слишком существенны,
>            причем растут экспоненциально в зависимости от колличества
>            серверов в группе репликации.
>
>
>
>                Я порыл в инете этот вопрос накопал,что в общем случае
>                проблема не решена,решена только в частных.
>
>                Накопал также и то,что там есть 3 возможных конфликта
>         репликации-
>
>                1. Ошибка обновления
>                2. Конфликт уникальности.
>                3. Конфликт удаления.
>
>                Скажите, эти проблемы до сих пор актуальны?Решены ли они в
>                новой версии?
>
>
>            Никакие  продвинутые механизмы разрешения репликационных
>            конфликтов не могут гарантировать 100% консистентность данных,
>            посему не лучше ли избрать по возможности более простую
>         архитектуру?
>
>
>
>
>                Спасибо.
>
>
>
>            --     Sent via pgsql-ru-general mailing list
>            (pgsql-ru-general@postgresql.org
>         <mailto:pgsql-ru-general@postgresql.org>
>            <mailto:pgsql-ru-general@postgresql.org
>         <mailto:pgsql-ru-general@postgresql.org>>)
>
>            To make changes to your subscription:
>            http://www.postgresql.org/mailpref/pgsql-ru-general
>
>
>
>
>     --
>     Sent via pgsql-ru-general mailing list
>     (pgsql-ru-general@postgresql.org
>     <mailto:pgsql-ru-general@postgresql.org>)
>     To make changes to your subscription:
>     http://www.postgresql.org/mailpref/pgsql-ru-general
>
>

On 17/10/10 17:13, simplevolk@gmail.com wrote:
> Здравствуйте!
> У меня вопрос- как в новой версии PostgreSQL обстоит с мультимастер
> репликацией?
> Я порыл в инете этот вопрос накопал,что в общем случае проблема не
> решена,решена только в частных.
>
> Накопал также и то,что там есть 3 возможных конфликта репликации-
>
> 1. Ошибка обновления
> 2. Конфликт уникальности.
> 3. Конфликт удаления.
>
> Скажите, эти проблемы до сих пор актуальны?Решены ли они в новой версии?
>
>
> Спасибо.

В общем случае эти конфликты - фундаментальная особенность любого
асинхронного мультимастера и никакими програмными ухищрениями этих
конфликтов избежать не удасться.

Вот сам подумайте... вот на одном сервере проставили что на складе
осталось 10 штук товара а на другом проставили что осталось 8 штук
товара... и пойди догадайся какое из значений правильное... и никакой
last_change_time или version вам в этом случае не поможет (кстати скорее
всего ни то ни другое в реальном мире). Подобных проблем можно придумать
дюжину за 5 минут.

Асинхронный мультимастер в работоспособном виде возможен только в базах
которые работают в режиме insert/delete без updates (и то там куча
грабель спрятанных остается с уникальными индексами и прочим).

Если очень хочется мультимастер смотрите в сторону bucardo и
настраивайте/программируйте ему правила разрешения конфликтов (головняк
еще тот и без гарантий того что все всегда будет успешно работать).

PS: у skype исключительно асинхронные master/slave c использованием
londiste... + поверх с использованием londiste создаются federated
database для аналитики.

--
SY, Maxim Boguk