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

Вопросы

Вопросы и Ответы

B.10.1: Какие версии Кластера программной поддержки MySQL? Я должен скомпилировать из источника?

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

Следует использовать MySQL Cluster NDB 7.2 или MySQL Cluster NDB 7.3 для любого нового развертывания; если Вы используете более старую версию MySQL Cluster, следует обновить до одного из них скоро насколько возможно. Для краткого обзора улучшений, сделанных в MySQL Cluster NDB 7.2, см. MySQL Cluster Development в MySQL Cluster NDB 7.2; для информации об улучшениях, сделанных в MySQL Cluster NDB 7.3, см. Раздел 17.1.4.1, "MySQL Cluster Development в MySQL Cluster NDB 7.3".

Можно определить, имеет ли Ваш MySQL Server NDB поддержка используя один из операторов SHOW VARIABLES LIKE 'have_%', SHOW ENGINES, или SHOW PLUGINS.

B.10.2: Что делает среднее значение "NDB" и "NDBCLUSTER"?

"NDB" обозначает "Сетевую базу данных". NDB и NDBCLUSTER оба имена для механизма хранения, который позволяет кластеризировать поддержку в MySQL. В то время как наши разработчики предпочитают NDB, любое имя корректно; оба имени появляются в нашей документации, и любое имя может использоваться в ENGINE опция a CREATE TABLE оператор для того, чтобы составить таблицу MySQL Cluster.

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

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

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

Асинхронная репликация также доступна в MySQL Cluster. MySQL Cluster Replication (также иногда известный как "гео-репликация") включает возможность тиражироваться и между двумя MySQL Clusters, и от MySQL Cluster до сервера MySQL некластера. См. Раздел 17.6, "MySQL Cluster Replication".

B.10.4: я нуждаюсь в каких-либо специальных сетях, чтобы выполнить MySQL Cluster? Как делают компьютеры в кластере связываются?

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

Более быстрый протокол SCI также поддерживается, но требует специальных аппаратных средств. См. Раздел 17.3.5, "Используя Высокоскоростные Межсоединения с MySQL Cluster", для получения дополнительной информации о SCI.

B.10.5: Сколько компьютеров я должен выполнить MySQL Cluster, и почему?

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

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

B.10.6: Что различные компьютеры делают в MySQL Cluster?

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

B.10.7: Когда я работаю SHOW команда в клиенте управления MySQL Cluster, я вижу строку вывода, который похож на это:

id=2    @10.100.10.32  (Version: 5.6.11-ndb-7.3.3 Nodegroup: 0, Master)

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

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

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

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

Для некоторых из этих различных механизмов и протоколов возможно иметь различные главные узлы, но вообще то же самое ведущее устройство выбирается для всех них. Узел, обозначенный как ведущее устройство в выводе SHOW в управлении клиент фактически DICT ведущее устройство (см. DBDICT Блок, в Руководстве разработчика API MySQL Cluster, для получения дополнительной информации), ответственный за координирование DDL и действия метаданных.

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

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

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

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

B.10.9: Каковы требования к аппаратным средствам для рабочего MySQL Cluster?

MySQL Cluster должен работать на любой платформе для который NDBПоддерживающие двоичные файлы доступны. Для узлов данных и узлов API, более быстрые ЦП и больше памяти, вероятно, улучшат производительность, и 64-разрядные ЦП, вероятно, будут более эффективными чем 32-разрядные процессоры. Должна быть достаточная память на машинах, используемых для узлов данных, чтобы содержать долю каждого узла базы данных (см., В каком количестве RAM я Нуждаюсь? для получения дополнительной информации). Для компьютера, который используется только для того, чтобы выполнить сервер управления MySQL Cluster, требования минимальны; общий настольный ПК (или эквивалент) обычно достаточен для этой задачи. Узлы могут связаться через стандартную сеть TCP/IP и аппаратные средства. Они могут также использовать высокоскоростной протокол SCI; однако, специальное сетевое аппаратное и программное обеспечение обязаны использовать SCI (см. Раздел 17.3.5, "Используя Высокоскоростные Межсоединения с MySQL Cluster").

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

Прежде MySQL Cluster был в памяти только. MySQL 5.1 и позже также обеспечивает возможность сохранить MySQL Cluster на диске. (Отметьте, что у нас нет никаких планов бэкпортировать эту возможность к предыдущим выпускам.) См. Раздел 17.5.12, "MySQL Cluster Disk Data Tables", для получения дополнительной информации.

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

(SizeofDatabase × NumberOfReplicas × 1.1 ) / NumberOfDataNodes

Вычислить требования к памяти более точно требует определения, для каждой таблицы в базе данных кластера, пространство памяти, требуемое на строку (см. Раздел 11.6, "Требования Хранения Типа данных", для деталей), и умножающий это на число строк. Следует также не забыть учитывать любой столбец, индексирует следующим образом:

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

Вычисляя требования к памяти Кластера, можно счесть полезным ndb_size.pl утилита, которая доступна в недавних выпусках MySQL 5.6. Этот сценарий Perl соединяет с током (некластер) базу данных MySQL и создает отчет относительно того, сколько пространства, которого потребовала бы база данных, если бы это использовало NDBCLUSTER механизм хранения. Для получения дополнительной информации см. Раздел 17.4.23, "ndb_size.pl — Оценочная функция Требования Размера NDBCLUSTER" .

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

Можно определить, сколько памяти используется для хранения данных MySQL Cluster и индексирует в любой момент времени использование REPORT MEMORYUSAGE команда в ndb_mgm клиенте; см. Раздел 17.5.2, "Команды в MySQL Cluster Management Client", для получения дополнительной информации. Кроме того, предупреждения пишутся журналу кластера когда 80 % доступных DataMemory или IndexMemory используется, и снова когда использование достигает 85 %, 90 %, и так далее.

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

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

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

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

B.10.12: я могу выполнить узлы MySQL Cluster в виртуальных машинах (таких как создаваемые VMWare, Параллелями, или Xen)?

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

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

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

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

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

В некоторых случаях возможно добраться, Таблица является полными ошибками в клиентских приложениях MySQL, даже когда ndb_mgm-e "ВЕСЬ ОТЧЕТ MEMORYUSAGE" показывает существенный свободный DataMemory. Можно вызвать NDB создать дополнительные разделы для таблиц MySQL Cluster и таким образом иметь больше памяти в наличии для хеша индексируют при использовании MAX_ROWS опция для CREATE TABLE. Вообще, установка MAX_ROWS к дважды числу строк, которые Вы ожидаете хранить в таблице, должно быть достаточным.

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

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

Очень маловероятно, что кластер выполнил бы достоверно в таких условиях, поскольку MySQL Cluster был разработан и реализован учитывая, что это будет выполнено при условиях, гарантирующих, выделил высокоскоростную связь, такую как это, нашел в установке LAN, используя 100 Мбит/с или гигабитном Ethernet — предпочтительно последний. Мы ни не тестируем, ни гарантируем его производительность, используя что-либо медленнее чем это.

Кроме того, чрезвычайно важно иметь в виду, что связь между узлами в MySQL Cluster не безопасна; они ни не шифруются, ни гарантируются любым другим защитным механизмом. Самая безопасная конфигурация для кластера находится в частной сети позади брандмауэра без прямого доступа к любым данным Кластера или узлам управления снаружи. (Для узлов SQL следует взять те же самые предосторожности, как Вы были бы с любым другим экземпляром сервера MySQL.) Для получения дополнительной информации, см. Раздел 17.5.11, "MySQL Cluster Security Issues".

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

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

Некоторые специализированные параметры конфигурации и файлы обязаны устанавливать MySQL Cluster — см. Раздел 17.3.2, "MySQL Cluster Configuration Files", для информации о них.

Несколько простых команд используются в клиенте управления MySQL Cluster (ndb_mgm) для задач, таких как запуск и остановка узлов кластера. См. Раздел 17.5.2, "Команды в MySQL Cluster Management Client".

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

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

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

MySQL Cluster (NDB 7.1 и позже) также поддерживает использование прикладного программирования Java ClusterJ, который поддерживает объектную модель домена сеансов использования данных и транзакций. См. Java и MySQL Cluster для получения дополнительной информации.

MySQL Cluster (NDB 7.2 и позже) также поддерживает memcached, разрешение разработчикам получить доступ к данным, хранившим в MySQL Cluster, используя memcached интерфейс; для получения дополнительной информации см. ndbmemcache— API Memcache для MySQL Cluster.

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

B.10.17: Кластер MySQL Does включает какие-либо инструменты управления?

MySQL Cluster включает клиент командной строки для того, чтобы выполнить основные функции управления. См. Раздел 17.4.5, "ndb_mgm — MySQL Cluster Management Client", и Раздел 17.5.2, "Команды в MySQL Cluster Management Client".

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

MySQL Cluster NDB 7.3 представляет графический, основанный на браузере Автоустановщик для установки и развертывания MySQL Cluster как часть распределения программного обеспечения MySQL Cluster. Для получения дополнительной информации см. Раздел 17.2.1, "MySQL Cluster Auto-Installer".

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

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

B.10.19: безопасный от транзакции Кластер MySQL Is? Какие уровни изоляции поддерживаются?

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

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

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

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

B.10.21: В случае катастрофического отказа — говорят, например, целый город теряет питание и мои сбои UPS — я потерял бы все свои данные?

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

B.10.22: это возможный использовать FULLTEXT индексирует с MySQL Cluster?

FULLTEXT индексация в настоящий момент не поддерживается никаким механизмом хранения MySQL кроме MyISAM.

B.10.23: я могу выполнить многократные узлы на единственном компьютере?

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

Учитывая, что MySQL Cluster может быть выполнен на товарных аппаратных средствах, загруженных дешевым (или даже без стоимости) операционная система, расход дополнительной машины или два хорошо стоит этого, чтобы охранять данные для решения ответственных задач. Это также ценность, отмечающая, что требования для узла кластера, выполняющего узел управления, минимальны. Эта задача может быть выполнена с Pentium на 300 МГц или эквивалентным ЦП и достаточной RAM для операционной системы плюс небольшое количество издержек для процессов ndb_mgm и ndb_mgmd.

Приемлемо выполнить многократные узлы данных кластера на единственном узле, у которого есть многократные ЦП, ядра, или оба. MySQL Cluster NDB 7.0 и позже также обеспечивает многопоточную версию двоичного файла узла данных, предназначенного для использования на таких системах. Для получения дополнительной информации см. Раздел 17.4.3, "ndbmtd — MySQL Cluster Data Node Daemon (Многопоточный)" .

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

B.10.24: Есть ли какие-либо ограничения, о которых я должен знать при использовании MySQL Cluster?

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

Для полного списка ограничений в MySQL Cluster см. Раздел 17.1.6, "Известные Ограничения MySQL Cluster". См. также Раздел 17.1.6.11, "Предыдущий MySQL Cluster Issues Resolved в MySQL Cluster NDB 7.3".

B.10.25: Кластер MySQL Does поддерживает внешние ключи?

MySQL Cluster NDB 7.3 добавляет поддержку ограничений внешнего ключа, сопоставимых с найденным в InnoDB механизм хранения; см. Раздел 1.8.6.2,"FOREIGN KEY Ограничения", для более подробной информации, так же как Раздела 13.1.17.2, "Используя FOREIGN KEY Ограничения". Приложения, требующие поддержки внешнего ключа, должны использовать MySQL Cluster NDB 7.3 (или позже).

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

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

Также возможно преобразовать существующие таблицы, которые используют другие механизмы хранения для NDBCLUSTER использование один или больше ALTER TABLE оператор. Однако, определение таблицы должно быть совместимым с NDBCLUSTER механизм хранения до создания преобразования. В MySQL 5.6 также требуется дополнительное обходное решение; см. Раздел 17.1.6, "Известные Ограничения MySQL Cluster", для деталей.

B.10.27: Как узлы MySQL Cluster связываются друг с другом?

Узлы кластера могут связаться через любой из трех различных транспортных механизмов: TCP/IP, ОТМЕТКА КУРСА КОРАБЛЯ (разделяемая память), и SCI (Масштабируемый когерентный интерфейс). Где доступный, ОТМЕТКА КУРСА КОРАБЛЯ используется по умолчанию между узлами, находящимися на том же самом узле кластера; однако, это считают экспериментальным. SCI является высокоскоростным (1 гигабит в секунду и выше), высоконадежный протокол, используемый в создании масштабируемых многопроцессорных систем; это требует специальных аппаратных средств и драйверов. См. Раздел 17.3.5, "Используя Высокоскоростные Межсоединения с MySQL Cluster", для больше об использовании SCI как транспортный механизм для MySQL Cluster.

B.10.28: Каков арбитр?

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

То, когда все узлы данных по крайней мере в одной группе узла являются живым, сетевым разделением, не является проблемой, потому что никакое единственное подмножество кластера не может сформировать функциональный кластер самостоятельно. Настоящая проблема возникает, когда ни у какой единственной группы узла нет всех своих живых узлов, когда разделение сети ("мозговой разделением" сценарий) становится возможным. Затем арбитр требуется. Все узлы кластера распознают тот же самый узел как арбитр, который обычно является сервером управления; однако, возможно сконфигурировать любой MySQL Servers в кластере, чтобы действовать как арбитр вместо этого. Арбитр принимает, что первый набор узлов кластера связывается с этим, и говорит остающемуся набору завершать работу. Выбором арбитра управляют ArbitrationRank параметр конфигурации для MySQL Server и узлов сервера управления. В MySQL Cluster NDB 7.0.7 и позже, можно также использовать ArbitrationRank параметр конфигурации, чтобы управлять процессом выбора арбитра. Для получения дополнительной информации об этих параметрах, см. Раздел 17.3.2.5, "Определяя MySQL Cluster Management Server".

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

B.10.29: Какие типы данных поддерживаются MySQL Cluster?

MySQL Cluster поддерживает все обычные типы данных MySQL, включая связанных с пространственными расширениями MySQL; однако, NDB механизм хранения не поддерживает пространственный, индексирует. (Пространственный индексирует, поддерживаются только MyISAM; см. Раздел 12.18, "Пространственные Расширения", для получения дополнительной информации.), Кроме того, есть некоторые различия относительно, индексирует когда использующийся с NDB таблицы.

См. Раздел 17.1.6, "Известные Ограничения MySQL Cluster", для получения дополнительной информации об этих проблемах.

B.10.30: Как я запускаю и останавливаю MySQL Cluster?

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

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

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

shell> ndb_mgm -e
        "SHUTDOWN"

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

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

Для получения дополнительной информации см. Раздел 17.5.2, "Команды в MySQL Cluster Management Client", и Раздел 17.2.7, "Безопасное Завершение работы и Перезапуск MySQL Cluster".

B.10.31: Что происходит с данными MySQL Cluster, когда MySQL Cluster выключен?

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

B.10.32: действительно ли это - хорошая идея иметь больше чем один узел управления для MySQL Cluster?

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

См. Раздел 17.3.2, "MySQL Cluster Configuration Files", для информации о том, как сконфигурировать узлы управления MySQL Cluster.

B.10.33: я могу смешать различные виды систем аппаратного обеспечения и операционных систем в одном MySQL Cluster?

Да, пока у всех машин и операционных систем есть тот же самый "порядок байтов" (весь обратный порядок байтов или весь прямой порядок байтов). Мы работаем, чтобы преодолеть это ограничение в будущем выпуске MySQL Cluster.

Также возможно использовать программное обеспечение от различных выпусков MySQL Cluster на различных узлах. Однако, мы поддерживаем это только как часть прокручивающейся процедуры обновления (см. Раздел 17.5.5, "Выполняя Прокручивающийся Перезапуск MySQL Cluster").

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

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

Мы также отговариваем от выполнения узлов данных и узлов SQL вместе на том же самом узле, так как ndbd и процессы mysqld могут конкурировать за память.

B.10.35: я могу использовать имена хоста с MySQL Cluster?

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

B.10.36: Кластер MySQL Does поддерживает IPv6?

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

На практике это означает, что можно использовать IPv6 для репликации между MySQL Clusters, но соединения между узлами в том же самом MySQL Cluster должны использовать IPv4. Для получения дополнительной информации см. Раздел 17.6.3, "Известные Проблемы в MySQL Cluster Replication".

B.10.37: Как я обрабатываю пользователей MySQL в MySQL Cluster, имеющем многократные серверы MySQL?

Учетные записи пользователей MySQL и полномочия обычно автоматически не распространяются между различными серверами MySQL, получающими доступ к тому же самому MySQL Cluster. Начинаясь с MySQL Cluster NDB 7.2, MySQL Cluster оказывает поддержку для распределенных полномочий. В то время как распределение полномочия не включается автоматически, можно активировать его следующим процедура, обеспеченная в документации MySQL Cluster. См. Раздел 17.5.14, "Распределенный MySQL Privileges для MySQL Cluster", для получения дополнительной информации.

B.10.38: Как я продолжаю отправлять запросы, когда один из узлов SQL перестал работать?

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

B.10.39: Как я поддерживаю и восстанавливаю MySQL Cluster?

Можно использовать собственное резервное копирование NDB и восстановить функциональность в клиенте управления MySQL Cluster и ndb_restore программе. См. Раздел 17.5.3, "Онлайновое Резервное копирование MySQL Cluster", и Раздел 17.4.18, "ndb_restore — Восстановление MySQL Cluster Backup".

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

B.10.40: Каков "процесс ангела"?

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

shell> ./ndb_mgmdshell> ps aux | grep ndbme      23002  0.0  0.0 122948  3104 ?        Ssl  14:14   0:00 ./ndb_mgmdme      23025  0.0  0.0   5284   820 pts/2    S+   14:14   0:00 grep ndbshell> ./ndbd -c 127.0.0.1 --initialshell> ps aux | grep ndbme      23002  0.0  0.0 123080  3356 ?        Ssl  14:14   0:00 ./ndb_mgmdme      23096  0.0  0.0  35876  2036 ?        Ss   14:14   0:00 ./ndbd -c 127.0.0.1 --initialme      23097  1.0  2.4 524116 91096 ?        Sl   14:14   0:00 ./ndbd -c 127.0.0.1 --initialme      23168  0.0  0.0   5284   812 pts/2    R+   14:15   0:00 grep ndb

Процесс ndbd, показывая 0 памятей и использование ЦП является процессом ангела. Это фактически использует очень небольшое количество каждого, конечно. Это просто проверяет, чтобы видеть, обрабатывают ли основные ndbd (основной процесс узла данных, который фактически обрабатывает данные), работает. Если разрешено сделать так (например, если StopOnError параметр конфигурации устанавливается в ложь — видят Раздел 17.3.3.1, "MySQL Cluster Data Node Configuration Parameters"), процесс ангела пытается перезапустить основной процесс узла данных.