Есть желание географически распределить проект, и начать с одной из его состовляющих: MySQL. Интересны ответы тех, кто вплотную работал с этой БД и не в теории знает как работают различные схемы географически распределенной балансировки.
Текущая схема примерно следующая: один веб-сервер и два сервера БД в режиме «master-slave». К одному идут запросы только на чтение, к другому преимущественно на запись, оба сервера БД стоят рядом и соединены кроссом. Есть идея сделать схему немного посложнее и ввести в строй еще несколько серверов в другой стране, при этом настроить репликацию БД. Каналы и там и там хорошие, но задержки уже больше чем при соединении серверов «попа-в-попу». Кто реализовывал такие схемы: что можете сказать?
Реально или есть какие-то известные проблемы?
Может репликационный трафик можно как-то жать, для экономии канала?
Стоит использовать встроенный в MySQL ssl или лучше паковать все в OpenVPN?
Какие подводные (или даже вполне надводные) камни встретятся, если к этому еще прибавить master-master?
Кто чего скажет о кластерных типах БД в MySQL?
Добавлю, что в первую очередь, естественно интересуют практические знания, чем теоретические.
На прошлой работе была схема один мастер vs слейвы в разных регионах. Задача балансировки на уровне баз не решалась, доступ был преимущественно локальный. Жить можно, но, как Вы уже заметили, репликация может отставать, причем делает она это неравномерно. Еще одна грабля — каналы, сука, все-таки не так надежны, как того хотелось бы. Пропал линк между серверами — реплика встала. По этой же причине достаточно периодически пропадала возможность записать что-то в мастер «издалека». Так что в любом случае советую первым делом ввести хотя бы простейший мониторинг и попытаться понять, как сильно оно будет тупить конкретно в вашем случае, и оценить, подходит ли это. Если у Вас будут графики времени задержки репликации, контроль доступности мастера с каждой точки, откуда будете в него писать — жить станет может быть и не проще, но предсказуемее :)
Могут также проявиться плавающие проблемы с кодом, который рассчитывает на отсутствие задержек. Скажем, регистрируется новый юзер (вы его заводите в мастер-базе), но сделать реально ничего не может, т.к. его данные не доехали до слейва. Эта проблема выглядит довольно тупо, но могут быть и более хитрые ее проявления.
MySQL proxy — с помощью этого продукта можно незаметно для пользователей перераспределять нагрузки для серверов MySQL, в т.ч. настраивать сложные схемы с распределенными базами.
Если географическое разделение делается для ускорение доступа локальных пользователей( те к вынесеным серверам БД еще и бэкенды стоят) то самое лучшее это разделить бд на две части.
Одна часть «ядро» которая частенько синхриться, второе — местно-географическое отпочкование, которое в неком роде самом по себе.
И которое можно синхрить без паранои. Что сильно облегчает работу.
My<cod/>.net
