7.4.2.9 Формат вывода журнала ошибок
Каждый компонент источника журнала ошибок (запись) имеет характерный формат вывода, который он использует для записи сообщений в пункт назначения, но на содержание сообщений могут влиять и другие факторы:
Доступная информация источнику журнала ошибок. Если компонент фильтра журнала, выполненный до выполнения компонента источника, удаляет поле события журнала, это поле недоступно для записи. Подробнее о фильтрации журналов см. Раздел 7.4.2.4 «Типы фильтрации журналов ошибок».
Информация, относящаяся к источнику журнала ошибок. Не каждый источник записывает все поля, доступные в событиях ошибок.
Системные переменные могут влиять на источники журналов. См. Системные переменные, влияющие на формат журнала ошибок.
Для получения имен и описаний полей в событиях ошибок см. Раздел 7.4.2.3 «Поля событий ошибок». Для всех источников журналов идентификатор потока, включенный в сообщения журнала ошибок, — это идентификатор потока в mysqld, ответственный за запись сообщения. Этот идентификатор указывает, какая часть сервера сгенерировала сообщение, и согласуется с сообщениями общего журнала запросов и журнала медленных запросов, которые включают идентификатор потока соединения.
Формат вывода 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"
}
Показанное сообщение переформатировано для удобочитаемости. События, записанные в журнал ошибок, появляются по одному сообщению в строке.
Ключ 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_sink_syseventlog
Источник журнала системы генерирует вывод, соответствующий формату системного журнала, используемому на локальной платформе.
Формат вывода журнала ранней загрузки
Сервер генерирует некоторые сообщения журнала ошибок до обработки параметров загрузки и, следовательно, до того, как он узнает настройки журнала ошибок, такие как системные переменные log_error_verbosity и log_timestamps, и до того, как он узнает, какие компоненты журнала будут использоваться. Сервер обрабатывает сообщения журнала ошибок, которые генерируются на ранней стадии процесса запуска следующим образом:
-
Сервер буферизует события журнала (а не отформатированные сообщения журнала), что позволяет ему применить параметры конфигурации к этим событиям ретроактивно, после того, как параметры будут известны, в результате чего обработанные сообщения используют настроенные параметры, а не значения по умолчанию. Кроме того, сообщения передаются во все настроенные источники, а не только в источник по умолчанию.
Если перед тем, как будут известны параметры конфигурации журнала, произойдет фатальная ошибка, и сервер должен завершиться, сервер отформатирует буферизованные сообщения с помощью значений по умолчанию, чтобы они не потерялись. Если фатальная ошибка не произошла, но загрузка чрезмерно замедлена до обработки параметров запуска, сервер периодически форматирует и отправляет буферизованные сообщения с использованием значений по умолчанию, чтобы не казаться невосприимчивым. Хотя это поведение использует значения по умолчанию, предпочтительнее потерять сообщения, чем столкнуться с экстремальными условиями.
Системные переменные, влияющие на формат журнала ошибок
Системная переменная log_timestamps управляет часовым поясом временных меток в сообщениях, записываемых в журнал ошибок (а также в общий журнал запросов и журнал медленных запросов). Сервер применяет log_timestamps к событиям ошибок перед их попаданием в любой источник журнала; это влияет на вывод сообщений об ошибках из всех источников.
Допустимые значения log_timestamps — UTC (значение по умолчанию) и SYSTEM (локальный часовой пояс системы). Временные метки записываются в формате ISO 8601/RFC 3339: плюс хвостовое значение YYYY-MM-DDThh:mm:ss.uuuuuuZ, обозначающее время по Гринвичу (UTC), или ±hh:mm (смещение, которое указывает корректировку локального часового пояса системы относительно UTC). Например:
2020-08-07T15:02:00.832521Z (UTC)
2020-08-07T10:02:00.832521-05:00 (SYSTEM)
© 2025 Oracle
Licensed under the GPLv2 License.