每个错误日志sink(writer)组件都有其特征输出格式,用于将消息写入其目标,但其他因素也可能影响消息的内容:
-
日志sink可用的信息。如果在sink组件执行之前执行的日志过滤器组件删除了日志事件字段,那么该字段将不可用于写入。有关日志过滤的信息,请参见第 7.4.2.4 节,“错误日志过滤类型”。
-
与日志sink相关的信息。不每个sink都写入所有可用的字段。
-
系统变量可能会影响日志sink。请参见影响错误日志格式的系统变量。
有关错误事件字段的名称和描述,请参见第 7.4.2.3 节,“错误事件字段”。对于所有日志sink,错误日志消息中的线程 ID 是负责写入消息的 mysqld 线程的 ID。这 ID 表示服务器的哪一部分产生了消息,并与一般查询日志和慢查询日志消息一致,其中包括连接线程 ID。
内部日志sink产生传统的错误日志输出。例如:
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
方括号 [
和 ]
是消息格式中的文字字符,不表示字段是可选的。
标签值对应于错误事件优先级字段的字符串形式。
字段 [err_code]
和 [subsystem]
是在 MySQL 8.0 中添加的,因此在旧服务器生成的日志中不存在。日志解析器可以将这些字段视为仅在最近的服务器生成的日志中存在的消息文本的一部分。解析器必须将 err_code
部分的 [err_code]
指示符视为字符串值,而不是数字,因为值如 MY-012487
和 MY-010051
包含非数字字符。
JSON 格式日志sink产生的消息是 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 格式日志sink的唯一键。该值是一个整数,表示自 epoch('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
系统变量值,以及不知道哪些日志组件将被使用的情况下。服务器处理早期启动过程中生成的错误日志消息如下:
-
服务器缓冲日志事件(而不是格式化的日志消息),这使得它可以将配置设置应用于这些事件,以便在配置设置已知的情况下,结果是刷新的消息使用配置的设置,而不是默认值。此外,消息将被刷新到所有配置的 sink,而不仅仅是默认的 sink。
如果在不知道日志配置的情况下发生致命错误并且服务器必须退出,服务器将使用日志默认值格式化缓冲的消息,以便不丢失。如果没有致命错误,但是在处理启动选项之前启动非常慢,服务器将定期格式化和刷新缓冲的消息,以便不出现无响应。虽然这种行为使用默认值,但是在异常情况下丢失消息是不可取的。
系统变量 log_timestamps
控制错误日志中的时间戳的时区(以及通用查询日志和慢查询日志文件)。服务器在错误事件到达任何日志 sink 之前应用 log_timestamps
,因此它影响所有 sink 的错误消息输出。
允许的 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)