NodeId

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

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

ExecuteOnComputer

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

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

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 для всех узлов данных кластера, только для тех узлов, которые будут запущены и добавлены в кластер как новая группа узлов в более позднее время. Более подробная информация в Разделе 25.6.7.3, «Добавление узлов данных кластера NDB онлайн: подробный пример».

LocationDomainId

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

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

NoOfReplicas

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

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

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

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

Количество узлов данных в кластере должно быть четно делимо на значение этого параметра. Например, если есть два узла данных, то 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

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

BatchSizePerLocalScan

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

Устарело.

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

LongMessageBuffer

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

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

MaxFKBuildBatchSize

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

MaxNoOfConcurrentScans

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

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

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

MaxNoOfLocalScans

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

4 * MaxNoOfConcurrentScans * [# data nodes] + 2

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

MaxParallelCopyInstances

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

MaxParallelScansPerFragment

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

MaxReorgBuildBatchSize

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

MaxUIBuildBatchSize

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

FragmentLogFileSize

Установка этого параметра позволяет напрямую управлять размером файлов журнала redo. Это может быть полезно в ситуациях, когда NDB Cluster работает под высокой нагрузкой и не может достаточно быстро закрыть файлы журнала фрагментов, прежде чем попытаться открыть новые (одновременно может быть открыто только 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.

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

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

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

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

RecoveryWork

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

Более низкое значение для 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 имеет значение true, то есть только при включённых частичных локальных контрольных точках.

EnableRedoControl

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

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

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

MaxNoOfAttributes

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

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

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

При установке MaxNoOfAttributes важно заранее подготовиться к любым операциям ALTER TABLE, которые вы можете захотеть выполнить в будущем. Это связано с тем, что во время выполнения операции ALTER TABLE над таблицей кластера используется в три раза больше атрибутов, чем в исходной таблице, и хорошей практикой является разрешение в два раза большего количества. Например, если таблица 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. Для некоторых приложений NDB API может быть необходимо или желательно изменить этот параметр. Однако для нормального использования с серверами MySQL, действующими как узлы SQL, это не нужно.

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

MaxNoOfSubscribers

Этот параметр представляет интерес только при использовании репликации NDB Cluster. Значение по умолчанию равно 0. Оно обрабатывается как 2 * MaxNoOfTables + 2 * [number of API nodes]. Существует одна подписка на каждую NDB таблицу для каждого из двух серверов MySQL (один — источник репликации, другой — реплика). Каждый подписчик использует 16 байт памяти.

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

Дополнительную информацию см. в разделе 25.7, “Репликация NDB Cluster”.

MaxNoOfConcurrentSubOperations

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

CompressedLCP

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

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

CrashOnCorruptedTuple

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

Diskless

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

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

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

EncryptedFileSystem

Шифрование файлов LCP и табличного пространства, включая журналы отката и журналы переписывания. Отключено по умолчанию (0); установите в 1, чтобы включить.

Дополнительную информацию см. в Разделе 25.6.14, «Шифрование файловой системы для NDB Cluster».

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. Настройка этого параметра игнорируется, если выполняется хотя бы одно из следующих условий:

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

RequireCertificate

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

RequireTls

Если этот параметр установлен в true, соединения с этим узлом данных должны быть аутентифицированы с использованием TLS.

RestartOnErrorInsert

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

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

StopOnError

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

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

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

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

UseShm

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

TimeBetweenWatchDogCheck

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

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

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

TimeBetweenWatchDogCheckInitial

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

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

StartPartialTimeout

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

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

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

StartPartitionedTimeout

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

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

StartFailureTimeout

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

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

StartNoNodeGroupTimeout

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

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

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

HeartbeatIntervalDbDb

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

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

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

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

HeartbeatIntervalDbApi

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

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

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

HeartbeatOrder

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

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

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

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

Предположим, что сигналы о работоспособности передаются в порядке 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

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

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

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

TimeBetweenGlobalCheckpoints

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

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

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

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

TimeBetweenGlobalCheckpointsTimeout

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

TimeBetweenEpochs

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

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

TimeBetweenEpochsTimeout

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

TimeBetweenEpochsTimeout является частью реализации “микро-GCP”, которые могут быть использованы для повышения производительности репликации 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 позволяет выбрать схему арбитража, соответствующую одному из трёх возможных значений:

LogLevelStartup

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

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

LogLevelShutdown

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

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

LogLevelStatistic

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

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

LogLevelCheckpoint

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

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

LogLevelNodeRestart

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

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

LogLevelConnection

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

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

LogLevelError

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

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

LogLevelCongestion

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

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

LogLevelInfo

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

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

MemReportFrequency

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

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

StartupStatusReportFrequency

При запуске узла данных с помощью --initial, он инициализирует файл журнала redo во время Фазы запуска 4 (см. Раздел 25.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 (по умолчанию), тогда отчеты записываются в журнал кластера только в начале и в конце процесса инициализации файла журнала redo.

BackupDataBufferSize

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

Значение по умолчанию для этого параметра равно 16 МБ. Минимальное значение - 512 КБ.

BackupDiskWriteSpeedPct

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

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

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

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

BackupLogBufferSize

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

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

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

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

BackupMemory

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

BackupReportFrequency

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

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

BackupWriteSize

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

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

BackupMaxWriteSize

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

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

CompressedBackup

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

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

RequireEncryptedBackup

Если значение установлено в 1, резервные копии должны быть зашифрованы. Хотя можно установить этот параметр для каждого узла данных индивидуально, рекомендуется установить его в разделе [ndbd default] файла глобальной конфигурации config.ini. Дополнительную информацию о выполнении зашифрованных резервных копий см. в Разделе 25.6.8.2, «Использование клиента управления кластером NDB для создания резервной копии».

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

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

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

LockMaintThreadsToCPU

Этот параметр указывает ID ЦП, назначенного для обработки потоков обслуживания 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

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

SchedulerSpinTimer

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

SpinMethod

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

Параметры вращения, изменённые параметром SpinMethod, описаны в следующем списке:

На платформах, не имеющих полезных инструкций вращения, таких как PowerPC и некоторые платформы SPARC, время вращения устанавливается в 0 во всех ситуациях, а значения для SpinMethod, отличные от StaticSpinning, игнорируются.

TwoPassInitialNodeRestartCopy

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

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

AutomaticThreadConfig

При установке в 1, включает автоматическую настройку потоков, используя количество доступных процессоров для узла данных, учитывая любые ограничения, установленные taskset, numactl, виртуальными машинами, Docker и другими средствами управления доступными процессорами для данного приложения (в платформах Windows автоматическая настройка потоков использует все активные процессоры); в качестве альтернативы, вы можете установить NumCPUs до необходимого количества процессоров (до 1024, максимальное количество процессоров, которое может обрабатывать автоматическая настройка потоков). Любые настройки для ThreadConfig и MaxNoOfExecutionThreads будут игнорироваться. Кроме того, включение этого параметра автоматически отключает ClassicFragmentation.

ClassicFragmentation

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

Для новых кластеров, установка ClassicFragmentation в false при первой настройке кластера предпочтительнее; это приводит к количеству партиций на узел, равному значению PartitionsPerNode, гарантируя равномерное распределение партиций между всеми LDM.

Этот параметр и AutomaticThreadConfig являются взаимоисключающими; включение AutomaticThreadConfig автоматически отключает ClassicFragmentation.

EnableMultithreadedBackup

Включает многопоточный бэкап. Если каждый узел данных имеет как минимум 2 LDM, все потоки LDM участвуют в бэкапе, который создаётся с использованием одной поддиректории на поток LDM, и каждая поддиректория содержит файлы бэкапа .ctl, .Data и .log.

Этот параметр обычно включен (установлен в 1) для ndbmtd. Чтобы принудительно выполнить однопоточный бэкап, который можно легко восстановить с помощью более старых версий ndb_restore, отключите многопоточный бэкап, установив этот параметр в 0. Это необходимо сделать для каждого узла данных в кластере.

См. Раздел 25.6.8.5, «Выполнение бэкапа NDB с параллельными узлами данных», для получения дополнительной информации.

MaxSendDelay

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

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

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

NoOfFragmentLogParts

Установите количество групп файлов журнала для журналов отката, относящихся к этому ndbmtd. Значение этого параметра должно быть равно количеству потоков LDM, используемых ndbmtd, как определено значением MaxNoOfExecutionThreads. Конфигурация с более чем 4 группами журналов отката на поток LDM запрещена.

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

NumCPUs

Принудительно использовать только указанное количество ЦП для автоматической настройки потоков. Не имеет эффекта, если AutomaticThreadConfig не включен.

PartitionsPerNode

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

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

Если ClassicFragmentation включен, любое значение для этого параметра игнорируется. (Помните, что включение AutomaticThreadConfig отключает ClassicFragmentation.)

DiskPageBufferEntries

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

DiskPageBufferMemory

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

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

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

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

SharedGlobalMemory

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

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

DiskIOThreadPool

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

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

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

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

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

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

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

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