25.6.2.3 Event Buffer Reporting in the Cluster Log — MySQL 9.2

25.6.2.3 Отчёт о буфере событий в журнале кластера

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

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

Отчёты о логах буфера событий в журнале кластера используют представленный здесь формат:

Node node_id: Event buffer status (object_id):
used=bytes_used (percent_used% of alloc)
alloc=bytes_allocated (percent_alloc% of max) max=bytes_available
latest_consumed_epoch=latest_consumed_epoch
latest_buffered_epoch=latest_buffered_epoch
report_reason=report_reason

Поля, составляющие этот отчёт, перечислены здесь с описаниями:

node_id: Идентификатор узла, откуда исходит отчёт.
object_id: Идентификатор объекта, откуда исходит отчёт.
bytes_used: Количество байтов, используемых буфером.
percent_used: Процент выделенных байтов, используемых.
bytes_allocated: Количество байтов, выделенных для этого буфера.
percent_alloc: Процент используемых доступных байтов; не выводится, если ndb_eventbuffer_max_alloc равен 0 (неограничен).
bytes_available: Количество доступных байтов; это 0, если ndb_eventbuffer_max_alloc равно 0 (неограничен).
latest_consumed_epoch: Эпоха, которая была полностью обработана последней. (В приложениях NDB API это делается с помощью вызова .)
latest_buffered_epoch: Эпоха, которая была последней (полностью) вставлена в буфер событий.
report_reason: Причина создания отчёта. Возможные причины показаны позже в данном разделе.

Возможные причины создания отчёта описаны в следующем списке:

ENOUGH_FREE_EVENTBUFFER: В буфере событий достаточно места.

LOW_FREE_EVENTBUFFER: В буфере событий заканчивается свободное место.

Пороговое значение свободного процента, которое приводит к генерации этих отчётов, может быть скорректировано путем настройки переменной сервера ndb_report_thresh_binlog_mem_usage.
BUFFERED_EPOCHS_OVER_THRESHOLD: Число буферизованных эпох превысило заданный порог. Это число представляет разницу между последней эпохой, которая была полностью получена, и эпохой, которая была обработана последней (в приложениях NDB API это делается с помощью вызова или ). Отчёт генерируется каждую секунду, пока количество буферизованных эпох не опустится ниже порога, который может быть скорректирован настройкой переменной сервера ndb_report_thresh_binlog_epoch_slip. Вы также можете скорректировать порог в приложениях NDB API, вызвав .
PARTIALLY_DISCARDING: Память буфера событий исчерпана — то есть, 100% ndb_eventbuffer_max_alloc использовано. Любая частично буферизованная эпоха буферизуется до завершения, даже если использование превышает 100%, но все новые полученные эпохи отбрасываются. Это означает, что в потоке событий произошла разрыв.
COMPLETELY_DISCARDING: Эпохи не буферизуются.
PARTIALLY_BUFFERING: Процент свободного места буфера после разрыва достиг порога, который может быть установлен в клиенте mysql с помощью переменной системы сервера ndb_eventbuffer_free_percent или в приложениях NDB API с помощью вызова . Новые эпохи буферизуются. Эпохи, которые не могли быть завершены из-за разрыва, отбрасываются.
COMPLETELY_BUFFERING: Все полученные эпохи буферизуются, что означает, что памяти буфера событий достаточно. Разрыв в потоке событий закрыт.