5.2 Using the Logging Feature

The logging feature can be handy for developing and testing your application and deployment of the MySQL Router. To use logging, enable the logging level option in the configuration file under the section named [logger]. For example:

[logger]
level = INFO

Set the log file's location with the logging_folder option, defined as a directory path under the [DEFAULT] section in the configuration file. The logging file is named mysqlrouter.log. For example:

[DEFAULT]
# Logs are sent to /path/to/folder/mysqlrouter.log
logging_folder = /path/to/folder

[logger]
level = DEBUG

Setting logging_folder to an empty string sends logs to the console (stdout).

Two common logging levels are INFO (default) and DEBUG:

• INFO: includes informational messages like those shown above, and is the default.

• DEBUG: includes messages generated inside Router's source code for use in diagnostics. DEBUG presents verbose information concerning the inner workings of Router. While it may not be of interest to the application, use of DEBUG may be helpful if you encounter a problem or when Router is not behaving as you expect.

The following example shows what the messages look like for the DEBUG logging level; compare the INFO and DEBUG messages:

2019-04-07 18:25:56 INFO    [0x700009673000] Connections using ssl_mode 'PREFERRED'
2019-04-07 18:25:56 INFO    [0x700009673000] Connected with metadata server running on 127.0.0.1:3310
2019-04-07 18:25:56 DEBUG   [0x700009673000] Updating metadata information for cluster 'devCluster'
2019-04-07 18:25:56 DEBUG   [0x700009673000] Updating replicaset status from GR for 'default'
2019-04-07 18:25:56 DEBUG   [0x700009673000] Replicaset 'default' has 3 members in metadata, 3 in status table
2019-04-07 18:25:56 DEBUG   [0x700009673000] End updating replicaset for 'default'
2019-04-07 18:25:56 INFO    [0x700009673000] Changes detected in cluster 'devCluster' after metadata refresh
2019-04-07 18:25:56 INFO    [0x700009673000] Metadata for cluster 'devCluster' has 1 replicasets:

Log Rotation

Router supports log rotation; listed here are scenarios with example implementations.

Note

This functionality is not supported on Windows.

Rotation On Demand

Log rotation on demand can be accomplished in two steps: rename the log file, and then notify Router so it creates and switches to a new log file.

Execute log rotation either directly from the system's shell, or from a script that could be called automatically as a scheduled task. For example:

sudo mv /var/log/mysqlrouter/mysqlrouter.log /var/log/mysqlrouter/mysqlrouter.log.old
kill -HUP $(pidof mysqlrouter)

logrotate

The logrotate mechanism can also rotate Router's log file. After rotating, Router would be notified to reopen the log file and this is accomplished by sending HUP to the Router process. An example logrotate configuration file:

/var/log/mysqlrouter/mysqlrouter.log {
    rotate 9
    size 10M
    create 0755 mysqlrouter mysqlrouter
    postrotate
    kill -HUP $(pidof mysqlrouter)
    endscript
}

The example rotates the logs as mysqlrouter.log, mysqlrouter.log.1, ..., mysqlrouter.log.9. The rotation is triggered based on the size of the current mysqlrouter.log file, only if the size is greater than 10MB. Assuming this configuration is saved as /etc/mysqlrouter/logrotate.conf, it might be executed periodically (added to cron) as follows:

[sudo] logrotate  /etc/mysqlrouter/logrotate.conf