Здравствуйте. Приступая к написанию ТЗ для крупного проекта заказчик дал четкое требование: система должна быть доступна для работы даже при падении соединения с интернетом. Система представляет собой сложный документооборот внутри учебного заведения. Не долго думая, пришла в голову идея поднять в интрасети заказчика связку LAMP идентичную той, что будет крутиться в интернете. Тут же возник вопрос по поводу репликации. Я так понимаю, единственный безболезненный способ репликации, это создание реплики БД в интрасети заказчика только в режиме чтения. Но задача стоит ясно, кроме чтения, должна быть и возможность записи.
Почитав несколько статей на хабре, понял, что репликация типа мастер-мастер может привести к полной каше в БД. Вопрос знатокам: так ли это? Или существует безболезненные методы репликации типа мастер-мастер? Как это реализовано в Active Direcotory Windows? Почему в активном каталоге винды репликация типа мастер-мастер возможна, причем без каких либо подводных камней, а в MySQL нет. Может быть можно написать какой либо костыль на Perl, что бы как-то синхронизировал таблицы и писал в обе БД только самые последние изменения. Если честно, совершенно не представляю как это возможно...
1. nkl - 28 Января, 2013 - 08:22:25 - перейти к сообщению
2. Мелкий - 28 Января, 2013 - 08:45:01 - перейти к сообщению
Разумеется, это так. Мастер-мастер - всегда головная боль.
Известная аксиома услуг "быстро, качественно, дешево - выберите любые 2 пункта" в мире СУБД предлагает взаимоисключающий выбор между доступностью, производительностью и согласованностью данных.
Это значит, что эти самые камни там есть. Потому что задача одновременного достижения всех 3 пунктов нерешаема в принципе. Не знаком, возможно там пожертвовали производительностью и работает двухфазный коммит. Что не исключает определённой каши, если изолировать оба мастера друг от друга и начать делать противоречивые настройки.
И познакомитесь как раз с проблемой невозможности нормального функционирования мастер-мастер.
Что вы будете делать, если будет такая ситуация:
0) соединение между машинами пропало
1) первый мастер обновил значение в строке на число 5
2) второй мастер обновил то же самое значение на число 6
Какое из них правильное и после восстановления связи должно быть синхронизировано? 5? 6? Или же вовсе 7?
Почему не на удалённой площадке как раз? Это же документооборот внутри учебного заведения.
Известная аксиома услуг "быстро, качественно, дешево - выберите любые 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. Так или иначе, это будет костыль, причем довольно шаткий. Ещё можно посмотреть в сторону облачных баз данных, но требований к системе не знаю, потому не уверен можно ли этот подход вам рекомендовать.
На вашем месте серьёзно бы подумал на предмет поднятия единого сервера БД в локали заказчика.
Если позволяет ТЗ, можно строить не обмен данными в реальном режиме, а работу через одно мастера, например внешнего, а при падении интернет-соединения система остается живой в локали и работает через локальный сервер БД. В живом режиме синхронизировать БД, допустим раз в несколько часов средствами и, после появления доступа обновлять данные на внешнем мастере и переключать клиентов обратно на него.
В противном случае, если, как вы указали, репликация средствами мускула вас не устраивает (фактическая остановка приложения), то ваше решение - слать данные с слейва на мастер (или мастер-мастер) через веб-сервис/любой аналогичный костыль. При этом между серверами придется делать OpenVPN. Так или иначе, это будет костыль, причем довольно шаткий. Ещё можно посмотреть в сторону облачных баз данных, но требований к системе не знаю, потому не уверен можно ли этот подход вам рекомендовать.
На вашем месте серьёзно бы подумал на предмет поднятия единого сервера БД в локали заказчика.
Если позволяет ТЗ, можно строить не обмен данными в реальном режиме, а работу через одно мастера, например внешнего, а при падении интернет-соединения система остается живой в локали и работает через локальный сервер БД. В живом режиме синхронизировать БД, допустим раз в несколько часов средствами и, после появления доступа обновлять данные на внешнем мастере и переключать клиентов обратно на него.