Статья об отказоустойчивости MySQL Cluster

Я так понимаю, что арбитр - это Master.

Пересказ документации, только сумбурный и очень непоследовательный.

Гораздо лучше было воткнуть статью о построении отказоустойчивой (реально, а не как в статье) системы с двумя управляющими машинами (есть на opennet.ru).

Арбитр это Arbitrator. Существуют другие отказоустойчивые решения, но в статье речь идет именно о MySQL Cluster. Основное внимание уделяется алгоритмам арбитража, которые в документации MySQL в настоящее время не описаны. Другая информация о MySQL Cluster приведена в справочном виде без стремления охватить все, так как тема достаточно широкая.

ИМХО статья ни о чем. Никакой конкретики и очень сумбурно.

все признаки диалекта русского языка, использованного в статье, указывают на то, что её разработал высокоуровневый программист... начинающий -- судя по сумбуру и недосказанностям. )

статья из 10 строчек? ага это даже на рассказ школьника о mysql не тянет

>Арбитр это Arbitrator. Существуют другие отказоустойчивые решения,

Когда на управляющей ноде смотришь в машины это скорее всего Master.

Других решений есть одна штука, если я все верно помню - реплика мастер-мастер + к ней slaves по принципу двойного дерева. Адрес навскидку не скажу, т.к. для моих целей не подходило и тестил кратко.

> Когда на управляющей ноде смотришь в машины это скорее всего Master.

Такова официальная терминология MySQL Cluster. Master в кластере - одна из дата-нод, которая выполняет некоторые дополнительные функции (координация транзакций и другие). На управляющей ноде действительно можно смотреть текущую конфигурацию, но арбитр не обязательно на управляющей ноде. Арбитр - роль, которую может играть управляющая или SQL-нода. Роль простая - решать, кто остается в работе в случае фрагментации.

На двух физических машинах MySQL Cluster отказоустойчивым быть не может - такой факт жизни (исключение - MySQL CLuster Carrier Grade Edition с отключенным арбитражом). Среди других решений можно привести Master-Master репликацию (так называемую круговую) с числом серверов от 2 и выше, решения с использованием DRBD и сторонние решения на MySQL, например Continuent uni/cluster.

При использовании Master-Master репликации на двух машинах все равно требуется некий внешний сервис мониторинга, который будет отслеживать сбои и в случае сбоя перенаправлять запросы на работающую машина. Фактически это арбитр, а работает он на некоторой третьей машине. В кластере роли автоматизированы и восставновление каждой ноды тоже. Если в приведенной в статье конфигурации из трех машин (простейшей), выйдет из строя любая машина

а) кластер продолжит нормальную работу без потери данных

б) вышедшую из строя машину достаточно будет просто включить и подключить к сети (при необходимости установив MySQL заново), она войдет в конфигурацию и, при необходимости, скопирует у других машин все необходимые ей данные.