Я работаю над таким проектом, как создание конфигурации базы данных на лету, получил массив реплик чтения для экземпляра mysql и поддерживал одно открытое соединение с каждым и сохранял их статику в этой службе, поэтому, когда клиент пытается подключить реплику для чтения, чем предполагается, вернуть менее занятого.
Мои вопросы: какова должна быть формула для этого?
Пока у меня есть только 2 переменные, любые улучшения этих переменных также приветствуются.
Вы можете сделать это с помощью простого скрипта или использовать плагины Nagios.
check_ping или check_icmp
check_mysql_health, что-то вроде этого:
define command{
command_name check_mysql_health
command_line $USER1$/check_mysql_health -t 20 --hostname $HOSTADDRESS$ --port $ARG1$ --username $ARG2$ --password $ARG3$ --mode $ARG4$ --warning $ARG5$ --critical $ARG6$
}
define service{
use generic-service
host_name mysql_slave
service_description MySQL_threads-connected
check_command check_mysql_health!3306!user!password!threads-connected!30!40
}
define service{
use critical-service
host_name mysql_slave
service_description MySQL_slave-io-running
check_command check_mysql_health!3307!user!password!slave-io-running
contact_groups admin-sms
}
define service{
use critical-service
host_name mysql_slave
service_description MySQL_slave-sql-running
check_command check_mysql_health!3307!user!password!slave-sql-running
contact_groups admin-sms
}
Я разработал системы, которые направляют объем запросов в аналогичном сценарии. Может быть интересно включить еще несколько вещей:
Раньше я давал каждому из ресурсов вес, а затем складывал их. Итак, с одного сервера вы можете вернуться:
memory 50(%)
cpu 40(%)
disk 4000 (iops, if you know the limit here making it a % is good)
ms 300 (msecs average response time)
вес этого сервера будет 4390 (здесь выше будет хуже). Здесь вы можете увидеть, где, возможно, если процессор не вызывает беспокойства, вы можете изменить его «вес» в вычислениях, чтобы принять решение о том, какой клиент использовать более точно для вашей среды.
От того, как вы его собираете, зависит, как часто его можно собирать и насколько надежным он будет (возможно, узел умер после того, как вы составили список наименее используемых серверов). Один из подходов - запустить демон отчетов для каждого кандидата и запросить его, когда вы получите запрос клиента, возможно, через многоадресную рассылку. Демон отчетов может очень часто собирать статистику, чтобы информация о решениях была как можно более точной.
Неясно, насколько преходяща конфигурация, которую вы создаете, что является важным фактором при распространении. Будут ли у вас подключены клиенты на долгое время? Возможно ли, что вам нужно отключить и перераспределить клиентов из-за перегрузки сервера? Возможно, вы уже обдумали это.
В зависимости от того, насколько это непостоянно и насколько вы знаете о запросах, вы также можете добавить дополнительные данные к метрикам решений:
Надеюсь, это поможет! Это интересная проблема.