更新日期：2024年09月11日
取值：[0|1]
默认值：0
说明：consumer 数据入库延时时间记录
设置此参数=1 表示让kafka consumer 记录每一个kafka 消息的时间戳，从该消息被
consumer 接收到开始计时，至该消息被正确同步到8A 数据落地计时结束，用户通
过这两个时间戳，能够了解到数据在consumer 环节的延迟时间。由于consumer 采
用批量提交的方式，
所以实际上采用的是本批次数据中第一条数据的接收时间和提
交完成时间。
此外，用户如果要核对同步结果的数据条数，对每次提交涉及的总数据量（Insert、
Delete、Update）做统计，统计方法与gcluster_kafka_result_check 的方法相同。
这些统计信息最终被记录到checkpoint table 里。
配置此参数=1 后，consumer 启动时会改变checkpoint table 表结构，如下所示：
gbase> select * from gclusterdb.kafka_consumer_offset_jx5;
+--------+----------------------+---------------------+---------------------+----------------+
| OFFSET | POS
| recieve_time
| commit_time
|
dml_count
|
+--------+----------------------+---------------------+---------------------+----------------+
|
0 | 00000000010000000600 | NULL
| NULL
| I:68,D:10,U:20 |
|
0 | 00000000010000000600 | 2019-09-17 15:54:00 | 2019-09-17 15:54:02 |
I:68,D:10,U:20 |
GBase 8a MPP Cluster 参数手册
文档版本2022-06-07
南大通用数据技术股份有限公司
14
|
1 | 00000000010000001100 | NULL
| NULL
| I:68,D:10,U:20 |
|
1 | 00000000010000001100 | 2019-09-17 15:54:02 | 2019-09-17 15:54:03 |
I:68,D:10,U:20 |
表结构一旦修改，即使在配置此参数=0，checkpoint table 依然保持当前表结构。
由于本批次数据的提交时间只有在提交完成后才能得到，
而checkpoint table 的数据
是在提交前就确定的，所以在提交完成、得到时间戳后，出于性能考虑，这个信息
需要在下一次提交再追加记录。因此用户stop consumer 的话，最后一次提交的时
间戳信息是无法记录的。
记录checkpoint table 是通过insert 操作来实现的，
随着提交次数的增加，
checkpoint
table 的数据量也越来越多，之前的设计是每当consumer 启动时，读取上次提交的
offset 后，
旧数据就不再有价值，
会自动对旧数据做清理，
只保留最大的一个offset。
当打开gcluster_kafka_consumer_latency_time_statistics，
因为用户需要追溯数据提交
情况，因此不能再用以前的机制，所以consumer 要根据时间信息定期淘汰旧数据，
目前设计是checkpoint table 里的数据保留7 天，
consumer 启动时记录最旧的时间戳，
每批提交完成后检查当前时间与这个时间戳的差值，
达到7 天就会淘汰与最旧时间
戳差值小于1 天的所有记录。
修改方式：
可使用set 语句修改值也可在配置文件中修改值。
适用于session、
global
范围均可。
track_stmt_retention_time
参数说明：组合参数，控制全量/慢SQL 记录的保留时间。以60 秒为周期读取该参数，
并执行清理超过保留时间的记录，仅sysadmin 用户可以访问。
该参数属于SIGHUP 类型参数，请参考表15-1 中对应设置方法进行设置。
取值范围：字符型
该参数分为两部分，形式为'full sql retention time, slow sql retention time'
full sql retention time 为全量SQL 的保留时间，取值范围为0 ~ 86400
slow sql retention time 为慢SQL 的保留时间，取值范围为0 ~ 604800
默认值：3600,604800