Что нового в NDB Cluster 8.4

Изменения в инновационных релизах NDB 8.x

Таблица ndbinfo transporter_details. Таблица transporter_details предоставляет информацию об отдельных транспóртах, используемых в кластере NDB. В остальном она аналогична таблице ndbinfo transporters, которая предоставляет такую информацию в агрегированном виде.

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

NDB 8.4.1 добавляет столбец type, отображающий тип подключения транспорта (TCP или SHM).

Дополнительную информацию см. в разделе 25.6.17.65 «Таблица ndbinfo transporter_details».

Репликация NDB: Фильтрация неиспользуемых обновлений. Ранее, когда узлы SQL, выполняющие двоичное протоколирование, использовали log_replica_updates=OFF, любые реплицированные обновления, которые применялись в реплике NDB-кластера, отправлялись узлам SQL, выполняющим двоичное протоколирование. Эти обновления фактически не применялись и не использовались для каких-либо других целей; это приводило к ненужному трафику сети и потреблению ресурсов.

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

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

Устаревание файла ndb.cfg. Использование файла Ndb.cfg для задания строки подключения для процесса NDB не было хорошо документировано или поддерживалось. Начиная с NDB 8.4.3, использование этого файла теперь формально устарело; вы должны ожидать, что поддержка его будет удалена в будущих выпусках MySQL Cluster.

TLS для межузловых коммуникаций кластера. NDB Cluster 8.3 и более поздние версии поддерживают межсетевые коммуникации, защищённые протоколом Transport Layer Security (TLS) и инфраструктурой публичных ключей (PKI) для аутентификации и шифрования соединений между узлами NDB, а также между сервером управления NDB и его клиентами; TLS применяется к протоколу NDB Transporter и к протоколу управления NDB.

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

Соединения, использующие протокол клиента MySQL, используют аутентификацию пользователя MySQL и могут использовать TLS (включая необязательную взаимную аутентификацию TLS), как описано в другом месте в этом руководстве; см. Раздел 8.3, «Использование защищённых соединений» для получения дополнительной информации.

NDB реализует новый инструмент ndb_sign_keys, который можно использовать для создания и управления CA, файлами сертификатов и ключами. Вы можете сгенерировать набор ключей и сертификатов для всех узлов в кластере с заданным файлом конфигурации, используя ndb_sign_keys --create-key.

Используя ndb_sign_keys, сертификат узла может быть привязан к определённому имени хоста, установлен срок действия на определённую дату и связан с определённым типом узла, чтобы клиенты отличались от серверов, а серверы управления от узлов данных. (Каждый сертификат TLS NDB может использоваться для соединений клиента MGM.) Приватные ключи создаются локально, чтобы минимизировать копирование файлов, содержащих приватные ключи. Приватные ключи и сертификаты помечаются как активные или ожидающие; ndb_sign_keys также предоставляет помощь в ротации ключей, чтобы ожидающие ключи могли заменить активные ключи до истечения срока действия активных ключей.

Тестирование соединений TLS узла может быть выполнено из системной оболочки с помощью клиента ndb_mgm с --test-tls или в клиенте ndb_mgm с использованием команды TLS INFO. Информацию о сертификатах, используемых узлами кластера, можно получить, проверив таблицу ndbinfo certificates.

Чтобы обеспечить требование TLS, установите параметр клиента ndb-mgm-tls=strict в my.cnf на каждом узле кластера, затем установите RequireTls=true в разделе [mgm default] файла конфигурации кластера config.ini, и установите RequireTls=true в разделе [ndbd default] файла конфигурации. Затем выполните поэтапный перезапуск кластера, перезапустив сервер управления с --reload --config-file.

Использование TLS-соединений также поддерживается в приложениях NDB Cluster API в NDB 8.3 и более поздних версиях. Для получения информации о поддержке API MGM, см. Класс NDB API добавляет методы для настройки TLS-соединений клиентами.

Дополнительную информацию см. в Разделе 25.6.15, «Шифрование TLS для NDB Cluster», а также в Разделе 25.5.28, «ndb_sign_keys — Создание, подпись и управление ключами и сертификатами TLS для NDB Cluster».

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

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

Обновления первичного ключа в NDB API. Ранее, когда использовался любой другой механизм, кроме , для попытки обновить значение первичного ключа, NDB API возвращал ошибку 4202 Запрещено устанавливать значение для атрибута ключа кортежа, даже при установке значения, идентичного существующему. В NDB 8.1 и более поздних версиях проверка при выполнении обновлений другими методами передаётся узлам данных, как это уже было при использовании NdbRecord для выполнения обновления.

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

Улучшенные предупреждения. Внесены следующие улучшения в вывод предупреждений:

Кроме того, мы больше не выводим сообщение Проверка исключённых объектов в журнал ошибок узла SQL каждые ndb_metadata_check_interval (по умолчанию 60) секунд, когда log_error_verbosity больше или равно 3 (уровень INFO), поскольку такие сообщения часто заполняли журнал ошибок, затрудняя его изучение и используя избыточное дисковое пространство, не предоставляя при этом никакой дополнительной пользы пользователю.

Объединения запросов с очень большими и, возможно, перекрывающимися списками IN() и NOT IN() теперь обрабатываются корректным и безопасным способом.

Сообщения в журнале плагина ndbcluster теперь используют SYSTEM как уровень журнала и NDB как подсистему для ведения журнала. Это означает, что информационные сообщения из плагина ndbcluster всегда выводятся; их подробность можно контролировать с помощью --ndb_extra_logging.