MySQL 8.4 Release Notes
25.6.2.3 集群日志中的事件缓冲区报告
NDB 使用一个或多个内存缓冲区来接收来自数据节点的事件。对于每个订阅表事件的Ndb对象，存在一个这样的缓冲区，这意味着通常每个执行二进制日志的mysqld都有两个缓冲区（一个用于架构事件，另一个用于数据事件）。每个缓冲区包含事件的epochs，这些事件由操作类型（插入、更新、删除）和行数据（前后图像加元数据）组成。
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: 是否已超过配置的阈值，buffered epochs 的数量是最新接收到的完整 epoch 和最近消费的 epoch 之差（在 NDB API 应用程序中，这通过调用nextEvent()或nextEvent2()实现）。报告每秒生成，直到buffered epochs 的数量低于阈值，可以通过设置ndb_report_thresh_binlog_epoch_slip服务器变量来调整阈值。在 NDB API 应用程序中，您也可以通过调用setEventBufferQueueEmptyEpoch()来调整阈值。 -
PARTIALLY_DISCARDING: 事件缓冲区内存已耗尽，即ndb_eventbuffer_max_alloc已经使用了100%。任何部分缓冲的 epoch 都将被缓冲到完成，但任何新接收到的 epochs 都将被丢弃。这意味着事件流中出现了空隙。 -
COMPLETELY_DISCARDING: 没有 buffered 的 epochs。 -
PARTIALLY_BUFFERING: 缓冲区空闲百分比已经上升到阈值，可以在 mysql 客户端中使用ndb_ eventbuffer_free_percent服务器系统变量或在 NDB API 应用程序中通过调用set_eventbuffer_free_percent()设置。新的epochs将被缓冲，无法完成的epochs由于gap而被丢弃。 -
COMPLETELY_BUFFERING: 所有收到的epochs都在缓冲中，这意味着有足够的事件缓存内存。事件流中的gap已经关闭。