Одним из преимуществ кластера NDB является то, что он может работать на стандартном оборудовании и не имеет необычных требований, за исключением больших объёмов оперативной памяти, поскольку все данные хранятся в памяти. (Можно уменьшить это требование, используя таблицы данных на диске — см. Раздел 25.6.11, «Таблицы данных на диске кластера NDB», для получения дополнительной информации.) Вы можете получить информацию об использовании памяти узлами данных, просмотрев таблицу ndbinfo.memoryusage или вывод команды REPORT MemoryUsage в клиенте ndb_mgm. Для получения информации об использовании памяти таблицами NDB, можно запросить таблицу ndbinfo.memory_per_fragment.

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

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

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

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

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

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

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

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

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

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