Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: Репликация типа мастер-мастер в MySQL
Форумы портала PHP.SU » Серверное администрирование » Администрирование БД » Репликация типа мастер-мастер в MySQL

Страниц (1): [1]
 

1. nkl - 28 Января, 2013 - 08:22:25 - перейти к сообщению
Здравствуйте. Приступая к написанию ТЗ для крупного проекта заказчик дал четкое требование: система должна быть доступна для работы даже при падении соединения с интернетом. Система представляет собой сложный документооборот внутри учебного заведения. Не долго думая, пришла в голову идея поднять в интрасети заказчика связку LAMP идентичную той, что будет крутиться в интернете. Тут же возник вопрос по поводу репликации. Я так понимаю, единственный безболезненный способ репликации, это создание реплики БД в интрасети заказчика только в режиме чтения. Но задача стоит ясно, кроме чтения, должна быть и возможность записи.
Почитав несколько статей на хабре, понял, что репликация типа мастер-мастер может привести к полной каше в БД. Вопрос знатокам: так ли это? Или существует безболезненные методы репликации типа мастер-мастер? Как это реализовано в Active Direcotory Windows? Почему в активном каталоге винды репликация типа мастер-мастер возможна, причем без каких либо подводных камней, а в MySQL нет. Может быть можно написать какой либо костыль на Perl, что бы как-то синхронизировал таблицы и писал в обе БД только самые последние изменения. Если честно, совершенно не представляю как это возможно...
2. Мелкий - 28 Января, 2013 - 08:45:01 - перейти к сообщению
Разумеется, это так. Мастер-мастер - всегда головная боль.
Известная аксиома услуг "быстро, качественно, дешево - выберите любые 2 пункта" в мире СУБД предлагает взаимоисключающий выбор между доступностью, производительностью и согласованностью данных.

nkl пишет:
Почему в активном каталоге винды репликация типа мастер-мастер возможна, причем без каких либо подводных камней

Это значит, что эти самые камни там есть. Потому что задача одновременного достижения всех 3 пунктов нерешаема в принципе. Не знаком, возможно там пожертвовали производительностью и работает двухфазный коммит. Что не исключает определённой каши, если изолировать оба мастера друг от друга и начать делать противоречивые настройки.

nkl пишет:
костыль на Perl, что бы как-то синхронизировал таблицы и писал в обе БД только самые последние изменения

И познакомитесь как раз с проблемой невозможности нормального функционирования мастер-мастер.
Что вы будете делать, если будет такая ситуация:
0) соединение между машинами пропало
1) первый мастер обновил значение в строке на число 5
2) второй мастер обновил то же самое значение на число 6
Какое из них правильное и после восстановления связи должно быть синхронизировано? 5? 6? Или же вовсе 7?

nkl пишет:
создание реплики БД в интрасети заказчика только в режиме чтения

Почему не на удалённой площадке как раз? Это же документооборот внутри учебного заведения.
3. DeepVarvar - 01 Февраля, 2013 - 03:38:53 - перейти к сообщению
Мелкий пишет:
Какое из них правильное и после восстановления связи должно быть синхронизировано? 5? 6? Или же вовсе 7?
То, которое было последним. И гори оно огнем, этот мастер-мастер.
4. Zuldek - 01 Февраля, 2013 - 09:49:06 - перейти к сообщению
А не вариант развернуть единый сервер БД в локали заказчика и к нему подвязать всю систему? Нужно смотреть по требованиям к системе и т.д., но если это документооборот одной конкретной организации, то такое же вполне возможно сделать, поскольку нагрузки и количество соединений можно точно спрогнозировать.

В противном случае, если, как вы указали, репликация средствами мускула вас не устраивает (фактическая остановка приложения), то ваше решение - слать данные с слейва на мастер (или мастер-мастер) через веб-сервис/любой аналогичный костыль. При этом между серверами придется делать OpenVPN. Так или иначе, это будет костыль, причем довольно шаткий. Ещё можно посмотреть в сторону облачных баз данных, но требований к системе не знаю, потому не уверен можно ли этот подход вам рекомендовать.

На вашем месте серьёзно бы подумал на предмет поднятия единого сервера БД в локали заказчика.

Если позволяет ТЗ, можно строить не обмен данными в реальном режиме, а работу через одно мастера, например внешнего, а при падении интернет-соединения система остается живой в локали и работает через локальный сервер БД. В живом режиме синхронизировать БД, допустим раз в несколько часов средствами и, после появления доступа обновлять данные на внешнем мастере и переключать клиентов обратно на него.

 

Powered by ExBB FM 1.0 RC1