|
|
Задавайте вопросы, мы ответим
Вы не зашли.
всем привет
1) Как-то всё немножко путано с версиями. Я так понял до какой-то из 5.0.х версий mysql cluster поставлялся вместе с собственно mysql server, затем выделился в отдельную ветку со своей нумерацией версий. Какая совместимость между версиями mysql и ndbd? Можно ли уговорить mysql 5.0.90 дружить с mysql cluster 6.3/7.0 и что в какой последовательности нужно устанавливать для старших версий?
2) В FAQ-e написано что "MySQL Cluster does not provide any sort of automatic failover between SQL nodes. Your application must be prepared to handle the loss of SQL nodes and to fail over between them."
Что в таком случае ожидается от хорошего приложения? Поймать ошибку, пореконнектится к живому узлу и повторить транзакцию? А другие узлы у нас, я так понимаю, в строке подключения перечислены и выбираем к какому попробовать подключится мы по принципу round-robin. Получается что если у нас 2 узла, то в половине случаев реконнектиться мы будем пытаться к мёртвому и при этом будем повисать на долгих tcp-шных таймаутах.
Или я неправильно понимаю?
Кстати, в случае гибели ndbd процесса пользовательская сессия тоже умрёт, или эта ситуация обработается прозрачно для приложения?
Что происходит если у приложения пул закешированых соединений? Почистятся ли автоматом дохлые сессии? Это нужно смотреть документацию к конкретному драйверу-коннектору, да?
Неактивен
1. Кластер — это независимое от MySQL приложение. У него есть свой
протокол общения, свой API. MySQL умеет использовать это независимое
приложение через специальный тип таблиц. Но на самом деле он исполь-
зует его именно через API. Соответственно, обновлять их можно незави-
симо. API обычно вообще не меняется, так что версии должны быть
совместимы.
2. Да, балансировать нагрузку нужно какими-то своими средствами. Мо-
жете использовать, например, haproxy — он будет балансировать нагрузку
за Вас (тем не менее, если упадет он — Вы останетесь без точки входа
в кластер, поэтому он не есть идеальное решение). Для HA-приложений
приходится писать свою логику (например, периодическое пропингивание
серверов на живость; если это делать отдельным потоком, то Вы не очень
зависите от tcp-таймаутов). Пул соединений ничем не лучше, чем пачка
независимых соединений — если они были открыты к умершей ноде, они
все умрут.
ndbd ничего не знает о пользовательских сессиях — он работает внутри
своего приложения и своего API.
Неактивен
спасибо большое за ответы
1) да, я размышлял руководствуясь той же логикой про API, но в документации явного подтверждения не нашёл, возможно невнимательно читал
2) хм... я как бы не писатель, скорее мне придётся пытаться натягивать существующие приложения на mysql cluster. Кроме того у меня психика деформирована работой с oracle RAC, потому я надеялся что какие-то механизмы фейловера соединений в mysql кластере есть из коробки, ну или хотя бы есть способ это прикрутить, не сильно трогая код.
3) "ndbd ничего не знает о пользовательских сессиях — он работает внутри своего приложения и своего API."
но как минимум текущая транзакция при этом теряется (4025 'Node failure caused abort of transaction' from ndbcluster).
т.е. в случае смерти mysqld - реконнектимся (желательно к живому узлу) и начинаем всё сначала
в случае смерти ndbd (любого одного?) - повторяем последнюю незафиксированную транзакцию в рамках текущей сессии (можно не переконнекчиваться)
Отредактированно artemg (22.02.2010 22:16:15)
Неактивен
Oracle RAC ничем не лучше — он так же не умеет балансировать 
В случае смерти соединения — Вам нужно соединение переустановить. Если
у Вас не прошла транзакция — ее, возможно, нужно повторить.
Неактивен
в oracle RAC механизмы фейловера и балансировки есть и не по одному, можно повыбирать
но сравнивать его с mysql давайте не будем, это холиварная тема и продукты явно совсем разные и для разных задач
paulus написал:
В случае смерти соединения — Вам нужно соединение переустановить. Если
у Вас не прошла транзакция — ее, возможно, нужно повторить.
да, это понятно
непонятно почему при смерти ndbd помирает текущая транзакция
ну, вернее понятно, но немного нелогично, ведь если она пишется во все реплики, то продолжить её с середины должно быть несложно
Неактивен
artemg написал:
непонятно почему при смерти ndbd помирает текущая транзакция
ну, вернее понятно, но немного нелогично, ведь если она пишется во все реплики, то продолжить её с середины должно быть несложно
Это не всегда происходит, но, например, может погибнуть нода, которая является координатором транзакции.
Неактивен
rgbeast написал:
нода, которая является координатором транзакции.
хм...
не нашел в доке, что за функции она выполняет, только про то, как её выбирают
где можно почитать про это координаторство?
кстати про совместимость версий
поставил ndb-6.3.27
ndb_mgm написал:
ndb_mgm> show
Connected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)] 2 node(s)
id=2 @192.168.2.11 (mysql-5.1.37 ndb-6.3.27, Nodegroup: 0, Master)
id=3 @192.168.2.12 (mysql-5.1.37 ndb-6.3.27, Nodegroup: 0)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @192.168.2.1 (mysql-5.1.37 ndb-6.3.27)
[mysqld(API)] 2 node(s)
id=4 (not connected, accepting connect from any host)
id=5 (not connected, accepting connect from any host)
при попытке приконнектиться к кластеру 5.0.90 mysql-ем получил
Node 3: Connection attempt from api or mysqld id=4 with ndb-5.0.90 incompatible with mysql-5.1.37 ndb-6
Неактивен
Координатор отвечает за исполнение "two-phase commit protocol". У кластера документация сильно неполна. Неплохо написано в книге "MySQL Cluster Certification Study Guide", там есть порядок исполнения транзакции и поведение при различных типах отказов. Часть же знания о кластере вообще не записана нигде.
В двухфазном протоколе, если нода выпадает на первой фазе, то транзакция везде откатывается, а если на второй, то коммит происходит везде, кроме выпавшей ноды. Так как, если вы работаете с кластером, то должны в любом случае обрабатывать временные откаты транзакций, откат транзакции с ошибкой не считается проблемой.
Неактивен
Хм, видимо, до 5.0 не дотянули протокол 
Жалко
Неактивен
спасибо!
rgbeast написал:
"MySQL Cluster Certification Study Guide"
её в России где-то можно купить?
на озоне нету, яндекс тоже не сильно помог
Неактивен
artemg написал:
на озоне нету, яндекс тоже не сильно помог
На amazon.com можно заказать с доставкой в Россию. К сожалению, это почти единственный способ купить данную книгу.
Неактивен
упс, на амазоне тоже нет в наличии, странно. Книга издана в on-demand издательстве lulu.com и должна быть в наличии всегда по определению. Но на сайте издательства ее тоже нет.
Неактивен
наверно тираж очень маленький
в электронном виде, я так понимаю, её тоже бесполезно искать?
Неактивен
Вот здесь есть второе издание в продаже (тоже on-demand издательство) http://store.vervante.com/c/v/595352502.html
Неактивен
а вот эта книжка хорошая, держал кто-то в руках?
https://www.ozon.ru/context/detail/id/3668006/
Неактивен
artemg написал:
а вот эта книжка хорошая, держал кто-то в руках?
https://www.ozon.ru/context/detail/id/3668006/
Пока что не приходилось
Неактивен
