Глава 3. Обзор NDB Cluster

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

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

NDB Cluster объединяет стандартный сервер MySQL с механизмом кластерной системы хранения в памяти NDB (сокращение от Network Data Base). В нашей документации термин NDB относится к части установки, которая является определенной для хранения, тогда как MySQL NDB Cluster относится к комбинации одного или более серверов MySQL с механизмом хранения NDB.

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

Рис. 3.1. Компоненты NDB Cluster

In this cluster, three MySQL servers (mysqld program) are SQL nodes
that provide access to four data nodes (ndbd program) that store data.
The SQL nodes and data nodes are under the control of an NDB management
server (ndb_mgmd program). Various clients and APIs can interact with the
SQL nodes - the mysql client, the MySQL C API, PHP, Connector/J, and
Connector/NET. Custom clients can also be created using the NDB API to
interact with the data nodes or the NDB management server. The NDB management
client (ndb_mgm program) interacts with the NDB management server.

Все эти программы сотрудничают, чтобы сформировать NDB Cluster (см. главу 6. Когда данные хранятся в механизме NDB, таблицы (и данные о таблице) сохранены в узлах данных. Такие таблицы непосредственно доступны от всех других серверов MySQL (узлы SQL) в группе. Таким образом, в запросе на платежную ведомость, хранящем данные в группе, если приложение обновило зарплату сотрудника, все другие серверы MySQL, которые запрашивают эти данные, немедленно видят это изменение.

Хотя в NDB Cluster узел SQL использует mysqld, он отличается по многим критическим отношениям от mysqld в MySQL 5.7, эти две версии mysqld не взаимозаменяемые.

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

Данные в узлах данных для NDB Cluster могут быть отражены, группа может обращаться с неудачами отдельных узлов данных без другого воздействия, небольшое количество транзакций прерывается из-за потери операционного состояния. Поскольку транзакционные приложения, как ожидают, будут обращаться со сбоем транзакции, это не должно быть источником проблем.

Отдельные узлы могут быть остановлены и перезапущены и могут тогда воссоединиться с системой. Катящийся перезапуск (в котором все узлы перезапущены в свою очередь) используется в создании изменений конфигурации и обновлений программного обеспечения (см. раздел 7.5). Катящиеся перезапуски также используются в качестве части процесса добавления новых узлов данных онлайн (см. раздел 7.15). Для получения дополнительной информации об узлах данных, как они организованы в NDB Cluster, и как они обращаются и хранят данные NDB Cluster см. раздел 3.2.

Поддержка и восстановление баз данных NDB Cluster могут быть сделаны, используя функциональность NDB в клиенте управления NDB Cluster, программа ndb_restore включена в пакет NDB Cluster. См. разделы 7.3 и раздел 6.24 . Можно также использовать стандартную функциональность MySQL, обеспеченную с этой целью в mysqldump и сервер MySQL. См. mysqldump.

Узлы NDB Cluster могут использовать различные транспортные механизмы для коммуникаций междоузлия, TCP/IP по стандарту, 100 Мбит/с или более быстрые аппаратные средства Ethernet, используется в большей части реального развертывания.

3.1. Понятия ядра NDB Cluster

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

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

Кластерная часть NDB Cluster формируется независимо от серверов MySQL. В NDB Cluster каждая часть считается узлом.

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

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

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

Для краткого введения в отношения между узлами, группами узлов, точными копиями и разделами в NDB Cluster см. раздел 3.2.

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

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

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

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

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

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

NDB-Java приложения могут также быть написаны для NDB Cluster с NDB Cluster Connector for Java. NDB Cluster Connector включает ClusterJ, API высокого уровня, подобный структурам постоянства отображения Hibernate и JPA, которые соединяются непосредственно с NDBCLUSTER и не требует доступа к MySQL Server. Поддержка также оказывается в NDB Cluster для ClusterJPA, реализации OpenJPA для NDB Cluster, которая усиливает преимущества ClusterJ и JDBC, поиски ID и другие быстрые операции выполняются, используя ClusterJ (обходя MySQL Server) в то время, как более сложные запросы, которые могут извлечь выгоду из оптимизатора запросов MySQL, посылают через MySQL Server, применяя JDBC. См. Java and NDB Cluster и The ClusterJ API and Data Object Model.

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

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

Стандартное кэширование memcached включено в NDB Cluster 7.5. Ккаждый сервер memcached имеет прямой доступ к данным в NDB Cluster, но также в состоянии обратиться к данным кэша в местном масштабе.

См. ndbmemcache Memcache API for NDB Cluster.

Клиенты управления. Эти клиенты соединяются с сервером управления и обеспечивают команды для старта и остановки узлов, старта и остановки отслеживания сообщения (только отладочные версии), показ версий узла и статуса, старта и остановки резервных копий и так далее. Пример этого типа программы: ndb_mgm (см. раздел 6.5). Такие запросы могут быть написаны, используя MGM API, C-подобный API который общается непосредственно с одним или более серверами управления NDB Cluster. См. The MGM API.

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

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

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

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

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

3.2. Узлы NDB Cluster, группы узлов, точные копии и разделение

Эта секция обсуждает способ, которым NDB Cluster делит и дублирует данные для хранения.

Много понятий, важных в понимании этой темы, обсуждены в следующих нескольких параграфах.

Узел данных. Процесс ndbd или ndbmtd, который хранит одну или более точных копий то есть, копии разделов, назначенных на группу узлов, членом которой является узел.

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

Терминам узел и узел данных свойственно использоваться попеременно, относясь к процессам ndbd или ndbmtd, где упомянуто, узлам управления (процесс ndb_mgmd) и узлам SQL (процесс mysqld).

Группа узла. Группа узла состоит из одного или более узлов и хранит разделение или наборы точных копий.

Количество групп узла в NDB Cluster не конфигурируемо непосредственно, это функция количества узлов данных и количества точных копий (параметр конфигурации NoOfReplicas):

[число групп узлов] = [число узлов данных] / NoOfReplicas

Таким образом у NDB Cluster с 4 узлами данных есть 4 группы узла, если NoOfReplicas = 1 в config.ini, 2 группы узлов, если NoOfReplicas = 2 или 1 группа узлов, если NoOfReplicas = 4. Точные копии обсуждены позже в этой секции, для получения дополнительной информации о NoOfReplicas см. раздел 5.3.6.

У всех групп узлов в NDB Cluster должно быть то же самое количество узлов данных.

Можно добавить новые группы узлов (и таким образом новые узлы данных) онлайн к работающему NDB Cluster, см. раздел 7.15.

Разделы. Это часть данных. Каждый узел ответственен за хранение по крайней мере одной копии любого разделения, назначенного на него (то есть, по крайней мере одной точной копии).

Количество разделов, используемых по умолчанию NDB Cluster, зависит от количества узлов данных и количества потоков LDM, задействованных узлами:

[число разделов] = [число узлов данных] * [число потоков LDM]

Используя узлы данных, работающие с ndbmtd, число потоков LDM управляется MaxNoOfExecutionThreads. При использовании ndbd есть единственный поток LDM, что означает, что есть столько же разделов, сколько узлов в кластере. Это также имеет место, используя ndbmtd с MaxNoOfExecutionThreads = 3 или меньше (необходимо знать, что количество потоков LDM растет с увеличением этого параметра, но не строго линейным способом, и что есть дополнительные ограничения, см. описание MaxNoOfExecutionThreads).

NDB и определенное пользователями разделение. NDB Cluster обычно разделяет таблицы NDBCLUSTER сам. Однако также возможно использовать определенное пользователями разделение с таблицами NDBCLUSTER. Это подвергается следующим ограничениям:

  1. Только схемы KEY и LINEAR KEY поддерживаются в производстве с таблицами NDB.

  2. Максимальное количество разделов, которое может быть определено явно для любой таблицы NDB, 8 * [число потоков LDM ] * [число групп узлов ], число групп узлов в NDB Cluster определяется как обсуждено ранее в этой секции. При работе с ndbd для процессов узла данных, определение числа потоков LDM не имеют никакого эффекта (так как ThreadConfig применяется только к only to ndbmtd), в таких случаях можно рассматривать это значение как будто это было равно 1 в целях выполнить это вычисление.

    См. раздел 6.3.

Для получения дополнительной информации о NDB Cluster и определенного пользователями разделения посмотрите разделы 3.7 и Partitioning Limitations Relating to Storage Engines.

Точная копия. Это копия разделения группы. Каждый узел в группе узлов хранит точную копию. Также иногда известно как точная копия разделения. Количество точных копий равно количеству узлов на группу узлов.

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

Следующая диаграмма иллюстрирует NDB Cluster с четырьмя узлами данных, работающими с ndbd, в двух группах из двух узлов каждая, узлы 1 и 2 принадлежат группе узлов 0, а узлы 3 и 4 принадлежат группе 1.

Только узлы данных показывают здесь, хотя работа NDB Cluster требует процесса ndb_mgmd для управления и по крайней мере одного узла SQL для доступа к данным, они были опущены на рисунке для ясности.

Рис. 3.2. NDB Cluster с двумя группами узлов

Content is described in the surrounding text.

Данные, хранившие группой, разделены на четыре раздела, пронумерованных 0, 1, 2 и 3. Каждый раздел сохранен в многочисленных копиях в той же самой группе узлов. Разделение сохранено в дополнительных группах узлов следующим образом:

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

Рис. 3.3. Узлы, необходимые для 2x2 группы NDB Cluster

Content is described in the surrounding text.

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

В NDB 7.5.4 и позже максимальное количество групп узлов для единственного экземпляра NDB Cluster = 48 (Bug#80845, Bug #22996305).

3.3. Требования NDB Cluster

Одно из преимуществ NDB Cluster: им можно управлять на потребительском оборудовании и не имеется никаких необычных требований в этом отношении, кроме больших объемов RAM, вследствие того, что все живое хранение данных сделано в памяти. Возможно уменьшить это требование, используя таблицы Disk Data, см раздел 7.13. Естественно, многократные и более быстрые CPU могут увеличить производительность. Требования к памяти для других процессов NDB Cluster относительно небольшие.

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

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

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

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

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

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

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

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

3.4. Новое в NDB Cluster

Следующие разделы описывают изменения в NDB Cluster в MySQL NDB Cluster 7.6 5.7.29-ndb-7.6.13 и в NDB Cluster 7.5 5.7.29-ndb-7.5.17 по сравнению с более ранним рядом выпусков. NDB Cluster 8.0 доступен как General Availability (GA), начиная с NDB 8.0.19, см. What is New in NDB Cluster. NDB Cluster 7.6 и 7.5 являются предыдущими GA releases, они все еще поддержанные в производстве, для получения информации о NDB Cluster 7.6 см. раздел 3.4.2. Для подобной информации о NDB Cluster 7.5 см. раздел 3.4.1. NDB Cluster 7.4 и 7.3 являются предыдущими GA releases, они все еще поддержанные в производстве, хотя мы рекомендуем, чтобы новое развертывание для производства использовало NDB Cluster 8.0, см. MySQL NDB Cluster 7.3 and NDB Cluster 7.4. NDB Cluster 7.2 является прошлой серией GA release, которая больше не поддерживается для нового развертывания, пользователи NDB 7.2 должны модернизировать систему до более поздней версии. Для получения дополнительной информации о NDB Cluster 7.2 см. MySQL NDB Cluster 7.2.

3.4.1. Новое в NDB Cluster 7.5

Существенные изменения и новые особенности в NDB Cluster 7.5, которые, вероятно, будут представлять интерес, показывают в следующем списке:

NDB Cluster 7.5 также поддерживается MySQL Cluster Manager, который обеспечивает современный интерфейс командной строки, который может упростить многие сложные задачи управления NDB Cluster. См. MySQL Cluster Manager 1.4.8 User Manual.

3.4.2. Новое в NDB Cluster 7.6

Новые особенности и другие важные изменения в NDB Cluster 7.6, которые, вероятно, будут представлять интерес, показывают в следующем списке:

3.5. NDB: добавленные и удаленные опции, переменные и параметры

3.5.1. NDB 7.5

Этот раздел содержит информацию о параметрах конфигурации NDB и mysqld, которые были добавлены или удалены в NDB 7.5.

Параметры конфигурации узла, введенные в NDB 7.5

Следующие параметры конфигурации узла были добавлены в NDB 7.5.

Параметры конфигурации узла, устаревшие в NDB 7.5

Следующие параметры конфигурации узла устарели в NDB 7.5.

Параметры конфигурации узла, удаленные в NDB 7.5

Следующие параметры конфигурации узла были удалены в NDB 7.5.

Опции MySQL, добавленные в NDB 7.5

Устаревшие опции MySQL Server в NDB 7.5

Никакие системные переменные, переменные статуса или опции не устарели в NDB 7.5.

Удаленные опции MySQL Server в NDB 7.5

Ничего не удалено в NDB 7.5.

3.5.2. Опции, переменные и параметры добавленные, устаревшие или удаленные в NDB 7.6

Параметры конфигурации узла, введенные в NDB 7.6

Следующие параметры конфигурации узла были добавлены в NDB 7.6.

Параметры конфигурации узла, устаревшие в NDB 7.6

Параметры конфигурации узла, удаленные в NDB 7.6

Нет таких в NDB 7.6.

Опции и переменные MySQL Server, добавленные в NDB 7.6

Опции и переменные MySQL Server, устаревшие в NDB 7.6

Ничего не устарело.

Опции и переменные MySQL Server, удаленные в NDB 7.6

Ничего не удалено.

3.6. MySQL Server, использующий InnoDB по сравнению с NDB Cluster

MySQL Server предлагает много выбора в механизмах хранения. Начиная с обоих NDB и InnoDB могут служить транзакционными механизмами хранения MySQL пользователям MySQL Server в NDB Cluster. Они видят NDB как возможную альтернативу или модернизацию механизма хранения по умолчанию InnoDB в MySQL 5.7. В то время, как NDB и InnoDB разделяют общие характеристики, есть различия в архитектуре и внедрении, чтобы некоторые существующие приложения MySQL Server и сценарии использования могли быть подходящим вариантом для NDB Cluster.

В этой секции мы обсуждаем и сравниваем некоторые особенности NDB в NDB 7.5 и InnoDB в MySQL 5.7. Следующие несколько секций обеспечивают техническое сравнение. Во многих случаях решение о том, когда и где использовать NDB Cluster, должно быть сделано в зависимости от конкретного случая, приняв все факторы во внимание. В то время, как это выходит за рамки этой документации, чтобы обеспечить специфические особенности для каждого мыслимого сценария использования, мы также пытаемся предложить некоторое очень общее руководство по относительной пригодности некоторых общих типов приложений для NDB в противоположность InnoDB.

NDB Cluster 7.5 тспользует mysqld на основе MySQL 5.7, включая поддержку InnoDB 1.1. В то время как возможно использовать таблицы InnoDB с NDB Cluster, такие таблицы не сгруппированы. Также невозможно использовать программы или библиотеки от NDB Cluster 7.5 с MySQL Server 5.7 или наоборот.

Также верно, что некоторыми типами общих бизнес-приложений можно управлять в NDB Cluster или MySQL Server (скорее всего, используя InnoDB), но есть некоторые важные различия, архитектурные и во внедрении. Раздел 3.6.1 предоставляет резюме этих различий. Из-за различий, некоторые сценарии использования явно более подходят для одного или другого механизма, посмотрите раздел 3.6.2. Это в свою очередь оказывает влияние на типы запросов, которые лучше подошли для использования с NDB или InnoDB. См. раздел 3.6.3 для сравнения относительной пригодности каждого для использования в общих типах приложений базы данных.

Для получения информации об относительных особенностях механизмов NDB и MEMORY см. When to Use MEMORY or NDB Cluster.

См. Alternative Storage Engines для получения дополнительной информации о механизмах хранения MySQL.

3.6.1. Разница между NDB и InnoDB

Механизм хранения NDB осуществляется, используя распределенную и разделенную архитектуру, которая заставляет его вести себя по-другому по сравнению с InnoDB. Для непривычных к работе с NDB, неожиданные поведения могут возникнуть из-за его распределенного характера относительно транзакций, внешних ключей, пределов таблицы и других особенностей. Их показывают в следующей таблице:

Таблица 3.1. Различия между InnoDB и NDB

Фишка InnoDB (MySQL 5.7) NDB 7.5/7.6
Версия MySQL Server 5.75.7
Версия InnoDB InnoDB 5.7.30 InnoDB 5.7.30
Версия NDB Cluster N/A NDB 7.5.17/7.6.13
Пределы хранения 64 TB128 TB (с NDB 7.5.2)
Внешние ключи ДаДа
Транзакции Все стандартные типы READ COMMITTED
MVCC ДаНет
Сжатие данных ДаНет (но файлы контрольной точки NDB и резервные файлы могут быть сжаты)
Поддержка больших строк (> 14K) Да для столбцов типов VARBINARY, VARCHAR, BLOB и TEXT Да для столбцов типов BLOB и TEXT. Используя эти типы, чтобы сохранить очень большие объемы данных, можно понизить производительность NDB.
Репликация Использование асинхронной и полусинхронной репликации MySQL, MySQL Group Replication Автоматическая синхронная репликация в NDB Cluster, асинхронная репликация между NDB Cluster, используя MySQL Replication (полусинхронная репликация не поддерживается)
Scaleout для операций чтения Да (MySQL Replication) Да (автоматическое разделение в NDB Cluster, NDB Cluster Replication)
Scaleout для операций записи Требует разделения уровня приложения. Да (автоматическое разделение в NDB Cluster).
High Availability (HA) Встроено от InnoDB cluster. Да (разработано для продолжительности работы на 99.999%).
Восстановление после сбоя узла и отказоустойчивость Из MySQL Group Replication. Автоматически (основной элемент в архитектуре NDB).
Время для восстановления после сбоя узла 30 секунд или дольшеОбычно < 1 секунды
Работа в реальном времени НетДа
Таблицы In-Memory Нет Да (некоторые данные могут произвольно храниться на диске, хранение данных в памяти и дисковое хранение данных совместимы)
Доступ NoSQL к механизму храненияДа Да (много API, включая Memcached, Node.js/JavaScript, Java, JPA, C++ и HTTP/REST)
Параллельные записи и доступДа До 48 параллельных записей
Обнаружение конфликта и решение (многократные ведущие репликации) Да (MySQL Group Replication)Да
Хэш-индексы НетДа
Добавление узлов онлайн Использование точных копий чтения-записи MySQL Group Replication Да (все типы узлов)
Модернизации онлайн Да (с использованием репликации) Да
Модификации схемы онлайн Да, как часть MySQL 5.7 Да

3.6.2. NDB и рабочая нагрузка InnoDB

NDB Cluster имеет диапазон уникальных признаков, которые делают ее идеалом, чтобы служить запросам, требующим высокой доступности, быстрой отказоустойчивости, высокой пропускной способности и низкого времени ожидания. Из-за распределенной архитектуры и внедрения мультиузлов, у NDB Cluster также есть определенные ограничения, которые могут помешать некоторой рабочей нагрузке. Много существенных различий в поведении между NDB и InnoDB относительно некоторых общих типов управляемых базой данных рабочих нагрузок приложений показывают в следующей таблице:

Таблица 3.2. Различия между механизмами хранения InnoDB и NDB с общими типами управляемых данными рабочих нагрузок приложений.

Нагрузка InnoDB NDB Cluster (NDB )
High-Volume OLTP Applications ДаДа
DSS Applications (data marts, analytics) Да Ограничено (операции по соединению через наборы данных OLTP не больше 3 TB в размере)
Пользовательские приложения ДаДа
Пакетные приложения Да Ограничено (должен быть доступ главным образом первичного ключа). NDB Cluster 7.5 понимает внешние ключи
In-Network Telecoms Applications (HLR, HSS, SDP) НетДа
Управление сеансами и кэширование ДаДа
E-Commerce ДаДа
Управление профилем пользователя, протокол AAA ДаДа

3.6.3. Резюме использования особенностей NDB и InnoDB

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

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

Таблица 3.3. Поддерживаемые возможности приложений согласно механизму хранения, к которому, как правило, лучше подходит каждая особенность

Требования предпочтительного приложения для InnoDB Требования предпочтительного приложения для NDB
  • Внешние ключи

    NDB Cluster 7.5 поддерживает внешние ключи

  • Полное сканирование таблицы

  • Очень большие базы данных, строки или транзакции

  • Транзакции кроме READ COMMITTED

  • Масштабирование записи

  • 99.999% uptime

  • Добавление онлайн узлов и операции по схеме онлайн

  • Многократные SQL и NoSQL API (см. NDB Cluster APIs: Overview and Concepts)

  • Работа в реальном времени

  • Ограниченное использование столбцов BLOB

  • Внешние ключи поддерживаются, хотя их использование может оказать влияние на работу на высокой пропускной способности

3.7. Известные ограничения NDB Cluster

В секциях, которые следуют, мы обсуждаем известные ограничения в текущих выпусках NDB Cluster по сравнению с особенностями, доступными, используя MyISAM и InnoDB. Если вы проверяете категорию Cluster в базе данных глюков MySQL на http://bugs.mysql.com, можно найти известные ошибки в следующих категориях под MySQL Server: в базе данных ошибок MySQL на http://bugs.mysql.com, которые мы намереваемся исправить в предстоящих выпусках NDB Cluster:

См. Previous NDB Cluster Issues Resolved in NDB Cluster 8.0 для получения списка проблем в более ранних выпусках, которые были решены в NDB Cluster 7.5.

Ограничения и другие проблемы, определенные для NDB Cluster Replication, описаны в разделе 8.3.

3.7.1. Несоблюдение синтаксиса SQL в NDB Cluster

Некоторые SQL-операторы, касающиеся определенных особенностей MySQL, производят ошибки, когда используются с NDB, как описано в следующем списке:

3.7.2. Пределы и различия NDB Cluster от стандартного MySQL

В этой секции мы перечисляем пределы NDB Cluster, отличающиеся от обычного MySQL.

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

3.7.3. Пределы, касающиеся операционной обработки в NDB Cluster

Много ограничений существуют в NDB Cluster относительно обработки транзакций. Они включают следующее:

3.7.4. Обработка ошибок NDB Cluster

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

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

См. раздел 3.7.2.

3.7.5. Пределы, связанные с объектами базы данных в NDB Cluster

У некоторых объектов базы данных, таких как таблицы и индексы, есть различные ограничения, используя NDBCLUSTER:

3.7.6. Неподдержанные или недостающие возможности NDB Cluster

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

См. раздел 3.7.3 для получения дополнительной информации касающийся ограничений на операционную обработку в NDB.

3.7.7. Ограничения, касающиеся работы в NDB Cluster

Следующие исполнительные проблемы определены для NDB Cluster:

3.7.8. Проблемы именно с NDB Cluster

Следующее ограничения, определенные для механизма хранения NDB:

См. раздел 3.7.10.

3.7.9. Ограничения, касающиеся хранения данных NDB Cluster на диске

Дисковые максимумы и минимумы объекта данных. Дисковые объекты данных подвергаются следующим максимумам и минимумам:

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

Таблицы Disk Data и бездисковый режим. Использование таблиц Disk Data не поддерживается в бездисковом режиме.

3.7.10. Ограничения, касающиеся многократных узлов NDB Cluster

Много узлов SQL. Следующее это проблемы, касающиеся использования многократных серверов MySQL как узлов SQL NDB Cluster для NDBCLUSTER:

Многократные узлы управления. Используя многократные серверы управления:

Многократные сетевые адреса. Многократные сетевые адреса на узел данных не поддерживаются. Использование их склонно вызвать проблемы: в случае неудачи узла данных узел SQL ждет подтверждения, что узел данных отвалился, но никогда не получает его, потому что другой маршрут к тому узлу данных остается открытым. Это может эффективно сделать кластер нерабочим.

Возможно использовать многократные сетевые аппаратные интерфейсы (например, карты Ethernet) для единственного узла данных, но они должны быть связаны с тем же самым адресом. Это также означает, что невозможно использовать больше одного раздела [tcp] для каждого подключения в config.ini. См. раздел 5.3.10.