NodeId

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

NodeId — единственное поддерживаемое имя параметра для идентификации узлов данных. (Id был удален в NDB 7.5.0.)

ExecuteOnComputer

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

HostName

Указание этого параметра определяет имя хоста компьютера, на котором должен находиться узел данных. Используйте HostName для указания имени хоста, отличного от localhost.

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 предназначен главным образом для добавления новой группы узлов в работающий кластер NDB без необходимости выполнения постепенного перезапуска. Для этой цели следует установить его значение в 65536 (максимальное значение). Вам не требуется устанавливать значение NodeGroup для всех узлов данных кластера, только для тех узлов, которые должны быть запущены и добавлены в кластер в качестве новой группы узлов впоследствии. Дополнительную информацию см. в разделе 21.6.7.3, “Добавление узлов данных NDB Cluster онлайн: подробный пример”.

LocationDomainId

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

LocationDomainId принимает целое значение от 0 до 16 включительно, при этом 0 является значением по умолчанию; использование 0 эквивалентно отсутствию параметра.

NoOfReplicas

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

Группы узлов формируются неявно. Первая группа узлов формируется набором узлов данных с наименьшими идентификаторами узлов, следующая группа узлов — набором следующих по величине идентификаторов узлов и так далее. Например, предположим, что у нас есть 4 узла данных и что NoOfReplicas установлено в 2. Четыре узла данных имеют идентификаторы узлов 2, 3, 4 и 5. Тогда первая группа узлов формируется из узлов 2 и 3, а вторая группа узлов — из узлов 4 и 5. Важно настроить кластер таким образом, чтобы узлы в одной группе узлов не размещались на одном компьютере, так как отказ одного аппаратного обеспечения приведет к отказу всего кластера.

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

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

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

DataDir

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

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

FileSystemPath

Этот параметр указывает каталог, в котором размещаются все файлы, созданные для метаданных, журналов REDO, журналов UNDO (для таблиц данных на диске) и файлов данных. Значение по умолчанию — каталог, указанный параметром DataDir.

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

BackupDataDir

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

DataMemory

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

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

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

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

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

В NDB 7.6 ресурсы, выделенные для DataMemory, используются для хранения всех данных и индексов; любая память, сконфигурированная как IndexMemory, автоматически добавляется к той, что используется DataMemory, образуя общий пул ресурсов.

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

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

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

В NDB 7.5 (и более ранних версиях) значение по умолчанию для DataMemory составляет 80 МБ; в NDB 7.6 — 98 МБ. Минимальное значение — 1 МБ. Максимального размера нет, но на практике максимальный размер должен быть подобран таким образом, чтобы процесс не начал подкачку, когда достигнет предела. Этот предел определяется количеством доступной физической оперативной памяти на машине и количеством памяти, которое операционная система может задействовать для одного процесса. 32-битные операционные системы, как правило, ограничены 2−4 ГБ на процесс; 64-битные операционные системы могут использовать больше. Для больших баз данных по этой причине предпочтительнее использовать 64-битную операционную систему.

IndexMemory

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

В NDB 7.6.2 параметр IndexMemory устарел (и подлежит будущему удалению); любая память, выделенная для IndexMemory, вместо этого выделяется в тот же пул, что и DataMemory, который становится единственным ответственным за все ресурсы, необходимые для хранения данных и индексов в памяти. В NDB 7.6 использование IndexMemory в конфигурационном файле кластера генерирует предупреждение от сервера управления.

Вы можете оценить размер хеш-индекса, используя эту формулу:

  size  = ( (fragments * 32K) + (rows * 18) )
          * fragment_replicas

          

fragments — количество фрагментов, fragment_replicas — количество реплик фрагментов (обычно два), а rows — количество строк. Если таблица содержит один миллион строк, восемь фрагментов и две реплики фрагментов, ожидаемое использование памяти индекса рассчитывается, как показано здесь:

  ((8 * 32K) + (1000000 * 18)) * 2 = ((8 * 32768) + (1000000 * 18)) * 2
  = (262144 + 18000000) * 2
  = 18262144 * 2 = 36524288 bytes = ~35MB

Статистика индексов для упорядоченных индексов (если они включены) хранится в таблице mysql.ndb_index_stat_sample. Поскольку эта таблица имеет хеш-индекс, это добавляет к использованию памяти индекса. Верхнюю границу количества строк для данного упорядоченного индекса можно рассчитать следующим образом:

  sample_size= key_size + ((key_attributes + 1) * 4)

  sample_rows = IndexStatSaveSize
                * ((0.01 * IndexStatSaveScale * log2(rows * sample_size)) + 1)
                / sample_size

В приведенной формуле key_size — размер ключа упорядоченного индекса в байтах, key_attributes — количество атрибутов в ключе упорядоченного индекса, а rows — количество строк в базовой таблице.

Предположим, что таблица t1 содержит 1 миллион строк и упорядоченный индекс, названный ix1, по двум четырёхбайтным целым числам. Предположим также, что IndexStatSaveSize и IndexStatSaveScale установлены в их значения по умолчанию (32К и 100 соответственно). Используя предыдущие 2 формулы, мы можем вычислить следующее:

  sample_size = 8  + ((1 + 2) * 4) = 20 bytes

  sample_rows = 32K
                * ((0.01 * 100 * log2(1000000*20)) + 1)
                / 20
                = 32768 * ( (1 * ~16.811) +1) / 20
                = 32768 * ~17.811 / 20
                = ~29182 rows

Таким образом, ожидаемое использование памяти индекса составляет 2 * 18 * 29182 = ~1050550 байт.

До NDB 7.6 значение по умолчанию для IndexMemory составляет 18 МБ, а минимум — 1 МБ; в NDB 7.6 минимальное и значение по умолчанию для этого параметра — 0 (ноль). Это имеет последствия для понижающих обновлений с NDB 7.6 до более ранних версий NDB Cluster; см. Раздел 21.3.7, «Обновление и понижающее обновление NDB Cluster», для получения дополнительной информации.

StringMemory

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

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

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

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

BatchSizePerLocalScan

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

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

LongMessageBuffer

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

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

MaxFKBuildBatchSize

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

MaxNoOfConcurrentScans

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

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

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

MaxNoOfLocalScans

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

4 * MaxNoOfConcurrentScans * [# data nodes] + 2

Минимальное значение — 32.

MaxParallelCopyInstances

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

MaxParallelScansPerFragment

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

MaxReorgBuildBatchSize

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

MaxUIBuildBatchSize

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

FragmentLogFileSize

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

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

InitialNoOfOpenFiles

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

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

InitFragmentLogFiles

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

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

EnablePartialLcp

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

Если EnablePartialLcp отключено (false), каждая LCP использует только один файл и записывает полную контрольную точку; это требует минимального количества дискового пространства для LCP, но увеличивает нагрузку на запись для каждой LCP. Значение по умолчанию включено (true). Долю пространства, используемого частичными LCPS, можно изменить с помощью параметра для параметра конфигурации RecoveryWork.

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

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

LcpScanProgressTimeout

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

Значение по умолчанию — 60 секунд (обеспечивает совместимость с предыдущими выпусками). Установка этого параметра в 0 полностью отключает контроллер сканирования фрагмента LCP.

MaxNoOfOpenFiles

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

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

MaxNoOfSavedMessages

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

Значение по умолчанию равно 25, что устанавливает эти максимумы для 25 сообщений об ошибках и 25 файлов трассировки.

MaxLCPStartDelay

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

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

NoOfFragmentLogFiles

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

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

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

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

RecoveryWork

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

Меньшее значение для RecoveryWork означает:

Например, установка RecoveryWork на 60 означает, что общий размер LCP примерно в 1 + 0,6 = 1,6 раза больше размера данных, которые необходимо проверить. Это означает, что на 60% больше работы требуется на этапе восстановления перезапуска по сравнению с работой, выполняемой во время перезапуска, который использует полные контрольные точки. (Это более чем компенсируется на других этапах перезапуска, так что перезапуск в целом все еще быстрее при использовании частичных LCP, чем при использовании полных LCP.) Чтобы не заполнять журнал redo, необходимо писать в 1 + (1 / RecoveryWork) раз больше скорости изменения данных во время контрольных точек — таким образом, когда RecoveryWork = 60, необходимо писать примерно в 1 + (1 / 0,6) = 2,67 раза больше скорости изменения. Другими словами, если изменения записываются со скоростью 10 МБ в секунду, контрольная точка должна записываться примерно со скоростью 26,7 МБ в секунду.

Установка RecoveryWork = 40 означает, что требуется только 1,4 раза больше общего размера LCP (и, следовательно, фаза восстановления занимает на 10–15 процентов меньше времени. В этом случае скорость записи контрольной точки в 3,5 раза больше скорости изменения.

Дистрибутив исходного кода NDB включает в себя тестовую программу для моделирования LCP. lcp_simulator.cc можно найти в storage/ndb/src/kernel/blocks/backup/. Для компиляции и запуска на платформах Unix выполните показанные здесь команды:

$> gcc lcp_simulator.cc
$> ./a.out

Эта программа не имеет других зависимостей, кроме stdio.h, и не требует подключения к кластеру NDB или серверу MySQL. По умолчанию он моделирует 300 LCP (три набора по 100 LCP, каждый из которых состоит из вставок, обновлений и удалений по очереди), сообщая размер LCP после каждого из них. Вы можете изменить моделирование, изменив значения recovery_work, insert_work и delete_work в исходном коде и перекомпилировав его. Для получения дополнительной информации см. исходный код программы.

InsertRecoveryWork

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

EnableRedoControl

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

При включении EnableRedoControl позволяет узлам данных получить большую гибкость относительно скорости записи LCP на диск. Более конкретно, включение данного параметра означает, что можно использовать более высокие скорости записи, чтобы LCP завершились и журналы переигрывания были обрезаны быстрее, тем самым сокращая время восстановления и потребности в дисковом пространстве. Данная функция позволяет узлам данных эффективнее использовать более высокую скорость ввода-вывода и большую пропускную способность, доступные от современных устройств хранения на твердотельных накопителях и протоколах, таких как твердотельные накопители (SSD) с использованием NVMe (Non-Volatile Memory Express).

В настоящее время параметр по умолчанию равен false (выключен), поскольку NDB всё ещё широко используется на системах, в которых ввод-вывод или пропускная способность ограничены по сравнению с системами, использующими твердотельные технологии, например, с использованием обычных жёстких дисков (HDD). В таких настройках механизм EnableRedoControl может легко привести к насыщению подсистемы ввода-вывода, увеличивая время ожидания для ввода-вывода узла данных. В частности, это может вызвать проблемы с таблицами NDB Disk Data, у которых пространства таблиц или группы файлов журнала используют ограниченную подсистему ввода-вывода совместно с файлами LCP и журнала переигрывания узла данных; такие проблемы потенциально включают отказ узла или кластера из-за ошибок остановки GCP.

MaxNoOfAttributes

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

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

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

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

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

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

MaxNoOfTables

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

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

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

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

MaxNoOfOrderedIndexes

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

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

MaxNoOfUniqueHashIndexes

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

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

MaxNoOfTriggers

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

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

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

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

MaxNoOfSubscriptions

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

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

MaxNoOfSubscribers

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

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

Для получения дополнительной информации см. Раздел 21.7, «Репликация NDB Cluster».

MaxNoOfConcurrentSubOperations

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

CompressedLCP

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

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

На платформах Windows этот параметр не оказывает никакого влияния в NDB 7.5 или NDB 7.6.

CrashOnCorruptedTuple

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

Diskless

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

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

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

LateAlloc

Выделить память для этого узла данных после установления соединения с сервером управления. Включено по умолчанию.

LockPagesInMainMemory

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

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

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

ODirect

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

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

ODirectSyncFlag

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

Отключен по умолчанию.

RestartOnErrorInsert

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

Этот параметр отключён по умолчанию.

StopOnError

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

Значение параметра по умолчанию равно 1; это означает, что по умолчанию ошибка приводит к остановке процесса узла данных.

При возникновении ошибки и значении StopOnError равном 0, процесс узла данных перезапускается.

До версии NDB Cluster 7.5.5, если процесс узла данных завершается неуправляемым образом (например, из-за выполнения kill -9 на процессе узла данных во время выполнения запроса или из-за сегментационной ошибки), и StopOnError имеет значение 0, процесс ангела пытается перезапустить его таким же образом, как он был запущен ранее — то есть с использованием тех же параметров запуска, которые были использованы в последний раз при запуске узла. Таким образом, если процесс узла данных изначально запускался с использованием параметра --initial, он также перезапускается с параметром --initial. Это означает, что в таких случаях, если ошибка возникает на достаточном количестве узлов данных в очень короткий промежуток времени, эффект такой же, как при первоначальном перезапуске всего кластера, что приводит к потере всех данных. Эта проблема решена в NDB Cluster 7.5.5 и более поздних версиях NDB 7.5 (Ошибка #83510, Ошибка #24945638).

Пользователи MySQL Cluster Manager должны учесть, что, когда StopOnError равно 1, это предотвращает агент MySQL Cluster Manager от перезапуска узлов данных после выполнения собственного перезапуска и восстановления. См. Запуск и остановка агента в Linux для получения дополнительной информации.

UseShm

Использовать сокеты shared memory между этим узлом данных и узлом API, также работающим на этом хосте. Установить значение 1 для активации.

Смотрите Раздел 21.4.3.12, «Подключения NDB Cluster к общей памяти» для получения дополнительной информации.

TimeBetweenWatchDogCheck

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

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

Время ожидания по умолчанию составляет 6000 миллисекунд (6 секунд).

TimeBetweenWatchDogCheckInitial

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

Время ожидания по умолчанию составляет 6000 миллисекунд (6 секунд).

StartPartialTimeout

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

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

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

StartPartitionedTimeout

Если кластер готов к запуску после ожидания StartPartialTimeout миллисекунд, но, возможно, все еще находится в раздробленном состоянии, кластер ожидает, пока не истечет и это время ожидания. Если StartPartitionedTimeout установлено равным 0, кластер ожидает бесконечно (2³²−1 мс или приблизительно 49,71 дня).

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

Значение по умолчанию в NDB 7.6 равно 0; ранее оно было 60000 (60 секунд).

StartFailureTimeout

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

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

StartNoNodeGroupTimeout

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

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

Дополнительную информацию см. в разделе 21.6.7, «Добавление узлов данных кластера NDB в режиме онлайн».

HeartbeatIntervalDbDb

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

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

Интервал «сердцебиения» по умолчанию составляет 5000 миллисекунд (5 секунд). Этот параметр не должен резко изменяться и не должен сильно отличаться между узлами. Если один узел использует 5000 миллисекунд, а узел, наблюдающий за ним, использует 1000 миллисекунд, очевидно, что узел объявляется неработоспособным очень быстро. Этот параметр можно изменить во время онлайн-обновления программного обеспечения, но только с небольшими приращениями.

См. также сетевое взаимодействие и задержки, а также описание параметра конфигурации ConnectCheckIntervalDelay.

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 объявляет узел A мертвым, а узел C объявляет узел B мертвым. В результате теряется группа узлов 0, и кластер выходит из строя. С другой стороны, если порядок передачи — A->B->D->C->A (и все остальные условия остаются такими же, как и ранее), потеря сердечного удара приводит к объявлению узлов A и D мертвыми; в этом случае каждая группа узлов имеет по одному выжившему узлу, и кластер сохраняется.

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

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

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

ConnectCheckIntervalDelay

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

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

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

TimeBetweenLocalCheckpoints

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

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

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

TimeBetweenGlobalCheckpoints

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

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

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

TimeBetweenGlobalCheckpointsTimeout

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

TimeBetweenEpochs

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

TimeBetweenEpochs является частью реализации “micro-GCPs”, которая может использоваться для повышения производительности репликации NDB Cluster.

TimeBetweenEpochsTimeout

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

TimeBetweenEpochsTimeout является частью реализации “micro-GCPs”, которая может использоваться для повышения производительности репликации NDB Cluster.

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

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

MaxBufferedEpochs

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

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

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

MaxBufferedEpochBytes

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

TimeBetweenInactiveTransactionAbortCheck

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

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

TransactionInactiveTimeout

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

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

TransactionDeadlockDetectionTimeout

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

Отсутствие ответа может произойти по любой из следующих причин:

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

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

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

DiskSyncSize

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

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

MaxDiskWriteSpeed

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

Для установки максимальной скорости записи на диск, разрешенной во время перезапуска этого узла данных, используйте MaxDiskWriteSpeedOwnRestart. Для установки максимальной скорости записи на диск, разрешенной во время перезапуска других узлов данных, используйте MaxDiskWriteSpeedOtherNodeRestart. Минимальную скорость записи на диск всеми LCP и операциями резервного копирования можно настроить, установив MinDiskWriteSpeed.

MaxDiskWriteSpeedOtherNodeRestart

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

Для установки максимальной скорости записи на диск, разрешенной во время перезапуска этого узла данных, используйте MaxDiskWriteSpeedOwnRestart. Для установки максимальной скорости записи на диск, разрешенной, когда ни один узел данных нигде в кластере не перезапускается, используйте MaxDiskWriteSpeed. Минимальную скорость записи на диск всеми LCP и операциями резервного копирования можно настроить, установив MinDiskWriteSpeed.

MaxDiskWriteSpeedOwnRestart

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

Для установки максимальной скорости записи на диск, разрешенной во время перезапуска других узлов данных, используйте MaxDiskWriteSpeedOtherNodeRestart. Для установки максимальной скорости записи на диск, разрешенной, когда ни один узел данных нигде в кластере не перезапускается, используйте MaxDiskWriteSpeed. Минимальную скорость записи на диск всеми LCP и операциями резервного копирования можно настроить, установив MinDiskWriteSpeed.

MinDiskWriteSpeed

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

Максимальные скорости записи на диск для LCP и резервного копирования в различных условиях можно настроить с помощью параметров MaxDiskWriteSpeed, MaxDiskWriteSpeedOwnRestart и MaxDiskWriteSpeedOtherNodeRestart. См. описания этих параметров для получения дополнительной информации.

ArbitrationTimeout

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

Значение по умолчанию составляет 7500 миллисекунд (7,5 секунд).

Arbitration

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

RestartSubscriberConnectTimeout

Этот параметр определяет время, в течение которого узел данных ожидает подключения подписывающихся API-узлов. После истечения этого таймаута любые «отсутствующие» API-узлы отключаются от кластера. Для отключения этого таймаута установите RestartSubscriberConnectTimeout в 0.

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

LogLevelStartup

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

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

LogLevelShutdown

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

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

LogLevelStatistic

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

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

LogLevelCheckpoint

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

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

LogLevelNodeRestart

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

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

LogLevelConnection

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

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

LogLevelError

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

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

LogLevelCongestion

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

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

LogLevelInfo

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

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

MemReportFrequency

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

Использование памяти данных и индексной памяти каждого узла данных регистрируется как в процентах, так и в количестве страниц по 32 КБ DataMemory и (NDB 7.5 и ранее) 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%), как упоминалось в обсуждении статистических событий в разделе 21.6.3.2, «События журнала кластера NDB».

StartupStatusReportFrequency

При запуске узла данных с --initial, он инициализирует файл журнала повторения во время фазы запуска 4 (см. раздел 21.6.4, «Обзор фаз запуска кластера NDB»). При установке очень больших значений для 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: 15557
2009-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, страницы отправляются на диск. Во время записи данных на диск процесс резервного копирования может продолжать заполнять этот буфер до тех пор, пока не закончится место. В этом случае процесс резервного копирования приостанавливает сканирование и ожидает завершения некоторых записей на диск, освобождая память для продолжения сканирования.

BackupDiskWriteSpeedPct

Во время нормальной работы узлы данных пытаются максимизировать скорость записи на диск, используемую для локальных контрольных точек и резервных копий, оставаясь в пределах границ, установленных параметрами MinDiskWriteSpeed и MaxDiskWriteSpeed. Сброс скорости записи на диск обеспечивает каждому потоку LDM равную долю общего бюджета. Это позволяет параллельным LCP осуществлять свою работу без превышения бюджета ввода-вывода на диске. Поскольку резервное копирование выполняется только одним потоком LDM, это эффективно приводит к сокращению бюджета, что приводит к более длительному времени завершения резервного копирования, а в случае достаточно высокой скорости изменения — к невозможности завершения резервного копирования, когда скорость заполнения буфера журнала резервного копирования выше достижимой скорости записи.

Эту проблему можно решить, используя параметр конфигурации BackupDiskWriteSpeedPct, который принимает значение в диапазоне 0-90 (включительно), которое интерпретируется как процент от максимального бюджета скорости записи узла, резервируемого перед распределением остальной части бюджета между потоками LDM для LCP. Поток LDM, выполняющий резервное копирование, получает весь бюджет скорости записи для резервного копирования, плюс свою (уменьшенную) долю бюджета скорости записи для локальных контрольных точек. (Это делает бюджет скорости записи на диск аналогичным тому, как он обрабатывался в NDB Cluster 7.3 и более ранних версиях.)

Значение по умолчанию для этого параметра составляет 50 (интерпретируется как 50%).

BackupLogBufferSize

Буфер журнала резервной копии выполняет роль, аналогичную роли буфера данных резервной копии, за исключением того, что он используется для создания журнала всех записей таблиц, выполненных во время выполнения резервного копирования. Те же принципы применяются для записи этих страниц, что и для буфера данных резервной копии, за исключением того, что при отсутствии места в буфере журнала резервной копии резервное копирование завершается неудачей. По этой причине размер буфера журнала резервной копии должен быть достаточно большим, чтобы справиться с нагрузкой, вызванной операциями записи во время создания резервной копии. См. Раздел 21.6.8.3, “Настройка резервного копирования NDB Cluster”.

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

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

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

BackupMemory

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

BackupReportFrequency

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

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

BackupWriteSize

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

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

BackupMaxWriteSize

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

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

CompressedBackup

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

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

BuildIndexThreads

Этот параметр определяет количество потоков, создаваемых при перестроении упорядоченных индексов во время запуска системы или узла, а также при выполнении ndb_restore --rebuild-indexes. Он поддерживается только в том случае, если для таблицы на каждом узле данных имеется более одного фрагмента (например, когда COMMENT="NDB_TABLE=PARTITION_BALANCE=FOR_RA_BY_LDM_X_2" используется с CREATE TABLE).

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

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

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

LockExecuteThreadToCPU

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

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

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

LockMaintThreadsToCPU

Этот параметр указывает идентификатор ЦП, назначенный для обработки потоков обслуживания NDBCLUSTER.

Значение этого параметра представляет собой целое число в диапазоне от 0 до 65535 (включительно). Значение по умолчанию отсутствует.

Numa

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

Установка Numa = 0 означает, что сам процесс узла данных не пытается установить политику распределения памяти и позволяет определить это поведение операционной системе, которая может быть дополнительно настроена с помощью отдельного инструмента numactl. То есть, Numa = 0 обеспечивает поведение по умолчанию системы, которое может быть настроено с помощью numactl. Для многих систем Linux поведение по умолчанию системы заключается в распределении локальной памяти сокета любому заданному процессу во время распределения. Это может быть проблематично при использовании ndbmtd; это связано с тем, что nbdmtd распределяет всю память при запуске, что приводит к дисбалансу, обеспечивая разные скорости доступа для разных сокетов, особенно при блокировке страниц в основной памяти.

Установка Numa = 1 означает, что процесс узла данных использует libnuma для запроса чередующегося распределения памяти. (Этого также можно добиться вручную, на уровне операционной системы, используя numactl.) Использование чередующегося распределения по сути говорит процессу узла данных игнорировать неравномерный доступ к памяти, но не пытается использовать быструю локальную память; вместо этого процесс узла данных пытается избежать дисбаланса из-за медленной удаленной памяти. Если чередующееся распределение нежелательно, установите Numa в 0, чтобы желаемое поведение можно было определить на уровне операционной системы.

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

RealtimeScheduler

Установка этого параметра в 1 включает планирование в реальном времени потоков узла данных.

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

SchedulerExecutionTimer

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

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

SchedulerResponsiveness

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

SchedulerSpinTimer

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

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

TwoPassInitialNodeRestartCopy

Многопоточное построение упорядоченных индексов может быть включено для начального перезапуска узлов данных, установив этот параметр конфигурации в true, что включает двухэтапную копию данных во время начального перезапуска узлов. В NDB 7.6 это значение по умолчанию (Ошибка #26704312, Ошибка #27109117).

Также необходимо установить BuildIndexThreads на ненулевое значение.

MaxSendDelay

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

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

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

NoOfFragmentLogParts

Установите количество групп файлов журнала для журналов redo, принадлежащих этому ndbmtd. Это значение должно быть равно количеству потоков LDM, используемых ndbmtd, как определено значением параметра MaxNoOfExecutionThreads. Начиная с NDB 7.5.7, конфигурация с более чем 4 журналами redo на поток LDM запрещена. (Ошибка #25333414)

См. описание параметра MaxNoOfExecutionThreads для получения дополнительной информации.

DiskPageBufferEntries

Это количество записей страниц (ссылок на страницы) для выделения. Оно задаётся как количество 32К страниц в DiskPageBufferMemory. Значение по умолчанию достаточно для большинства случаев, но может потребоваться увеличить это значение, если возникают проблемы с очень большими транзакциями в таблицах Disk Data. Каждая запись страницы требует примерно 100 байт.

DiskPageBufferMemory

Это определяет объём памяти, используемой для кэширования страниц на диске, и настраивается в разделе [ndbd] или [ndbd default] файла конфигурации config.ini. Измеряется в байтах. Каждая страница занимает 32 КБ. Это означает, что хранилище Disk Data NDB Cluster всегда использует N * 32 КБ памяти, где N — некоторое неотрицательное целое число.

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

Если значение DiskPageBufferMemory установлено слишком низко в сочетании с использованием большего, чем по умолчанию, числа потоков LDM в ThreadConfig (например, {ldm=6...}), могут возникнуть проблемы при попытке добавления большого (например, 500Гб) файла данных в таблицу Disk Data на основе диска, где процесс длится бесконечно, занимая один из ядер процессора.

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

Вы можете запросить таблицу ndbinfo.diskpagebuffer, чтобы определить, следует ли увеличить значение этого параметра для минимизации ненужных обращений к диску. Более подробная информация содержится в Разделе 21.6.15.20 «Таблица ndbinfo diskpagebuffer».

SharedGlobalMemory

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

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

DiskIOThreadPool

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

Этот параметр применяется только к потокам ввода-вывода Disk Data.

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

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

Параметры файловой системы для данных на диске. Параметры в следующем списке позволяют размещать файлы NDB Cluster Disk Data в определённых директориях без использования символических ссылок.

Более подробную информацию см. в разделе 21.6.11.1, «Объекты NDB Cluster Disk Data».

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