MySQL 服务器维护的日志中,有一个是错误日志,它用于写入诊断消息(参见 第 7.4.2 节,“错误日志”)。通常,服务器会将诊断信息写入服务器主机上的文件或系统日志服务。根据错误日志配置,服务器也可以将最新的错误事件写入 Performance Schema error_log
表。因此,授予 error_log
表的 SELECT
权限可以让客户端和应用程序使用 SQL 查询访问错误日志内容,从而让 DBA 可以提供对日志的访问权限,而无需允许直接访问服务器主机的文件系统。
error_log
表支持基于其更结构化的列的聚焦查询。它还包括错误消息的完整文本,以支持更自由的分析。
表实现使用固定大小的内存环形缓冲区,旧事件会根据需要自动丢弃,以腾出空间供新事件使用。
示例 error_log
内容
mysql> SELECT * FROM performance_schema.error_log\G
*************************** 1. row ***************************
LOGGED: 2020-08-06 09:25:00.338624
THREAD_ID: 0
PRIO: System
ERROR_CODE: MY-010116
SUBSYSTEM: Server
DATA: mysqld (mysqld 9.0.0) starting as process 96344
*************************** 2. row ***************************
LOGGED: 2020-08-06 09:25:00.363521
THREAD_ID: 1
PRIO: System
ERROR_CODE: MY-013576
SUBSYSTEM: InnoDB
DATA: InnoDB initialization has started.
...
*************************** 65. row ***************************
LOGGED: 2020-08-06 09:25:02.936146
THREAD_ID: 0
PRIO: Warning
ERROR_CODE: MY-010068
SUBSYSTEM: Server
DATA: CA certificate /var/mysql/sslinfo/cacert.pem is self signed.
...
*************************** 89. row ***************************
LOGGED: 2020-08-06 09:25:03.112801
THREAD_ID: 0
PRIO: System
ERROR_CODE: MY-013292
SUBSYSTEM: Server
DATA: Admin interface ready for connections, address: '127.0.0.1' port: 33062
error_log
表包含以下列。如描述中所示,除了 DATA
列之外,所有列都对应于底层错误事件结构的字段,该结构在 第 7.4.2.3 节,“错误事件字段” 中描述。
LOGGED
事件时间戳,精确到微秒。
LOGGED
对应于错误事件的time
字段,尽管可能存在一些潜在的差异错误日志中的
time
值会根据log_timestamps
系统变量设置显示;参见 早期启动日志输出格式.LOGGED
列使用TIMESTAMP
数据类型存储值,其值存储在 UTC 中,但在检索时以当前会话时区显示;参见 第 13.2.2 节,“DATE、DATETIME 和 TIMESTAMP 类型”.
要以与错误日志文件中显示的相同时区显示
LOGGED
值,请首先设置会话时区,如下所示SET @@session.time_zone = @@global.log_timestamps;
如果
log_timestamps
值为UTC
并且您的系统未安装命名时区支持(参见 第 7.1.15 节,“MySQL 服务器时区支持”),请按如下方式设置时区SET @@session.time_zone = '+00:00';
THREAD_ID
MySQL 线程 ID。
THREAD_ID
对应于错误事件的thread
字段。在 Performance Schema 中,
error_log
表中的THREAD_ID
列与threads
表的PROCESSLIST_ID
列最为相似对于前台线程,
THREAD_ID
和PROCESSLIST_ID
代表连接标识符。它与INFORMATION_SCHEMA
PROCESSLIST
表的ID
列中显示的值相同,也与SHOW PROCESSLIST
输出的Id
列中显示的值相同,以及线程内部使用CONNECTION_ID()
函数返回的值相同。对于后台线程,
THREAD_ID
为 0,PROCESSLIST_ID
为NULL
。
除
error_log
外,许多其他 Performance Schema 表都包含名为THREAD_ID
的列,但在这些表中,THREAD_ID
列是 Performance Schema 内部分配的值。PRIO
事件优先级。允许的值为
System
、Error
、Warning
、Note
。PRIO
列基于错误事件的label
字段,而该字段本身基于底层的数字prio
字段值。ERROR_CODE
数字事件错误代码。
ERROR_CODE
对应于错误事件的error_code
字段。SUBSYSTEM
发生事件的子系统。
SUBSYSTEM
对应于错误事件的subsystem
字段。DATA
错误事件的文本表示形式。此值的格式取决于生成
error_log
行的日志接收器组件的输出格式。例如,如果日志接收器为log_sink_internal
或log_sink_json
,则DATA
值分别代表传统格式或 JSON 格式的错误事件。(参见 第 7.4.2.9 节,“错误日志输出格式”)。由于错误日志可以重新配置以更改向
error_log
表提供行的日志接收器组件,并且由于不同的接收器会生成不同的输出格式,因此写入error_log
表的行在不同时间可能具有不同的DATA
格式。
error_log
表具有以下索引
主键为 (
LOGGED
)索引为 (
THREAD_ID
)索引为 (
PRIO
)索引为 (
ERROR_CODE
)索引为 (
SUBSYSTEM
)
TRUNCATE TABLE
不允许用于 error_log
表。
Performance Schema error_log
表由错误日志接收器组件填充,这些组件除了将格式化的错误事件写入错误日志外,还会写入该表。日志接收器对 Performance Schema 的支持分为两部分
目前,传统格式的 log_sink_internal
和 JSON 格式的 log_sink_json
接收器支持将新事件写入 error_log
表,并提供解析器用于读取以前写入的错误日志文件。
log_error_services
系统变量控制为错误日志启用哪些日志组件。它的值是日志过滤器和日志接收器组件的管道,当发生错误事件时,它们按从左到右的顺序执行。 log_error_services
值与填充 error_log
表的方式有关,如下所示
在启动时,服务器检查
log_error_services
值,并从中选择最左边的日志接收器,该接收器满足以下条件如果没有任何日志接收器满足这些条件,则
error_log
表将保持为空。否则,如果接收器提供解析器,并且日志配置允许找到以前写入的错误日志文件,则服务器将使用接收器解析器读取文件的最后部分,并将其中包含的旧事件写入该表。然后,接收器会将新的错误事件写入该表,以便在发生错误时记录。在运行时,如果
log_error_services
的值发生变化,则服务器会再次检查它,这次会查找最左边的已启用日志接收器,该接收器支持error_log
表,无论它是否提供解析器。如果没有这样的日志接收器,则不会将任何其他错误事件写入
error_log
表。否则,新配置的接收器会将新的错误事件写入该表,以便在发生错误时记录。
任何影响写入错误日志的输出的配置都会影响 error_log
表的内容。这包括详细程度、消息抑制和消息过滤等设置。它也适用于在启动时从以前的日志文件中读取的信息。例如,如果以前服务器实例的配置详细程度较低,则不会写入的错误消息在当前实例配置了更高的详细程度时也不会变得可用。
error_log
表是固定大小的内存环形缓冲区的视图,旧的事件会根据需要自动丢弃,以便为新的事件腾出空间。如以下表格所示,几个状态变量提供有关正在进行的 error_log
操作的信息。
状态变量 | 含义 |
---|---|
Error_log_buffered_bytes |
表中使用的字节数 |
Error_log_buffered_events |
表中存在的事件数 |
Error_log_expired_events |
从表中丢弃的事件数 |
Error_log_latest_write |
上次写入表的时间 |