MySQL 8.3 Release Notes
NDB 使用一个或多个内存缓冲区来接收来自数据节点的事件。每个 Ndb 对象订阅表事件时，会使用一个缓冲区，这意味着通常每个执行二进制日志记录的 mysqld 都有两个缓冲区（一个用于模式事件，一个用于数据事件）。每个缓冲区包含由事件组成的 epoch，这些事件包括操作类型（插入、更新、删除）和行数据（before 和 after 图像加元数据）。
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: 报告来源的节点 ID。 -
object_id: 报告来源的Ndb对象 ID。 -
bytes_used: 缓冲区中使用的字节数。 -
percent_used: 缓冲区中使用的百分比。 -
bytes_allocated: 分配给该缓冲区的字节数。 -
percent_alloc: 可用字节的百分比；如果ndb_eventbuffer_max_alloc等于 0（无限制），则不打印。 -
bytes_available: 可用字节数；如果ndb_eventbuffer_max_alloc等于 0（无限制），则为 0。 -
latest_consumed_epoch: 最近完成的 epoch。（在 NDB API 应用程序中，这是通过调用nextEvent()完成的。） -
latest_buffered_epoch: 最近缓冲的 epoch（完全缓冲到事件缓冲区中）。 -
report_reason: 报告的原因。可能的原因将在本节后面列出。
可能的报告原因如下所示：
-
ENOUGH_FREE_EVENTBUFFER: 事件缓冲区有足够的空闲空间。LOW_FREE_EVENTBUFFER: 事件缓冲区的空闲空间不足。触发这些报告的阈值百分比可以通过设置
ndb_report_thresh_binlog_mem_usage服务器变量来调整。 -
BUFFERED_EPOCHS_OVER_THRESHOLD: 缓冲的 epoch 数量是否超过了配置的阈值。这是通过调用nextEvent()或nextEvent2()完成的。报告每秒生成，直到缓冲的 epoch 数量低于阈值，可以通过设置ndb_report_thresh_binlog_epoch_slip服务器变量来调整。您也可以在 NDB API 应用程序中通过调用setEventBufferQueueEmptyEpoch()来调整阈值。 -
PARTIALLY_DISCARDING: 事件缓冲器内存耗尽——即，ndb_eventbuffer_max_alloc的 100% 已经使用完毕。任何部分缓冲的 epoch 都将被缓冲到完成，即使使用率超过 100%，但任何新的 epoch 都将被丢弃。这意味着事件流中出现了间隙。 -
COMPLETELY_DISCARDING: 不缓冲任何 epoch。 -
部分缓冲：缓冲区空闲百分比在gap之后上升到了阈值，可以在 mysql 客户端中使用ndb_eventbuffer_free_percent服务器系统变量或在 NDB API 应用程序中通过调用set_eventbuffer_free_percent()设置。新的纪元被缓冲。由于gap而无法完成的纪元将被丢弃。 -
完全缓冲：所有收到的纪元都被缓冲，这意味着事件缓冲内存充足。事件流中的gap已经关闭。