21.2.1 NDB Cluster Core Concepts — MySQL 5.7

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

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

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

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

Примечание

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

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

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

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

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

Важно

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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