Имеется проект, на котором кроме двух неБД-серверов (http, ftp, почта и т.п.), трудятся четыре MySQL-сервера. Балансировка реализована по принципу "создание каждой новой базы на псевдо-рандомном сервере с ручным переносом части баз в случае обнаружения заметного перекоса нагрузки". Задолбало меня это слежение, как и периодические статистически аномальные всплески нагрузки на отдельных серверах, и задумался я о нормальном кластере. Начал изучать вопрос, и что-то хочется мне этого кластера все меньше и меньше. Хотелось бы спросить у знающих людей, действительно ли я все понял правильно, и это правда:
1. У MySQL-кластера нет единой точки входа и мне нужно самому прописывать в скрипты всю логику, связанную с выбором сервера? Т.е. самому реализовывать балансировщик и отслеживать недоступные в данный момент ноды?
2. Данные синхронно кешируются в памяти нод и при наличии разных серверов с разным объемом RAM, на всех из них я могу использовать только наименьший вариант? Сервера закупались в разное время и на одном из них 16 GB, а на другом -- 48, это замечательно!
3. Максимальное количество объектов БД жестко ограничено числом 20320 и я не могу создать 100 баз, в каждой из которых 20 таблиц, в каждой из которых 10 полей и 3 индекса? У меня уже сейчас около 3000 баз, в каждой из которых более 50 таблиц и хрен знает сколько полей/индексов...

Это все правда? И все ли это "чудеса"?

artasпо пп2 виртуализация решает. У нас например уже физических серверов не осталось
Как-то грустно это будет выглядеть. На одном сервере одна нода, на другом -- три, на остальных двух еще по две. И у каждого своя ОС со своими настройками и апдейтами. Плюс хосты. Как с этим зверинцем потом управляться, даже страшно подумать.

netwindmisha mike, все кластера убоги.
Ну в Оракле по крайней мере есть штатный балансировщик, который нагрузку распределяет и доступность мониторит. И ограничений на количество объектов БД там нет. Не знаю, правда, что там с использованием памяти.

У вас еще не так уж плохо получилось. Почему бы не автоматизировать то, что есть?
Автоматизировать очень сложно. Как узнать среднюю нагрузку на сервер в виде машиночитаемой величины (например, в процентах от 0 до 100)? Как узнать распределение средней нагрузки по базам внутри сервера? Это нужно для автоматизации переноса баз, но как извлечь эту информацию из MySQL -- непонятно.

Да и поможет это только при долговременном перекосе, а что делать, если одна база на одном сервере вдруг оказывается сильно нагруженной (очередной говно-бот в гости зашел) на ограниченное время? В случае кластера с балансировщиком и общим (в пределах всего кластера) запасом "прочности", такой всплеск легко сглаживается, а при разделении типа моего, проблема не решаема в принципе, если нагрузка превышает способности отдельного сервера.

Еще вариант : совмещать веб и sql-ноду на одном сервере. Но эти sql-ноды берут на себя часть нагрузки по сортировке и тд.
Если заглох веб-сервер то автоматические отпадает необходимость обслуживать и SQL с этого сервера.
Звучит приемлемо, если бы не другие ограничения...

Если делаете не как все, то и проблемы будут не как у всех.
А что в моей ситуации не так, как у всех?

netwindтаблиц много.
У phpBB 64 таблицы, у IPB -- еще больше, а это ведь всего лишь форумы.

Как это выглядит технически с точки зрения MySQL?
Одна сессия, в которой много запросов? Или много сессий?
Это обычное php-приложение со всеми вытекающими последствиями: много короткоживущих сессий (все под одним логином) с пятью-десятью запросов в каждой.

См. max_user_connections и Setting Account Resource Limits.
Не пойдет. Во-первых все базы под одним логином используются, а во-вторых, такое ограничение просто начнет валить ошибки в скрипты, а не выстраивать запросы в очередь с ограничением плотности потока. Да и плотность потока ограничивать глупо, т.к. запросы очень разные по стоимости. Тут в общем случае не ограничивать нужно, а выяснять актуальную загруженность для своевременной разгрузки сервера.

miksoft http://dev.mysql.com/doc/refman/5.5/en/server-status-variables.html#statvar_Com_xxx
Это к сожалению никак не отражает реальную нагрузку. Два соседних запроса могут отличаться по стоимости на три порядка, но счетчики они увеличат на одинаковую величину. Да и по базам разделения нет. Нет ли аналогичного набора переменных, которые показывали бы не количество запросов на весь сервер, а количество по каждой базе и среднее время выполнения? Ведь если запросы в среднем выполняются в течении 1000 мс, то весь сервис уже начинает заметно тормозить и это явный признак перегрузки.

miksoftА что так? почему бы не разделить?
Исторически сложилось. Разделение пользователей идет на уровне сервера приложений, подключение к базе, грубо говоря, одно на всех.

А какая разница, если на том конце все равно боты? (как я понял, нежелательные)
Иногда боты, а иногда и нормальные юзера по "жирной" ссылке. Показывать ошибки подключения -- последнее дело, ИМХО.

Так сравнивать нужно за достаточно длительный период, а не после каждого запроса. Как я понимаю, базы однообразные и вероятность запросов одинаковой сложности тоже одинаковая. Тогда можно определенно говорить, что сервер, обработавший два миллиона запросов, загружен примерно вдвое больше, чем сервер, обработавший один миллион запросов.
Это при условии, что сервера одинаковые и что в запросах нет перекоса. Сервера у меня разные, и в то же время у одного клиента в самой_главной_таблице 10 записей, а у другого 10000. Да и характер нагрузки неоднородный, у одного в фаворе одни таблицы у другого -- другие (хотя комбинаций не так много, да).

Да, мне почему-то показалось, что разные базы - это разные инстансы.
Но даже в вашем случае эти показатели могут принести пользу. Например, сервер для очередной базы создавать не псевдорандомно, а с учетом этих параметров.
Ну псевдо-рандомно -- это с учетом эмпирически вычисленных коэффициентов производительности серверов: если сервер A вдвое быстрее, чем B, то и вероятность выбора его для создания новой базы вдвое выше. Если кроме этих весьма приблизительных коэффициентов учитывать еще и такие ненадежные в плане нагрузки параметры, как счетчики запросов, то точность будет до трамвайной остановки, не думаю что такому автомату можно доверять автоматическую балансировку.

Еще существует Performance Schema . Я про нее толком не читал, но, возможно, там найдете подходящие метрики.
Что-то не работает она у меня:

miksoftВерсия MySQL какая?
Performance Schema появилась начиная с версии 5.5.
5.3.чего-то.там :(
Обновлять ради экспериментов продакшн пока нет желания.

Вы опять смотрите на частности, а в статистике они не работают. Когда на сервере сотни более-менее однородных баз, то отклонение единиц особой роли не играет.
С этим согласен, но разница мощностей серверов все равно остается. Не самый лучший вид статистики, ИМХО. Гораздо логичнее в обертку над mysql_query() счетчик времени добавить, раз уж сам MySQL такой статистики не ведет.

InterSkyМожет вы не там копаете? Вместо того чтобы защититься от ботов, вы пытаетесь увеличить мощности сервера до уровня когда он будет не замечать ботов. Грубо говоря - на вход в квартиру лучше повесить замок чем держать в квартире кучу каратистов которые наваляют шайке бомжей зашедших погреться в открытую дверь...
Это не DDoS-боты, это разные поисковики, архивы и т.п. условно-полезные "клиенты". От атак защита есть на фронт-энде и она работает хорошо.

Правда вы упомянули что заходят " иногда и нормальные юзера по "жирной" ссылке ", но насколько жирна ссылка что может вас вывести из строя? Ведь не стартовая страница гугла на вас перенаправилась.
Вывести из строя не может, а вот заметно увеличить время отклика -- запросто. А т.к. на сервисе хостятся тысячи по сути совершенно независимых сайтов, такие боты шляются по моим серверам круглые сутки.

Тут опять же на лицо полное нежелание что-то делать руками. Допустим у вас один phpBB движок на весь сервер, и он смотрит на какой домен зашёл клиент и в зависимости от этого соединяется с нужной базой
Принцип разделения пользователей на сервере приложений является нормальной практикой, мне непонятно ваше раздражение. А плодить аккаунты без реального выхлопа (уже говорил выше почему) не вижу смысла, тем более, что это усложняет процедуру переноса пользователей между серверами.

Народ, изначальный вопрос совсем не в том, что можно сделать с моим проектом. Я сам вижу достаточно путей разной степени геморройности. Вопрос был в том, что из себя представляет кластер, который виделся мне как один из легких способов решения проблемы.