MySQL 8.4 发行说明
NDB 使用一个或多个内存缓冲区来存储从数据节点接收的事件。每个订阅表事件的 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: 报告来源节点的 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: 最近完全消耗的纪元。（在 NDB API 应用程序中，这是通过调用nextEvent()完成的。）latest_buffered_epoch: 最近在事件缓冲区中完全缓冲的纪元。report_reason: 生成报告的原因。本节稍后将列出可能的原因。
以下列表描述了报告的可能原因
ENOUGH_FREE_EVENTBUFFER: 事件缓冲区有足够的可用空间。LOW_FREE_EVENTBUFFER: 事件缓冲区的可用空间不足。可以通过设置
ndb_report_thresh_binlog_mem_usage服务器变量来调整触发这些报告的阈值自由百分比级别。BUFFERED_EPOCHS_OVER_THRESHOLD: 缓冲的纪元数量是否已超过配置的阈值。此数量是完全接收到的最新纪元与最近消耗的纪元（在 NDB API 应用程序中，这是通过调用nextEvent()或nextEvent2()完成的）之间的差值。每秒生成一次报告，直到缓冲的纪元数量低于阈值，该阈值可以通过设置ndb_report_thresh_binlog_epoch_slip服务器变量来调整。您也可以通过在 NDB API 应用程序中调用setEventBufferQueueEmptyEpoch()来调整阈值。PARTIALLY_DISCARDING: 事件缓冲区内存已耗尽，即已使用ndb_eventbuffer_max_alloc的 100%。即使使用量超过 100%，任何部分缓冲的纪元也会被完全缓冲，但任何新接收到的纪元都会被丢弃。这意味着事件流中出现了间隙。COMPLETELY_DISCARDING: 没有纪元被缓冲。PARTIALLY_BUFFERING: 间隙后的缓冲区自由百分比已上升到阈值，可以在 mysql 客户端中使用ndb_eventbuffer_free_percent服务器系统变量或在 NDB API 应用程序中调用set_eventbuffer_free_percent()来设置。新纪元正在被缓冲。由于间隙而无法完成的纪元将被丢弃。COMPLETELY_BUFFERING: 接收到的所有纪元都正在被缓冲，这意味着有足够的事件缓冲区内存。事件流中的间隙已关闭。