25.2.1 NDB Cluster Core Concepts — MySQL 8.4

25.2.1 Основные понятия NDB Cluster

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

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

Часть NDB Cluster, обозначенная как «“Кластер”», настраивается независимо от серверов MySQL. В NDB Cluster каждый элемент кластера считается узлом.

Примечание

Во многих контекстах термин «“узел”» используется для обозначения компьютера, но в обсуждении NDB Cluster он означает процесс. Возможно запустить несколько узлов на одном компьютере; для компьютера, на котором выполняется один или несколько узлов кластера, используется термин хост кластера.

Существует три типа узлов кластера, и в минимальной конфигурации NDB Cluster должно быть не менее трех узлов, по одному каждого из этих типов:

Узел управления: Этот тип узла управляет другими узлами в рамках NDB Cluster, выполняя такие функции, как предоставление конфигурационных данных, запуск и остановка узлов и выполнение резервного копирования. Поскольку этот тип узла управляет конфигурацией других узлов, узел этого типа должен быть запущен первым, перед любым другим узлом. Узел управления запускается с помощью команды ndb_mgmd.
Узел данных: Этот тип узла хранит данные кластера. Количество узлов данных равно количеству реплик фрагментов, умноженному на количество фрагментов (см. Раздел 25.2.2, «Узлы NDB Cluster, группы узлов, реплики фрагментов и разделы»). Например, при двух репликах фрагмента, каждая из которых имеет два фрагмента, вам необходимо четыре узла данных. Одна реплика фрагмента достаточно для хранения данных, но не обеспечивает избыточности; поэтому рекомендуется иметь две (или более) реплики фрагментов для обеспечения избыточности и, следовательно, высокой доступности. Узел данных запускается с помощью команды ndbd (см. Раздел 25.5.1, «ndbd — Демон узла данных NDB Cluster») или ndbmtd (см. Раздел 25.5.3, «ndbmtd — Демон узла данных NDB Cluster (многопоточный)»).

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

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

Важно

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

Для краткого введения в взаимосвязи между узлами, группами узлов, репликами фрагментов и разделами в NDB Cluster, см. Раздел 25.2.2, «Узлы NDB Cluster, группы узлов, реплики фрагментов и разделы».

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

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

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

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

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

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

Также можно написать приложения Java, специфичные для NDB, для NDB Cluster, используя NDB Cluster Connector для Java. Этот NDB Cluster Connector включает ClusterJ, высокоуровневый API базы данных, аналогичный объектно-реляционным каркасам отображения, таким как Hibernate и JPA, которые подключаются непосредственно к NDBCLUSTER, и поэтому не требуют доступа к серверу MySQL. Подробнее см. , и .

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

Клиенты управления. Эти клиенты подключаются к серверу управления и предоставляют команды для плавного запуска и остановки узлов, запуска и остановки отслеживания сообщений (только в отладочных версиях), отображения версий и состояния узлов, запуска и остановки резервного копирования и т. д. Пример такой программы — клиент управления ndb_mgm, поставляемый с NDB Cluster (см. Раздел 25.5.5, «ndb_mgm — Клиент управления NDB Cluster»). Такие приложения могут быть написаны с использованием API MGM, API на языке C, который напрямую взаимодействует с одним или несколькими серверами управления NDB Cluster. Подробнее см. .

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

Журналы событий. NDB Cluster записывает события по категориям (запуск, остановка, ошибки, контрольные точки и т. д.), приоритету и степени серьезности. Полный список всех докладываемых событий можно найти в Разделе 25.6.3, «Отчеты об событиях, сгенерированных в NDB Cluster». Журналы событий имеют два типа, указанных здесь:

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

Примечание

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

Точка сохранения. В общем случае, когда данные сохраняются на диск, говорят, что достигнута точка сохранения. Более конкретно для кластера NDB, точка сохранения — это момент времени, когда все выполненные транзакции сохраняются на диск. В отношении NDB движка хранения существуют два типа точек сохранения, которые работают вместе, чтобы гарантировать сохранение согласованного представления данных кластера. Они показаны в следующем списке:

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

NDB 8.4 поддерживает частичные LCP, которые могут значительно улучшить производительность в некоторых условиях. См. описания параметров конфигурации EnablePartialLcp и RecoveryWork, которые активируют частичные LCP и контролируют используемое ими хранилище.
Глобальная точка сохранения (GCP): GCP происходит каждые несколько секунд, когда транзакции для всех узлов синхронизируются, а журнал повтора записывается на диск.

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

Перевозчик. Мы используем термин перевозчик для механизма передачи данных между узлами данных. MySQL NDB Cluster 8.4 поддерживает три таких механизма, которые перечислены ниже:

TCP/IP по Ethernet. См. Раздел 25.4.3.10, «NDB Cluster TCP/IP Connections».
Прямой TCP/IP. Использует соединения между машинами. См. Раздел 25.4.3.11, «NDB Cluster TCP/IP Connections Using Direct Connections».

Хотя этот перевозчик использует тот же протокол TCP/IP, что и в предыдущем пункте, он требует другого аппаратного обеспечения и отличается в настройке. По этой причине он считается отдельным механизмом передачи для кластера NDB.
Общий доступ к памяти (SHM). См. Раздел 25.4.3.12, «NDB Cluster Shared-Memory Connections».

Поскольку он повсеместен, большинство пользователей используют TCP/IP по Ethernet для кластера NDB.

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