【 使用环境 】生产环境
【 OB or 其他组件 】OB
【 使用版本 】 4.3.4.1
【问题描述】
如上图,查询主副本所在机器,执行的sql记录。根据执行时间倒序,查询到的最新记录居然是2025-09-04号的记录。 今天是2025-09-23.
长时间未更新sql_audit记录。是什么原因
【 使用环境 】生产环境
【 OB or 其他组件 】OB
【 使用版本 】 4.3.4.1
【问题描述】
如上图,查询主副本所在机器,执行的sql记录。根据执行时间倒序,查询到的最新记录居然是2025-09-04号的记录。 今天是2025-09-23.
长时间未更新sql_audit记录。是什么原因
这里看你条件添加了svr ip 看一下是不是这个节点的leader分区都被迁走了
这个节点是一个表组的 主副本节点。
而且看机器监控。cpu使用率基本都在60-90%之间
而且我们部署了一个允许弱读代理。即使无主副本,也应该存在 弱读请求才对。
集群是三台机器组成的 1-1-1集群。 其他两台机器查询到的ob_sql_audit记录都正常。只有这一台机器sql审计不更新了
查一下该租户的参数ob_enable_sql_audit值是不是调为false了
查询
SELECT tablegroup_name,svr_ip,count(1) FROM oceanbase.DBA_OB_TABLE_LOCATIONS WHERE tablegroup_name is not null and ROLE = ‘LEADER’
group by tablegroup_name,svr_ip;
显示,该节点,是存在leader表副本的
select usec_to_time(REQUEST_TIME) from gv$ob_sql_audit order by REQUEST_TIME desc limit 2;
执行下这个看看
这显示的是有记录的呀。
order by execute_time是执行时间
emm. 其他两台机器是正常的。 只有一台机器没有更新 ob_sql_audit信息
你是如何确定第三台机器没更新呢? 查询的v$还是gv$
如图。 192.168.2.10这台机器 根据请求时间倒序查询。 最新的记录仍然在2025-09-04这天
另外查看ocp中的 sql诊断。这台机器近几天也是没有数据的
其他两台机器都是有记录的
primary zone 优先级是怎么设定的
核对一下primary zone 优先级
是不是审计日志的参数关闭了?
学习了!!
3个zone优先级是一样的。 不过我建了个表组 total。 将所有表都加到这个表组。
这样设置主要是为了后面 将业务表按模块逐一进行分区。 但是目前还没有时间来做这个事情。所以先全部加一个表组来避免跨机关联查询
那按理说副本分区应该都在一个节点了
是的。而且我查过了。 所有节点主副本都在这台 sql审计有问题的节点上
有没有什么办法恢复 开启 ob_sql_audit 。
目前我试过了,将参数 ob_enable_sql_audit 改为off再重新改回 on。 无效果