17.1.3. MySQL Cluster Hardware, программное обеспечение, и Объединяющиеся в сеть Требования

Одни из сильных мест MySQL Cluster - то, что он может быть выполнен на товарных аппаратных средствах и не имеет никаких необычных требований в этом отношении, кроме для большого количества RAM, вследствие того, что все живое хранение данных делается в памяти. (Возможно уменьшить это требование, используя Дисковые Таблицы данных — см. Раздел 17.5.12, "MySQL Cluster Disk Data Tables", для получения дополнительной информации о них.) Естественно, многократные и более быстрые ЦП могут улучшить производительность. Требования к памяти для других процессов MySQL Cluster являются относительно маленькими.

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

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

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

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

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

Эта обработка медленного узла как отказавший может или, возможно, не является требуемой при некоторых обстоятельствах, в зависимости от воздействия работы узла, которая замедляют, на остальной части кластера. Устанавливая значения тайм-аута такой как HeartbeatIntervalDbDb и HeartbeatIntervalDbApi для MySQL Cluster забота должна заботиться, чтобы достигнуть быстрого обнаружения, failover, и возвратиться к службе, избегая потенциально дорогих ложных положительных сторон.

Где коммуникационные задержки между узлами данных, как ожидают, будут выше, чем ожидалось бы в среде LAN (на порядке 100 µs), параметры тайм-аута должны быть увеличены, чтобы гарантировать, что любые позволенные периоды периодов ожидания хорошо в пределах сконфигурированных тайм-аутов. Увеличение тайм-аутов таким образом имеет соответствующий эффект на время худшего случая, чтобы обнаружить отказ и поэтому время, чтобы обслужить восстановление.

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

Поддержка SCI. Также возможно использовать высокоскоростной Масштабируемый когерентный интерфейс (SCI) с MySQL Cluster, но это не требование. См. Раздел 17.3.5, "Используя Высокоскоростные Межсоединения с MySQL Cluster", для больше об этом протоколе и его использовании с MySQL Cluster.