Как настроить Keepalived HA для MySQL кластера?

Question

[WooDFox]

Вводные:
1. Три сервера с MySQL (Percona XtraDB Cluster) Ubuntu 12.04
2. IP адреса 10.10.1.121-123 и балансировщик .120
3. Необходимо разделить запись в виде один RW остальные RO

Настроено:
Виртуальный IP .120
Два вируал-сервера с IP .120 и портами 3307 и 3308
3307 ссылается на весь пул real_server 3306, маршрутизация DR (lb_kind)
3308 ссылается только на текущую ноду на 3306, маршрутизация NAT

Соединение на .120:3308 работает нормально, при переездах всегда отвечает локальный MySQL
А соединение на .120:3307 не работает (отваливается по таймауту). Судя по tcpdump port 3306, пакеты ходят нормально, но обрабатывающий сервер их не принимает (ответы MySQL идут с src ip ноды)

Собственно вопрос - что можно сделать?)

Answer 1

[WooDFox]

Проблема решена.
Решение пришло со стороны мануала и заключалось в том, что при DR на IPVS нельзя маппить порты.
Чуть позже будет мануал по сборке такого конфига.

Answer 2

[Пума Тайланд]

Настроить разделение запросов через mysqlproxy

Comments

[WooDFox]

Думал об этом решении, но, увы, не получилось поднять его. Нет ли у вас стоящего мануала по mysqlproxy?

[Пума Тайланд]

сказать честно оно там подымается в полпинка и там только добавить скрипт для разделения записи чтения

[WooDFox]

Я потыкал в мускуль-прокси, настройки там действительно крайне простые, но, в моей ситуации он отказывается стартовать. Почему - не ясно. Демон стартует, а статус прокси - fail.
Правда, ставил из пакета убунты 0.8.2, сча попробую 0.8.4 поднять...

[WooDFox]

sudo ./bin/mysql-proxy --proxy-lua-script=/etc/mysql-proxy/share/doc/mysql-proxy/rw-splitting.lua \
--proxy-address=10.10.1.120:3307 \
--proxy-backend-addresses=localhost:3306 \
--proxy-read-only-backend-addresses=10.10.1.122:3306 \
--proxy-read-only-backend-addresses=10.10.1.123:3306
Работает, но всегда отвечает одна нода кластера - что не так?

[Пума Тайланд]

ну вы наверно видите какая нода и можете понять почему из конфига

[WooDFox]

Увы, даже по IP, не localhost, отвечает только она. Или я чего-то не понял?)

[WooDFox]

Буду чуть точнее, другие ноды отвечают ошибкой.

[Пума Тайланд]

ну вы хотите чтобы мы гадали на кофейной гуще или все таки скажите какие у вас запросы и какие ошибки на них

[WooDFox]

Хорошо, попробую подробнее. Конфиг урезал до:
--plugins=proxy
--proxy-lua-script=/usr/share/mysql-proxy/rw-splitting.lua
--proxy-address=10.10.1.120:3307
--proxy-backend-addresses=10.10.1.122:3306
--proxy-read-only-backend-addresses=10.10.1.123:3306
--log-file=/var/log/mysql-proxy.log
--log-level=debug

Прокси сейчас на .121. Делаем рестарт сервиса mysql-proxy и обращаемся к веб-серверу, который коннектится к .120:3307 с запросом "SELECT * FROM `users`;". Первые 10 раз отвечает .122 нормально, потом подключается второй сервер и тут начинаются проблемы - ответ только через раз. Сервера местами менял, такая-же история. На неудачный запрос выпадают такие ошибки:

Ошибка php:
Warning: mysql_connect(): Unknown command in /var/www/frontend/index.php on line 12

Ошибка в логе прокси:
2014-05-21 11:15:43: (debug) [network-mysqld.c:937]: error on a connection (fd: -1 event: 0). closing client connection.

[Пума Тайланд]

не сталкивался с такой проблемой тут говорят какая то проблема из за ssh тунеля bugs.mysql.com/bug.php?id=43126
ошибка из php ставит в тупик мой мозг

[WooDFox]

Вот и я о том же. Баг по ссылке видел, но туннеля-то нет(( Ошибка в пыхе вообще убивает понимание ситуации, в том и дело((
Ведь подключается к удаленным нодам прокси нормально, к любой, но только к бэкенду. А на ридонли - никак.

[Пума Тайланд]

как вариант у вас какой то кривой луа скрипт не той версии для разделения запросов

[WooDFox]

Скрипт в пакете идет. Лан, нашел еще одно место теоретического затыка, ща из исходников соберу другую версию и посмотрю что будет.

[WooDFox]

@opium спасибо за советы. Удалось поднять все это на mysql_proxy, но решено от него отказаться - слишком тяжелый. Реализация на keepalived в 2+ раза быстрее.

[Пума Тайланд]

А кипаливед умеет делить записи и чтения на разные ноды?

[WooDFox]

Собственно, аппликаэйшн в процессе разработки и не проблема порезать порты для чтения/записи. Так же это дает возможность читать авторизационные данные только с текущей пишущей ноды и избежать ансинка по важным данным.
Текущая конфига:

virtual_server 10.10.1.120 3306 {
delay_loop 2
lb_algo rr
lb_kind DR
protocol TCP

real_server 10.10.1.122 3306 {
weight 10
}

real_server 10.10.1.123 3306 {
weight 10
}
}

virtual_server 10.10.1.120 3307 {
delay_loop 10
lb_algo rr
lb_kind NAT
protocol TCP

real_server 10.10.1.121 3306 {
weight 10
}
}

Ноды на рилсерверах зависят от ноды балансировщика, естественно.
Время записи 10 строк в индексированную таблицу (2кк+ записей) с новыми коннектами упало с 0,7-1,0 до 0,15-0,4, что весьма ощутимо. Чтение упало еще сильнее.

[WooDFox]

Зы, по времени не пугайтесь - большая ферма на слабом хосте развернута + 100 одновременных коннектов. На реальном железе разница еще ощутимее будет. Железки не приехали еще))

[Пума Тайланд]

проще тогда на базе самого апликейшена сделать все без лишних прослоек.

[WooDFox]

Если бы аппликэйшн жил на одной ноде - да. А их базово будет 4 (NLB), а значит необходимо синхронизировать текущую пишушую ноду кластера, иметь отдельные чекеры на всех нодах и далее по списку.