查看“错误日志输出格式”的源代码

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

*日志接收器可用的信息。如果在执行接收器组件之前执行的日志过滤器组件移除了日志事件字段，则该字段不可用于写入。

*与日志接收器相关的信息。并非每个接收器都会写入错误事件中的所有字段。

*系统变量可能会影响日志接收器。请参见影响错误日志格式的系统变量。


对于所有日志接收器，包含在错误日志消息中的线程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值对应于优先级错误事件优先级字段的字符串形式。

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


显示的消息已经重新格式化以增加可读性。写入错误日志的事件每行显示一个消息。


ts（时间戳）键是在MySQL 8.0.20中添加的，它是JSON格式日志接收端特有的。该值是一个整数，表示自纪元（'1970-01-01 00:00:00' UTC）以来的毫秒数。

ts和缓冲值都是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_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格式进行编写：*YYYY-MM-DDThh: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)