17.1.1. MySQL Cluster Core Concepts

NDBCLUSTER (также известный как NDB) механизм памяти, предлагающий функции персистентности данных и высокая доступность.

NDBCLUSTER механизм хранения может быть сконфигурирован с диапазоном failover и опций выравнивания нагрузки, но является самым легким запуститься с механизма хранения на уровне кластера. Кластер MySQL NDB механизм хранения содержит полный набор данных, зависимых только от других данных в пределах кластера непосредственно.

Часть "Кластера" MySQL Cluster конфигурируется независимо от серверов MySQL. В MySQL Cluster каждая часть кластера, как полагают, является узлом.

Отметить

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

Есть три типа узлов кластера, и в минимальном MySQL Cluster configuration, будет по крайней мере три узла, один из каждого из этих типов:

Узел управления: роль этого типа узла должна управлять другими узлами в пределах MySQL Cluster, выполняя такие функции как обеспечение данных конфигурации, запуск и остановка узлов, выполнение резервного копирования, и т.д. Поскольку этот тип узла управляет конфигурацией других узлов, узел этого типа должен быть запущен сначала перед любым другим узлом. Узел MGM запускается с команды ndb_mgmd.
Узел данных: Этот тип узла хранит данные кластера. Есть так много узлов данных, как есть копии, времена число фрагментов (см. Раздел 17.1.2, "MySQL Cluster Nodes, Node Groups, Копии, и Разделы"). Например, с двумя копиями, каждый имеющий два фрагмента, Вы нуждаетесь в четырех узлах данных. Одна копия достаточна для хранения данных, но не обеспечивает избыточности; поэтому, рекомендуется иметь 2 (или больше) копии, чтобы обеспечить избыточность, и таким образом высокую доступность. Узел данных запускается с команды ndbd (см. Раздел 17.4.1, "ndbd — MySQL Cluster Data Node Daemon" ), или ndbmtd (см. Раздел 17.4.3, "ndbmtd — MySQL Cluster Data Node Daemon (Многопоточный)").

Таблицы MySQL Cluster обычно сохранены полностью в памяти, а не на диске (это - то, почему мы именуем MySQL Cluster как базу данных в памяти). Однако, некоторые данные MySQL Cluster могут храниться на диске; см. Раздел 17.5.12, "MySQL Cluster Disk Data Tables", для получения дополнительной информации.
Узел SQL: Это - узел, который получает доступ к данным кластера. В случае MySQL Cluster узел SQL является традиционным сервером MySQL, который использует NDBCLUSTER механизм хранения. Узел SQL является процессом mysqld, запущенным с --ndbcluster и --ndb-connectstring опции, которые объясняются в другом месте в этой главе, возможно с дополнительными параметрами сервера MySQL также.

Узел SQL является фактически только специализированным типом узла API, который определяет любое приложение который данные MySQL Cluster доступов. Другим примером узла API является ndb_restore утилита, которая используется, чтобы восстановить резервное копирование кластера. Возможно записать такие приложения, используя API NDB. Для основной информации о API NDB см. Начинание с API NDB.

Важный

Не реалистично ожидать использовать установку с тремя узлами в продуктивной среде. Такая конфигурация не обеспечивает избыточности; чтобы извлечь выгоду из высоконадежных функций Кластера MySQL, следует использовать многократные данные и узлы SQL. Использование многократных узлов управления также настоятельно рекомендуется.

Для краткого введения в отношения между узлами, группами узла, копии, и разделы в MySQL Cluster, видят Раздел 17.1.2, "MySQL Cluster Nodes, Node Groups, Копии, и Разделы".

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

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

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

Стандартные клиенты MySQL. MySQL Cluster может использоваться с существующими приложениями MySQL, записанными в PHP, Perl, C, C++, Java, Python, Ruby, и так далее. Такие клиентские приложения отправляют SQL-операторы и получают ответы от серверов MySQL, действующих как узлы SQL MySQL Cluster почти таким же способом, которым они взаимодействуют с автономными серверами MySQL.

Клиенты MySQL, использующие MySQL Cluster в качестве источника данных, могут быть изменены, чтобы использовать в своих интересах возможность соединиться с многократными серверами MySQL, чтобы достигнуть выравнивания нагрузки и failover. Например, клиенты Java, использующие Connector/J 5.0.6 и позже, могут использовать jdbc:mysql:loadbalance:// URL (улучшенный в Connector/J 5.1.7), чтобы достигнуть выравнивания нагрузки прозрачно; для получения дополнительной информации об использовании Connector/J с MySQL Cluster, см. Используя Connector/J с MySQL Cluster.

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

NDBСпецифичные приложения Java могут также быть записаны для MySQL Cluster, используя MySQL Cluster Connector для Java. Этот MySQL Cluster Connector включает ClusterJ, высокоуровневый API базы данных, подобный объектно-реляционным платформам персистентности отображения тем, которые В спящем режиме и JPA, которые соединяются непосредственно с NDBCLUSTER, и так не требует доступа к MySQL Server. Поддержка также оказывается в MySQL Cluster NDB 7.1 и позже для ClusterJPA, реализации OpenJPA для MySQL Cluster, который усиливает сильные места ClusterJ и JDBC; поиски ID и другие быстрые операции выполняются, используя ClusterJ (обходящий MySQL Server), в то время как более сложные запросы, которые могут извлечь выгоду из оптимизатора запросов MySQL, отправляются через MySQL Server, используя JDBC. См. Java и MySQL Cluster, и API ClusterJ и Модель Объекта данных, для получения дополнительной информации.

MySQL Cluster NDB 7.3 также поддерживает приложения, записанные в JavaScript, используя Node.js. MySQL Connector для JavaScript включает адаптеры для прямого доступа к NDB механизм хранения и так же как для MySQL Server. Приложения используя этот Соединитель обычно управляемы событиями и используют объектную модель домена, подобную разными способами используемому ClusterJ. Для получения дополнительной информации см. MySQL NoSQL Connector для JavaScript.

API Memcache для MySQL Cluster, реализованного как загружаемый ndbmemcache механизм хранения для memcached версии 1.6 и позже, может использоваться, чтобы обеспечить персистентное хранилище данных MySQL Cluster, получил доступ к использованию memcache протокола.

Стандарт memcached кэширующийся механизм включается в MySQL Cluster NDB 7.3 распределений. Каждый memcached сервер имеет прямой доступ к данным, хранившим в MySQL Cluster, но также в состоянии кэшировать данные локально и служить (немного) запросам от этого локального кэша.

Для получения дополнительной информации см. ndbmemcache— API Memcache для MySQL Cluster.

Клиенты управления. Эти клиенты соединяются с сервером управления и обеспечивают команды для запуска и остановки узлов корректно, запуска и остановки трассировки сообщения (отладочные версии только), показ версий узла и состояния, запуска и остановки резервных копий, и так далее. Примером этого типа программы является ndb_mgm клиент управления, предоставленный MySQL Cluster (см. Раздел 17.4.5, "ndb_mgm — MySQL Cluster Management Client"). Такие приложения могут быть записаны, используя API MGM, API языка C, который связывается непосредственно с одним или более серверами управления MySQL Cluster. Для получения дополнительной информации см. API MGM.

Oracle также делает доступным MySQL Cluster Manager, который обеспечивает усовершенствованный интерфейс командной строки, упрощающий много сложных задач управления MySQL Cluster, такой перезапуск MySQL Cluster с большим количеством узлов. Клиент MySQL Cluster Manager также поддерживает команды для получения и установки значений большинства параметров конфигурации узла так же как mysqld параметров сервера и переменных, касающихся MySQL Cluster. MySQL Cluster Manager 1.1 оказывает поддержку для того, чтобы добавить узлы данных онлайн. См. MySQL Cluster Manager User Manual для получения дополнительной информации.

Журналы событий. MySQL Cluster регистрирует события по категориям (запуск, завершение работы, ошибки, контрольные точки, и так далее), приоритет, и серьезность. Полный список всех заслуживающих публикации событий может быть найден в Разделе 17.5.6, "Отчеты события, Сгенерированные в MySQL Cluster". Журналы событий имеют эти два типа, перечисленные здесь:

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

Отметить

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

Контрольная точка. Вообще говоря, когда данные сохраняются на диск, говорится, что контрольная точка была достигнута. Более определенный для MySQL Cluster, контрольная точка является моментом времени, где все фиксировавшие транзакции сохранены на диске. Относительно NDB механизм хранения, есть два типа контрольных точек, которые сотрудничают, чтобы гарантировать, что сохраняется непротиворечивое представление данных кластера. Их показывают в следующем списке:

Локальная Контрольная точка (LCP): Это - контрольная точка, которая является определенной для единственного узла; однако, LCP имеют место для всех узлов в кластере более или менее одновременно. LCP включает сохранение на диск всех данных узла, и так обычно происходит каждые несколько минут. Точный интервал изменяется, и зависит от объема данных, сохраненного узлом, уровнем действия кластера, и другими факторами.
Глобальная Контрольная точка (GCP): GCP происходит каждые несколько секунд, когда транзакции для всех узлов синхронизируются, и журнал отката сбрасывается к диску.

Для получения дополнительной информации о файлах и каталогах, создаваемых локальными контрольными точками и глобальными контрольными точками, см. MySQL Cluster Data Node FileSystemDir Файлы.