Географически распределённый MySQL

Приветствую all.

Есть желание географически распределить проект, и начать с одной из его состовляющих: MySQL. Интересны ответы тех, кто вплотную работал с этой БД и не в теории знает как работают различные схемы географически распределенной балансировки.

Текущая схема примерно следующая: один веб-сервер и два сервера БД в режиме «master-slave». К одному идут запросы только на чтение, к другому преимущественно на запись, оба сервера БД стоят рядом и соединены кроссом. Есть идея сделать схему немного посложнее и ввести в строй еще несколько серверов в другой стране, при этом настроить репликацию БД. Каналы и там и там хорошие, но задержки уже больше чем при соединении серверов «попа-в-попу». Кто реализовывал такие схемы: что можете сказать?

  • Реально или есть какие-то известные проблемы?
  • Может репликационный трафик можно как-то жать, для экономии канала?
  • Стоит использовать встроенный в MySQL ssl или лучше паковать все в OpenVPN?
  • Какие подводные (или даже вполне надводные) камни встретятся, если к этому еще прибавить master-master?
  • Кто чего скажет о кластерных типах БД в MySQL?


Добавлю, что в первую очередь, естественно интересуют практические знания, чем теоретические.
  • Вопрос задан
  • 4987 просмотров
Решения вопроса 1
Bambr
@Bambr
На прошлой работе была схема один мастер vs слейвы в разных регионах. Задача балансировки на уровне баз не решалась, доступ был преимущественно локальный. Жить можно, но, как Вы уже заметили, репликация может отставать, причем делает она это неравномерно. Еще одна грабля — каналы, сука, все-таки не так надежны, как того хотелось бы. Пропал линк между серверами — реплика встала. По этой же причине достаточно периодически пропадала возможность записать что-то в мастер «издалека». Так что в любом случае советую первым делом ввести хотя бы простейший мониторинг и попытаться понять, как сильно оно будет тупить конкретно в вашем случае, и оценить, подходит ли это. Если у Вас будут графики времени задержки репликации, контроль доступности мастера с каждой точки, откуда будете в него писать — жить станет может быть и не проще, но предсказуемее :)

Могут также проявиться плавающие проблемы с кодом, который рассчитывает на отсутствие задержек. Скажем, регистрируется новый юзер (вы его заводите в мастер-базе), но сделать реально ничего не может, т.к. его данные не доехали до слейва. Эта проблема выглядит довольно тупо, но могут быть и более хитрые ее проявления.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 5
JayDi
@JayDi
MySQL proxy — с помощью этого продукта можно незаметно для пользователей перераспределять нагрузки для серверов MySQL, в т.ч. настраивать сложные схемы с распределенными базами.

dev.mysql.com/downloads/mysql-proxy/
Ответ написан
OdobenusRosmarus
@OdobenusRosmarus
Кто чего скажет о кластерных типах БД в MySQL?


Имеется в виду engine=NDB? Это однозначно не для Вас. NDB как раз предполагает, что машины рядышком и хорошо соединены…
Ответ написан
Комментировать
@leave
Рекордное время отставания master-master репликации у нас было ~10 часов, оно же ~900Мб. Каналы и железо однозначно не были слабым местом. Как-то так.
Ответ написан
Комментировать
pentarh
@pentarh
Сейчас засматриваюсь на коммерческий DRBD-proxy по этому поводу.
Ответ написан
Комментировать
kashey
@kashey
Программирую большую половину жизни
Если географическое разделение делается для ускорение доступа локальных пользователей( те к вынесеным серверам БД еще и бэкенды стоят) то самое лучшее это разделить бд на две части.
Одна часть «ядро» которая частенько синхриться, второе — местно-географическое отпочкование, которое в неком роде самом по себе.
И которое можно синхрить без паранои. Что сильно облегчает работу.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы