This file contains.
a) The API for the reading of previously written error logs. (These functions will in turn use a parse-function defined in a log-sink. Whichever log-sink that has a parse-function is listed first in @global.log_error_services will be used; that service will decide what log-file to read (i.e. its name) and how to parse it. We initially support the reading of JSON- formatted error log files and of the traditional MySQL error log files.) This lets us restore error log information from previous runs when the server starts. These functions are called from mysqld.cc at start-up.
b) The log-sink that adds errors logged at run-time to the ring-buffer (to be called from
- See also
- log_line_submit() during normal operation, i.e. when loadable log-components are available, connections are accepted, and so on).
Restore error log messages from previous shutdown.
We try restoring from the first (leftmost) of those services listed in @global.log_error_services that have the LOG_SERVICE_LOG_PARSER characteristic.
It is assumed that the last run's log file name is the same as the current one's. That is to say, we check whether the file supplied to –log-error already exists.
Once we have determined what file to read from, we'll call
- See also
- log_error_read_loop() to do the actual reading and parsing.
It should be noted that at the point this function is normally called, buffered error logging will not have flushed yet.
a) If we are using the built-in "trad" sink/reader, the start-up messages are usually not buffered, and have already been written to the error log. In this case, they will be restored from the log (and flushing won't add another event to the ring-buffer).
b) If we are using a reader in a loadable log-service,
- Parameters
-
| log_name | The log file to read (log_error_dest). |
- Return values
-
| LOG_SERVICE_SUCCESS | Success (log read and parsed) |
| LOG_SERVICE_UNABLE_TO_READ | Could not read/access() file |
| LOG_SERVICE_INVALID_ARGUMENT | Invalid file-name (no '.') |
| LOG_SERVICE_NOT_AVAILABLE | No log_component active that can parse log-files |
| LOG_SERVICE_ARGUMENT_TOO_LONG | File-name too long |
| LOG_SERVICE_COULD_NOT_MAKE_LOG_NAME | Could not determine file extension |
| otherwise | Return value from reader |
Add a log-event to the ring buffer.
In the ring-buffer, each event exists as a header and a blob. The header is a log_sink_pfs_event struct containing the traditional error-log columns. It is followed by a variable-length blob that contains just the message string in traditional log mode, and the complete event as JSON in JSON log format. The length of the event will be align to the correct boundary.
If writing the event would go past the end of the ring-buffer, we wrap around to the beginning of the buffer.
After the function success, ring_buffer_read will be set to a valid, non-zero value.
- Parameters
-
| e | filled-in event struct to copy into the ring-buffer |
| blob_src | variable-length part of the event to add to the ring-buffer |
- Return values
-
| LOG_SERVICE_SUCCESS | event was added |
| LOG_SERVICE_NOT_AVAILABLE | ring-buffer not available |
| LOG_SERVICE_INVALID_ARGUMENT | event has no message |
| LOG_SERVICE_ARGUMENT_TOO_LONG | event is larger than buffer(!) |
Get event following the supplied one.
Caller should hold read-lock on THR_LOCK_log_perfschema when calling this.
If advancing the read position puts the read-pointer beyond the highest-address event in the ring-buffer (which isn't necessarily the latest event, which is defined as the last event before catching up with the write-pointer), i.e. at a position where either a wrap- around marker exists, or there is not enough space for a header, we wrap around to the start of the ring-buffer.
- Parameters
-
| e | Last event the caller was processing. This event should be valid, non-NULL, and should not be a wrap-around marker (m_messages_length == 0). |
- Return values
-
| nullptr | No more events in ring-buffer (caught up with writer) |
| otherwise | Address of the next event in the ring-buffer |
1.9.2