17.3.2.6. Определение MySQL Cluster Data Nodes

Id

Уникальный ID узла используется в качестве адреса узла для всего кластера внутренние сообщения. Для узлов данных это - целое число в диапазоне 1 - 48 включительно. У каждого узла в кластере должен быть уникальный идентификатор.

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

NodeId

Уникальный ID узла используется в качестве адреса узла для всего кластера внутренние сообщения. Для узлов данных это - целое число в диапазоне 1 - 48 включительно. У каждого узла в кластере должен быть уникальный идентификатор.

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

ExecuteOnComputer

Это обращается к Id набор для одного из компьютеров определяется в a [computer] раздел.

HostName

Определение этого параметра определяет имя узла компьютера, на котором должен находиться узел данных. Определить имя узла кроме localhost, или этот параметр или ExecuteOnComputer требуется.

ServerPort

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

Однако, если Вы должны быть в состоянии открыть определенные порты в брандмауэре, чтобы разрешить передачу между узлами данных и узлами API (включая узлы SQL), можно установить эти параметры к числу требуемого порта в [ndbd] раздел или (если Вы должны сделать это для многократных узлов данных), [ndbd default] раздел config.ini файл, и затем открывает порт, имеющий то число для входящих соединений от узлов SQL, узлов API, или обоих.

TcpBind_INADDR_ANY

Устанавливание этих параметров к TRUE или 1 связывает IP_ADDR_ANY так, чтобы соединения могли быть сделаны отовсюду (для автоматически сгенерированных соединений). Значение по умолчанию FALSE (0).

NodeGroup

Этот параметр может использоваться, чтобы присвоить узел данных определенной группе узла. Это только для чтения, когда кластер запускается впервые, и не может использоваться, чтобы повторно присвоить узел данных различной группе узла онлайн. Это является обычно не требуемым, чтобы использовать этот параметр в [ndbd default] раздел config.ini файл, и забота должны быть взяты, чтобы не присвоить узлы группам узла таким способом, которым недопустимые числа узлов присваиваются любым группам узла.

NodeGroup параметр в основном предназначается для использования в добавлении новой группы узла к рабочему MySQL Cluster, не имея необходимость выполнять прокручивающийся перезапуск. С этой целью следует установить это в 65536 (максимальное значение). Вы не обязаны устанавливать a NodeGroup значение для всех узлов данных кластера, только для тех узлов, которые должны быть запущены и добавлены к кластеру как новая группа узла в более позднее время. Для получения дополнительной информации см. Раздел 17.5.13.3, "Узлы данных Кластера MySQL Adding Онлайн: Подробный Пример".

NoOfReplicas

Эти глобальные параметры могут быть установлены только в [ndbd default] раздел, и определяет число копий для каждой таблицы, хранимой в кластере. Этот параметр также определяет размер групп узла. Группа узла является рядом узлов все хранящие ту же самую информацию.

Группы узла формируются неявно. Первая группа узла формируется набором узлов данных с самыми низкими ID узла, следующей группой узла набором следующих самых низких идентификационных данных узла, и так далее. Посредством примера предположите, что у нас есть 4 узла данных и что NoOfReplicas устанавливается в 2. У этих четырех узлов данных есть ID узла 2, 3, 4 и 5. Затем первая группа узла формируется из узлов 2 и 3, и вторая группа узла узлами 4 и 5. Важно сконфигурировать кластер таким способом, что узлы в тех же самых группах узла не помещаются в тот же самый компьютер, потому что единственный отказ оборудования заставил бы весь кластер перестать работать.

Если никакие ID узла не будут обеспечены, то порядок узлов данных будет определяющим фактором для группы узла. Делаются ли явные присвоения, они могут быть просмотрены в выводе клиента управления SHOW команда.

Значение по умолчанию для NoOfReplicas 2, который является рекомендуемой установкой в наиболее распространенных сценариях использования.

Максимальное возможное значение 4; в настоящий момент только значения 1 и 2 фактически поддерживаются.

Значение для этого параметра должно разделиться равномерно на число узлов данных в кластере. Например, если есть два узла данных, то NoOfReplicas должно быть равным или 1 или 2, так как 2/3 и 2/4 оба приводят к дробным значениям; если есть четыре узла данных, то NoOfReplicas должно быть равным 1, 2, или 4.

DataDir

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

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

FileSystemPath

Этот параметр определяет каталог, куда все файлы, создаваемые для метаданных, Журналов отката, журналов ОТМЕНЫ (для Дисковых Таблиц данных), и файлы данных, помещаются. Значение по умолчанию является каталогом, определенным DataDir.

Рекомендуемая иерархия каталогов для MySQL Cluster включает /var/lib/mysql-cluster, под которым создается каталог для файловой системы узла. Имя этого подкаталога содержит ID узла. Например, если ID узла 2, этот подкаталог называют ndb_2_fs.

BackupDataDir

Этот параметр определяет каталог, в который помещаются резервные копии.

DataMemory

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

Память, выделенная DataMemory используется, чтобы сохранить обоих фактические записи и индексирует. На каждой записи есть 16-байтовые издержки; дополнительное количество для каждой записи поносится, потому что это сохранено в странице 32 Кбит с 128-байтовыми издержками страницы (см. ниже). Есть также небольшое количество, потраченное впустую на страницу вследствие того, что каждая запись сохранена только в одной странице.

Для табличных атрибутов переменного размера данные хранятся на отдельном datapages, выделенном от DataMemory. Использование записей переменной длины фиксированный размер расстается с дополнительными издержками 4 байтов, чтобы сослаться на часть переменного размера. У части переменного размера есть 2-байтовые издержки плюс 2 байта за атрибут.

Максимальный размер записи составляет 14000 байтов.

Пространство памяти, определенное DataMemory также используется, чтобы сохранить упорядоченный, индексирует, которые используют приблизительно 10 байтов за запись. Каждая строка таблицы представляется в упорядоченном, индексируют. Распространенная ошибка среди пользователей состоит в том, чтобы предположить, что все индексирует, сохранены в памяти, выделенной IndexMemory, но дело обстоит не так: Только первичный ключ и уникальный хеш индексируют использование эта память; упорядоченный индексирует использование память, выделенная DataMemory. Однако, создание первичного ключа или уникального хеша индексирует, также создает упорядоченный, индексируют на тех же самых ключах, если Вы не определяете USING HASH в операторе создания индекса. Это может быть проверено, работая ndb_desc-d db_name table_name в клиенте управления.

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

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

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

DataMemory пространство памяти также содержит информацию об ОТМЕНЕ: Для каждого обновления копия неизменной записи выделяется в DataMemory. Есть также ссылка на каждую копию в упорядоченной таблице, индексирует. Уникальный хеш индексирует, обновляются только, когда столбцы уникального индекса обновляются, когда новая запись в индексировать таблице вставляется, и старая запись удаляется на фиксацию. Поэтому также необходимо выделить достаточно памяти, чтобы обработать самые большие транзакции, выполняемые приложениями, используя кластер. В любом случае выполнение нескольких больших транзакций не содержит преимущества перед использованием многих меньших по следующим причинам:

Значение по умолчанию для DataMemory 80 МБ; минимум составляет 1 МБ. Нет никакого максимального размера, но в действительности максимальный размер должен быть адаптирован так, чтобы процесс не начал подкачивать, когда предел достигается. Этот предел определяется количеством физической RAM, доступной на машине и объемом памяти, что операционная система может передать любой процесс. 32-разрядные операционные системы обычно ограничиваются 2–4GB, для каждого процесса; 64-разрядные операционные системы могут использовать больше. Для больших баз данных может быть предпочтительно использовать 64-разрядную операционную систему по этой причине.

IndexMemory

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

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

Значение по умолчанию для IndexMemory 18 МБ. Минимум составляет 1 МБ.

StringMemory

Этот параметр определяет, сколько памяти выделяется для строк, таких как имена таблиц, и определяется в [ndbd] или [ndbd default] раздел config.ini файл. Значение между 0 и 100 включительно интерпретируется как процент максимального значения по умолчанию, которое вычисляется основанное на многих факторах включая число таблиц, максимального размера имени таблицы, максимального размера .FRM файлы, MaxNoOfTriggers, максимальный размер имени столбца, и максимальное значение столбца значения по умолчанию.

Значение, больше чем 100 интерпретируется как многие байты.

Значение по умолчанию 25 — то есть, 25 процентов максимума значения по умолчанию.

При большинстве обстоятельств значение по умолчанию должно быть достаточным, но когда у Вас есть очень много таблиц Кластера (1000 или больше), возможно получить Ошибку 773 Из строковой памяти, пожалуйста, измените параметр конфигурации StringMemory: Систематическая ошибка: ошибка Схемы, когда следует увеличить это значение. 25 (25 процентов) не являются чрезмерными, и должны препятствовать этой ошибке повториться во всех кроме самых экстремальных условий.

MaxNoOfConcurrentTransactions

Каждый узел данных кластера требует записи транзакции для каждой активной транзакции в кластере. Задача координирования транзакций распределяется среди всех узлов данных. Общее количество записей транзакции в кластере является числом транзакций в любые данные времена узла число узлов в кластере.

Записи транзакции выделяются отдельным серверам MySQL. Каждое соединение с сервером MySQL требует по крайней мере одной записи транзакции плюс дополнительный объект транзакции на таблицу, к которой получает доступ то соединение. Это означает, что разумный минимум для общего количества транзакций в кластере может быть выражен как

TotalNoOfConcurrentTransactions =    (maximum number of tables accessed in any single transaction + 1)    * number of cluster SQL nodes

Предположите, что есть 10 узлов SQL, используя кластер. Единственное соединение, включающее 10 таблиц, требует 11 записей транзакции; если есть 10 такие, присоединяется в транзакции, то 10 * 11 = 110 записей транзакции требуются для этой транзакции на сервер MySQL, или 110 * 10 = общее количество записей транзакции 1100 года. Каждый узел данных, как могут ожидать, обработает TotalNoOfConcurrentTransactions / число узлов данных. Для MySQL Cluster, имеющего 4 узла данных, это означало бы устанавливать MaxNoOfConcurrentTransactions на каждом узле данных к 1100 / 4 = 275. Кроме того, следует предусмотреть восстановление отказа, обеспечивая, чтобы единственная группа узла могла разместить все параллельные транзакции; другими словами, то, что MaxNoOfConcurrentTransactions каждого узла данных достаточен, чтобы покрыть много транзакций, равных TotalNoOfConcurrentTransactions / число групп узла. Если у этого кластера есть единственная группа узла, то MaxNoOfConcurrentTransactions должен быть установлен в 1100 (то же самое как общее количество параллельных транзакций для всего кластера).

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

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

Изменение значения MaxNoOfConcurrentTransactions требует полного завершения работы и перезапуска кластера.

Значение по умолчанию 4096.

MaxNoOfConcurrentOperations

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

Учет ведут для каждой транзакции, обновляющей данные кластера, и в координаторе транзакции и в узлах, где фактические обновления выполняются. Эти записи содержат информацию о состоянии, должен был найти записи ОТМЕНЫ для отката, очередей блокировки, и других целей.

Эти параметры должны быть установлены как минимум к числу записей, которые будут обновлены одновременно в транзакциях, разделенных на число узлов данных кластера. Например, в кластере, у которого есть четыре узла данных и который, как ожидают, обработает один миллион параллельных обновлений, используя транзакции, следует установить это значение в 1000000 / 4 = 250000. Чтобы помочь обеспечить упругость против отказов, предлагается, чтобы Вы установили эти параметры к значению, которое достаточно высоко, чтобы разрешить отдельному узлу данных обрабатывать загрузку для своей группы узла. Другими словами следует установить значение, равное total number of concurrent operations / number of node groups. (В случае, где есть единственная группа узла, это - то же самое как общее количество параллельных операций для всего кластера.)

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

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

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

Значение по умолчанию 32768.

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

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

Также важно иметь идею требований к памяти для записей работы. Они используют приблизительно 1 Кбит за запись.

MaxNoOfLocalOperations

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

MaxDMLOperationsPerTransaction

Этот параметр ограничивает размер транзакции. Транзакция прерывается, если она требует больше чем эти много DML операции. Минимальное число операций на транзакцию 32; однако, можно установить MaxDMLOperationsPerTransaction к 0, чтобы отключить любое ограничение на число операций DML на транзакцию. Максимум (и значение по умолчанию) 4294967295.

MaxNoOfConcurrentIndexOperations

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

Значение по умолчанию этого параметра 8192. Только в редких случаях чрезвычайно высокого параллелизма, используя уникальный хеш индексирует, должен это быть необходимым увеличить это значение. Используя меньшее значение возможно и может сохранить память, если DBA является бесспорным, что высокая степень параллелизма не требуется для кластера.

MaxNoOfFiredTriggers

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

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

TransactionBufferMemory

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

Значение по умолчанию для TransactionBufferMemory 1 МБ.

Нормальные операции чтения и операции записи используют подобный буфер, использование которого является даже более недолгим. Параметр времени компиляции ZATTRBUF_FILESIZE (найденный в ndb/src/kernel/blocks/Dbtc/Dbtc.hpp) набор к 4000 × 128 байтов (500 Кбит). Подобный буфер для ключевой информации, ZDATABUF_FILESIZE (также в Dbtc.hpp) содержит 4000 × 16 = 62.5KB пространства буфера. Dbtc модуль, который обрабатывает координацию транзакции.

MaxNoOfConcurrentScans

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

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

Значение по умолчанию MaxNoOfConcurrentScans 256. Максимальное значение 500.

MaxNoOfLocalScans

Определяет число локальных записей сканирования, если много сканирований не полностью параллелизируются. Когда число локальных записей сканирования не обеспечивается, оно вычисляется как 4 раза продукт MaxNoOfConcurrentScans и число узлов данных в системе. (Ранее, это было вычислено как продукт MaxNoOfConcurrentScans и число узлов данных.) Минимальное значение 32.

BatchSizePerLocalScan

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

BatchSizePerLocalScan имеет соединение strong с BatchSize определенный в узлах SQL.

LongMessageBuffer

Это - внутренний буфер, используемый для того, чтобы передать сообщения в пределах отдельных узлов и между узлами. Значение по умолчанию составляет 4 МБ.

Этот параметр редко должен изменяться от значения по умолчанию.

MaxParallelScansPerFragment

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

Значение по умолчанию для этого параметра в MySQL Cluster NDB 7.3 256.

NoOfFragmentLogFiles

Этот параметр определяет номер файлов Журнала отката для узла, и таким образом количество места, выделенного, чтобы ВОССТАНОВИТЬ журналирование. Поскольку файлы Журнала отката организуются в кольце, чрезвычайно важно, чтобы первые и последние файлы журнала в наборе (иногда называемый файлами журнала "головы" и "хвоста", соответственно) не встретились. Когда они приближаются к друг другу слишком близко, узел начинает прерывать все транзакции, охватывающие обновления из-за нехватки комнаты для новых записей журнала.

A REDO запись журнала не удаляется, пока необходимое число локальных контрольных точек не было завершено, так как та запись журнала была вставлена. (В MySQL Cluster NDB 7.3, только 2 локальных контрольных точки необходимы). Частота установки контрольных точек определяется ее собственным набором параметров конфигурации, обсужденных в другом месте в этой главе.

Значение параметра значения по умолчанию 16, который значением по умолчанию означает 16 наборов файлов на 4 16 МБ для в общей сложности 1024 МБ. Размер отдельных файлов журнала является конфигурируемым использованием FragmentLogFileSize параметр. В сценариях, требующих очень многих обновлений, значения для NoOfFragmentLogFiles возможно, должен быть установлен столь же высоко как 300 или еще выше обеспечить достаточное пространство для Журналов отката.

Если установка контрольных точек является медленной и есть очень много записей к базе данных, что файлы журнала полны, и хвост журнала не может быть сокращен, не подвергая опасности восстановление, все транзакции обновления прерываются с внутренним кодом ошибки 410 (Out of log file space temporarily). Это условие преобладает, пока контрольная точка не завершилась, и хвост журнала может быть продвинут.

FragmentLogFileSize

Устанавливание этих параметров позволяет Вам управлять непосредственно размером файлов журнала отката. Это может быть полезно в ситуациях, когда MySQL Cluster работает при высокой загрузке, и это неспособно закрыть файлы журнала фрагмента достаточно быстро прежде, чем попытаться открыть новые (только 2 файла журнала фрагмента могут быть открытыми когда-то); увеличение размера файлов журнала фрагмента дает кластеру больше времени прежде, чем иметь необходимость открыть каждый новый файл журнала фрагмента. Значение по умолчанию для этого параметра 16M.

Для получения дополнительной информации о файлах журнала фрагмента, см. описание для NoOfFragmentLogFiles.

InitFragmentLogFiles

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

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

MaxNoOfOpenFiles

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

Значение по умолчанию 0. Однако, минимальное значение, к которому могут быть установлены эти параметры, 20.

InitialNoOfOpenFiles

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

Значение по умолчанию 27.

MaxNoOfSavedMessages

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

Значение по умолчанию является 25 файлами трассировки.

MaxLCPStartDelay

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

Возможно вынудить задержку локальной контрольной точки разрешить больше (и возможно все) узлы данных завершать синхронизацию метаданных; как только синхронизация метаданных каждого узла данных полна, все узлы данных могут восстановить табличные данные параллельно, даже в то время как локальная контрольная точка выполняется. Чтобы вызвать такую задержку, установить MaxLCPStartDelay, который определяет число секунд, кластер может ожидать, чтобы начать локальную контрольную точку, в то время как узлы данных продолжают синхронизировать метаданные. Эти параметры должны быть установлены в [ndbd default] раздел config.ini файл, так, чтобы это было то же самое для всех узлов данных. Максимальное значение 600; значение по умолчанию 0.

MaxNoOfAttributes

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

(В более старых выпусках MySQL Cluster этот параметр иногда обрабатывался как жесткий предел для определенных операций. Это вызвало проблемы с MySQL Cluster Replication, когда было возможно составить больше таблиц, чем мог быть тиражирован, и иногда приводиться беспорядок, когда это было возможно [или не возможное, в зависимости от обстоятельств], чтобы создать больше чем MaxNoOfAttributes атрибуты.)

Значение по умолчанию 1000 с минимальным возможным значением, являющимся 32. Максимум 4294967039. Каждый атрибут использует приблизительно 200 байтов хранения на узел вследствие того, что все метаданные полностью тиражируются в серверы.

Устанавливая MaxNoOfAttributes, важно подготовиться заранее к любому ALTER TABLE операторы, которые Вы могли бы хотеть выполнить в будущем. Это происходит из-за факта, во время выполнения ALTER TABLE на таблице Кластера 3 раза используется число атрибутов как в исходной таблице, и хорошая практика должна разрешить двойной это количество. Например, если таблица MySQL Cluster, имеющая самое большое число атрибутов (greatest_number_of_attributes) имеет 100 атрибутов, хорошую начальную точку для значения MaxNoOfAttributes был бы 6 * greatest_number_of_attributes = 600.

Следует также оценить среднее число атрибутов на таблицу и умножить это на MaxNoOfTables. Если это значение больше чем значение, полученное в предыдущем абзаце, следует использовать большее значение вместо этого.

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

MaxNoOfTables

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

(В более старых выпусках MySQL Cluster этот параметр иногда обрабатывался как жесткий предел для определенных операций. Это вызвало проблемы с MySQL Cluster Replication, когда было возможно составить больше таблиц, чем мог быть тиражирован, и иногда приводиться беспорядок, когда это было возможно [или не возможное, в зависимости от обстоятельств], чтобы создать больше чем MaxNoOfTables таблицы.)

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

Значение по умолчанию этого параметра 128. Минимум 8, и максимум 20320. Каждый табличный объект использует приблизительно 20 Кбит за узел.

MaxNoOfOrderedIndexes

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

Значение по умолчанию этого параметра 128. Каждый индексирует объект, использует приблизительно 10 Кбит данных на узел.

MaxNoOfUniqueHashIndexes

Для каждого уникального индекса, который не является первичным ключом, специальная таблица выделяется, который отображает уникальный ключ на первичный ключ индексированной таблицы. По умолчанию, упорядоченный индексируют, также определяется для каждого уникального индекса. Чтобы предотвратить это, следует определить USING HASH опция, определяя уникальный индекс.

Значение по умолчанию 64. Каждый индексирует, использует приблизительно 15 Кбит за узел.

MaxNoOfTriggers

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

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

Этот параметр устанавливает максимальное количество триггерных объектов в кластере.

Значение по умолчанию 768.

MaxNoOfIndexes

Этот параметр осуждается и подвергается удалению в будущей версии MySQL Cluster. Следует использовать MaxNoOfOrderedIndexes и MaxNoOfUniqueHashIndexes вместо этого.

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

Значение по умолчанию этого параметра 128.

MaxNoOfSubscriptions

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

Значение по умолчанию для MaxNoOfSubscriptions 0, который обрабатывается как равный MaxNoOfTables. Каждая подписка использует 108 байтов.

MaxNoOfSubscribers

Этот параметр представляет интерес только при использовании MySQL Cluster Replication. Значение по умолчанию 0, который обрабатывается как 2 * MaxNoOfTables; то есть, есть одна подписка на NDB таблица для каждого из двух серверов MySQL (одно действие как ведущее устройство репликации и другой как ведомое устройство). Каждый подписчик использует 16 байтов памяти.

При использовании круговой репликации, мультиосновной репликации, и другой репликации устанавливает включение больше чем 2 серверов MySQL, следует увеличить этот параметр до числа процессов mysqld, включенных в репликацию (это часто, но не всегда, то же самое как число кластеров). Например, если у Вас есть круговая установка репликации, используя три MySQL Clusters с одним mysqld, присоединенным к каждому кластеру, и каждому из этих действий процессов mysqld как ведущее устройство и как ведомое устройство, следует установить MaxNoOfSubscribers равный 3 * MaxNoOfTables.

Для получения дополнительной информации см. Раздел 17.6, "MySQL Cluster Replication".

MaxNoOfConcurrentSubOperations

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

LockPagesInMainMemory

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

Этот параметр берет одно из целочисленных значений 0, 1, или 2, которые действуют как показано в следующем списке:

Если операционная система не конфигурируется, чтобы разрешить непривилегированным пользователям блокировать страницы, то процесс узла данных, использующий этот параметр, вероятно, придется выполнить как системный корень. (LockPagesInMainMemory использование mlockall функция. От ядра Linux 2.6.9, непривилегированные пользователи могут заблокировать память как ограничено max locked memory. Для получения дополнительной информации см. ulimit-l и http://linux.die.net/man/2/mlock).

StopOnError

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

Эта опция активируется по умолчанию.

CrashOnCorruptedTuple

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

Diskless

Возможно определить таблицы MySQL Cluster как бездисковые, означая, что таблицы не отмечаются контрольной точкой к диску и что никакое журналирование не происходит. Такие таблицы существуют только в оперативной памяти. Последствие использования бездисковых таблиц - то, что ни таблицы, ни записи в тех таблицах не переживают катастрофический отказ. Однако, работая в бездисковом режиме, возможно выполнить ndbd на бездисковом компьютере.

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

Diskless отключается по умолчанию.

ODirect

Включение этому параметру причины NDB делать попытку использования O_DIRECT записи для LCP, резервных копий, и журналов отката, часто понижаясь kswapd и использования ЦП. При использовании MySQL Cluster on Linux включить ODirect если Вы используете 2.6 или более позднее ядро.

ODirect отключается по умолчанию.

RestartOnErrorInsert

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

Эта опция отключается по умолчанию.

CompressedBackup

Устанавливание этих параметров к 1 файлы резервных копий причин, которые будут сжаты. Используемое сжатие эквивалентно gzip - быстро, и может сохранить 50 % или больше пространства, требуемого на узле данных сохранить несжатые файлы резервных копий. Сжатые резервные копии могут быть включены для отдельных узлов данных, или для всех узлов данных (устанавливая эти параметры в [ndbd default] раздел config.ini файл).

Значение по умолчанию 0 (отключенный).

CompressedLCP

Устанавливание этих параметров к 1 причины локальные файлы контрольной точки, которые будут сжаты. Используемое сжатие эквивалентно gzip - быстро, и может сохранить 50 % или больше пространства, требуемого на узле данных сохранить несжатые файлы контрольной точки. Сжатые LCP могут быть включены для отдельных узлов данных, или для всех узлов данных (устанавливая эти параметры в [ndbd default] раздел config.ini файл).

Значение по умолчанию 0 (отключенный).

TimeBetweenWatchDogCheck

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

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

Тайм-аут значения по умолчанию является 6000 миллисекунд (6 секунд).

TimeBetweenWatchDogCheckInitial

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

Тайм-аут значения по умолчанию является 6000 миллисекунд (6 секунд).

StartPartialTimeout

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

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

Значение по умолчанию является 30000 миллисекунд (30 секунд). 0 отключает тайм-аут, когда кластер может запуститься, только если все узлы доступны.

StartPartitionedTimeout

Если кластер готов запуститься после ожидания StartPartialTimeout миллисекунды, но находятся все еще возможно в разделенном состоянии, кластер ожидает, пока этот тайм-аут также не передал. Если StartPartitionedTimeout устанавливается в 0, кластер ожидает неопределенно.

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

Тайм-аут значения по умолчанию является 60000 миллисекунд (60 секунд).

StartFailureTimeout

Если узел данных не завершил свою последовательность запуска в пределах времени, определенного этим параметром, сбоями запуска узла. Устанавливание этих параметров к 0 (значение по умолчанию) означает, что никакой тайм-аут узла данных не применяется.

Для ненулевых значений этот параметр измеряется в миллисекундах. Для узлов данных, содержащих чрезвычайно большие объемы данных, должен быть увеличен этот параметр. Например, в случае узла данных, содержащего несколько гигабайтов данных, период целых, 10-15 минут (то есть, 600000 - 1000000 миллисекунд) могли бы быть обязаны выполнять перезапуск узла.

StartNoNodeGroupTimeout

Когда узел данных конфигурируется с Nodegroup = 65536, расценивается как не присваиваемый любой группе узла. Когда это делается, кластер ожидает StartNoNodegroupTimeout миллисекунды, затем обрабатывает такие узлы, как если бы они были добавлены к списку, который передают к --nowait-nodes опция, и запускается. Значение по умолчанию 15000 (то есть, сервер управления ожидает 15 секунд). Устанавливание этих параметров, равных 0 средства, что кластер ожидает неопределенно.

StartNoNodegroupTimeout должно быть то же самое для всех узлов данных в кластере; по этой причине следует всегда устанавливать это в [ndbd default] раздел config.ini файл, а не для отдельных узлов данных.

См. Раздел 17.5.13, "Узлы данных Кластера MySQL Adding Онлайн", для получения дополнительной информации.

HeartbeatIntervalDbDb

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

В MySQL Cluster NDB 7.3, интервал биения значения по умолчанию является 5000 миллисекунд (5 секунд). Этот параметр не должен быть изменен решительно и не должен значительно различаться в узлах. Если один узел будет использовать 5000 миллисекунд, и узел, наблюдая его использует 1000 миллисекунд, то очевидно узел будет объявлен мертвый очень быстро. Этот параметр может быть изменен во время онлайнового обновления программного обеспечения, но только в маленьких инкрементах.

См. также Сетевые коммуникации и задержку.

HeartbeatIntervalDbApi

Каждый узел данных отправляет сигналы биения каждому серверу MySQL (узел SQL), чтобы гарантировать, что это остается в контакте. Если сервер MySQL не в состоянии отправить биение вовремя, он объявляется "мертвый", когда все продолжающиеся транзакции завершаются и все высвобожденные средства. Узел SQL не может повторно соединиться, пока все действия, инициируемые предыдущим экземпляром MySQL, не были завершены. Критерии с тремя биениями для этого определения являются тем же самым как описано для HeartbeatIntervalDbDb.

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

Для получения дополнительной информации см. Сетевые коммуникации и задержку.

HeartbeatOrder

Узлы данных отправляют биения друг другу круговым способом, посредством чего каждый узел данных контролирует предыдущий. Если биение не обнаруживается узлом определенных данных, этот узел не объявляет предыдущий узел данных в "мертвом" кругу (то есть, больше доступный кластером). Определение, что узел данных мертв, делается глобально; другими словами; как только узел данных объявляется мертвый, он расценивается как таковой всеми узлами в кластере.

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

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

Рассмотрите установку, где есть 4 узла данных A, B, C, и работа D 2 главных компьютеров host1 и host2, и что эти узлы данных составляют 2 группы узла, как показано в следующей таблице:

Предположите, что биения передаются в порядке A-> B-> C-> D-> A. В этом случае потеря биения между узлами заставляет узел B объявлять, что узел мертвый и узел C объявляет узел B мертвый. Это приводит к утрате Node Group 0, и таким образом, кластер перестал работать. С другой стороны, если порядок передачи является A-> B-> D-> C-> (и все другие условия остаются как ранее утверждено), потеря биения заставляет узлы A и D быть объявленными мертвая; в этом случае у каждой группы узла есть один выживающий узел, и кластер выживает.

HeartbeatOrder параметр конфигурации делает порядок передачи биения конфигурируемым пользователем. Значение по умолчанию для HeartbeatOrder нуль; разрешение значения по умолчанию использоваться на всех узлах данных заставляет порядок передачи биения быть определенным NDB. Если этот параметр используется, он должен быть установлен в ненулевое значение (максимальные 65535) для каждого узла данных в кластере, и это значение должно быть уникальным для каждого узла данных; это заставляет передачу биения продолжаться от узла данных до узла данных в порядке их HeartbeatOrder значения от самого низкого до самого высокого (и затем непосредственно от узла данных, имеющего самое высокое HeartbeatOrder к узлу данных, имеющему самое низкое значение, чтобы завершить круг). Значения не должны быть последовательными; например, чтобы вызвать порядок передачи биения A-> B-> D-> C-> в сценарии, обрисованном в общих чертах ранее, Вы могли установить HeartbeatOrder значения как показано здесь:

Чтобы использовать этот параметр, чтобы изменить порядок передачи биения в рабочем MySQL Cluster, следует сначала установить HeartbeatOrder для каждого узла данных в кластере в глобальной конфигурации (config.ini) файл (или файлы). Чтобы заставить изменение вступать в силу, следует выполнить любое из следующего:

Можно использовать DUMP 908 наблюдать эффект этого параметра в журналах узла данных.

ConnectCheckIntervalDelay

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

Значение по умолчанию для этого параметра 0; это - изменение от MySQL Cluster NDB 7.1.

TimeBetweenLocalCheckpoints

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

Размер всех операций записи, выполняемых начиная с запуска предыдущих локальных контрольных точек, добавляется. Этот параметр является также исключительным в этом, он определяется как основа 2 логарифма числа 4-байтовых слов, так, чтобы значение по умолчанию 20 средств, 4 МБ (4 × ²²⁰) операций записи, 21 означали бы 8 МБ, и так далее до максимального значения 31, который приравнивается к 8 Гбайт операций записи.

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

TimeBetweenGlobalCheckpoints

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

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

Этот параметр определяет интервал между глобальными контрольными точками. Значение по умолчанию является 2000 миллисекунд.

TimeBetweenEpochs

Этот параметр определяет интервал между эпохами синхронизации для MySQL Cluster Replication. Значение по умолчанию является 100 миллисекундами.

TimeBetweenEpochs часть реализации "micro-GCPs", который может использоваться, чтобы улучшить производительность MySQL Cluster Replication.

TimeBetweenEpochsTimeout

Этот параметр определяет тайм-аут для эпох синхронизации для MySQL Cluster Replication. Если узел не в состоянии участвовать в глобальной контрольной точке в пределах времени, определенного этим параметром, узел выключен. В MySQL Cluster NDB 7.3, значение по умолчанию 0; другими словами тайм-аут отключается.

TimeBetweenEpochsTimeout часть реализации "micro-GCPs", который может использоваться, чтобы улучшить производительность MySQL Cluster Replication.

Текущая стоимость этого параметра и предупреждения пишется журналу кластера всякий раз, когда GCP сохраняет, занимает больше времени, чем 1 минута или GCP сохраняют, занимает больше времени чем 10 секунд.

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

MaxBufferedEpochs

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

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

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

TimeBetweenInactiveTransactionAbortCheck

Обработка тайм-аута выполняется, проверяя таймер на каждой транзакции однажды для каждого интервала, определенного этим параметром. Таким образом, если эти параметры будут установлены к 1000 миллисекунд, то каждая транзакция будет проверена на синхронизацию однажды в секунду.

Значение по умолчанию является 1000 миллисекунд (1 секунда).

TransactionInactiveTimeout

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

Значение по умолчанию для этого параметра 4G (также максимум). Для базы данных в реальном времени, которая должна гарантировать, что никакая транзакция не сохраняет блокировки слишком долго, эти параметры должны быть установлены к относительно маленькому значению. Модуль является миллисекундами.

TransactionDeadlockDetectionTimeout

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

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

Значение тайм-аута значения по умолчанию является 1200 миллисекундами (1.2 секунды).

Минимум для этого параметра является 50 миллисекундами.

DiskSyncSize

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

Значение по умолчанию 4M (4 мегабайта).

DiskCheckpointSpeed

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

Значение по умолчанию 10M (10 мегабайт в секунду).

DiskCheckpointSpeedInRestart

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

Значение по умолчанию 100M (100 мегабайт в секунду).

NoOfDiskPagesToDiskAfterRestartTUP

Этот параметр осуждается и подвергается удалению в будущей версии MySQL Cluster. Использовать DiskCheckpointSpeedInRestart и DiskSyncSize вместо этого.

NoOfDiskPagesToDiskAfterRestartACC

Этот параметр осуждается и подвергается удалению в будущей версии MySQL Cluster. Использовать DiskCheckpointSpeedInRestart и DiskSyncSize вместо этого.

NoOfDiskPagesToDiskDuringRestartTUP (ОСУЖДАЕМЫЙ)

Этот параметр осуждается и подвергается удалению в будущей версии MySQL Cluster. Использовать DiskCheckpointSpeedInRestart и DiskSyncSize вместо этого.

NoOfDiskPagesToDiskDuringRestartACC (ОСУЖДАЕМЫЙ)

Этот параметр осуждается и подвергается удалению в будущей версии MySQL Cluster. Использовать DiskCheckpointSpeedInRestart и DiskSyncSize вместо этого.

ArbitrationTimeout

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

В MySQL Cluster NDB 7.3, значение по умолчанию является 7500 миллисекундами (7.5 секунд).

Arbitration

Arbitration параметр включает выбору арбитражных схем, соответствуя одному из 3 возможных значений для этого параметра:

UndoIndexBuffer

Индексный буфер ОТМЕНЫ, размер которого устанавливается этим параметром, используется во время локальных контрольных точек. NDB механизм хранения использует схему восстановления, основанную на непротиворечивости контрольной точки в соединении с операционным Журналом отката. Чтобы произвести непротиворечивую контрольную точку, не блокируя всю систему для записей, журналирование ОТМЕНЫ делается, выполняя локальную контрольную точку. Журналирование ОТМЕНЫ активируется на единственном табличном фрагменте за один раз. Эта оптимизация возможна, потому что таблицы сохранены полностью в оперативной памяти.

Индексный буфер ОТМЕНЫ используется для обновлений о хеше первичного ключа, индексируют. Вставляет и удаляет, перестраивают хеш, индексируют; записи механизма хранения NDB ОТМЕНЯЮТ записи журнала, которые отображают все физические изменения на индексную страницу так, чтобы они могли быть отменены в системном перезапуске. Это также регистрирует всех активные операции вставки для каждого фрагмента в начале локальной контрольной точки.

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

Этот буфер составляет 2 МБ по умолчанию. Минимальное значение составляет 1 МБ, который достаточен для большинства приложений. Для приложений, делающих чрезвычайно большие или многочисленные вставки и, удаляет вместе с большими транзакциями и большими первичными ключами, может быть необходимо увеличить размер этого буфера. Если этот буфер является слишком маленьким, механизм хранения NDB выпускает внутренний код ошибки 677 (Index UNDO buffers overloaded).

UndoDataBuffer

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

Поскольку записи журнала ОТМЕНЫ имеют тенденцию расти, поскольку больше операций регистрируется, этот буфер также более крупный чем индексировать дубликат памяти со значением по умолчанию 16 МБ.

Этот объем памяти может быть излишне большим для некоторых приложений. В таких случаях возможно уменьшить этот размер к минимуму 1 МБ.

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

Если этот буфер является слишком маленьким и переполняется, механизм хранения NDB выпускает внутренний код ошибки 891 (Перегруженные буферы ОТМЕНЫ данных).

RedoBuffer

Все действия обновления также должны быть зарегистрированы. Журнал отката позволяет воспроизвести эти обновления всякий раз, когда система перезапускается. Алгоритм восстановления NDB использует "нечеткую" контрольную точку данных вместе с журналом ОТМЕНЫ, и затем применяет Журнал отката, чтобы воспроизвести все изменения до точки восстановления.

RedoBuffer устанавливает размер буфера, в котором пишется Журнал отката. Значение по умолчанию составляет 32 МБ; минимальное значение составляет 1 МБ.

Если этот буфер является слишком маленьким, NDB механизм хранения выпускает код ошибки 1221 (Перегруженные буферы журнала отката). Поэтому следует осуществить заботу, если Вы пытаетесь уменьшить значение RedoBuffer как часть онлайнового изменения в конфигурации кластера.

LogLevelStartup

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

Уровень значения по умолчанию 1.

LogLevelShutdown

Уровень создания отчетов для событий, сгенерированных как часть корректного завершения работы узла.

Уровень значения по умолчанию 0.

LogLevelStatistic

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

Уровень значения по умолчанию 0.

LogLevelCheckpoint

Уровень создания отчетов для событий сгенерирован локальными и глобальными контрольными точками.

Уровень значения по умолчанию 0.

LogLevelNodeRestart

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

Уровень значения по умолчанию 0.

LogLevelConnection

Уровень создания отчетов для событий сгенерирован соединениями между узлами кластера.

Уровень значения по умолчанию 0.

LogLevelError

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

Уровень значения по умолчанию 0.

LogLevelCongestion

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

Уровень значения по умолчанию 0.

LogLevelInfo

Уровень создания отчетов для событий сгенерирован для информации об общем состоянии кластера.

Уровень значения по умолчанию 0.

MemReportFrequency

Этот параметр управляет, как часто отчеты использования памяти узла данных записываются в журнале кластера; это - целочисленное значение, представляющее число секунд между отчетами.

Память данных каждого узла данных и индексирует использование памяти, регистрируется и как процент и как много страниц на 32 Кбайта DataMemory и IndexMemory, соответственно, набор config.ini файл. Например, если DataMemory равно 100 Мбайтам, и узел определенных данных использует 50 Мбайт для хранения памяти данных, соответствующая строка в журнале кластера могла бы быть похожей на это:

2006-12-24 01:18:16 [MgmSrvr] INFO -- Node 2: Data usage is 50%(1280 32K pages of total 2560)

MemReportFrequency не обязательный параметр. Если использующийся, это может быть установлено для всех узлов данных кластера в [ndbd default] раздел config.ini, и может также быть установлен или переопределен для отдельных узлов данных в соответствии [ndbd] разделы конфигурационного файла. Минимальное значение — который является также значением по умолчанию — 0, когда отчеты памяти регистрируются только, когда использование памяти достигает определенных процентов (80 %, 90 %, и 100 %), как упомянуто в обсуждении событий статистики в Разделе 17.5.6.2, "MySQL Cluster Log Events".

StartupStatusReportFrequency

Когда узел данных запускается с --initial, это инициализирует файл журнала отката во время Фазы 4 Запуска (см. Раздел 17.5.1, "Сводка MySQL Cluster Start Phases"). Когда очень большие значения устанавливаются для NoOfFragmentLogFiles, FragmentLogFileSize, или оба, эта инициализация может занять много времени. Можно вынудить отчеты относительно продвижения этого процесса периодически регистрироваться, посредством StartupStatusReportFrequency параметр конфигурации. В этом случае о продвижении сообщают в журнале кластера, и с точки зрения числа файлов и с точки зрения количества пространства, которые были инициализированы, как показано здесь:

2009-06-20 16:39:23 [MgmSrvr] INFO -- Node 1: Local redo log file initialization status:#Total files: 80, Completed: 60#Total MBytes: 20480, Completed: 155572009-06-20 16:39:23 [MgmSrvr] INFO -- Node 2: Local redo log file initialization status:#Total files: 80, Completed: 60#Total MBytes: 20480, Completed: 15570

Эти отчеты регистрируются каждый StartupStatusReportFrequency секунды во время Фазы 4 Запуска. Если StartupStatusReportFrequency 0 (значение по умолчанию), затем сообщает, пишутся журналу кластера только, когда вначале и при завершении инициализации файла журнала отката обрабатывают.

BackupDataBufferSize

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

Значение по умолчанию для этого параметра составляет 16 МБ.

BackupLogBufferSize

Буфер журнала резервного копирования выполняет роль, подобную играемому резервным буфером данных, за исключением того, что это используется для того, чтобы генерировать журнал всех табличных записей, сделанных во время выполнения резервного копирования. Те же самые принципы просят запись этих страниц как с резервным буфером данных, за исключением того, что, когда нет больше пространства в буфере журнала резервного копирования, резервных сбоях. По этой причине размер буфера журнала резервного копирования должен быть достаточно большим, чтобы обработать загрузку, вызванную действиями записи, в то время как резервное копирование делается. См. Раздел 17.5.3.3, "Конфигурация для MySQL Cluster Backups".

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

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

Значение по умолчанию для этого параметра составляет 16 МБ.

BackupMemory

Этот параметр является просто суммой BackupDataBufferSize и BackupLogBufferSize.

Значение по умолчанию этого параметра в MySQL Cluster NDB 7.3 составляет 16 МБ + 16 МБ = 32 МБ.

BackupReportFrequency

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

Значение по умолчанию 0.

BackupWriteSize

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

Значение по умолчанию для этого параметра составляет 256 Кбит.

BackupMaxWriteSize

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

Значение по умолчанию для этого параметра составляет 1 МБ.

BackupDataBufferSize >= BackupWriteSize + 188KB

BackupLogBufferSize >= BackupWriteSize + 16KB

BackupMaxWriteSize >= BackupWriteSize

LockExecuteThreadToCPU

Когда использующийся с ndbd, этот параметр (теперь строка) определяет ID ЦП, присвоенного дескриптору NDBCLUSTER поток выполнения. Когда использующийся с ndbmtd, значение этого параметра является списком разделенных запятой значений ID ЦП, присвоенных обработать потоки выполнения. Каждый ID ЦП в списке должен быть целым числом в диапазоне от 0 до 65535 (включительно).

Число определенных ID должно соответствовать число потоков выполнения, определенных MaxNoOfExecutionThreads. Однако, нет никакой гарантии, что потоки присваиваются ЦП в любом данном порядке при использовании этого параметра. Можно получить более точно гранулированное управление этого использования типа ThreadConfig.

LockExecuteThreadToCPU не имеет никакого значения по умолчанию.

LockMaintThreadsToCPU

Этот параметр определяет ID ЦП, присвоенного дескриптору NDBCLUSTER потоки обслуживания.

Значение этого параметра является целым числом в диапазоне от 0 до 65535 (включительно). В MySQL Cluster NDB 7.3, нет никакого значения по умолчанию.

RealtimeScheduler

Устанавливание этих параметров к 1 включает планированию в реальном времени NDBCLUSTER потоки.

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

Значение по умолчанию 0 (планирование отключенного).

SchedulerExecutionTimer

Этот параметр определяет время в микросекундах для потоков, которые будут выполняться в планировщике прежде, чем быть отправленным. Установка этого к 0 минимизирует время отклика; чтобы достигнуть более высокой пропускной способности, можно увеличить значение за счет более длительного времени отклика.

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

SchedulerSpinTimer

Этот параметр определяет время в микросекундах для потоков, которые будут выполняться в планировщике передо сном.

Значение по умолчанию 0.

BuildIndexThreads

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

Устанавливание этих параметров к 0 (который является также значением по умолчанию) отключает многопоточное здание упорядоченных, индексирует. Максимальное позволенное значение 128.

Этот параметр поддерживается при использовании ndbd или ndbmtd.

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

TwoPassInitialNodeRestartCopy

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

Следует также установить BuildIndexThreads к ненулевому значению.

Numa

NDB чрезвычайно чувствительно к настройкам Non-Uniform Memory Access и системам мульти-ЦП из-за тайм-аутов, которые это может вызвать. Из-за этого факта, и потому что большинство пользователей MySQL Cluster не использует numactl, поддержка NUMA игнорируется по умолчанию ndbd, работая на системе Linux. Если Ваша система Linux оказывает поддержку NUMA, и Вы хотите для памяти узла данных подвергнуться управлению NUMA, можно установить эти параметры, равные 0.

Numa параметр конфигурации поддерживается только на системах Linux где libnuma.so устанавливается.

MaxNoOfExecutionThreads

Этот параметр непосредственно управляет числом потоков выполнения, используемых ndbmtd до максимума 36. Хотя эти параметры устанавливаются в [ndbd] или [ndbd default] разделы config.ini файл, это является монопольным к ndbmtd и не применяется к ndbd.

Установка MaxNoOfExecutionThreads определяет номер потоков типом как определено в следующей таблице:

В MySQL Cluster NDB 7.3 и позже, всегда есть один SUMA (репликация) поток.

Отметьте, что число потоков LQH не должно превысить NoOfFragmentLogParts. Если значение этого параметра является значением по умолчанию (4), это означает, что следует увеличить это также, устанавливая MaxNoOfExecutionThreads к 16 или больше; то есть, следует установить NoOfFragmentLogParts к соответствующему числу LQH распараллеливает значение, показанное для того значения MaxNoOfExecutionThreads в предыдущей таблице.

Типы потока описываются позже в этом разделе (см. ThreadConfig).

Установка этого параметра вне разрешенного диапазона значений заставляет сервер управления прерываться на запуске с ошибочной Ошибочной строкой number: Недопустимое значение value для параметра MaxNoOfExecutionThreads.

Для MaxNoOfExecutionThreads, значение 0 или 1 окружается внутренне NDB к 2, так, чтобы 2 считался значением по умолчанию этого параметра и минимальным значением.

MaxNoOfExecutionThreads обычно предназначается, чтобы быть установленным равный числу доступных потоков ЦП, и выделить много потоков каждого типа, подходящего для типичных рабочих нагрузок. Это не присваивает определенные потоки указанным ЦП. Для случаев, откуда это является требуемым, чтобы измениться настроек, если, или связывать потоки с ЦП, следует использовать ThreadConfig вместо этого, который позволяет Вам выделять каждый поток непосредственно требуемому типу, ЦП, или обоим.

Многопоточный процесс узла данных всегда порождает по крайней мере 5 потоков, перечисленных здесь:

NoOfFragmentLogParts

Определите номер групп файла журнала для журналов отката, принадлежащих этому ndbmtd. Значение должно быть даже многократно из 4 между 4 и 16, включительно.

ThreadConfig

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

ThreadConfig := entry[,entry[,...]]entry := type={param[,param[,...]]}type := ldm | main | recv | send | rep | ioparam := count=number | cpubind=cpu_list

Изогнутые фигурные скобки ({...}) окружение списка параметров требуется, даже если есть только один параметр в списке.

A param (параметр) определяет число потоков данного типа (count), ЦП, с которыми должны быть связаны потоки данного типа (cpubind), или оба.

type атрибут представляет тип потока NDB. Типы потока, поддерживаемые в MySQL Cluster NDB 7.3 и диапазоне разрешенных count значения для каждого обеспечиваются в следующем списке:

DiskPageBufferMemory

Это определяет количество пространства, использованного для того, чтобы кэшировать страницы на диске, и устанавливается в [ndbd] или [ndbd default] раздел config.ini файл. Это измеряется в байтах. Каждая страница приводит 32 Кбайта в рабочее состояние. Это означает, что Хранение данных Кластерного диска всегда использует N * память на 32 Кбайта, где N некоторое неотрицательное целое число.

Значение по умолчанию для этого параметра 64M (2000 страниц 32 Кбайт каждый).

Можно запросить ndbinfo.diskpagebuffer таблица, чтобы помочь определить, должно ли значение для этого параметра быть увеличено, чтобы минимизировать ненужный поиск на диске. См. Раздел 17.5.10.8," ndbinfo diskpagebuffer Таблица", для получения дополнительной информации.

SharedGlobalMemory

Этот параметр определяет объем памяти, который используется для буферов журнала, дисковые операции (такие как запросы страницы, и ожидайте очереди), и метаданные для табличных областей, групп файла журнала, UNDO файлы, и файлы данных. Совместно используемый глобальный пул памяти также обеспечивает память, используемую для того, чтобы она удовлетворила требования к памяти INITIAL_SIZE и UNDO_BUFFER_SIZE опции, используемые с CREATE LOGFILE GROUP и ALTER LOGFILE GROUP операторы, включая любое значение по умолчанию, подразумеваемое для этих опций установкой InitialLogFileGroup параметр конфигурации узла данных. SharedGlobalMemory может быть установлен в [ndbd] или [ndbd default] раздел config.ini конфигурационный файл, и измеряется в байтах.

Значение по умолчанию 128M.

DiskIOThreadPool

Этот параметр определяет число несвязанных потоков, используемых для Дискового доступа Файла данных. Прежде DiskIOThreadPool был представлен, точно один поток был порожден для каждого Дискового Файла данных, который мог привести к проблемам производительности, особенно при использовании очень больших файлов данных. С DiskIOThreadPool, Вы можете — например — получают доступ к единственному большому файлу данных, используя несколько потоков, работающих параллельно.

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

Оптимальное значение для этого параметра зависит от Ваших аппаратных средств и конфигурации, и включает эти факторы:

Значение по умолчанию для этого параметра 2.

Дисковые системные параметры Файла данных. Параметры в следующем списке позволяют поместить MySQL Cluster Disk Data files в определенные каталоги без потребности в использовании символьных ссылок.

Для получения дополнительной информации см. Раздел 17.5.12.1, "MySQL Cluster Disk Data Objects".

Дисковые параметры создания Объекта данных. Следующие два параметра позволяют Вам — запуская кластер впервые — заставить Дисковую группу файла журнала Данных, табличную область, или обоих, создаваться без использования SQL-операторов.

ExtraSendBufferMemory

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

TotalSendBufferMemory

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

Если эти параметры устанавливаются, его минимальное разрешенное значение составляет 256 Кбит; maxmimum 4294967039.

ReservedSendBufferMemory

Этот параметр присутствует в NDBCLUSTER исходный код, начинающийся с MySQL Cluster NDB 6.4.0. Однако, это в настоящий момент не включается.

Этот параметр осуждался в MySQL Cluster NDB 7.2, и подвергается удалению в будущем выпуске MySQL Cluster (Ошибка #11760629, Ошибка #53053).

RedoOverCommitCounter

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

RedoOverCommitCounter значения по умолчанию к 3. Установите это в 0, чтобы отключить предел.

RedoOverCommitLimit

Этот параметр устанавливает верхний предел в секундах для того, чтобы попытаться записать данный журнал отката в диск перед синхронизацией. Число раз узел данных пытается сбросить этот журнал отката, но занимает больше времени чем RedoOverCommitLimit, сохраняется и по сравнению с RedoOverCommitCounter, и когда сбрасывание берет слишком долго больше раз чем значение того параметра, прерываются любые транзакции, которые не фиксировались в результате тайм-аута сброса. Когда это происходит, узел API где любая из этих транзакций порожденные дескрипторы операции, составляющие те транзакции согласно DefaultOperationRedoProblemAction установка (это или очереди операции, которые будут повторены, или, прерывают их).

По умолчанию, RedoOverCommitLimit 20 секунд. Набор к 0, чтобы отключить проверку журнал отката сбрасывает тайм-ауты. Этот параметр был добавлен в MySQL Cluster NDB 7.1.10.