Я использую ldirectord с пульсом для балансировки нагрузки mysql. Он распределяет соединения mysql в равной степени на все серверы, доступные в пуле, но иногда подчиненное устройство остается в пуле даже после обнаружения ошибки «Слишком много соединений». Должна быть какая-то опция для подсчета количества запущенных запросов на ведомом устройстве перед отправкой ему дополнительных подключений.
Кто-нибудь, кто использует ldirectord для mysql и хотел бы поделиться тем же опытом с предлагаемыми решениями для этой заминки?
Спасибо.
С этих страниц:
http://www.ultramonkey.org/3/topologies/ha-lb-eg.html
http://www.ultramonkey.org/3/topologies/config/lb/non-fwmark/linux-director/ldirectord.cf
Похоже, что вы хотите настроить какой-то URL-адрес, к которому вы можете получить доступ на каждом внутреннем хосте (что-то вроде крошечного CGI с thttpd, подойдет), который тестирует демон на коробке и сообщает что-то, что не соответствует получить строку. Когда это произойдет, ldirectord вытащит узел из пула.
Пример конфигурации:
request="test-mysql.cgi"
receive="MYSQL OK"
Если вы используете алгоритм балансировки нагрузки с минимальным количеством подключений, IPVS отправит новое подключение к бэкэнду с минимальным количеством активных подключений, что будет означать, что вы получите ошибку «слишком много подключений» только тогда, когда все серверы заполнены. В настоящее время в IPVS (или ldirectord) нет механизмов, определяющих ограничение на количество одновременных подключений, которые серверная часть будет принимать, прежде чем она больше не сможет обрабатывать; на самом деле это было бы несложно реализовать, но вопрос в том, что вы делаете с подключениями, когда вы заполнены? RST попытка подключения? Что бы вы ни делали, это будет ошибка, которую клиент должен будет обработать, а «слишком много подключений» на языке протокола MySQL легче диагностировать, на мой взгляд, это «соединение отклонено», потому что есть гораздо больше Причины последней ошибки были разными, чем предыдущая.
Если бы это был мой кластер, я бы переключился на балансировку с наименьшим количеством подключений и добавил бы гораздо больше мониторинга рабочей нагрузки; если вы достигли пределов и заранее не знали, что приближаетесь к ним, у вас тут же сбой мониторинга.