每个错误日志接收器(写入器)组件都有一个用于将其写入其目标的特征输出格式,但其他因素可能会影响消息的内容
日志接收器可用的信息。如果日志过滤器组件在执行接收器组件之前执行并删除了日志事件字段,则该字段不可用于写入。有关日志过滤的信息,请参见第 7.4.2.4 节,“错误日志过滤类型”。
与日志接收器相关的消息。并非所有接收器都会写入错误事件中所有可用的字段。
系统变量可能会影响日志接收器。请参见影响错误日志格式的系统变量。
有关错误事件中字段的名称和描述,请参见第 7.4.2.3 节,“错误事件字段”。对于所有日志接收器,错误日志消息中包含的线程 ID 是负责写入消息的mysqld 中的线程 ID。此 ID 指示服务器的哪个部分生成了消息,并且与通用查询日志和慢速查询日志消息一致,这些消息包含连接线程 ID。
内部日志接收器生成传统的错误日志输出。例如
2020-08-06T14:25:02.835618Z 0 [Note] [MY-012487] [InnoDB] DDL log recovery : begin
2020-08-06T14:25:02.936146Z 0 [Warning] [MY-010068] [Server] CA certificate /var/mysql/sslinfo/cacert.pem is self signed.
2020-08-06T14:25:02.963127Z 0 [Note] [MY-010253] [Server] IPv6 is available.
2020-08-06T14:25:03.109022Z 5 [Note] [MY-010051] [Server] Event Scheduler: scheduler thread started with id 5
传统格式的消息具有以下字段
time thread [label] [err_code] [subsystem] msg
[
和 ]
方括号是消息格式中的字面字符。它们并不表示字段是可选的。
label
值对应于 prio
错误事件优先级字段的字符串形式。
JSON 格式的日志接收器生成的消息为包含键值对的 JSON 对象。例如
{
"prio": 3,
"err_code": 10051,
"source_line": 561,
"source_file": "event_scheduler.cc",
"function": "run",
"msg": "Event Scheduler: scheduler thread started with id 5",
"time": "2020-08-06T14:25:03.109022Z",
"ts": 1596724012005,
"thread": 5,
"err_symbol": "ER_SCHEDULER_STARTED",
"SQL_state": "HY000",
"subsystem": "Server",
"buffered": 1596723903109022,
"label": "Note"
}
显示的消息已重新格式化以提高可读性。写入错误日志的事件每行一条消息。
ts
(时间戳)键是 JSON 格式的日志接收器所独有的。该值是一个整数,表示自纪元('1970-01-01 00:00:00'
UTC)以来的毫秒数。
ts
和 buffered
值是 Unix 时间戳值,可以使用 FROM_UNIXTIME()
和适当的除数进行转换
mysql> SET time_zone = '+00:00';
mysql> SELECT FROM_UNIXTIME(1596724012005/1000.0);
+-------------------------------------+
| FROM_UNIXTIME(1596724012005/1000.0) |
+-------------------------------------+
| 2020-08-06 14:26:52.0050 |
+-------------------------------------+
mysql> SELECT FROM_UNIXTIME(1596723903109022/1000000.0);
+-------------------------------------------+
| FROM_UNIXTIME(1596723903109022/1000000.0) |
+-------------------------------------------+
| 2020-08-06 14:25:03.1090 |
+-------------------------------------------+
服务器在处理启动选项之前会生成一些错误日志消息,因此在它知道错误日志设置(如log_error_verbosity
和log_timestamps
系统变量值)以及在它知道要使用哪些日志组件之前会生成这些消息。服务器处理在启动过程的早期生成的错误日志消息的方式如下
服务器会缓冲日志事件(而不是格式化的日志消息),这使其能够在设置已知后追溯地将配置设置应用于这些事件,从而导致刷新的消息使用配置设置而不是默认设置。此外,消息将刷新到所有配置的接收器,而不仅仅是默认接收器。
如果在知道日志配置之前发生致命错误并且服务器必须退出,服务器会使用日志默认设置格式化缓冲的消息,这样就不会丢失。如果未发生致命错误,但启动在处理启动选项之前过慢,则服务器会定期使用日志默认设置格式化并刷新缓冲的消息,以免出现无响应状态。虽然此行为使用默认设置,但它比在发生异常情况时丢失消息更好。
系统变量 log_timestamps
控制写入错误日志(以及常规查询日志和慢查询日志文件)的消息中时间戳的时间区域。服务器在错误事件到达任何日志接收器之前应用 log_timestamps
;因此它影响所有接收器的错误消息输出。
允许的 log_timestamps
值为 UTC
(默认值)和 SYSTEM
(本地系统时区)。时间戳使用 ISO 8601 / RFC 3339 格式写入:
,加上 YYYY-MM-DD
Thh:mm:ss.uuuuuu
Z
尾部值,表示 Zulu 时间(UTC)或 ±hh:mm
(指示相对于 UTC 的本地系统时区调整的偏移量)。例如
2020-08-07T15:02:00.832521Z (UTC)
2020-08-07T10:02:00.832521-05:00 (SYSTEM)