Распределение запросов MySQL

Здравствуйте!
Ситуация такая. Есть два сервера с MySQL, настроена репликация, один сервер — мастер, другой соответственно — слейв. Каким образом можно сделать так, чтобы запросы на изменение базы (INSERT, UPDATE, DELETE и т.д.) шли на мастер, а запросы на чтение (SELECT) на слейв. Может есть какая-нибудь настройка в mysql или стороннее решение?

Сам проект сделан на PHP и мы заранее не продумали этот вопрос. Вызов запросов идёт через обычные mysql_query.
Заранее спасибо!
  • Вопрос задан
  • 4546 просмотров
Пригласить эксперта
Ответы на вопрос 7
@edogs
Стандартное решение в том, что бы иметь тупо 2 разных коннекта.
Один идет на мастер, второй на слейв. Изменение на первый, чтение со второго.
Это самое естественное что может быть.

ну или www.linuxvirtualserver.org/, но это уже немного о другом.
Ответ написан
Есть такая штука, как MySQL proxy, которая может прозрачно для клиента раскидывать соединения на мастер и слейв (естетсвенно с ограничениями) читат тут — forge.mysql.com/wiki/MySQL_Proxy_RW_Splitting
жаль что пока не production ready.

по хорошему — переписать все обращения к базе через свой класс (в простейшем случае просто поиском-заменой по исходникам) и в нем анализировать — чтение или запись идет.
Ответ написан
@edogs
По поводу хетзнера и серверов. Обдумайте вариант взять www.hetzner.de/hosting/produkte_rootserver/ex5, конечно разоритесь на сетап, но 24Гб памяти вместо 8Гб решает в случае мускула достаточно сильно за счет кэша, особенно если у Вас много чтения.
Более того, иногда есть смысл повесить слэйв на сервер, где все таблицы находятся на ram диске. Для слейва рам не помеха, а вот для скорости чтение из оперативки это Вам не чтение с бытового винта, пусть даже на 7200.
Ответ написан
Комментировать
Tonik
@Tonik
Если вам в целях HA, то есть несколько вариантов. И однозначно хорошего среди них нет — нужно смотреть по обстоятельствам. Опять же много зависит, от того какая нужная надежность.

Если нужно очень очень надежно и малейшая потеря данных недопустима, то придется платить производительностью в любом случае. Обычная, асинхронная репликация вам не подойдет, так как не будет 100% уверенности, что данные успели уйти на слейв.

Можно использовать DRDB + Heartbeat
Надежно, но пенальти на запись. И сеть между серверами должна быть хорошей.
Для FreeBSD можно нечто подобное соорудить при помощи репликации на уровне ZFS.
В 5.5 появилась репликация с подтверждением записи данных, хотя бы на один из слейвов.

Если кратковременный простой и небольшая потеря данных, допустимы (внимание, я не предлагаю плевать на юзерские данные! Но одно дело банк и финансы, другое — потерять два три голоса за авотарочку...), то асинхронная репликация, вполне хорошее решение.
Однако, что то (например nagios) должен мониторить SHOW SLAVE STATUS, что бы вовремя заметить если репликация слетела.

Переключаться на слейв можно либо на уровне конфига вашего приложения. Либо используя виртуальный IP, котроый в случаеумирания мастера быстро перекидывается на живой слейв.

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

Это все мое имхо…
Ответ написан
Комментировать
serzhb
@serzhb Автор вопроса
2korvindest, вопрос репликации для меня тема не очень знакомая, но знаю, что многие работают именно по такому принципу. Записывают на мастер, читают со слейва. Как мне кажется процесс репликации с сервера на сервер происходит мгновенно, если это не какой-то тяжелый запрос, конечно.

Дело в том, что я не вижу другого достойного решения для масштабирования mysql. Если кто-то подскажет, что-то лучше я буду только рад.
Ответ написан
@shagguboy
а расскажите характеристики сервера, раз вам одного ящика не хватает
Ответ написан
serzhb
@serzhb Автор вопроса
На начальном этапе не было смысла тратить лишние деньги на неоправданно мощный сервер. Кстати, первый сервер только спустя полгода начал показывать серьезную нагрузка. В пиковые моменты Load Average доходил до 7.0 и это при двух ядрах, хотя тормозов не было на самом сайте.
Ответ написан
Ваш ответ на вопрос

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

Похожие вопросы