5.4.2.9 错误日志输出格式_MySQL 8.0 参考手册

MySQL 8.0 参考手册 / 第 5 章 MySQL 服务器管理 / 5.4 MySQL 服务器日志 / 5.4.2 错误日志 / 5.4.2.9 错误日志输出格式

5.4.2.9 错误日志输出格式

每个错误日志接收器（编写器）组件都有一个特征输出格式，用于将消息写入其目的地，但其他因素可能会影响消息的内容：

日志接收器可用的信息。如果在执行接收器组件之前执行的日志过滤器组件删除了日志事件字段，则该字段不可用于写入。有关日志过滤的信息，请参阅第 5.4.2.4 节，“错误日志过滤的类型”。
与日志接收器相关的信息。并非每个接收器都会写入错误事件中可用的所有字段。
系统变量可能会影响日志接收器。请参阅影响错误日志格式的系统变量。

有关错误事件中字段的名称和描述，请参阅第 5.4.2.3 节，“错误事件字段”。对于所有日志接收器，错误日志消息中包含的线程 ID 是mysqld中负责写入消息的线程的 ID。这个ID表示是服务器的哪个部分产生了消息，与一般查询日志和慢查询日志消息一致，其中包含连接线程ID。

log_sink_internal 输出格式

内部日志接收器产生传统的错误日志输出。例如：

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错误事件优先级字段的字符串形式。

[err_code]和 [subsystem]字段是在 MySQL 8.0 中添加的。它们在旧服务器生成的日志中缺失。日志解析器可以将这些字段视为消息文本的一部分，这些消息文本仅适用于由最近足够包含它们的服务器写入的日志。解析器必须将指示符err_code部分 [err_code]视为字符串值，而不是数字，因为诸如 MY-012487和之类的值MY-010051 包含非数字字符。

log_sink_json 输出格式

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"
}

显示的消息被重新格式化以提高可读性。写入错误日志的事件每行显示一条消息。

( tstimestamp) 键是在 MySQL 8.0.20 中添加的，对于 JSON 格式的日志接收器是唯一的。该值是一个整数，指示自纪元 ( '1970-01-01 00:00:00'UTC) 以来的毫秒数。

和值是 Unix 时间戳值ts，buffered 可以使用 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_sink_syseventlog 输出格式

系统日志接收器产生符合本地平台上使用的系统日志格式的输出。

早期启动日志输出格式

服务器在处理启动选项之前生成一些错误日志消息，因此在它知道错误日志设置（例如 log_error_verbosity和 log_timestamps系统变量值）之前，并且在它知道要使用哪些日志组件之前生成一些错误日志消息。服务器按如下方式处理在启动过程早期生成的错误日志消息：

在 MySQL 8.0.14 之前，服务器会生成具有默认时间戳、格式和详细级别的消息，并对其进行缓冲。在启动选项被处理并且错误日志配置已知之后，服务器刷新缓冲的消息。由于这些早期消息使用默认日志配置，因此它们可能与启动选项指定的内容不同。此外，除默认情况外，早期消息不会刷新到日志接收器。例如，记录到 JSON 接收器不包括这些早期消息，因为它们不是 JSON 格式。
从 MySQL 8.0.14 开始，服务器缓冲日志事件而不是格式化的日志消息。这使它能够在已知设置后将配置设置追溯应用到这些事件，结果是刷新的消息使用配置的设置，而不是默认设置。此外，消息会刷新到所有已配置的接收器，而不仅仅是默认接收器。
如果在已知日志配置并且服务器必须退出之前发生致命错误，服务器将使用日志记录默认值格式化缓冲消息，以免丢失。如果没有发生致命错误，但在处理启动选项之前启动速度过慢，服务器会使用日志记录默认值定期格式化和刷新缓冲消息，以免出现无响应。尽管此行为在使用默认值方面与 8.0.14 之前的行为相似，但它比在出现异常情况时丢失消息更可取。

影响错误日志格式的系统变量

log_timestamps系统变量控制写入错误日志（以及一般查询日志和慢速查询日志文件）的消息中时间戳的时区。服务器 log_timestamps在错误事件到达任何日志接收器之前应用它们；因此，它会影响所有接收器的错误消息输出。

允许的log_timestamps 值为UTC（默认值）和 SYSTEM（本地系统时区）。时间戳使用 ISO 8601 / RFC 3339 格式编写：加上表示祖鲁时间 (UTC) 的尾值或（表示相对于 UTC 的本地系统时区调整的偏移量）。例如： YYYY-MM-DDThh:mm:ss.uuuuuuZ±hh:mm

2020-08-07T15:02:00.832521Z            (UTC)
2020-08-07T10:02:00.832521-05:00       (SYSTEM)