25.2.1 NDB Cluster Core Concepts — MySQL 9.2

25.2.1 Основные концепции кластера NDB

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

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

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

Примечание

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

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

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

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

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

Важно

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

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

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

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

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

Стандартные клиенты MySQL. Кластер NDB можно использовать с существующими приложениями MySQL, написанными на PHP, Perl, C, C++, Java, Python и т. д. Такие клиентские приложения отправляют SQL-запросы и получают ответы от серверов MySQL, выступающих в роли узлов SQL кластера NDB, почти так же, как они взаимодействуют со стандартными серверами 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 из хранилища данных NDBCLUSTER, минуя любые серверы MySQL, которые могут быть подключены к кластеру, используя API NDB, высокоуровневый API C++. Такие приложения могут быть полезны для специализированных целей, где не требуется SQL-интерфейс к данным. Для получения дополнительной информации см. .

Специфичные для NDB приложения Java также могут быть написаны для кластера NDB, используя Коннектор кластера NDB для Java. Этот коннектор для кластера NDB включает ClusterJ, высокоуровневый API для баз данных, аналогичный фреймворкам ORM, таким как Hibernate и JPA, которые подключаются напрямую к NDBCLUSTER и, следовательно, не требуют доступа к серверу MySQL. См. , и , для получения дополнительной информации.

Кластер NDB больше не поддерживает приложения, использующие Node.js (удалено в NDB 9.1).

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

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

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

END_OF_DOCUMENT_MARKER

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

Примечание

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

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

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

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

Дополнительную информацию о файлах и каталогах, созданных локальными и глобальными точками сохранения, можно найти в NDB Cluster Data Node File System Directory.

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

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 Cluster.
Общий доступ к памяти (SHM). См. Раздел 25.4.3.12, «NDB Cluster Shared-Memory Connections».

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

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