21.6.2.3 Event Buffer Reporting in the Cluster Log — MySQL 5.7

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

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

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

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

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: Причина создания отчёта. Возможные причины показаны ниже в этом разделе.

Поля latest_consumed_epoch и latest_buffered_epoch соответствуют, соответственно, полям apply_gci и latest_gci старых сообщений протоколирования буфера событий, используемых до NDB 7.5.1.

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

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