Rechercher dans le manuel MySQL
5.4.2.8 Error Log Message Format
Each error log sink (writer) component has a characteristic output format it uses to write messages to its destination, but other factors may influence the content of the messages:
The information available to the log writer. If a log filter component executed prior to execution of the writer component removes a log event attribute, that attribute is not available for writing. For information about log filtering, see Section 5.4.2.3, “Types of Error Log Filtering”.
System variables may affect log writers. See System Variables That Affect Error Log Format.
For all log writers, the ID included in error log messages is that of the thread within mysqld responsible for writing the message. This indicates which part of the server produced the message, and is consistent with general query log and slow query log messages, which include the connection thread ID.
Output Format for log_sink_internal
This log writer produces the traditional error log output. It writes messages using this format:
timestamp thread_id [priority] [err_code] [subsystem] message
The [
and ]
square
bracket characters are literal characters in the message
format. They do not indicate that fields are optional.
The [
and err_code
][
fields were added in MySQL 8.0. They will be missing from logs
generated by older servers. Log parsers can treat these fields
as parts of the message text that will be present only for
logs written by servers recent enough to include them. Parsers
must treat the subsystem
]err_code
part of
[
indicators as a string value.
err_code
]
Examples:
2018-03-22T12:35:47.538083Z 0 [Note] [MY-012487] [InnoDB] InnoDB: DDL log recovery : begin
2018-03-22T12:35:47.550565Z 0 [Warning] [MY-010068] [Server] CA certificate /var/mysql/sslinfo/cacert.pem is self signed.
2018-03-22T12:35:47.669397Z 4 [Note] [MY-010051] [Server] Event Scheduler: scheduler thread started with id 4
2018-03-22T12:35:47.550939Z 0 [Note] [MY-010253] [Server] IPv6 is available.
The JSON-format log writer produces messages as JSON objects that contain key-value pairs. For example:
{ "prio": 3, "err_code": 10051, "subsystem": "Server",
"source_file": "event_scheduler.cc", "function": "run",
"msg": "Event Scheduler: scheduler thread started with id 4",
"time": "2018-03-22T12:35:47.669397Z", "thread": 4,
"err_symbol": "ER_SCHEDULER_STARTED", "SQL_state": "HY000",
"label": "Note" }
The system log writer produces output that conforms to the system log format used on the local platform.
The server generates some error log messages before startup
options have been processed, and thus before it knows error
log settings such as the
log_error_verbosity
and
log_timestamps
values, and
which log components are to be used. The server handles error
log messages that are generated early in the startup process
as follows:
Prior to MySQL 8.0.14, the server generates messages with the default timestamp, format, and verbosity level, and buffers them. After the startup options are processed and the error log configuration is known, the server flushes the buffered messages. Because these early messages use the default log configuration, they may differ from what is specified by the startup options. Also, the early messages are not flushed to log writers other than the default. For example, logging to the JSON writer does not include these early messages because they are not in JSON format.
As of MySQL 8.0.14, the server buffers log events rather than formatted log messages. This enables it to retroactively apply configuration settings to those events after the settings are known, with the result that flushed messages use the configured settings, not the defaults. Also, messages are flushed to all configured writers, not just the default writer.
If a fatal error occurs before log configuration is known and the server must exit, the server so they are not lost. If no fatal error occurs but startup is excessively slow prior to processing startup options, the server periodically formats and flushes buffered messages using the logging defaults so as not to appear unresponsive. Although these behaviors are similar to pre-8.0.14 behavior in that the defaults are used, they are preferable to losing messages when exceptional conditions occur.
The log_timestamps
system
variable controls the time zone of timestamps in messages
written to the error log (as well as to general query log and
slow query log files). Permitted values are
UTC
(the default) and
SYSTEM
(local system time zone).
Deutsche Übersetzung
Sie haben gebeten, diese Seite auf Deutsch zu besuchen. Momentan ist nur die Oberfläche übersetzt, aber noch nicht der gesamte Inhalt.Wenn Sie mir bei Übersetzungen helfen wollen, ist Ihr Beitrag willkommen. Alles, was Sie tun müssen, ist, sich auf der Website zu registrieren und mir eine Nachricht zu schicken, in der Sie gebeten werden, Sie der Gruppe der Übersetzer hinzuzufügen, die Ihnen die Möglichkeit gibt, die gewünschten Seiten zu übersetzen. Ein Link am Ende jeder übersetzten Seite zeigt an, dass Sie der Übersetzer sind und einen Link zu Ihrem Profil haben.
Vielen Dank im Voraus.
Dokument erstellt 26/06/2006, zuletzt geändert 26/10/2018
Quelle des gedruckten Dokuments:https://www.gaudry.be/de/mysql-rf-error-log-format.html
Die Infobro ist eine persönliche Seite, deren Inhalt in meiner alleinigen Verantwortung liegt. Der Text ist unter der CreativeCommons-Lizenz (BY-NC-SA) verfügbar. Weitere Informationen auf die Nutzungsbedingungen und dem Autor.
Referenzen
Diese Verweise und Links verweisen auf Dokumente, die während des Schreibens dieser Seite konsultiert wurden, oder die zusätzliche Informationen liefern können, aber die Autoren dieser Quellen können nicht für den Inhalt dieser Seite verantwortlich gemacht werden.
Der Autor Diese Website ist allein dafür verantwortlich, wie die verschiedenen Konzepte und Freiheiten, die mit den Nachschlagewerken gemacht werden, hier dargestellt werden. Denken Sie daran, dass Sie mehrere Quellinformationen austauschen müssen, um das Risiko von Fehlern zu reduzieren.