Я ищу способы сбалансировать нагрузку на нашу инфраструктуру MySQL и, похоже, не могу найти ответ, который работает для меня ... :)
Итак, у меня есть один большой и толстый сервер, который обрабатывает все. Много БД, много чтений, много записей и т. Д. Он справляется с этим довольно хорошо, но это единственная точка отказа.
Мы настроили пару ведомых устройств для перенаправления им чтения, но столкнулись с двумя проблемами: требуется много усилий, чтобы перестроить все программы для разделения чтения и записи; а иногда рабы отстают, что приводит к очень интересным артефактам в приложении.
Проблемы с отставанием ведомых устройств: поскольку многие базы данных смешаны - на стороне интеллектуального анализа данных выполняются как тяжелые 10-20-минутные запросы, так и атомарные запросы, которые не требуют времени. Но Slave выполняет один запрос за раз, поэтому все атомарные запросы должны ждать, пока завершится тяжелый.
Чтобы решить эти две проблемы, я подумал о чем-то вроде прокси, который учитывал бы это:
Одна проблема, которая все еще остается, но которую я хочу рассмотреть, - это отказоустойчивость. Если мастер терпит неудачу - было бы хорошо, если бы подчиненный взял на себя обязанности мастера, а когда мастер резервный - он стал бы подчиненным.
Любые ссылки на RTFM или тематические исследования по этой теме приветствуются =)
РЕДАКТИРОВАТЬ: погуглил еще, и помимо Tungsten enterprise - нашел dbShards и Schooner. Если посмотреть глубже - есть ли у кого-нибудь опыт работы с этими решениями? Есть отзывы?
Проверять, выписываться Вольфрамовое предприятие
MySQL-MMM не рекомендуется. Видеть: http://www.xaprb.com/blog/2011/05/04/whats-wrong-with-mmm/ Даже один из первоначальных авторов согласился с комментариями.
Ура
Изменить: ой, вторая ссылка была такой же, как первая. Исправлено
Чтобы устранить задержку репликации, мы внедрили SSD в качестве основного хранилища на ведомом устройстве. Более быстрое время записи помогает подчиненной базе данных не отставать, несмотря на то, что репликация на подчиненном устройстве является однопоточной операцией.
Как насчет двух серверов, выступающих в роли баз данных ваших приложений, и другого сервера (или двух?) В качестве уровня интеллектуального анализа данных. Ваши две «прикладные» базы данных не должны отставать (слишком далеко), потому что они не обрабатывают ни один из тяжелых запросов. Вы также можете настроить MySQL-ммм для обработки отказов. Затем вы можете направить свое приложение на Mysql VIP, который вы настроили в балансировщике нагрузки. У этого VIP есть два MMM IP. Но МММ может сказать: «Эй, ящик 2 слишком далеко позади, я перенесу этот IP в ящик 1, чтобы он мог наверстать упущенное».
Тогда у вас будет два уровня баз данных, обрабатывающих два разных типа запросов. Кеши на этих машинах будут оптимизированы для их типов запросов (теоретически).
Также посмотрите на карту Fusion-IO или Virident TachIOn. Это могло бы решить проблемы без добавления кучи оборудования.