Bloom Filter 打爆租户队列，报错 -4019

问题现象

Hash Join 计划中，两表连接选择率较低时会分配 runtime filter，同时当左表数据量（优化器估行 NDV）很大时，分配的 runtime bloom filter 会变大，达到百M级别时会触发，造成租户队列打爆。

关键诊断信息

触发条件

Hash Join 计划中，两表连接选择率较低时会分配 runtime filter，同时当左表数据量（优化器估行 NDV）很大时，有可能触发。

事前巡检

检查 join filter，runtime filter

事后诊断

组队队列打爆，日志中有 pcode=0x51e:cnt=xxxx 字样。

问题原因

当前 Runtime Bloom Filter 会进行切片分多个rpc包进行发送，每个包大小 8KB，当业务场景中分配了一个较大的 Bloom filter（大概率百M级别的），切片数量过大（几十万级别）需要发送大量 RPC，而rpc接收端来不及处理产生了租户队列积压。后续版本中会调整单个切片的大小，从而减少 RPC 发包数量。

问题的风险及影响

该问题会带来的影响，对业务或者系统风险。

影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

影响版本

OceanBase 数据库企业版 V4.2.0 GA（oceanbase-4.2.0.0-100010082023083014）及之后版本、V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）及之后版本、V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）及之后版本。

解决方法

• 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.2.1 BP5（oceanbase-4.2.1.5-105000072024041817）、V4.2.5 GA（oceanbase-4.2.5.0-100000082024102022）。

• 安全方式。

  设置租户级别系统变量。

  set runtime_filter_type='IN,RANGE';
  set global runtime_filter_type='IN,RANGE';
  

  关闭 Bloom filter 可规避此问题。需要注意关闭之后，在一些 HASH JOIN 场景中可能会出现性能变差的现象，一般可能回退 2-3 倍，极端情况可能回退 10 倍。

• 非绝对安全方式。

  必须确保所有租户完成了 runtime_filter_type 的变量配置。

  set global runtime_filter_type='IN,RANGE';
  

  之后，经历较长一段时间后，确保已经没有老流量了的情况下，随后在系统租户下，设置系统隐藏配置项。

  alter system set _send_bloom_filter_size = 128000;
  

  之后恢复 runtime_filter_type。

  set global runtime_filter_type='IN,RANGE,BLOOM_FILTER';
  

  这样完成之后，将不再有回退情况发生。

规避方式

同解决方法。