NDB Cluster не поддерживается в стандартных выпусках MySQL Server. Вместо этого MySQL NDB Cluster предоставляется как отдельный продукт. Доступные серии выпусков NDB Cluster включают следующие:

Вы можете получить и скомпилировать NDB Cluster из исходного кода (см. Раздел 25.3.1.4, “Building NDB Cluster from Source on Linux” и Раздел 25.3.2.2, “Compiling and Installing NDB Cluster from Source on Windows”), но для всех случаев, кроме наиболее специализированных, рекомендуется использовать один из следующих установщиков, предоставляемых Oracle, соответствующий вашей операционной системе и обстоятельствам:

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

Вы можете определить, поддерживает ли ваш MySQL Server NDB, используя одно из предложенных высказываний SHOW VARIABLES LIKE 'have_%', SHOW ENGINES или SHOW PLUGINS.

“NDB” расшифровывается как “Cеть Данных Базы”. NDB и NDBCLUSTER — это оба названия хранилища, которое обеспечивает поддержку кластеризации в MySQL. NDB предпочтительно, но любое название верно.

В традиционной репликации MySQL источник MySQL Server обновляет один или несколько реплик. Транзакции коммитируются последовательно, и медленная транзакция может привести к тому, что реплика отстанет от источника. Это означает, что если источник выйдет из строя, возможно, что реплика не запишет последние несколько транзакций. Если используется движок, безопасный для транзакций, такой как InnoDB, транзакция либо завершается на реплике, либо вообще не применяется, но репликация не гарантирует, что все данные на источнике и реплике останутся согласованными во все моменты времени. В NDB Cluster все узлы данных поддерживаются в синхронном состоянии, и транзакция, зафиксированная в любом узле данных, фиксируется во всех узлах данных. В случае отказа узла данных все оставшиеся узлы данных остаются в согласованном состоянии.

Короче говоря, в то время как стандартная репликация MySQL является асинхронной, NDB Cluster является синхронной.

Асинхронная репликация также доступна в NDB Cluster. Репликация NDB Cluster (также иногда известная как “гео-репликация”) включает возможность репликации как между двумя NDB Cluster, так и из NDB Cluster в сервер MySQL, не являющийся кластером. См. Раздел 25.7, “NDB Cluster Replication”.

NDB Cluster предназначен для использования в среде с высокой пропускной способностью, где компьютеры соединяются с помощью TCP/IP. Его производительность напрямую зависит от скорости соединения между компьютерами кластера. Минимальные требования к подключению для NDB Cluster включают типичную сеть 100 мегабит Ethernet или эквивалент. Рекомендуется использовать гигабитный Ethernet, когда это возможно.

Минимально требуется три компьютера для работоспособного кластера. Однако минимальное рекомендуемое количество компьютеров в NDB Cluster составляет четыре: по одному для управления и SQL узлов и два компьютера в качестве узлов данных. Цель двух узлов данных — обеспечение резервирования; узел управления должен работать на отдельном компьютере, чтобы гарантировать непрерывное предоставление арбитражных услуг в случае отказа одного из узлов данных.

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

Кластер NDB имеет физическую и логическую организацию, причём компьютерами являются физические элементы. Логические или функциональные элементы кластера называются узлами, а компьютер, в котором размещён узел кластера, иногда называется хостом кластера. Существует три типа узлов, каждый из которых соответствует определённой роли в кластере. Это:

Проще всего ответить так: “Этого вы не можете контролировать, и в любом случае беспокоиться об этом не нужно, если только вы не программист, который пишет или анализирует исходный код кластера NDB”.

Если этот ответ вас не удовлетворяет, вот более длинный и технический вариант:

Ряд механизмов в кластере NDB требуют распределённого координирования между узлами данных. Эти распределённые алгоритмы и протоколы включают глобальное создание контрольных точек, изменения DDL (схемы) и обработку перезапуска узлов. Чтобы упростить это координирование, узлы данных “выбирают” одного из них в качестве лидера. Нет никакого пользовательского механизма для влияния на этот выбор, который полностью автоматичен; то, что он является автоматическим, является ключевой частью внутренней архитектуры NDB Cluster.

Когда узел выполняет роль “лидера” для любого из этих механизмов, он обычно является точкой координации для данной активности, а другие узлы выступают в роли “ведомых”, выполняя свои части активности по указанию лидера. Если узел, выполняющий роль лидера, выходит из строя, оставшиеся узлы выбирают нового лидера. Задачи, которые выполнялись под руководством старого лидера, могут либо завершиться неудачей, либо будут продолжены новым лидером, в зависимости от конкретного механизма.

Возможно, для разных механизмов и протоколов могут быть выбраны разные узлы-лидеры, но в целом для всех них выбирается один и тот же лидер. Узел, указанный как лидер в выводе команды SHOW в клиенте управления, известен внутри как DICT менеджер, отвечающий за координирование деятельности DDL и метаданных.

Кластер NDB разработан таким образом, что выбор лидера не оказывает заметного влияния за пределами самого кластера. Например, у текущего лидера нет существенно более высокой загрузки процессора или ресурсов, чем у других узлов данных, и отказ лидера не должен оказывать существенно большего влияния на кластер, чем отказ любого другого узла данных.

NDB Cluster поддерживается на большинстве Unix-подобных операционных систем. NDB Cluster также поддерживается в производственных средах на операционных системах Microsoft Windows.

Более подробную информацию о поддержке NDB Cluster на различных версиях операционных систем, дистрибутивах операционных систем и аппаратных платформах см. на странице https://www.mysql.com/support/supportedplatforms/cluster.html.

NDB Cluster должен работать на любой платформе, для которой доступны NDB-бинарные файлы. Для узлов данных и узлов API более быстрые процессоры и больше оперативной памяти, скорее всего, улучшат производительность, а 64-битные процессоры, вероятно, будут более эффективными, чем 32-битные. На машинах, используемых для узлов данных, должно быть достаточно оперативной памяти для хранения каждой доли базы данных (см. Сколько оперативной памяти мне нужно? для получения дополнительной информации). Для компьютера, используемого только для запуска сервера управления кластером NDB, требования минимальны; обычный настольный компьютер (или его эквивалент) обычно достаточно для этой задачи. Узлы могут обмениваться данными через стандартную сеть TCP/IP и оборудование. Они также могут использовать высокоскоростной протокол SCI; однако для использования SCI требуется специальное сетевое оборудование и программное обеспечение (см. раздел 25.4.4, «Использование высокоскоростных соединений с NDB Cluster»).

Кластер NDB изначально реализовывался только в оперативной памяти, но все доступные в настоящее время версии также предоставляют возможность хранения кластера NDB на диске. Более подробную информацию см. в разделе 25.6.11 «NDB Cluster Disk Data Tables».

Для таблиц в оперативной памяти NDB вы можете использовать следующую формулу для получения приблизительной оценки необходимого объёма оперативной памяти для каждого узла данных в кластере:

(SizeofDatabase × NumberOfReplicas × 1.1 ) / NumberOfDataNodes

Для более точного расчёта потребностей в памяти необходимо определить для каждой таблицы в базе данных кластера требуемый объём памяти на строку (см. раздел 13.7 «Требования к хранению типов данных» для получения подробных сведений) и умножить это значение на количество строк. Также необходимо учесть все индексы столбцов следующим образом:

Создание таблиц NDB Cluster с USING HASH для всех первичных ключей и уникальных индексов обычно приводит к тому, что обновление таблиц выполняется быстрее — в некоторых случаях на 20–30 процентов быстрее, чем обновление таблиц, где USING HASH не использовалось при создании первичных и уникальных ключей. Это связано с тем, что требуется меньше памяти (поскольку не создаются упорядоченные индексы) и используется меньше ЦП (поскольку нужно читать и, возможно, обновлять меньше индексов). Однако это также означает, что запросы, которые в противном случае могли бы использовать диапазонные сканирования, должны удовлетворяться другими средствами, что может привести к замедлению операций выборки.

При расчёте потребностей кластера в памяти вам может быть полезной утилита ndb_size.pl, доступная в последних выпусках MySQL 9.2. Этот скрипт Perl подключается к текущей (не кластерной) базе данных MySQL и создаёт отчёт о том, сколько места потребовала бы эта база данных, если бы она использовала движок хранения NDBCLUSTER. Более подробную информацию см. в разделе 25.5.29 «ndb_size.pl — NDBCLUSTER Size Requirement Estimator».

Очень важно помнить, что каждая таблица NDB Cluster должна иметь первичный ключ. Движок хранения NDB создаёт первичный ключ автоматически, если он не определён; этот первичный ключ создаётся без USING HASH.

Вы можете определить объём памяти, используемый для хранения данных и индексов NDB Cluster в любой момент времени, используя команду REPORT MEMORYUSAGE в клиенте ndb_mgm; для получения дополнительной информации см. раздел 25.6.1 «Команды в клиенте управления кластером NDB». Кроме того, в журнале кластера записываются предупреждения, когда 80% доступной DataMemory или (до NDB 7.6) IndexMemory используется, а также при достижении 90%, 99% и 100% использования.

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

Для Windows мы рекомендуем использовать NTFS файловые системы для кластера NDB, как и для стандартного MySQL. Мы не тестируем кластер NDB с FAT или VFAT файловыми системами. По этой причине мы не рекомендуем их использовать с MySQL или кластером NDB.

NDB Cluster реализован как решение «без общего доступа»; идея заключается в том, что отказ одного компонента оборудования не должен привести к отказу нескольких узлов кластера, а возможно, и всего кластера в целом. По этой причине использование сетевых общих ресурсов или сетевых файловых систем не поддерживается для кластера NDB. Это также относится к устройствам общего хранения, таким как SAN.

Поддержка кластера NDB в виртуальных машинах есть. В настоящее время мы поддерживаем и тестируем использование Oracle VM.

Некоторые пользователи кластера NDB успешно развернули кластер NDB с использованием других продуктов виртуализации; в таких случаях Oracle может предоставить поддержку кластера NDB, но проблемы, специфичные для виртуальной среды, должны быть обращены к поставщику этого продукта.

Вероятной причиной является то, что ваша конфигурация не предоставляет достаточного объёма оперативной памяти для всех данных таблиц и всех индексов, включая первичный ключ, необходимый для движка хранения NDB и автоматически создаваемый в случае, если определение таблицы не включает определение первичного ключа.

Также следует отметить, что все узлы данных должны иметь одинаковый объём оперативной памяти, поскольку ни один узел данных в кластере не может использовать больше памяти, чем наименьший объём памяти, доступный любому отдельному узлу данных. Например, если четыре компьютера выполняют роль узлов данных кластера, и три из них имеют 3 ГБ оперативной памяти для хранения данных кластера, в то время как оставшийся узел данных имеет только 1 ГБ оперативной памяти, то каждый узел данных может выделить максимум 1 ГБ для данных и индексов NDB Cluster.

В некоторых случаях возможны ошибки Таблица заполнена в приложениях клиентов MySQL, даже когда ndb_mgm -e "ALL REPORT MEMORYUSAGE" показывает значительный свободный объём DataMemory. Вы можете заставить NDB создавать дополнительные разделы для таблиц NDB Cluster и тем самым иметь больше памяти для индексов хеширования, используя параметр MAX_ROWS для CREATE TABLE. В целом, установить MAX_ROWS в два раза больше ожидаемого количества строк, которые вы планируете хранить в таблице, должно быть достаточно.

По аналогичным причинам иногда могут возникать проблемы с перезагрузкой узлов данных на узлах, сильно загруженных данными. Параметр MinFreePct может помочь с этой проблемой, резервируя часть (по умолчанию 5%) DataMemory и (до NDB 7.6) IndexMemory для использования при перезагрузке. Эта зарезервированная память недоступна для хранения таблиц или данных NDB.

Вероятность того, что кластер будет работать надёжно в таких условиях, очень низка, так как кластер NDB был разработан и реализован с предположением о функционировании в условиях, гарантирующих выделенную высокоскоростную связь, например, в локальной сети с использованием 100 Мбит/с или гигабитного Ethernet — предпочтительно последнего. Мы не тестируем и не гарантируем его производительность с использованием чего-либо медленнее, чем это.

Также крайне важно помнить, что коммуникации между узлами в кластере NDB не защищены; они не зашифрованы и не защищены никаким другим механизмом защиты. Наиболее безопасная конфигурация кластера — в частной сети позади брандмауэра без прямого доступа к данным или узлам управления кластера извне. (Для узлов SQL вы должны принять те же меры предосторожности, что и для любого другого экземпляра сервера MySQL.) Более подробную информацию см. в разделе 25.6.21 «Проблемы безопасности кластера NDB».

Нет. Хотя некоторые специализированные команды используются для управления и настройки самого кластера, для следующих операций требуется только стандартные (My)SQL-запросы:

Для настройки NDB Cluster требуются некоторые специализированные параметры конфигурации и файлы — см. Раздел 25.4.3, «Файлы конфигурации NDB Cluster» для получения информации об этих параметрах.

В клиенте управления NDB Cluster (ndb_mgm) используются несколько простых команд для таких задач, как запуск и остановка узлов кластера. См. Раздел 25.6.1, «Команды в клиенте управления NDB Cluster».

NDB Cluster поддерживает те же API и языки программирования, что и стандартный MySQL Server, включая ODBC, .Net, MySQL C API и множество драйверов для популярных языков сценариев, таких как PHP, Perl и Python. Приложения NDB Cluster, написанные с использованием этих API, работают аналогично другим приложениям MySQL; они передают SQL-запросы в MySQL Server (в случае NDB Cluster, в узел SQL) и получают ответы, содержащие строки данных. Более подробную информацию об этих API см. в Главе 31, Коннекторы и API.

NDB Cluster также поддерживает программирование приложений с помощью NDB API, который предоставляет низкоуровневый C++ интерфейс к данным NDB Cluster без необходимости прохождения через MySQL Server. См. . Кроме того, многие функции управления NDBCLUSTER доступны через API MGM на языке C; см. для получения дополнительной информации.

NDB Cluster также поддерживает программирование Java-приложений с помощью ClusterJ, которое поддерживает модель предметной области данных с использованием сессий и транзакций. См. для получения дополнительной информации.

NDB Cluster 8.0 также включает адаптеры, поддерживающие приложения NoSQL, написанные для Node.js с NDB Cluster в качестве хранилища данных. См. для получения дополнительной информации.

NDB Cluster включает клиент командной строки для выполнения основных функций управления. См. Раздел 25.5.5, «ndb_mgm — Клиент управления NDB Cluster» и Раздел 25.6.1, «Команды в клиенте управления NDB Cluster».

NDB Cluster также поддерживается MySQL Cluster Manager, отдельным продуктом, предоставляющим расширенный интерфейс командной строки, который может автоматизировать многие задачи управления NDB Cluster, такие как поэтапные перезагрузки и изменения конфигурации. Для получения дополнительной информации о MySQL Cluster Manager см. Руководство пользователя MySQL Cluster Manager 9.2.0.

Существует два способа:

Да. Для таблиц, созданных с помощью NDB движка хранения, поддерживаются транзакции. В настоящее время NDB Cluster поддерживает только уровень изоляции транзакций READ COMMITTED.

NDB Cluster требует NDB движок хранения. То есть, чтобы таблица могла быть разделена между узлами в NDB Cluster, таблица должна быть создана с использованием ENGINE=NDB (или эквивалентного варианта ENGINE=NDBCLUSTER).

Можно создавать таблицы с использованием других движков хранения (таких как InnoDB или MyISAM) на MySQL-сервере, используемом с NDB Cluster, но так как эти таблицы не используют NDB, они не участвуют в кластеризации; каждая такая таблица строго локальна для отдельной MySQL-инстанции, в которой она создана.

NDB Cluster существенно отличается от InnoDB кластеризации по архитектуре, требованиям и реализации; несмотря на сходство в именах, эти два варианта несовместимы. Более подробную информацию о InnoDB кластеризации см. . Также см. Раздел 25.2.6, «MySQL Server с InnoDB по сравнению с NDB Cluster» для информации о различиях между NDB и InnoDB движками хранения.

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

FULLTEXT индексация в настоящее время поддерживается только InnoDB и MyISAM движками хранения. См. Раздел 14.9, «Функции полнотекстового поиска» для получения дополнительной информации.

Это возможно, но не всегда рекомендуется. Одна из основных причин запуска кластера — обеспечение избыточности. Чтобы получить все преимущества этой избыточности, каждый узел должен находиться на отдельном компьютере. Если вы разместите несколько узлов на одном компьютере, и этот компьютер выйдет из строя, вы потеряете все эти узлы. По этой причине, если вы запускаете несколько узлов данных на одном компьютере, крайне важно, чтобы они были настроены таким образом, что отказ этого компьютера не приводил к потере всех узлов данных в данной группе узлов.

Учитывая, что кластер NDB может работать на обычном оборудовании, загруженном операционной системой с низкой стоимостью (или даже без неё), затраты на дополнительный компьютер или два оправданы, чтобы защитить критически важные данные. Также следует отметить, что требования к хосту кластера, на котором работает управляющий узел, минимальны. Эта задача может быть выполнена с процессором Pentium 300 МГц или эквивалентом и достаточным объёмом оперативной памяти для операционной системы, плюс небольшой объём ресурсов для процессов ndb_mgmd и ndb_mgm.

Допустимо запускать несколько узлов данных кластера на одном хосте, имеющем несколько процессоров, ядер или то и другое. Распространение NDB Cluster также предоставляет многопоточную версию двоичного файла узла данных, предназначенного для использования на таких системах. Дополнительную информацию см. в Разделе 25.5.3 «ndbmtd — Узел данных кластера NDB (многопоточный)».

В некоторых случаях также возможно одновременное выполнение узлов данных и SQL-узлов на одном компьютере; эффективность такой конфигурации зависит от ряда факторов, таких как количество ядер и процессоров, а также объём дискового пространства и оперативной памяти, доступные процессам узла данных и SQL-узла, и вы должны учитывать эти факторы при планировании такой конфигурации.

Можно добавить новые узлы данных в работающий кластер NDB без вывода кластера из работы. Дополнительную информацию см. в Разделе 25.6.7 «Добавление узлов данных кластера NDB online».

Для других типов узлов кластера NDB требуется только поэтапная перезагрузка (см. Раздел 25.6.5 «Поэтапная перезагрузка кластера NDB»).

Ограничения на таблицах NDB в MySQL NDB Cluster включают следующее:

Полный список ограничений в кластере NDB см. в Разделе 25.2.7 «Известные ограничения кластера NDB». См. также Раздел 25.2.7.11 «Прежние проблемы кластера NDB, решенные в кластере NDB 9.2».

Кластер NDB предоставляет поддержку ограничений внешних ключей, которая сопоставима с поддержкой механизма хранения InnoDB; см. Раздел 1.7.3.2 «Ограничения FOREIGN KEY» для более подробной информации, а также Раздел 15.1.21.5 «Ограничения FOREIGN KEY». Приложения, которым требуется поддержка внешних ключей, должны использовать кластер NDB 7.3, 7.4, 7.5 или более поздние версии.

Вы можете импортировать базы данных в кластер NDB так же, как и в любой другой версии MySQL. Помимо ограничений, упомянутых в данном FAQ, единственное дополнительное требование состоит в том, что все таблицы, которые должны быть включены в кластер, должны использовать механизм хранения NDB. Это означает, что таблицы должны быть созданы с использованием ENGINE=NDB или ENGINE=NDBCLUSTER.

Также возможно преобразовать существующие таблицы, использующие другие механизмы хранения, в механизм хранения NDBCLUSTER с помощью одной или нескольких инструкций ALTER TABLE. Однако определение таблицы должно быть совместимо с механизмом хранения NDBCLUSTER до преобразования. В MySQL 9.2 требуется дополнительный обходной путь; см. Раздел 25.2.7 «Известные ограничения кластера NDB» для получения подробностей.

Узлы кластера могут взаимодействовать через три разных механизма передачи данных: TCP/IP, SHM (общая память) и SCI (масштабируемый когерентный интерфейс). Там, где доступна, SHM используется по умолчанию между узлами, находящимися на одном хосте кластера; однако это считается экспериментальным. SCI — это высокоскоростной (1 гигабит в секунду и выше), высокодоступный протокол, используемый для создания масштабируемых многопроцессорных систем; он требует специального оборудования и драйверов. См. Раздел 25.4.4 «Использование высокоскоростных соединений с кластером NDB» для получения дополнительной информации об использовании SCI в качестве механизма передачи данных для кластера NDB.

Если один или несколько узлов данных в кластере выходят из строя, возможно, что не все узлы данных кластера смогут “видеть” друг друга. Фактически, возможно, что два набора узлов данных могут оказаться изолированными друг от друга в результате разделения сети, также известного как сценарий “split-brain”. Такая ситуация нежелательна, поскольку каждый набор узлов данных пытается вести себя так, как будто он является целым кластером. Для выбора между конкурирующими наборами узлов данных требуется арбитр.

Когда все узлы данных хотя бы в одной группе узлов активны, разделение сети не является проблемой, поскольку ни один подмножество кластера не может самостоятельно образовать функциональный кластер. Реальная проблема возникает, когда ни одна группа узлов не имеет всех своих узлов активными, в этом случае разделение сети (сценарий “split-brain”) становится возможным. Тогда требуется арбитр. Все узлы кластера распознают один и тот же узел в качестве арбитра, которым обычно является сервер управления; однако можно настроить любой из MySQL Server в кластере для работы в качестве арбитра. Арбитр принимает первый набор узлов кластера, которые обращаются к нему, и предписывает оставшемуся набору отключиться. Выбор арбитра управляется параметром конфигурации ArbitrationRank для узлов MySQL Server и сервера управления. Вы также можете использовать параметр конфигурации ArbitrationRank для управления процессом выбора арбитра. Для получения дополнительной информации об этих параметрах см. Раздел 25.4.3.5, «Определение сервера управления кластером NDB».

Роль арбитра сама по себе не накладывает каких-либо больших требований на назначенный таким образом хост, и поэтому хост арбитра не должен быть особенно быстрым или иметь дополнительную память специально для этой цели.

NDB Cluster поддерживает все обычные типы данных MySQL, включая те, которые связаны с пространственными расширениями MySQL; однако, механизм хранения NDB не поддерживает пространственные индексы. (Пространственные индексы поддерживаются только MyISAM; см. Раздел 13.4, «Пространственные типы данных» для получения дополнительной информации.) Кроме того, существуют некоторые различия в отношении индексов при использовании с таблицами NDB.

См. Раздел 25.2.7, «Известные ограничения NDB Cluster» для получения дополнительной информации об этих проблемах.

Необходимо запустить каждый узел в кластере отдельно, в следующем порядке:

Каждая из этих команд должна выполняться из системной оболочки на компьютере, на котором находится соответствующий узел. (Вам не обязательно физически присутствовать на компьютере — для этого можно использовать удаленную оболочку для входа.) Вы можете убедиться, что кластер запущен, запустив клиент управления NDB ndb_mgm на компьютере, на котором находится узел управления, и выполнив команду SHOW или ALL STATUS.

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

$> ndb_mgm -e "SHUTDOWN"

(Кавычки в этом примере являются необязательными, поскольку в строке команды после параметра -e нет пробелов; кроме того, команда SHUTDOWN, как и другие команды клиента управления, не чувствительна к регистру.)

Любая из этих команд приводит к тому, что процессы ndb_mgm, ndb_mgm и любые процессы ndbd завершаются корректно. Серверы MySQL, работающие в качестве SQL-узлов, можно остановить с помощью mysqladmin shutdown.

Для получения дополнительной информации см. Раздел 25.6.1, «Команды в клиенте управления кластером NDB» и Раздел 25.3.6, «Безопасное завершение работы и перезапуск NDB Cluster».

MySQL Cluster Manager предоставляет дополнительные способы обработки запуска и остановки узлов NDB Cluster. См. Руководство пользователя MySQL Cluster Manager 9.2.0 для получения дополнительной информации об этом инструменте.

Данные, которые хранились в памяти узлами данных кластера, записываются на диск и перезагружаются в память при следующем запуске кластера.

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

См. Раздел 25.4.3, «Файлы конфигурации NDB Cluster» для получения информации о том, как настроить узлы управления NDB Cluster.

Да, если все машины и операционные системы имеют одинаковую “endianness” (все big-endian или все little-endian).

Также можно использовать программное обеспечение из разных релизов NDB Cluster на разных узлах. Однако мы поддерживаем такое использование только в рамках процедуры поэтапного обновления (см. Раздел 25.6.5, «Выполнение поэтапного перезапуска NDB Cluster»).

Да, это возможно. В случае нескольких узлов данных рекомендуется (но не обязательно), чтобы каждый узел использовал отдельный каталог данных. Если вы хотите запустить несколько узлов SQL на одном компьютере, каждый экземпляр mysqld должен использовать различный порт TCP/IP.

Запуск узлов данных и SQL-узлов вместе на одном хосте возможен, но следует помнить, что процессы ndbd или ndbmtd могут конкурировать за память с mysqld.

Да, можно использовать DNS и DHCP для хостов кластера. Однако, если ваше приложение требует доступности “пять девяток”, вы должны использовать фиксированные (численные) IP-адреса, так как передача сообщений между узлами кластера, зависящая от таких сервисов, как DNS и DHCP, вносит дополнительные потенциальные точки отказа.

Все типы узлов NDB Cluster поддерживают IPv6; это включает узлы управления, узлы данных и узлы API или SQL.

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

MySQL NDB Cluster не предоставляет автоматического failover между SQL-узлами. Ваше приложение должно быть готово к потере SQL-узлов и переключению на другие.

Вы можете использовать встроенную функцию резервного копирования и восстановления NDB Cluster в клиенте управления NDB и программе ndb_restore. См. Раздел 25.6.8, «Онлайн резервное копирование NDB Cluster» и Раздел 25.5.23, «ndb_restore — Восстановление резервной копии NDB Cluster».

Также вы можете использовать традиционную функциональность для этой цели в mysqldump и сервере MySQL. См. Раздел 6.5.4, «mysqldump — Программа резервного копирования базы данных» для получения дополнительной информации.

Этот процесс отслеживает и, при необходимости, пытается перезапустить процесс узла данных. Если вы проверите список активных процессов в вашей системе после запуска ndbd, вы можете увидеть, что на самом деле работают 2 процесса с этим именем, как показано здесь (мы опускаем вывод ndb_mgmd и ndbd для краткости):

$> ./ndb_mgmd

$> ps aux | grep ndb
me      23002  0.0  0.0 122948  3104 ?        Ssl  14:14   0:00 ./ndb_mgmd
me      23025  0.0  0.0   5284   820 pts/2    S+   14:14   0:00 grep ndb

$> ./ndbd -c 127.0.0.1 --initial

$> ps aux | grep ndb
me      23002  0.0  0.0 123080  3356 ?        Ssl  14:14   0:00 ./ndb_mgmd
me      23096  0.0  0.0  35876  2036 ?        Ss   14:14   0:00 ./ndbmtd -c 127.0.0.1 --initial
me      23097  1.0  2.4 524116 91096 ?        Sl   14:14   0:00 ./ndbmtd -c 127.0.0.1 --initial
me      23168  0.0  0.0   5284   812 pts/2    R+   14:15   0:00 grep ndb

Процесс ndbd, показывающий 0.0 для использования памяти и ЦП, — это процесс ангела (хотя он фактически использует очень небольшое количество каждого). Этот процесс просто проверяет, запущен ли основной процесс ndbd или ndbmtd (основной процесс узла данных, который фактически обрабатывает данные). Если ему разрешено (например, если параметр конфигурации StopOnError установлен на false), процесс ангела пытается перезапустить основной процесс узла данных.