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» означает «Сеть данных». NDB и NDBCLUSTER — это названия хранилища, которое позволяет поддерживать кластеризацию в MySQL. NDB предпочтительнее, но любое название верно.

При традиционной репликации MySQL исходный сервер MySQL обновляет один или несколько реплик. Транзакции выполняются последовательно, и медленная транзакция может привести к отставанию реплики от источника. Это означает, что если источник выходит из строя, возможно, что реплика не записала последние несколько транзакций. Если используется движок, обеспечивающий безопасность транзакций, такой как 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, подключенные к кластеру). Также возможно (хотя и не строго необходимо) запускать несколько серверов управления.

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

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

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

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

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

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

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

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

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

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

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

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

(SizeofDatabase × NumberOfReplicas × 1.1 ) / NumberOfDataNodes

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

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

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

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

Чтобы определить объём памяти, используемой для хранения данных и индексов кластера NDB в любой момент времени, используйте команду 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 реализован как решение «shared-nothing»; идея заключается в том, что отказ одного компонента оборудования не должен вызывать отказ нескольких узлов кластера или, возможно, даже всего кластера в целом. По этой причине использование сетевых общих папок или сетевых файловых систем не поддерживается для кластера NDB. Это также относится к устройствам совместного хранения, таким как SAN.

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

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

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

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

В некоторых случаях могут возникать ошибки «Таблица заполнена» в приложениях клиентов MySQL, даже если ndb_mgm -e "ALL REPORT MEMORYUSAGE" показывает значительное количество свободной DataMemory. Вы можете принудительно заставить NDB создавать дополнительные разделы для таблиц кластера NDB и тем самым иметь больше памяти, доступной для хеш-индексов, используя опцию 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 Configuration Files”, для получения информации об этих параметрах.

В клиенте управления NDB Cluster (ndb_mgm) используются несколько простых команд для таких задач, как запуск и остановка узлов кластера. См. Раздел 25.6.1, “Commands in the NDB Cluster Management Client”.

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

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

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

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

NDB Cluster включает клиент командной строки для выполнения основных функций управления. См. Раздел 25.5.5, “ndb_mgm — The NDB Cluster Management Client” и Раздел 25.6.1, “Commands in the NDB Cluster Management Client”.

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

Это можно сделать двумя способами:

Да. Для таблиц, созданных с помощью 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 Using InnoDB Compared with NDB Cluster” для получения информации о различиях между движками хранения NDB и InnoDB.

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

FULLTEXT индексация в настоящее время поддерживается только движками хранения InnoDB и MyISAM. См. Раздел 14.9, “Full-Text Search Functions” для получения дополнительной информации.

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда все узлы данных хотя бы в одной группе узлов живы, разбиение сети не является проблемой, потому что ни один подмножество кластера не может образовать функциональный кластер самостоятельно. Реальная проблема возникает, когда ни одна группа узлов не имеет всех своих узлов живыми, в этом случае разбиение сети (сценарий “разделенного мозга”) становится возможным. Тогда требуется арбитр. Все узлы кластера распознают один и тот же узел как арбитра, которым обычно является сервер управления; однако, можно настроить любой из серверов MySQL в кластере на роль арбитра вместо этого. Арбитр принимает первый набор узлов кластера, которые с ним связываются, и сообщает оставшемуся набору о необходимости завершения работы. Выбор арбитра контролируется параметром конфигурации ArbitrationRank для серверов MySQL и узлов сервера управления. Вы также можете использовать параметр конфигурации 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».

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

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

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

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

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

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

Да, это возможно. В случае нескольких узлов данных рекомендуется (но не обязательно), чтобы каждый узел использовал отдельный каталог данных. Если вы хотите запустить несколько узлов 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), процесс ангела пытается перезапустить основной процесс узла данных.