OceanBase 数据库中 为什么会缺失V2.x 版本日志?

本文主要介绍 OceanBase 数据库 V2.X 版本中会导致日志缺失,进而不能形成完整的证据链的因素,以便预防。

适用版本

OceanBase 数据库 V2.X 版本

适用于本文的日志包含 observer.log、rootservice.log 与 election.log

日志限流

配置项

syslog_io_bandwidth_limit

用于设置系统日志所能占用的磁盘 IO 带宽上限,超过带宽上限容量的系统日志将被丢弃。该配置项限制的是日志输出的流量,而不是日志的条数。

可以通过检查关键字

[dc=xx]

查看是否存在日志缺失。OceanBase 数据库中每条异步日志都会包含该关键字,其中

xx

表示当前日志与上一条之间丢失的日志个数,如果日志没有缺失,该字段为 0。

也可以通过 

v$sysstat
 视图查询异步日志打印相关的统计信息,示例输出如下。

obclient> USE oceanbase;
obclient> SELECT * FROM v$sysstat WHERE STAT_ID > 160000 AND STAT_ID <170000 AND CON_ID=1;
+--------+------------+--------------+---------+-----------------------------------------------+
| CON_ID | STATISTIC# | VALUE        | STAT_ID | NAME                                          |
+--------+------------+--------------+---------+-----------------------------------------------+
|      1 |        522 | 201060770890 |  160001 | oblogger log bytes                            |
|      1 |        523 |    433915381 |  160002 | election log bytes                            |
|      1 |        524 |  94618690207 |  160003 | rootservice log bytes                         |
|      1 |        525 |    569142001 |  160004 | oblogger total log count                      |
|      1 |        526 |       662905 |  160005 | election total log count                      |
|      1 |        527 |    223597591 |  160006 | rootservice total log count                   |
|      1 |        528 |            0 |  160007 | async tiny log write count                    |
|      1 |        529 |            0 |  160008 | async normal log write count                  |


接上——

|      1 |        530 |            0 |  160009 | async large log write count                   |
|      1 |        531 |            0 |  160010 | async tiny log dropped count                  |
|      1 |        532 |            0 |  160011 | async normal log dropped count                |
|      1 |        533 |            0 |  160012 | async large log dropped count                 |
|      1 |        534 |            0 |  160013 | async active tiny log count                   |
|      1 |        535 |            0 |  160014 | async active normal log count                 |
|      1 |        536 |            0 |  160015 | async active large log count                  |
|      1 |        537 |            0 |  160016 | async released tiny log count                 |
|      1 |        538 |            0 |  160017 | async released normal log count               |
|      1 |        539 |            0 |  160018 | async released large log count                |
|      1 |        540 |            0 |  160019 | async error log dropped count                 |
|      1 |        541 |      4708945 |  160020 | async warn log dropped count                  |
|      1 |        542 |     11246655 |  160021 | async info log dropped count                  |
|      1 |        543 |         2192 |  160022 | async trace log dropped count                 |
|      1 |        544 |            0 |  160023 | async debug log dropped count                 |
|      1 |        545 |          437 |  160024 | async log flush speed                         |
|      1 |        546 |    782848974 |  160025 | async generic log write count                 |
|      1 |        547 |            0 |  160026 | async user request log write count            |
|      1 |        548 |      6428672 |  160027 | async data maintain log write count           |
|      1 |        549 |            0 |  160028 | async root service log write count            |
|      1 |        550 |      3461511 |  160029 | async schema log write count                  |


接上——

|      1 |        551 |     18191932 |  160030 | async force allow log write count             |
|      1 |        552 |     12601539 |  160031 | async generic log dropped count               |
|      1 |        553 |            0 |  160032 | async user request log dropped count          |
|      1 |        554 |      3356256 |  160033 | async data maintain log dropped count         |
|      1 |        555 |            0 |  160034 | async root service log dropped count          |
|      1 |        556 |            0 |  160035 | async schema log dropped count                |
|      1 |        557 |            0 |  160036 | async force allow log dropped count           |
|      1 |        558 |            0 |  160037 | async tiny log write count for error log      |
|      1 |        559 |            0 |  160038 | async normal log write count for error log    |
|      1 |        560 |            0 |  160039 | async large log write count for err/or log    |
|      1 |        561 |            0 |  160040 | async tiny log dropped count for error log    |
|      1 |        562 |            0 |  160041 | async normal log dropped count for error log  |
|      1 |        563 |            0 |  160042 | async large log dropped count for error log   |
|      1 |        564 |            0 |  160043 | async active tiny log count for error log     |
|      1 |        565 |            0 |  160044 | async active normal log count for error log   |
|      1 |        566 |            0 |  160045 | async active large log count for error log    |
|      1 |        567 |            0 |  160046 | async released tiny log count for error log   |
|      1 |        568 |            0 |  160047 | async released normal log count for error log |
|      1 |        569 |            0 |  160048 | async released large log count for error log  |
+--------+------------+--------------+---------+-----------------------------------------------+


单条日志独立限流

OceanBase 数据库 V2.2.7x 版本起,开始支持单条日志独立限流功能,避免某条日志占用日志系统过多资源。如果开启了单条日志独立限流,则被限流的日志可能出现缺失。


日志级别过低

日志级别过低是造成日志缺失的原因之一。

OceanBase 数据库支持的日志级别为:

ERROR
WARN
INFO
TRACE
 与 
DEBUG
 五种级别。由配置项 
syslog_level
 控制,默认为 
INFO
ERROR
 为最低级别,
DEBUG
 为最高级别。

如果某些级别的日志缺失,可以检查是否刻意设置了最低的日志级别,如果当前的日志级别为 

ERROR
,则会缺失 
WARN
 与 
INFO
 级别的日志。

接上——

日志过期回收

配置项  

enablesyslogrecycle
  用于设置是否开启回收系统日志的功能,默认为 FALSE,表示不开启该功能。如果将  
enablesyslogrecycle
  设置为  
TRUE 
,配置项 
maxsyslogfile_count
  用于设置在回收日志文件之前可以容纳的日志文件数量,默认为 0。有关以上两个参数的详细信息,请参见《OceanBase 数据库 参考指南》的 

系统配置项 章节。

如果开启了日志回收,并且日志数量达到了 

max_syslog_file_count
 设置的阈值,则过期的日志会被回收。

接上——

异常捕获阈值设置不合理

检查以下配置项或参数的值:

  • trace_log_slow_query_watermark
     用于设置查询的执行时间阈值,如果查询的执行时间超过该阈值,则被认为是慢查询,慢查询的追踪日志会被打印到系统日志中,默认为 100 ms。
  • OBProxy 参数 
    slow_transaction_time_threshold
     表示慢查询或事务的整个生命周期的时间阈值,超过了该时间,就会打印相关日志。默认为 5 秒。

如果异常捕获阈值不合理,例如将 

trace_log_slow_query_watermark
 设置为 100s,则无法捕获到影响数据库执行的慢查询日志。

关于 

trace_log_slow_query_watermark
 与 
slow_transaction_time_threshold
 的推荐值,需要对整体 SQL 运行状态做统计后,决定适合此环境的捕获阈值。

接上——

SQL 审计信息的淘汰机制

用于记录 SQL 审计信息的 

v$sql_audit
 视图具有淘汰机制,淘汰有两个触发条件:

① 内存占用比例。

② 数据条数的限制。

满足任意一条时,都会触发淘汰机制。

有关 SQL 审计信息淘汰机制的详细信息,请参见 OceanBase 数据库的 SQL 审计信息淘汰机制