Одним из преимуществ NDB Cluster является то, что он может работать на обычном оборудовании и не предъявляет необычных требований, кроме больших объёмов оперативной памяти, поскольку все данные хранятся в оперативной памяти. (Это требование можно снизить, используя таблицы данных на диске — см. Раздел 21.6.11, «Таблицы данных на диске NDB Cluster», для получения дополнительной информации об этом). Естественно, несколько более быстрых процессоров могут повысить производительность. Требования к памяти для других процессов NDB Cluster относительно невелики.

Требования к программному обеспечению для NDB Cluster также умеренные. Для поддержки NDB Cluster операционные системы хостов не требуют никаких необычных модулей, служб, приложений или конфигураций. Для поддерживаемых операционных систем достаточно стандартной установки. Требования к программному обеспечению MySQL просты: всё, что нужно, это производственная версия NDB Cluster. Нет строгой необходимости компилировать MySQL самостоятельно, чтобы использовать NDB Cluster. Предполагается, что вы используете двоичные файлы, соответствующие вашей платформе, доступные на странице загрузки программного обеспечения NDB Cluster по адресу https://dev.mysql.com/downloads/cluster/.

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

Сетевое взаимодействие и задержка. NDB Cluster требует связи между узлами данных и узлами API (включая узлы SQL), а также между узлами данных и другими узлами данных для выполнения запросов и обновлений. Задержка связи между этими процессами может напрямую влиять на наблюдаемую производительность и задержку пользовательских запросов. Кроме того, для поддержания согласованности и обслуживания несмотря на бездействующий отказ узлов, NDB Cluster использует механизмы посылок сигналов состояния и таймаутов, которые рассматривают продолжительную потерю связи с узлом как отказ узла. Это может привести к снижению избыточности. Вспомните, что для поддержания согласованности данных NDB Cluster завершает работу, когда последний узел в группе узлов выходит из строя. Таким образом, чтобы избежать повышения риска принудительного завершения работы, следует избегать разрывов связи между узлами, где это возможно.

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

Сигналы состояния зависят от своевременного формирования сигналов состояния всеми узлами. Это может быть невозможно, если узел перегружен, имеет недостаточную производительность процессора из-за совместного использования с другими программами или испытывает задержки из-за подкачки.

Если формирование сигналов состояния достаточно задерживается, другие узлы считают узел, реагирующий медленно, вышедшим из строя.

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

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

Локальные сети обычно можно настроить со стабильно низкой задержкой и таким образом, чтобы они могли обеспечить резервирование с быстрым переключением. Отказы отдельных каналов могут быть восстановлены с минимальной и контролируемой задержкой, видимой на уровне TCP (где обычно работает NDB Cluster). В сетях WAN может быть широкий диапазон задержек, а также резервирование с более медленным временем переключения. Отказы отдельных каналов могут потребовать распространения изменений маршрута, прежде чем будет восстановлено конечное подключение. На уровне TCP это может проявляться в виде больших задержек на отдельных каналах. Максимальная наблюдаемая задержка TCP в таких сценариях связана с максимальным временем для уровня IP для перенаправления трафика вокруг отказавших узлов.