Запуск балансировщика и тестирование MySQL-кластера

7 Запуск балансировщиков и первичное тестирование

Теперь можно впервые запустить оба балансировщика нагрузки:

mysql-lb1.example.com / mysql-lb2.example.com:

/etc/init.d/ldirectord stop
/etc/init.d/heartbeat start

Если ошибок нет — перезагрузите оба сервера балансировщиков. Если ошибки появляются, перейдите в раздел Диагностика внизу — там собраны распространённые причины и исправления.

mysql-lb1.example.com / mysql-lb2.example.com:

shutdown -r now

После перезагрузки проверим, что оба балансировщика работают как ожидается:

mysql-lb1.example.com / mysql-lb2.example.com:

ip addr sh eth0

Активный балансировщик должен показывать виртуальный IP-адрес (10.0.1.10):

| 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:16:3e:45:fc:f8 brd ff:ff:ff:ff:ff:ff inet 10.0.1.31/24 brd 192.168.0.255 scope global eth0 inet 10.0.1.10/24 brd 192.168.0.255 scope global secondary eth0 |

Резервный (hot-standby) должен показывать обычный IP без виртуального адреса:

| 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:16:3e:16:c1:4e brd ff:ff:ff:ff:ff:ff inet 10.0.1.32/24 brd 192.168.0.255 scope global eth0 |

Проверьте статус демона ldirectord:

mysql-lb1.example.com / mysql-lb2.example.com:

ldirectord ldirectord.cf status

Вывод на активном балансировщике:

| ldirectord for /etc/ha.d/ldirectord.cf is running with pid: 1603 |

Вывод на резервном балансировщике:

| ldirectord is stopped for /etc/ha.d/ldirectord.cf |

Проверьте таблицы IPVS:

mysql-lb1.example.com / mysql-lb2.example.com:

ipvsadm -L -n

Вывод на активном балансировщике:

| IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.0.1.10:3306 wrr -> 10.0.1.33:3306 Route 1 0 0 -> 10.0.1.34:3306 Route 1 0 0 |

Вывод на резервном:

| IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn |

Проверьте синхронизацию состояния LVSSyncDaemonSwap:

mysql-lb1.example.com / mysql-lb2.example.com:

/etc/ha.d/resource.d/LVSSyncDaemonSwap master status

Вывод на активном:

| master running (ipvs_syncmaster pid: 1766) |

Вывод на резервном:

| master stopped (ipvs_syncbackup pid: 1440) |

Если тесты прошли успешно, проверьте подключение к MySQL с другого сервера в той же сети (10.0.1.x) через виртуальный IP 10.0.1.10:

mysql -h 10.0.1.10 -u ldirector -p

Примечание: клиент MySQL должен быть версии не ниже 4.1; более старые клиенты не совместимы с MySQL 5.

Для проверки отказоустойчивости выключите один из узлов кластера MySQL — подключение через виртуальный IP должно оставаться работоспособным.

Контрольный список перед тестами

На обоих балансировщиках остановлен/запущен корректный набор демонов (ldirectord/heartbeat).
Виртуальный IP назначен только на активном узле.
ipvsadm показывает корректные бэкенд-адреса и расписание (scheduler).
Синхронизация состояний ipvs_sync настроена и работает.
На клиенте MySQL версия клиента >= 4.1.

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

Мини‑методология тестирования

Smoke test: подключение к виртуальному IP, выполнение простого SELECT.
Failover test: выключение активного балансировщика и проверка, что виртуальный IP переместился на резерв.
Backend fail test: выключение одного MySQL-узла и проверка, что запросы обслуживаются остальными узлами.
Load test: короткий стресс (несколько сотен соединений), отслеживать ActiveConn в ipvsadm.
Recovery test: восстановление узла и проверка повторной интеграции в таблицу IPVS.

Критерии приёмки

Подключение к MySQL через виртуальный IP стабильно работает после простых операций.
При отключении одного из MySQL-узлов соединения продолжают обслуживаться оставшимися узлами.
При отключении активного балансировщика виртуальный IP быстро переходит на резервный узел.
Синхронизация состояний между балансировщиками не прерывается дольше допустимого окна восстановления.

8 Аннотации и подсказки

Ошибки при запуске ldirectord

Пример ошибки:

ldirectord:

/ etc/init.d/ldirectord stop /etc/init.d/heartbeat start Stopping ldirectord Error [] reading file /etc/ha.d/ldirectord.cf at line 8: >Unknown command service=mysql

Эта ошибка обычно связана с форматированием файла конфигурации ldirectord/heartbeat. В исходнике строка вроде “service = mysql” может быть неправильно выровнена или содержать лишние символы. Правильное форматирование и выравнивание (табуляции или двойные пробелы после ключа virtual) часто решают проблему.

Откройте файл для правки:

vi /etc/heartbeat/ldirectord.cf

Пример корректной структуры (обратите внимание на отступы перед service, real и остальными опциями):

| # Global Directives checktimeout=10 checkinterval=2 autoreload=no logfile="local0" quiescent=yes #after virtual=... make TABS (or double spaces) in every line virtual = 10.0.1.10:3306 service = mysql real = 10.0.1.33:3306 gate real = 10.0.1.34:3306 gate checktype = negotiate login = "ldirector" passwd = "ldirector" database = "ldirectordb" request = "SELECT * FROM connectioncheck" scheduler = wrr |

После исправления форматирования перезапустите heartbeat и ldirectord.

Важные замечания по MySQL Cluster

Если у вас есть существующие базы данных на MyISAM и вы планируете перенести их в MySQL Cluster, нужно изменить ENGINE=MyISAM на ENGINE=NDBCLUSTER. Это требует отдельной процедуры миграции и тестирования.
Пользователей и права (GRANTs) нужно добавлять и менять на всех узлах данных, поскольку база mysql на данных может использовать MyISAM/InnoDB. Альтернативно — централизованное управление и затем синхронизация.
По умолчанию данные кластера хранятся в RAM. Это значит, что узлы кластера требуют значительного объёма оперативной памяти. Оценочная формула для расчёта памяти на узле:

(SizeOfDatabase × NumberOfReplicas × 1.1) / NumberOfDataNodes

Пример: если база 1 ГБ и реплик 1, у трёх узлов потребуется примерно 1.1 ГБ RAM на каждом узле.

Менеджер кластера слушает порт 1186 и по умолчанию доступен в сети. Запускайте кластер в изолированной частной сети или используйте firewall (/etc/hosts.deny и/или iptables) для ограничения доступа.
Полезная документация и FAQ (официальные ресурсы):

MySQL Cluster documentation: http://dev.mysql.com/doc/refman/5.1/en/ndbcluster.html
MySQL Cluster FAQ: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-faq.html

Диагностика распространённых проблем

Проблема: виртуальный IP не назначается на ожидаемый узел.
- Проверьте вывод ip addr sh eth0 и логи heartbeat (/var/log/daemon.log, /var/log/messages).
- Убедитесь, что firewall не блокирует протоколы heartbeat/keepalived или порты синхронизации IPVS.
Проблема: ipvsadm не показывает бэкенды на активном узле.
- Проверьте конфигурацию ldirectord и файл /etc/ha.d/ldirectord.cf на предмет синтаксических ошибок.
- Убедитесь, что ldirectord работает и имеет права на управление IPVS.
Проблема: клиенты теряют соединение при failover.
- Проверьте timeout-ы и TCP-состояния. Возможно, стоит настроить мягкое отключение соединений или использовать фиксированные таймауты на клиентах.

Чек-листы ролей

Администратору сети:

Проверить прокладку сети и доступность портов между узлами.
Настроить правила firewall для управления доступом.

Администратору баз данных:

Проверить консистентность данных после тестовых отключений.
Убедиться, что engine таблиц совместим с кластером (NDBCLUSTER при необходимости).

Тестировщику:

Прогнать сценарии failover и восстановления.
Провести нагрузочное тестирование и собрать метрики ActiveConn / CPU / RAM.

Ресурсы и ссылки

MySQL: http://www.mysql.com/
MySQL Cluster documentation: http://dev.mysql.com/doc/refman/5.1/en/ndbcluster.html
MySQL Cluster FAQ: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-faq.html
Ultra Monkey: http://www.ultramonkey.org/
The High-Availability Linux Project: http://www.linux-ha.org/
MySQL 5.1 Cluster Replication: http://blog.dbadojo.com/2007/08/mysql-51-ndb-cluster-replication-on-ec2.html
How to stress test my MySQL Cluster 5.1: http://blogs.techrepublic.com.com/howdoi/?p=133

Сводка

Запустите и перезагрузите балансировщики, затем проверьте виртуальный IP, статус ldirectord, таблицы ipvsadm и синхронизацию.
Протестируйте подключение из отдельного сервера и сценарии отказа.
Следуйте чек-листам и выполните диагностику, если возникают ошибки. Защитите порт управления кластера и разверните кластер в приватной сети.