Добрый день!
У меня есть потребность создать отказоустойчивый кластер mysql с балансировкой нагрузки между серверами. В документации написано, что ставится несколько backend-mysql серверов с репликацией между ними. А все пользовательские запросы приходят на mysql-proxy сервер и распределяются с его помощью. Но у нас получается единая точка отказа именно mysql-proxy сервер. Нигде не могу найти информацию о создании failover кластер-а mysql-proxy серверов. Это можно сделать штатными средствами mysql-proxy? Или как лучше мониторить доступность сервера по сети и главное - работоспособность сервиса mysql-proxy? ОС на всех серверах - FreeBSD 10, версии ПО - последние доступные в портах.

netwindЗначит погуглите так "mysql pacemaker corosync high availability".
И потом "how to uninstall freebsd".
Спасибо больше за вариант. Многое завязано на фряху, возможно придется перелопачивать гору работы. Но хоть подсказали разумное решение.

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

MasterZivтам ставится тривиальный watchdog и перезапускается этот mysqlproxy, или то же, но на аппаратном уровне.
Разве юниксовый watchdog отслеживает состояние сервиса? Смысл в том, чтобы отслеживать работоспособность службы. Если служба есть в списке задач, система по сети доступна, но сам сервис не пропускает mysql-запросы, то толку от такого кластера мало. Значит нужно (крайне желательно нативное) решение, которое будет через какой то интервал проводить тестовые запросы.

MasterZivи учти, что абсолютно надежную систему на hot standby не построить в принципе, там будет 99.9 % готовности, но всем этого обычно выше крыши хватает.
Я хочу построить сервис с максимальным временем простоя не более 1-2 минут. Абсолютно надежные системы не существуют, как и все идеальное.

netwindЗолотые слова. Операционный день банка ведь все равно только утром начнется. Дайте уже людям поспать! Смотрите реально на свои мифические потери от простоев.
В любой организации есть мониторинг разных критичных систем. Если в результате сбоя этот мониторинг не работал несколько часов, то он может пропустить критичные события типа: горит серверная в филиале, спилили банкомат, упал важный сервер. Админы утром придут, увидят проблему с мониторингм и начнут заниматься им. А неработоспособность критически важных для бизнеса систем может быть обнаружена за 5 минут до операционного дня в банке. Если это система управления производства, то она может упустить: перегрев, переполнение, затор в каких либо частях процесса. Даже на самом маленьком заводе есть какая-нибудь котельная, которая может рвануть. Могут погибнуть люди из-за пропущенного критически важного уведомления в результате сбоя мониторинга. Есть системы, простой которых должен измеряться минутами в год. Простой в часах просто недопустим.

netwindЕсть. Но люди ею управляющие на нашем форуме вопросы не задают.
Вы были на реальном предприятии? Я был. Раздолбайство некоторых работников просто феноменальное. Только хорошо построенная система мониторинга и сотни-тысячи датчиков снижают количество аварий.