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

Вы можете получить и скомпилировать NDB Cluster из исходного кода (см. Раздел 21.3.1.4, «Создание NDB Cluster из исходного кода в Linux» и Раздел 21.3.2.2, «Компиляция и установка NDB Cluster из исходного кода в 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, не являющийся кластером. См. Раздел 21.7, «Репликация NDB Cluster».

NDB Cluster предназначен для использования в высокоскоростной среде, где компьютеры соединяются с помощью TCP/IP. Его производительность напрямую зависит от скорости соединения между компьютерами кластера. Минимальные требования к подключению для NDB Cluster включают типичную сеть 100 Мбит/с Ethernet или эквивалентную. Рекомендуется использовать сеть Gigabit 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. Для узлов данных и узлов API более быстрые процессоры и больше оперативной памяти, вероятно, улучшат производительность, а 64-разрядные процессоры, вероятно, будут более эффективными, чем 32-разрядные процессоры. На машинах, используемых для узлов данных, должно быть достаточно оперативной памяти для хранения каждой части базы данных (см. Сколько ОЗУ мне нужно? для получения дополнительной информации). Для компьютера, используемого только для запуска сервера управления кластером NDB, требования минимальны; обычно достаточно обычного настольного ПК (или аналогичного устройства). Узлы могут взаимодействовать через стандартную сеть TCP/IP и оборудование. Они также могут использовать высокоскоростной протокол SCI; однако для использования SCI требуются специализированное сетевое оборудование и программное обеспечение (см. раздел 21.4.4, «Использование высокоскоростных соединений с кластером NDB»).

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

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

(SizeofDatabase × NumberOfReplicas × 1.1 ) / NumberOfDataNodes

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

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

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

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

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

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

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

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

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

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

Вероятной причиной является то, что ваша настройка не предоставляет достаточного объёма оперативной памяти для всех данных таблиц и всех индексов, включая первичный ключ, необходимый для 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 Cluster был разработан и реализован с предположением, что он будет работать в условиях, гарантирующих выделенную высокоскоростную соединение, например, в локальной сети с использованием 100 Мбит/с или гигабитного Ethernet — предпочтительно последнего. Мы не тестируем и не гарантируем его производительность с использованием чего-либо медленнее этого.

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

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

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

В клиенте управления NDB Cluster (ndb_mgm) используются несколько простых команд для задач, таких как запуск и остановка узлов кластера. См. Раздел 21.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 см. в Главе 27, Подключаемые модули и API.

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

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

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

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

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

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

Да. Для таблиц, созданных с помощью 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 см. . См. также Раздел 21.2.6, «MySQL Server с InnoDB по сравнению с NDB Cluster», для получения информации о различиях между NDB и InnoDB хранилищами.

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

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

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

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

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

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

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

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

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

Полный список ограничений в NDB Cluster см. в разделе 21.2.7 «Известные ограничения кластера NDB». См. также .

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

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

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

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

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

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

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

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

Дополнительную информацию об этих вопросах см. в разделе 21.2.7 «Известные ограничения кластера NDB».

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

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

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

$> ndb_mgm -e "SHUTDOWN"

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

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

Более подробную информацию см. в разделе 21.6.1 «Команды клиента управления кластером NDB» и разделе 21.3.6 «Безопасная остановка и перезапуск кластера NDB».

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

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

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

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

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

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

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

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

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

IPv6 поддерживается для подключений между SQL-узлами (серверами MySQL), но подключения между всеми другими типами узлов NDB Cluster должны использовать IPv4.

Практически это означает, что вы можете использовать IPv6 для репликации между NDB Cluster, но подключения между узлами в одном NDB Cluster должны использовать IPv4. Для получения дополнительной информации см. Раздел 21.7.3 «Известные проблемы в репликации NDB Cluster».

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

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

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

Вы также можете использовать традиционную функциональность для этой цели в mysqldump и сервере MySQL. См. Раздел 4.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), процесс-ангел пытается перезапустить основной процесс узла данных.