CLUSTER_LOG

集群日志表 CLUSTER_LOG 表用于查询集群当前所有 TiDB/PD/TiKV 节点日志。它通过将查询条件下推到各个节点,降低了日志查询对集群的影响。该表的查询性能优于 grep 命令。

TiDB 4.0 版本之前,要获取集群的日志,用户需要逐个登录各个节点汇总日志。TiDB 4.0 的集群日志表提供了一个全局且时间有序的日志搜索结果,为跟踪全链路事件提供了便利的手段。例如按照某一个 region id 搜索日志,可以查询该 Region 生命周期内的所有日志;类似地,通过慢日志的 txn id 搜索全链路日志,可以查询该事务在各个节点扫描的 key 数量以及流量等信息。

  1. USE information_schema;
  2. DESC cluster_log;
  1. +----------+------------------+------+------+---------+-------+
  2. | Field | Type | Null | Key | Default | Extra |
  3. +----------+------------------+------+------+---------+-------+
  4. | TIME | varchar(32) | YES | | NULL | |
  5. | TYPE | varchar(64) | YES | | NULL | |
  6. | INSTANCE | varchar(64) | YES | | NULL | |
  7. | LEVEL | varchar(8) | YES | | NULL | |
  8. | MESSAGE | var_string(1024) | YES | | NULL | |
  9. +----------+------------------+------+------+---------+-------+
  10. 5 rows in set (0.00 sec)

字段解释:

  • TIME:日志打印时间。
  • TYPE:节点的类型,可取值为 tidbpdtikv
  • INSTANCE:节点的服务地址。
  • LEVEL:日志级别。
  • MESSAGE:日志内容。

CLUSTER_LOG - 图1

注意

  • 日志表的所有字段都会下推到对应节点执行,所以为了降低使用集群日志表的开销,必须指定搜索关键字以及时间范围,然后尽可能地指定更多的条件。例如 select * from cluster_log where message like '%ddl%' and time > '2020-05-18 20:40:00' and time<'2020-05-18 21:40:00' and type='tidb'

  • message 字段支持 likeregexp 正则表达式,对应的 pattern 会编译为 regexp。同时指定多个 message 条件,相当于 grep 命令的 pipeline 形式,例如:select * from cluster_log where message like 'coprocessor%' and message regexp '.*slow.*' and time > '2020-05-18 20:40:00' and time<'2020-05-18 21:40:00' 相当于在集群所有节点执行 grep 'coprocessor' xxx.log | grep -E '.*slow.*'

查询某个 DDL 的执行过程示例如下:

  1. SELECT time,instance,left(message,150) FROM cluster_log WHERE message LIKE '%ddl%job%ID.80%' AND type='tidb' AND time > '2020-05-18 20:40:00' AND time < '2020-05-18 21:40:00'
  1. +-------------------------+----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------+
  2. | time | instance | left(message,150) |
  3. +-------------------------+----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------+
  4. | 2020/05/18 21:37:54.784 | 127.0.0.1:4002 | [ddl_worker.go:261] ["[ddl] add DDL jobs"] ["batch count"=1] [jobs="ID:80, Type:create table, State:none, SchemaState:none, SchemaID:1, TableID:79, Ro |
  5. | 2020/05/18 21:37:54.784 | 127.0.0.1:4002 | [ddl.go:477] ["[ddl] start DDL job"] [job="ID:80, Type:create table, State:none, SchemaState:none, SchemaID:1, TableID:79, RowCount:0, ArgLen:1, start |
  6. | 2020/05/18 21:37:55.327 | 127.0.0.1:4000 | [ddl_worker.go:568] ["[ddl] run DDL job"] [worker="worker 1, tp general"] [job="ID:80, Type:create table, State:none, SchemaState:none, SchemaID:1, Ta |
  7. | 2020/05/18 21:37:55.381 | 127.0.0.1:4000 | [ddl_worker.go:763] ["[ddl] wait latest schema version changed"] [worker="worker 1, tp general"] [ver=70] ["take time"=50.809848ms] [job="ID:80, Type: |
  8. | 2020/05/18 21:37:55.382 | 127.0.0.1:4000 | [ddl_worker.go:359] ["[ddl] finish DDL job"] [worker="worker 1, tp general"] [job="ID:80, Type:create table, State:synced, SchemaState:public, SchemaI |
  9. | 2020/05/18 21:37:55.786 | 127.0.0.1:4002 | [ddl.go:509] ["[ddl] DDL job is finished"] [jobID=80] |
  10. +-------------------------+----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------+

上面查询结果记录了一个 DDL 执行的过程:

  • 用户将 DDL JOB ID 为 80 的请求发给 127.0.0.1:4002 TiDB 节点。
  • 127.0.0.1:4000 TiDB 节点处理这个 DDL 请求,说明此时 127.0.0.1:4000 节点是 DDL owner。
  • DDL JOB ID 为 80 的请求处理完成。