RussianLDP Рейтинг@Mail.ru
WebMoney: 
WMZ Z294115950220 
WMR R409981405661 
WME E134003968233 
Visa 
4274 3200 2453 6495 

Приложение A. MySQL 5.7 FAQ: NDB Cluster

В следующем разделе мы отвечаем на вопросы, которые часто спрашивают о NDB Cluster и механизме хранения NDB.

A.1: Какие версии MySQL поддерживают NDB Cluster? Я должен собрать из исходных текстов?

NDB Cluster не поддерживается в стандартном MySQL Server 5.7. Вместо этого MySQL NDB Cluster обеспечивается как отдельный продукт. Доступные ряды выпусков NDB Cluster включают следующее:

  • NDB Cluster 7.3. Этот ряд предыдущая версия General Availability (GA) NDB Cluster, все еще доступная для производства, хотя мы рекомендуем, чтобы новое развертывание использовало последний выпуск NDB Cluster 7.6. Новые выпуски NDB Cluster 7.3 могут быть получены из https://dev.mysql.com/downloads/cluster/.

  • NDB Cluster 7.4. Этот ряд предыдущая версия General Availability (GA) NDB Cluster, все еще доступная для производства, хотя мы рекомендуем, чтобы новое развертывание использовало последний выпуск NDB Cluster 7.6. Новые выпуски NDB Cluster 7.4 могут быть получены из https://dev.mysql.com/downloads/cluster/.

  • NDB Cluster 7.5. Этот ряд предыдущая версия General Availability (GA) NDB Cluster, все еще доступная для производства, хотя мы рекомендуем, чтобы новое развертывание использовало последний выпуск NDB Cluster 7.6. Новые выпуски NDB Cluster 7.5 могут быть получены из https://dev.mysql.com/downloads/cluster/.

  • NDB Cluster 7.6. Этот ряд новая версия General Availability (GA) NDB Cluster на основе версии 7.6 NDB и MySQL Server 5.7. NDB Cluster 7.6 доступен для производственного использования, новое развертывание, предназначенное для производства, должно использовать последнюю версию NDB Cluster 7.6. Можно получить новую версию NDB Cluster 7.6 с https://dev.mysql.com/downloads/cluster/. Для получения информации о новых особенностях и других важных изменениях в этом ряду посмотрите What is New in NDB Cluster 7.6.

  • NDB Cluster 8.0. Этот ряд теперь доступен как выпуск Developer Preview для оценки и тестирования новых особенностей в NDBCLUSTER, для получения дополнительной информации посмотрите MySQL NDB Cluster 8.0.

Необходимо использовать NDB Cluster 7.6 для любого нового развертывания, если вы используете более старую версию NDB Cluster, необходимо модернизироваться до этой версии как только возможно. Для обзора улучшений, сделанных в NDB Cluster 7.6, см. What is New in NDB Cluster 7.6. Для обзора улучшений, сделанных в NDB Cluster 7.5, см. What is New in NDB Cluster 7.5.

A.2: Что делает NDB и NDBCLUSTER?

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

A.3: Каково различие между использованием NDB Cluster и MySQL Replication?

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

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

Асинхронная репликация также доступна в NDB Cluster. NDB Cluster Replication (также иногда известна как geo-replication) включает способность копировать и между двумя NDB Clusters, и из NDB Cluster в сервер не-Cluster MySQL. См. главу 8.

A.4: Мне нужна какая-либо специальная организация сети, чтобы управлять NDB Cluster? Как делают связь в кластере?

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

A.5: Сколько компьютеров надо для работы NDB Cluster и почему?

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

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

A.6: Что различные компьютеры делают в NDB Cluster?

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

  • Узел управления. Этот узел предоставляет услуги управления кластером в целом, включая запуск, закрытие, резервные копии и данные конфигурации для других узлов. Сервер узла управления осуществляется как приложение ndb_mgmd, клиент управления, используемый, чтобы управлять NDB Cluster, это ndb_mgm. См. разделы 6.4 и 6.5.

  • Узел данных. Этот тип узла хранит и копирует данные. Функциональность узла данных обработана экземплярами процесса узла данных NDB ndbd. См. раздел 6.1.

  • Узел SQL. Это просто экземпляр MySQL Server (mysqld), который строится с поддержкой NDBCLUSTER и запускается с опцией --ndb-cluster, чтобы позволить механизм и опцией --ndb-connectstring, чтобы позволить ему соединиться с сервером управления. См. раздел 5.3.9.1.

    Узел API это любое приложение, которое делает прямое использование узлов данных кластера для хранения данных и поиска. Узел SQL можно таким образом считать подтипом узла API, который использует MySQL Server, чтобы предоставить интерфейс SQL кластеру. Можно написать такие приложения (которые не зависят от MySQL Server), с использованием API NDB, которые поставляют прямую, объектно-ориентированную транзакцию и интерфейс просмотра к данным NDB Cluster, см. NDB Cluster API Overview: The NDB API.

A.7: Когда я выполняю команду SHOW в клиенте управления NDB Cluster, я вижу строку, которая похожа на это:

id=2@10.100.10.32(Version: 5.6.47-ndb-7.4.27 Nodegroup: 0, *)

Что делает символ *? Как этот узел отличается от других?

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

Если вы не находите, что это удовлетворительный ответ, вот более длинное и более техническое объяснение:

Много механизмов в NDB Cluster требуют распределенной координации среди узлов данных. Эти распределенные алгоритмы и протоколы включают глобальную контрольную точку, DDL (схему), изменения и обработку перезапуска узла. Чтобы сделать эту координацию более простой, узлы данных выбирают один из своего числа, чтобы действовать как лидер. Этот узел однажды упоминался как ведущий, но эта терминология была отклонена, чтобы избежать конфликта с главным сервером в MySQL Replication. Нет никакого пользовательского механизма для влияния на этот выбор, который является абсолютно автоматическим, это является ключевой ролью внутренней архитектуры NDB Cluster.

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

Для некоторых из этих различных механизмов и протоколов возможно иметь различные узлы лидера, но в целом тот же самый лидер выбран для всех. Узел, обозначенный как лидер в выводе SHOW в клиенте управления, известен внутренне как менеджер DICT (см. The DBDICT Block в NDB Cluster API Developer Guide), ответственный за координирование DDL и деятельности метаданных.

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

A.8: С какими операционными системами я могу использовать NDB Cluster?

NDB Clusterподдерживается на большинстве Unix-подобных операционных систем. NDB Cluster также поддерживается в производственных параметрах настройки на операционных системах Microsoft Windows.

Для более подробной информации относительно уровня поддержки, который предлагается для NDB Cluster на различных версиях операционных систем и аппаратных платформ обратитесь к https://www.mysql.com/support/supportedplatforms/cluster.html.

A.9: Каковы требования к аппаратным средствам для управления NDB Cluster?

NDB Cluster должен работать на любой платформе, на которой доступны двоичные модули с поддержкой NDB. Для узлов данных и узлов API более быстрые CPU и больше памяти, вероятно, улучшат работу, 64-bit CPU, вероятно, будут более эффективными, чем 32-битные процессоры. Должна быть достаточная память на машинах, используемых для узлов данных, чтобы иметь долю базы данных для каждого узла. Для компьютера, который используется только для работы сервера управления NDB Cluster, требования минимальны, обычный настольный ПК (или его эквивалент) вообще достаточен для этой задачи. Узлы могут общаться через стандартную сеть TCP/IP и аппаратные средства. Они могут также использовать быстродействующий протокол SCI, однако, специальное сетевое аппаратное и программное обеспечение требуются, чтобы использовать SCI (см. раздел 5.4).

A.10: Сколько RAM я должен использовать для NDB Cluster? Действительно ли возможно использовать память на дисках вообще?

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

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

(SizeofDatabase * NumberOfReplicas * 1.1) / NumberOfDataNodes

Вычисление требования к памяти более точно требует определения для каждой таблицы в базе данных пространства памяти, требуемого на строку (см. Data Type Storage Requirements) и умножить это на количество строк. Необходимо также не забыть посчитать любые индексы столбца следующим образом:

  • Каждый первичный ключ или хэш-индекс, созданный для таблицы NDBCLUSTER, требует 21-25 байт на запись. Эти индексы используют IndexMemory.

  • Каждый упорядоченный индекс требует 10 байт на запись, используя DataMemory.

  • Создание первичного ключа или уникального индекса также создает упорядоченный индекс, если этот индекс не создается с USING HASH:

    • Первичный ключ или уникальный индекс на таблице обычно требует по 31-35 байтов на запись.

    • Однако, если первичный ключ или уникальный индекс создаются с USING HASH, требуется только 21-25 байтов на запись.

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

Вычисляя требования к памяти, можно счесть полезной утилиту ndb_size.pl, которая доступна в недавних выпусках MySQL 5.7. Этот скрипт на Perl соединяется с текущей (не-Cluster) базой данных MySQL database и создает отчет о том, сколько пространства потребовала бы база данных, если бы это использовало NDBCLUSTER . См. раздел 6.29.

Особенно важно иметь в виду, что у каждой таблицы NDB Cluster должен быть первичный ключ. NDB создает первичный ключ автоматически, если ни один не определяется, этот первичный ключ создается без USING HASH.

Можно определить, сколько памяти используется для хранения данных NDB Cluster и индексов в любой момент времени, используя команду REPORT MEMORYUSAGE в клиенте ndb_mgm, см. раздел 7.2. Кроме того, предупреждения написаны в журнал кластера, когда 80% доступной DataMemory или IndexMemory использовано и снова когда использование достигает 85%, 90% и так далее.

A.11: Какие файловые системы я могу использовать с NDB Cluster? Что относительно сетевых файловых систем или сетевых ресурсов?

Обычно любая файловая система, которая является родной для хостовой операционной системы, должна работать хорошо с NDB Cluster. Если вы находите, что данная файловая система работает особенно хорошо (или не так, чтобы особенно хорошо) с NDB Cluster, мы приглашаем вас обсуждать свои результаты на in the NDB Cluster Forums.

В Windows мы рекомендуем, чтобы вы использовали NTFS для NDB Cluster, как мы делаем для стандартного MySQL. Мы не проверяем NDB Cluster с FAT или VFAT. Из-за этого мы не рекомендуем их использование с MySQL или NDB Cluster.

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

A.12: Я могу управлять узлами NDB Cluster в виртуальных машинах (таких как созданные VMWare, Parallels или Xen)?

NDB Cluster поддерживается для использования в виртуальных машинах. Мы в настоящее время поддерживаем и проверяем Oracle VM.

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

A.13: Я пытаюсь наполнить базу данных NDB Cluster. Процесс загрузки заканчивается преждевременно, и я получаю сообщение об ошибке: ERROR 1114: The table 'my_cluster_table' is full . Почему это происходит?

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

Также стоит отметить, что у всех узлов данных должна быть та же самая сумма RAM, так как никакой узел данных в кластере не может использовать больше памяти, чем наименьшее количество, доступное любому отдельному узлу данных. Например, если есть четыре компьютера с узлами данных, и три из них имеют в наличии 3 ГБ RAM, чтобы хранить данные кластера в то время как у остающегося узла данных есть RAM только на 1 ГБ, тогда каждый узел данных может использовать самое большее 1 ГБ для данных и индексов NDB Cluster.

В некоторых случаях возможно получить ошибку Table is full в клиенте MySQL даже когда ndb_mgm -e "ALL REPORT MEMORYUSAGE" показывает значительную свободную DataMemory. Можно вызвать NDB, чтобы создать дополнительное разделение для таблиц NDB Cluster и таким образом иметь больше памяти в наличии для хэш-индексов при помощи опции MAX_ROWS в CREATE TABLE. В целом урегулирование MAX_ROWS к двойному количеству строк, которые вы ожидаете хранить в таблице, должно быть достаточным.

По подобным причинам можно также иногда сталкиваться с проблемами с перезапусками узла данных на узлах, которые в большой степени загружаются данными. Параметр MinFreePct может помочь с этой проблемой, резервируя часть (5% по умолчанию) DataMemory и IndexMemory для использования в перезапусках. Эта зарезервированная память недоступна для хранения таблиц или данных NDB.

A.14: NDB Cluster применяет TCP/IP. Это означает, что я могу управлять им по Интернету с одним или более узлами в удаленных местах?

Очень маловероятно, что кластер работал бы нормально в таких условиях, поскольку NDB Cluster был разработан и осуществлен учитывая, что этим будут управлять при условиях, гарантирующих возможность быстрого соединения, такую как LAN на 100 Mbps или gigabit Ethernet, предпочтительно последнее. Мы не проверяем и не гарантируем его работу, используя что-либо медленнее, чем это.

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

A.15: Я должен выучить новый язык программирования или язык запросов, чтобы использовать NDB Cluster?

Нет. Хотя некоторые специализированные команды используются, чтобы управлять и формировать сам кластер, только стандартные запросы (My)SQL требуются для следующих операций:

  • Создание, изменение и удаление таблиц

  • Вставка, обновление и удаление данных

  • Создание, изменение и удаление первичных и уникальных индексов

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

Несколько простых команд используются в клиенте управления NDB Cluster ( ndb_mgm) для задач, таких как старт и остановка узлов, см. раздел 7.2.

A.16: Какие языки программирования и API поддерживаются NDB Cluster?

NDB Cluster поддерживает те же самые API и языки как стандартный MySQL Server, включая ODBC, .Net, MySQL C API и многочисленные драйверы для популярных языков, таких как PHP, Perl и Python. Приложения NDB Cluster, написанные с применением API, ведут себя аналогично другим приложениям MySQL: они передают SQL-операторы MySQL Server (в случае NDB Cluster узлу SQL) и получают ответы, содержащие строки данных. Для получения дополнительной информации об API посмотрите Connectors and APIs.

NDB Cluster также поддерживает прикладное программирование, используя NDB API, который предоставляет интерфейс C++ низкого уровня данным NDB Cluster без обращения к MySQL Server. См. The NDB API. Кроме того, многие функции управления NDBCLUSTER выставляются языком C MGM API, см. The MGM API.

NDB Cluster также поддерживает программное использование Java ClusterJ, который поддерживает модель объекта области сессий использования данных и транзакций, см. Java and NDB Cluster.

Кроме того, NDB Cluster оказывает поддержку memcached, позволяя разработчикам получить доступ к данным NDB Cluster через интерфейс memcached, см. ndbmemcache Memcache API for NDB Cluster.

NDB Cluster 7.3 и позже включает адаптеры, поддерживающие приложения NoSQL, написанные с помощью Node.js, где NDB Cluster работает как хранилище данных. См. MySQL NoSQL Connector for JavaScript.

A.17: NDB Cluster включает какие-либо инструменты управления?

NDB Cluster включает клиента командной строки для выполнения основных функций управления. Посмотрите разделы 6.5 и 7.2.

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

NDB Cluster (version 7.3 и позже) предоставляет графический, основанный на браузере, автоинсталлятор для подготовки и развертывания NDB Cluster как часть программного обеспечения NDB Cluster. См. раздел 4.1.

A.18: Как я узнаю, что сообщение об ошибке или предупреждающее сообщение означают, используя NDB Cluster?

Есть два пути, которыми это может быть сделано:

  • Из клиента mysql используйте SHOW ERRORS или SHOW WARNINGS непосредственно после того, как получите сообщение.

  • Из системной оболочки используйте perror --ndb error_code.

A.19: NDB Cluster транзакционно безопасен? Какие уровни изоляции поддерживаются?

Да. Для таблиц, составленных с NDB, транзакции поддерживаются. В настоящее время NDB Cluster поддерживает только уровень изоляции READ COMMITTED.

A.20: Какие механизмы хранения поддерживаются NDB Cluster?

Объединение в кластеры с MySQL поддерживается только NDB. Таким образом, для таблицы, которая будет разделена между узлами в NDB Cluster, таблица должна быть составлена, используя ENGINE=NDB (или эквивалент ENGINE=NDBCLUSTER).

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

A.21: В случае катастрофического сбоя и отключения электричества я потерял бы все свои данные?

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

A.22: Возможно ли использовать индексы FULLTEXT в NDB Cluster?

Индексы FULLTEXT в настоящее время поддерживаются только в InnoDB и MyISAM. См. Full-Text Search Functions.

A.23: Я могу управлять многими узлами на одиночном компьютере?

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

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

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

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

A.24: Я могу добавить узлы данных к NDB Cluster без перезапуска?

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

Для других типов узлов NDB Cluster требуется катящийся перезапуск (см. раздел 7.5).

A.25: Есть ли какие-либо ограничения, о которых я должен знать, используя NDB Cluster?

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

  • Временные таблицы не поддерживаются, CREATE TEMPORARY TABLE с ENGINE=NDB или ENGINE=NDBCLUSTER приведет к ошибке.

  • Единственные типы определенного пользователями разделения, поддержанного для таблиц NDBCLUSTER, это KEY и LINEAR KEY .

  • Индексы FULLTEXT не поддерживаются.

  • Префиксы индекса не поддерживаются. Только полные колонки могут быть внесены в указатель.

  • Пространственные индексы не поддерживаются (хотя пространственные колонки могут использоваться). Посмотрите Spatial Data Types.

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

  • Максимальное количество признаков, позволенных на таблицу 512. Названия атрибута не могут быть больше, чем 31 знак. Для каждой таблицы максимальная объединенная длина имен таблиц и имен базы данных 122 знака.

  • Максимальный размер для строки таблицы составляет 14 килобайтов, не учитывая BLOB.

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

Для полного списка ограничений в NDB Cluster см. раздел 3.7 и Previous NDB Cluster Issues Resolved in NDB Cluster 8.0.

A.26: NDB Cluster поддерживает внешние ключи?

NDB Cluster 7.3 и позже оказывает поддержку для ограничений внешнего ключа, сопоставимых с найденными в InnoDB, см. FOREIGN KEY Constraints и FOREIGN KEY Constraints. Приложения, требующие поддержки внешнего ключа, должны использовать NDB Cluster 7.3, 7.4, 7.5 или позже.

A.27: Как я импортирую существующую базу данных MySQL в NDB Cluster?

Можно импортировать базы данных в NDB Cluster как с любой другой версией MySQL. Кроме ограничений, упомянутых в другом месте в этом FAQ, единственное особое требование: любые таблицы, которые будут включены в группу, должны использовать NDB. Это означает, что таблицы должны быть составлены с ENGINE=NDB или ENGINE=NDBCLUSTER.

Также возможно преобразовать существующие таблицы, которые используют другие механизмы хранения для NDBCLUSTER, применив ALTER TABLE. Однако, определение должно быть совместимо с NDBCLUSTER до преобразования. В MySQL 5.7 также требуется дополнительная работа, посмотрите раздел 3.7.

A.28: Как узлы Cluster общаются друг с другом?

Узлы группы могут общаться через любой из трех различных транспортных механизмов: TCP/IP, SHM (общая память) и SCI (Масштабируемый когерентный интерфейс). Где доступно, SHM используется по умолчанию между узлами на том же самом хосте, однако, это считают экспериментальным. SCI это быстродействующий (1 гигабит в секунду и выше), высоконадежный протокол, используемый в создании масштабируемых многопроцессорных систем, это требует специального оборудования и софта. См. раздел 5.4.

A.29: Кто такой арбитр?

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

Когда все узлы данных по крайней мере в одной группе узлов работают, сетевое разделение не является проблемой, потому что никакое единственное подмножество группы не может сформировать функциональную группу самостоятельно. Настоящая проблема возникает, когда ни у какой единственной группы узлов нет всех своих живых узлов, в этом случае сетевое разделение становится возможным. Тогда арбитр требуется. Все узлы группы признают тот же самый узел арбитром, который обычно является сервером управления, однако, возможно формировать любой из MySQL Server, чтобы действовать как арбитр вместо этого. Арбитр принимает, что первый набор узлов группы связывается с ним и говорит остающемуся набору закрываться. Выбором арбитра управляет параметр ArbitrationRank для MySQL Server и сервера управления MySQL. Можно также использовать ArbitrationRank, чтобы управлять процессом выбора арбитра. Для получения дополнительной информации об этих параметрах, посмотрите раздел 5.3.5.

Роль арбитра не налагает значимой нагрузки на его хост.

A.30: Какие типы данных поддерживаются NDB Cluster?

NDB Cluster поддерживает все обычные типы данных MySQL, включая связанные с пространственными расширениями MySQL, однако, NDB не поддерживает пространственные индексы. Пространственные индексы поддерживаются только MyISAM, см. Spatial Data Types. Кроме того, есть некоторые различия относительно индексов, когда используются с таблицами NDB.

Таблицы NDB Cluster Disk Data (то есть, таблицы, составленные с TABLESPACE ... STORAGE DISK ENGINE=NDB или TABLESPACE ... STORAGE DISK ENGINE=NDBCLUSTER) имейют только строки фиксированной ширины. Это означает что (например), каждая запись таблиц Disk Data, содержащая столбец VARCHAR(255), требует пространство для 255 знаков (как требуется для набора символов и сопоставления, используемого для таблицы, независимо от фактического количества сохраненных знаков.

См. раздел 3.7.

A.31: Как я начинаю и останавливаю NDB Cluster?

Необходимо начать каждый узел отдельно в следующем порядке:

  1. Начните узел управления, используя команду ndb_mgmd.

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

  2. Начните каждый узел данных, используя команду ndbd.

    Каждый узел данных должен быть начат с опцией -c или --ndb-connectstring, чтобы узел данных знал, как соединиться с сервером управления.

  3. Начните каждый MySQL Server (узел SQL) с использованием вашего предпочтительного скрипта запуска, такого как mysqld_safe.

    Каждый MySQL Server должен быть начат с --ndbcluster и --ndb-connectstring. Эти опции заставляют mysqld позволять поддержку NDBCLUSTER и указывают, как соединиться с сервером управления.

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

Чтобы закрыть кластер, дайте команду SHUTDOWN в клиенте управления. Альтернативно, можно выполнить следующую команду в системной оболочке:

shell> ndb_mgm -e "SHUTDOWN"

Кавычки в этом примере дополнительные, так как нет никаких пробелов в командной строке после опции -e, кроме того, команда SHUTDOWN, как другие команды клиента управления, нечувствительна к регистру.

Любая из этих команд заставляет ndb_mgm, ndb_mgm и любые процессы ndbd заканчиваться нормально. Серверы MySQL, работающие как узлы SQL, могут быть остановлены, используя mysqladmin shutdown.

См. раздел 7.2 и раздел 4.8.

A.32: Что происходит с данными NDB Cluster, когда кластер закрывается?

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

A.33: Действительно ли хорошая идея иметь больше, чем один узел управления для NDB Cluster?

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

См. раздел 5.3.

A.34: Я могу смешать различные виды аппаратных и операционных систем в одном NDB Cluster?

Да, пока у всех машин и операционных систем есть тот же самый endianness (все big-endian или little-endian).

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

A.35: Я могу управлять двумя узлами данных на единственном хосте? Двумя узлами SQL?

Да, возможно сделать это. В случае многих узлов данных желательно (но не требуется) для каждого узла использовать различный каталог данных. Если вы хотите управлять многими узлами SQL на одной машине, каждый экземпляр mysqld должен использовать различный порт TCP/IP.

Работающие узлы данных и узлы SQL вместе на том же самом хосте возможны, но необходимо знать, что процессы ndbd (или ndbmtd) и mysqld могут конкурировать за память.

A.36: Я могу использовать имена хоста с NDB Cluster?

Да, возможно использовать DNS и DHCP для хостов. Однако, если ваше приложение требует идеальной доступности, необходимо использовать зафиксированные (числовые) IP-адреса, начиная с создания связи между хостами кластера, зависящими от услуг, таких как DNS и DHCP, они вводят дополнительные потенциальные пункты неудачи.

A.37: NDB Cluster понимает IPv6?

IPv6 поддерживается для связей между узлами SQL (серверы MySQL), но связи между всеми другими типами узлов NDB Cluster должны использовать IPv4.

На практике это означает, что можно использовать IPv6 для репликации между NDB Cluster, но связи между узлами в том же самом NDB Cluster должны использовать IPv4. Для получения дополнительной информации посмотрите раздел 8.3.

A.38: Как я обращаюсь с пользователями MySQL в NDB Cluster, имеющем много серверов MySQL?

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

A.39: Как я продолжаю посылать запросы, если один из узлов SQL терпит неудачу?

MySQL NDB Cluster не обеспечивает автоматической отказоустойчивости между узлами SQL. Ваше приложение должно быть готово обращаться с потерей узлов SQL.

A.40: Как я резервирую и восстанавливаю NDB Cluster?

Можно использовать встроенную функциональность NDB Cluster в клиенте управления NDB и программу ndb_restore, см. разделы 7.3 и 6.24.

Можно также использовать традиционную функциональность, обеспеченную с этой целью в mysqldump и сервером MySQL. См. mysqldump A Database Backup Program.

A.41: Что такое процесс ангела?

Этот процесс мониторит и при необходимости пытается перезапустить процесс узла данных. Если вы проверяете список активных процессов на вашей системе после старта ndbd, вы видите, что есть на самом деле 2 процесса с именем, как показано здесь (мы опускаем вывод ndb_mgmd и ndbd):

shell> ./ndb_mgmd
shell> ps aux | grep ndb
me      23002  0.0  0.0 122948  3104 ?        Ssl  14:14   0:00 ./ndb_mgmd
me      23025  0.0  0.0   5284   820 pts/2    S+   14:14   0:00 grep ndb

shell> ./ndbd -c 127.0.0.1 --initial
shell> ps aux | grep ndb
me      23002  0.0  0.0 123080  3356 ?        Ssl  14:14   0:00 ./ndb_mgmd
me      23096  0.0  0.0  35876  2036 ?        Ss   14:14   0:00 ./ndbd -c 127.0.0.1 --initial
me      23097  1.0  2.4 524116 91096 ?        Sl   14:14   0:00 ./ndbd -c 127.0.0.1 --initial
me      23168  0.0  0.0   5284   812 pts/2    R+   14:15   0:00 grep ndb

Процесс ndbd показывает 0 использования памяти и CPU и является процессом ангела. Это на самом деле использует очень небольшое количество каждого ресурса, конечно. Это просто проверяет, чтобы видеть, обрабатывают ли что-то процессы ndbd (основной процесс узла данных, который на самом деле обрабатывает данные). Если разрешено сделать так (например, если StopOnError = false, см. раздел 5.2.1), процесс ангела пытается перезапустить основной процесс узла данных.

Поиск

 

Найди своих коллег!

Вы можете направить письмо администратору этой странички, Алексею Паутову. mailto:alexey.v.pautov@mail.ru