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

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

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

Если вы используете таблицы Disk Data, понижение версии с любой версии NDB 7.6 — независимо от статуса выпуска — до любой версии NDB 7.5 или более ранней требует перезапуска всех узлов данных с --initial в рамках процесса понижения версии. Это связано с тем, что NDB 7.5 и более ранние версии не могут читать новый формат файлов таблиц Disk Data.

Дополнительную информацию см. в Разделе 21.3.7, «Обновление и понижение версии NDB Cluster».

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

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

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

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

Кроме того, узлы данных теперь генерируют события MemoryUsage (см. Раздел 21.6.3.2, «События журнала NDB Cluster») и записывают соответствующие сообщения в журнал кластера, когда использование ресурсов достигает 99%, а также, как и прежде, 80%, 90% или 100%.

Другие связанные изменения перечислены здесь:

Процессы ndbinfo и таблицы config_nodes. NDB 7.6 добавляет две таблицы в базу данных информации ndbinfo для предоставления информации об узлах кластера; эти таблицы перечислены здесь:

Имя системы. Имя системы NDB кластера может использоваться для идентификации конкретного кластера. В NDB 7.6 MySQL Server отображает это имя как значение переменной состояния Ndb_system_name; приложения NDB API могут использовать метод , добавленный в том же выпуске.

Имя системы, основанное на времени запуска сервера управления, генерируется автоматически; вы можете переопределить это значение, добавив раздел [system] в файл конфигурации кластера и установив параметр Name в нужное значение в этом разделе до запуска сервера управления.

Инструмент импорта CSV ndb_import. ndb_import, добавленный в NDB Cluster 7.6, загружает данные в формате CSV непосредственно в таблицу NDB с использованием NDB API (сервер MySQL нужен только для создания таблицы и базы данных, в которой она находится). ndb_import можно рассматривать как аналог mysqlimport или SQL-команды LOAD DATA, и поддерживает многие такие же или похожие параметры для форматирования данных.

Предполагая, что база данных и целевая таблица NDB существуют, ndb_import нуждается только в подключении к серверу управления кластера (ndb_mgmd) для выполнения импорта; по этой причине должно быть доступно место [api] для инструмента в файле config.ini кластера.

Дополнительную информацию см. в Разделе 21.5.14, «ndb_import — Импорт данных CSV в NDB».

Инструмент мониторинга ndb_top. Добавлена утилита ndb_top, которая отображает информацию о загрузке и использовании ЦП для узла данных NDB в режиме реального времени. Данная информация может быть представлена в текстовом формате, в виде ASCII-графика или в обоих форматах. График может быть показан в цвете или в оттенках серого.

ndb_top подключается к узлу SQL NDB Cluster (то есть к MySQL Server). По этой причине программе необходимо подключиться как пользователю MySQL с правом SELECT на таблицы в базе данных ndbinfo.

Утилита ndb_top доступна для платформ Linux, Solaris и macOS, но в настоящее время недоступна для платформ Windows.

Для получения дополнительной информации см. Раздел 21.5.29, «ndb_top — Просмотр информации об использовании ЦП для потоков NDB».

Очистка кода. Значительное количество отладочных сообщений и выводов, не необходимых для нормальной работы, было перенесено в код, используемый только при тестировании или отладке NDB, или полностью удалено. Это удаление накладных расходов должно привести к заметному улучшению производительности потоков LDM и TC в некоторых случаях на порядок 10%.

Улучшения потоков LDM и LCP. Ранее, когда поток локального управления данными испытывал задержки ввода-вывода, он медленнее записывал в локальные контрольные точки. Это могло произойти, например, при перегрузке диска. Возникали проблемы, потому что другие потоки LDM не всегда замечали это состояние или не поступали аналогично. NDB теперь отслеживает режим задержек ввода-вывода глобально, поэтому это состояние сообщается, как только по крайней мере один поток записывает в режиме задержек ввода-вывода; затем он гарантирует, что сниженная скорость записи для этого LCP будет применена ко всем потокам LDM на период замедления. Поскольку снижение скорости записи теперь наблюдается другими экземплярами LDM, общая емкость увеличивается; это позволяет преодолевать перегрузку диска (или другое состояние, вызывающее задержки ввода-вывода) быстрее, чем раньше.

Идентификация ошибок NDB. Сообщения об ошибках и информацию можно получить с помощью клиента mysql в NDB 7.6 из новой таблицы error_messages в базе данных информации ndbinfo. Кроме того, NDB 7.6 представляет новый командный клиент ndb_perror для получения информации из кодов ошибок NDB; он заменяет использование perror с --ndb, который теперь устарел и может быть удален в будущих релизах.

Для получения дополнительной информации см. Раздел 21.6.15.21, «Таблица ndbinfo error_messages» и Раздел 21.5.17, «ndb_perror — Получение информации о сообщениях об ошибках NDB».

Улучшения SPJ. При выполнении сканирования в качестве присоединенного соединения (то есть, корень запроса является сканированием), блок DBTC отправляет запрос SPJ в экземпляр DBSPJ на том же узле, что и фрагмент для сканирования. Раньше такой запрос отправлялся для каждого из фрагментов узла. Поскольку число экземпляров DBTC и DBSPJ обычно устанавливается меньше, чем число экземпляров LDM, это означает, что все экземпляры SPJ были вовлечены в выполнение одного запроса, и, на самом деле, некоторые экземпляры SPJ могли (и получали) несколько запросов от одного и того же запроса. NDB 7.6 позволяет одному запросу SPJ обрабатывать набор фрагментов корня для сканирования, так что только один запрос SPJ (SCAN_FRAGREQ) должен быть отправлен любому данному экземпляру SPJ (DBSPJ блок) на каждом узле.

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

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

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

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

Блокировка ЦП для потоков создания офлайн-индексов. В NDB 7.6 создание офлайн-индексов по умолчанию использует все доступные ядра для ndbmtd, вместо ограничения одним ядром, зарезервированным для потока ввода-вывода. Также становится возможным указать желаемый набор ядер для использования потоками ввода-вывода при выполнении офлайн-многопоточных построений упорядоченных индексов. Это может улучшить время перезапуска и восстановления, а также производительность и доступность.

Это улучшение включает несколько связанных изменений. Первое из них – изменение значения по умолчанию для параметра конфигурации BuildIndexThreads (с 0 до 128), означает, что офлайн-построения упорядоченных индексов теперь выполняются многопоточно по умолчанию. Значение по умолчанию для TwoPassInitialNodeRestartCopy также изменено (с false на true), так что начальный перезапуск узла сначала копирует все данные без создания индексов с «живого» узла на узел, который запускается, создает упорядоченные индексы офлайн после копирования данных, а затем снова синхронизируется с живым узлом; это может значительно сократить время, необходимое для создания индексов. Кроме того, для обеспечения явной блокировки потоков создания офлайн-индексов на конкретных ЦПУ определен новый тип потоков (idxbld) для параметра конфигурации ThreadConfig.

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

NDB 7.6 также представляет параметр nosend для ThreadCOnfig. Установив его в 1, можно предотвратить участие потоков main, ldm, rep или tc в помощи потокам отправки. Этот параметр по умолчанию равен 0 и не может использоваться с потоками ввода-вывода, потоками отправки, потоками создания индексов или потоками-сторожами.

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

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

Для каждого из перечисленных параметров значение по умолчанию составляет 64, минимальное значение — 16, а максимальное — 512.

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

Частичные LCP. NDB 7.6 реализует частичные локальные контрольные точки. Раньше LCP всегда создавал копию всей базы данных. При работе с терабайтами данных этот процесс мог потребовать значительного времени с негативным влиянием на перезапуск узлов и кластера, а также на большее пространство для журналов redo. Теперь для LCP больше не строго необходимо делать это — вместо этого LCP теперь по умолчанию сохраняет только определенное количество записей, которое основано на количестве измененных данных с момента предыдущего LCP. Это может варьироваться от полной контрольной точки до контрольной точки, которая ничего не изменяет. В случае, если контрольная точка отражает какие-либо изменения, минимум — запись одной части из 2048, составляющих локальную LCP.

В рамках этого изменения в данном релизе введены два новых параметра конфигурации узла данных: EnablePartialLcp (значение по умолчанию true, или включено) включает частичные LCP. RecoveryWork управляет процентом пространства, отводимого для LCP; он увеличивается с объемом работы, которая должна быть выполнена для LCP во время перезапусков по сравнению с той, что выполняется во время нормальной работы. Повышение этого значения приводит к тому, что LCP во время нормальной работы требуют записи меньшего количества записей, и, таким образом, уменьшается обычная рабочая нагрузка. Повышение этого значения также означает, что перезапуск может занять больше времени.

Вы должны явно отключить частичные LCP, установив EnablePartialLcp=false. Это использует наименьшее количество места на диске, но также имеет тенденцию максимизировать рабочую нагрузку на запись для LCP. Для оптимизации наименьшей рабочей нагрузки на LCP во время нормальной работы используйте EnablePartialLcp=true и RecoveryWork=100. Для использования наименьшего места на диске для частичных LCP, но с ограниченными записями, используйте EnablePartialLcp=true и RecoveryWork=25, что является минимумом для RecoveryWork. Значение по умолчанию — EnablePartialLcp=true с RecoveryWork=50, что означает, что файлы LCP требуют примерно в 1,5 раза больше DataMemory; использование CompressedLcp=1 может ещё больше уменьшить это вдвое. Время восстановления с использованием значений по умолчанию должно быть значительно быстрее, чем при установке EnablePartialLcp на false.

Кроме того, параметры конфигурации узла данных BackupDataBufferSize, BackupWriteSize и BackupMaxWriteSize теперь устарели и могут быть удалены в будущих релизах MySQL NDB Cluster.

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

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

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

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

Некоторые типы записей по-прежнему обрабатываются последовательно: UNDO_LCP, UNDO_LCP_FIRST, UNDO_LOCAL_LCP, UNDO_LOCAL_LCP_FIRST, UNDO_DROP и UNDO_END.

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

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

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

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

Транспортер общей памяти. Пользовательские соединения с общей памятью (SHM) между узлом данных и узлом API на одном и том же компьютере полностью поддерживаются в NDB 7.6 и больше не считаются экспериментальными. Вы можете включить явное соединение с общей памятью, установив параметр конфигурации UseShm на 1 для соответствующего узла данных. При явном определении соединения с общей памятью также необходимо, чтобы и узел данных, и узел API были идентифицированы по HostName.

Производительность соединений SHM можно улучшить, настроив параметры, такие как ShmSize, ShmSpintime и SendBufferMemory в разделе [shm] или [shm default] файла конфигурации кластера (config.ini). Конфигурация SHM в остальном аналогична конфигурации транспортера TCP.

Параметр SigNum не используется в новой реализации SHM, и любые настройки для него игнорируются. Раздел 21.4.3.12, «Соединения NDB Cluster с общей памятью» содержит дополнительную информацию об этих параметрах. Кроме того, в рамках этой работы был удален код NDB, относящийся к старому транспортеру SCI.

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

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

Рассмотрим запрос соединения, где pk является первичным ключом таблиц t2, t3 и t4, а столбцы x, y и z — столбцы без индексов:

SELECT * FROM t1
  JOIN t2 ON t2.pk = t1.x
  JOIN t3 ON t3.pk = t1.y
  JOIN t4 ON t4.pk = t1.z;

Ранее это приводило к запросу SPJ, включающему сканирование таблицы t1 и поиск в каждой из таблиц t2, t3 и t4; эти запросы оценивались для каждой строки, возвращаемой из t1. Для этих запросов SPJ создавал запросы LQHKEYREQ для таблиц t2, t3 и t4. Теперь SPJ учитывает требование, что для получения любых строк результатов внутреннее соединение должно найти совпадение во всех объединённых таблицах; как только совпадение не будет найдено для одной из таблиц, все дальнейшие запросы к таблицам с тем же родителем или таблицами будут пропущены.

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

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

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

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

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

Повышение уровня также влияет на увеличение вычисленной целевой скорости контрольной точки.

Контроль LCP имеет следующие преимущества для установок NDB:

Параметры ndb_restore. Начиная с NDB 7.6.9, параметры --nodeid и --backupid являются обязательными при вызове ndb_restore.

Восстановление по частям. Начиная с NDB 7.6.13, можно разделить резервную копию на примерно равные части (части) и восстановить эти части параллельно, используя два новых параметра, реализованных для ndb_restore:

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

Для получения дополнительной информации см. описание параметра ndb_restore --num-slices.

ndb_restore: изменения схемы первичного ключа. NDB 7.6.14 (и более поздние версии) поддерживает различные определения первичного ключа для исходных и целевых таблиц при восстановлении резервной копии NDB с помощью ndb_restore, когда она запускается с параметром --allow-pk-changes. Поддерживается как увеличение, так и уменьшение количества столбцов, составляющих исходный первичный ключ.

Когда первичный ключ расширяется дополнительным столбцом или столбцами, все добавленные столбцы должны быть определены как NOT NULL, и значения в таких столбцах не могут быть изменены в период создания резервной копии. Поскольку некоторые приложения устанавливают все значения столбцов в строке при обновлении, независимо от того, были ли фактически изменены все значения, это может привести к сбою операции восстановления, даже если значения в столбце, добавляемом в первичный ключ, не изменились. Вы можете обойти это поведение, используя параметр --ignore-extended-pk-updates, также добавленный в NDB 7.6.14; в этом случае необходимо убедиться, что такие значения не меняются.

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

Дополнительную информацию см. в описании параметра --allow-pk-changes для ndb_restore.

Улучшения ndb_blob_tool. Начиная с NDB 7.6.14, утилита ndb_blob_tool может обнаруживать отсутствующие части blob, для которых существуют встроенные части, и заменять их на заполнитель blob (состоящий из пробелов) нужной длины. Чтобы проверить, есть ли отсутствующие части blob, используйте параметр --check-missing с этой программой. Чтобы заменить любые отсутствующие части blob на заполнители, используйте параметр --add-missing.

Дополнительную информацию см. в разделе 21.5.6, «ndb_blob_tool — Проверка и ремонт столбцов BLOB и TEXT в таблицах NDB Cluster».

Объединение резервных копий с помощью ndb_restore. В некоторых случаях может потребоваться объединить данные, первоначально хранившиеся в разных экземплярах NDB Cluster (все с одной и той же схемой) в один целевой NDB Cluster. Это теперь поддерживается при использовании резервных копий, созданных с помощью клиента ndb_mgm (см. раздел 21.6.8.2, «Использование клиента управления NDB Cluster для создания резервной копии») и восстановлении их с помощью ndb_restore, используя параметр --remap-column, добавленный в NDB 7.6.14 вместе с --restore-data (и, возможно, дополнительные совместимые параметры по необходимости или желанию). --remap-column может использоваться для обработки случаев, когда значения первичного и уникального ключа перекрываются между исходными кластерами, и необходимо, чтобы они не перекрывались в целевом кластере, а также для сохранения других взаимосвязей между таблицами, таких как внешние ключи.

--remap-column принимает в качестве аргумента строку с форматом db.tbl.col:fn:args, где db, tbl и col соответственно представляют имена базы данных, таблицы и столбца, fn — имя функции переназначения, а args — один или несколько аргументов для fn. Значения по умолчанию нет. Поддерживается только offset в качестве имени функции, с args как целочисленным смещением, которое будет применено к значению столбца при его вставке в целевую таблицу из резервной копии. Этот столбец должен быть одним из INT или BIGINT; допустимый диапазон значения смещения совпадает с диапазоном значений для соответствующего целого типа (это позволяет сделать смещение отрицательным, если необходимо).

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

Кроме того, для ndb_desc также добавлены два новых параметра, начиная с NDB 7.6.14:

Дополнительную информацию и примеры см. в описании параметра --remap-column.

Параметр --ndb-log-fail-terminate. Начиная с NDB 7.6.14, вы можете заставить узел SQL завершать работу всякий раз, когда он не может полностью записать все события строк. Это можно сделать, запустив mysqld с параметром --ndb-log-fail-terminate.

Программы NDB — удаление зависимости NDBT. Была удалена зависимость ряда утилит программ NDB от библиотеки NDBT. Эта библиотека используется внутри для разработки и не требуется для обычного использования; её включение в эти программы может привести к нежелательным проблемам при тестировании.

Затронутые программы указаны ниже вместе с версиями NDB, в которых была удалена зависимость:

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

Устаревание и удаление средства автоматической установки. Веб-инструмент установки MySQL NDB Cluster Auto-Installer (ndb_setup.py) устарел в NDB 7.6.16 и удален в NDB 7.6.17 и более поздних версиях. Он больше не поддерживается.

Устаревание и удаление ndbmemcache. ndbmemcache больше не поддерживается. ndbmemcache был устарел в NDB 7.6.16 и удален в NDB 7.6.17.

Удаление поддержки Node.js. Начиная с выпуска NDB Cluster 7.6.16, поддержка Node.js в NDB 7.6 была удалена.

Поддержка Node.js в NDB Cluster поддерживается только в NDB 8.0.

Преобразование между NULL и NOT NULL во время операций восстановления. Начиная с NDB 7.6.19, ndb_restore может поддерживать восстановление столбцов NULL как NOT NULL и наоборот, используя указанные здесь параметры:

Дополнительную информацию см. в описаниях указанных параметров ndb_restore.

Поддержка OpenSSL 3.0. Начиная с NDB 7.6.27, все двоичные файлы сервера и клиента MySQL, включенные в дистрибутив NDB, скомпилированы с поддержкой Open SSL 3.0