logging_folder

Path to the MySQL Router log file directory. The log file is named mysqlrouter.log, and it is either generated or appended to if this file already exists.

Setting logging_folder to an empty value sends the messages to the console (stdout).

An example that sends logs to /var/log/mysqlrouter/mysqlrouter.log:

[DEFAULT]
logging_folder = /var/log/mysqlrouter

When the --directory bootstrap option is used, the generated configuration file sets it to $directory/log/.

plugin_folder

Path to the MySQL Router plugins. This folder must match the MySQL Router installation directory. You should only set this if you have a custom installation where the plugins are not in the standard installation location.

Default value: /usr/local/lib/mysqlrouter

runtime_folder

Path to the MySQL Router runtime files.

Default value: /run/mysqlrouter

master-key-writer

Script that reads the master key from STDIN. Set using the --master-key-writer command-line bootstrap option.

master-key-reader

Script that returns the master key to STDOUT. Set using the --master-key-reader command-line bootstrap option.

config_folder

Path to the MySQL Router configuration files.

Default value: /usr/local/etc/mysqlrouter

sinks

The sink(s) (different logging methods) that a defined log level are sent to.

Supported sink values are: consolelog, filelog, eventlog (on Windows), and syslog (on Unix-based systems). Use a comma-separated list to define multiple values.

Default value: filelog if the logging_folder option is not empty in the "[DEFAULT]" section, otherwise consolelog.

For example, to configure logger to use the file, console and the event log each using the debug log level configured in the [logger] section:

[logger]
level=debug
sinks=consolelog,eventlog,filelog

keyring_path

Points to the keyring file's location.

A system-wide bootstrap does not add this option to the generated configuration file, and assumes the keyring file is located in the system-wide runtime state directory. If --directory is also used, then the keyring file is stored under the runtime state directory of that instance, under run/ in the specified directory.

System-wide default paths are used if this option is not defined.

Example usage:

keyring_path = /opt/myrouter/data/keyring
master_key_path = /opt/myrouter/mysqlrouter.key

master_key_path

The master key file's location. This option allows unattended decryption, as otherwise its location is requested at startup.

System-wide default paths are used if this option is not specified.

Example usage:

keyring_path = /opt/myrouter/data/keyring
master_key_path = /opt/myrouter/mysqlrouter.key

user (system)

Run mysqlrouter as the user having the name user_name or the numeric user ID user_id. “User” in this context refers to a system login account, not a MySQL user listed in the grant tables. This can also be assigned at runtime using the --user command line option.

On Linux, installing Router with official DEB or RPM packages creates a local system user and group named "mysqlrouter" on the host, and MySQL Router runs as this user by default. This account does not have shell access and its home directory points to the directory where the default configuration file is stored.

The purpose of this option is to run MySQL Router as a user with restricted system privileges. If the user does not exist on the system, or if an attempt to start Router as root is made, an error is emitted and Router exits.

MySQL Router can be bootstrapped and executed under any Operating System user and does not require special privileges other than read and write access to its own files. The files it accesses include plugins (read/execute), configuration file, logs, UNIX domain socket files (if enabled), and more.

By default, the configuration and log files are written to a system-wide location such as /etc and /var/log. Alternatively, Router can be bootstrapped to a self-contained directory of its own by using the --directory option. For example:

shell> sudo mysqlrouter --bootstrap localhost:3310 --directory /a/path/myrouter --user snoopy

In this example, Router creates /a/path/myrouter and adds all of the generated files and directories here, and these are only writable by the system user snoopy. Additionally, user is defined in the generated configuration file /a/path/myrouter/mysqlrouter.conf:

[DEFAULT]
user=snoopy

bind_address

Information related to the optional bind_address option:

Example usage:

bind_address = 127.0.0.1:7001

bind_port

Optionally, you can define a default port for bind_address using bind_port. If a port is not configured in bind_address, then bind_port is required and used.

The three examples below all result in bind_address = 127.0.0.1:7001

[routing:example_1]
bind_port = 7001

[routing:example_2]
bind_port = 7001
bind_address = 127.0.0.1

[routing:example_3]
bind_address = 127.0.0.1:7001

socket

Sockets are enabled using the socket option, which can be specified with or without the TCP bind_port and bind_address options. An example:

[routing]
socket = /tmp/mysqlrouter.sock
destinations = a.example.com:3306,b.example.com:3307

When launching MySQL Router, Router will refuse to run if either the socket file already exists or it cannot be written to.

Relative paths are acceptable and based on the current working directory where Router is launched.

Router can listen to both TCP sockets and Unix sockets simultaneously. For example, the following [routing] configuration example is valid and configures Router to listen for connections on both localhost:1234 and /tmp/mysqlrouter.sock:

[routing:my_redirect]
bind_address = localhost:1234
socket = /tmp/mysqlrouter.sock
mode = read-write
destinations = localhost:57121, localhost:57122, localhost:57123

protocol

Used by the routing plugin when connecting to the destination MySQL server, and can be set to either "classic" (default), or "x" (X Protocol).

Example usage:

[routing:basic_failover]
bind_port = 7001
mode = read-write
destinations = 10.20.200.1:33060, 10.20.200.2:33060
protocol = x

The protocol option also affects the default port used by by each destination. If a destination port is not configured, then the default port is 3306 for "classic" (default), 33060 for "x" (X Protocol).

pid_file

Sets location of the PID file. This can be set in three different ways (in order of precedence): the --pid-file command-line option, setting this pid_file option in Router's configuration file, or defining the ROUTER_PID environment variable.

If --bootstrap is specified, then the pid_file and ROUTER_PID definitions are ignored. This is unlike the --pid-file command-line option which causes Router to fail.

If --bootstrap is not specified, then the following cause Router to fail: the --pid-file already exists, pid_file or ROUTER_PID are set but empty, or if Router can't write the PID file.

connect_timeout

Timeout value used by the MySQL Router when connecting to the destination MySQL server. The default value is 1 second. The value cannot be unlimited, and an invalid value results in a configuration error. The valid range is between 1 and 65536. You should keep this value low.

For example, when using read-write mode, the value can be a little higher to wait for the PRIMARY to become available. When using read-only mode for secondary connections, a lower value makes more sense because Router selects a new server during connection routing.

Example usage:

[routing]
connect_timeout = 1

connect_timeout

Timeout value used by the MySQL Router when connecting to the MySQL metadata server. The default value is 30 seconds.

Example usage:

[DEFAULT]
connect_timeout = 30

read_timeout

Timeout value used by the MySQL Router when reading from the MySQL metadata server. The default value is 30 seconds.

Example usage:

[DEFAULT]
read_timeout = 30

destinations

Provides host information for establishing connections. It accepts either a comma-separated list of destination addresses or a metadata-cache link to an InnoDB cluster.

Example usage with specific hosts (static routing):

destinations = a.example.com,b.example.com,c.example.com

Example usage with InnoDB cluster metadata cache:

destinations=metadata-cache://mycluster/default?role=PRIMARY

The metadata-cache URI options are:

dynamic_state

This option tracks and stores active MySQL InnoDB Cluster Metadata server addresses and loads them if Router is restarted. This functionality is activated by --bootstrap and is preferred over the deprecated static bootstrap_server_addresses option.

Bootstrapping defines the dynamic_state option in mysqlrouter.conf file under the [DEFAULT] section. The value is a path to a JSON file named state.json, which is created when Router has been bootstrapped. The state.json is initialized with InnoDB Cluster Metadata server addresses and the Group Replication ID (the group_replication_name returned by the InnoDB Cluster ); additional information is added and updated while Router is running.

Example mysqlrouter.conf entry:

[DEFAULT]
dynamic_state=/opt/myrouter/data/state.json

Example state.json generated by --bootstrap:

{
    "metadata-cache": {
        "group-replication-id": "4b9e817a-0254-11e9-9cc0-080027bb5030",
        "cluster-metadata-servers": [
            "mysql://localhost:3310",
            "mysql://localhost:3320",
            "mysql://localhost:3330"
        ]
    },
    "version": "1.0.0"
}

The dynamic_state and deprecated bootstrap_server_addresses options cannot be set at the same time. For backwards compatibility, if only bootstrap_server_addresses is set then it functions as it did in previous Router versions and this dynamic configuration functionality is not used.

This option was added in MySQL Router 8.0.14.

mode

The deprecated mode option sets Router's scheduling, and the two supported mode values are:

Alternatively, the previous destinations example could use metadata-cache to utilize InnoDB cluster's metadata cache that dynamically configures host information. For example: .

[routing:ro_route]
bind_port = 7002
destinations=metadata-cache://myCluster/default?role=SECONDARY
routing_strategy=round-robin

routing_strategy

The routing strategy defines how MySQL Router chooses MySQL servers to connect to.

Available strategies:

The role defaults and available combinations:

max_connections

Each routing can limit the number of routes or connections. One possible use is to help prevent possible Denial-Of-Service (DOS) attacks. The default value is 512, and the valid range is between 1 and 65536.

This is similar to MySQL Server's max_connections server system variable.

max_connections = 512

MySQL Router 8.0.22 introduced functionality that increases the concurrent connection limit from around 5,000 to 50,000 connections. The maximum depends both on the system's poll (or linux_epoll) limitations and the number of available CPU cores/threads. See also the [IO] backend and threads configuration options.

thread_stack_size

The stack size allocated for each thread. It is measured in kilobytes, and defaults to 64.

[DEFAULT]
thread_stack_size=128

net_buffer_length

Sets the net_buffer_length MySQL server option.

max_connect_errors

The default value is 100, and the valid range is between 1 and 2^32 (4294967295, an unsigned int).

This is similar to MySQL Server's max_connect_errors server system variable.

This can cause a slight performance penalty if an application performs frequent reconnections, because MySQL Router attempts to discover if connection-related errors are present.

A successful connection resets the error counter (as of 8.0.14).

Each routing has its own list of blocked hosts. Blocked clients receive the MySQL Server error 1129 code with a slightly different error message: "1129: Too many connection errors from fail.example.com". The Router logs contain extra information for blocked clients, such as: INFO [...] 1 authentication errors for fail.example.com (max 100) WARNING [...] blocking client host fail.example.com

max_connect_errors = 100

client_connect_timeout

This is similar to MySQL Server's connect_timeout server system variable.

The default value is 9, which is one less than the MySQL 5.7 default. The valid range is between 2 and 31536000.

client_connect_timeout = 9

auth_cache_refresh_interval

Time (in seconds) between the auth-cache refresh attempts. Defaults to 2. The value must be smaller than auth_cache_ttl and ttl else Router won't start.

This option is applied if the http_auth_backend section's backend option is set to metadata_cache; which is a Router REST API feature.

auth_cache_ttl

Time (in seconds) until the cache becomes invalid if not refreshed. Defaults to -1 (infinite). The value must be larger than auth_cache_refresh_interval else Router won't start.

This option is applied if the http_auth_backend section's backend option is set to metadata_cache; which is a Router REST API feature.

router_id

The MySQL Router ID.

server_ssl_curves

Defaults to a secure list of SSL curves. Format this string as a colon separated list of curve names.

server_ssl_cipher

Defaults to a secure list of SSL ciphers. Format this string as a colon separated list of cipher names.

server_ssl_verify

SSL Verify is set to DISABLED by default.

server_ssl_mode

SSL Mode is set to AS_CLIENT by default.

client_ssl_dh_params

If specified and not empty, the DH parameters from this file are used instead of internal default DH parameters. Format the DH param file in PEM format.

client_ssl_curves

Which curves are allowed between the client and MySQL Router, defaults to a secure list of SSL curves. Format this string as a colon separated list of curve names.

client_ssl_cipher

Which ciphers are allowed between client and MySQL Router, defaults to a secure list of SSL ciphers. Format this string as a colon separated list of cipher names.

client_ssl_mode

Controls if connections from the client to MySQL Router must be encrypted.

ssl_mode

SSL mode for connecting to the MySQL metadata server. It defaults to PREFERRED if not set.

When set to PREFERRED (the default), bootstrapping will warn when SSL is not used and connection to the metadata server is unencrypted.

Available values are DISABLED, PREFERRED, REQUIRED, VERIFY_CA, and VERIFY_IDENTITY. As with the mysql client, this value is case-insensitive.

There is also a runtime option for bootstrapping; see --ssl-mode.

bootstrap_server_addresses

Points to a list of MySQL servers with metadata that can be connected to. After the metadata has been accessed, the metadata cache switches to the servers that are present in the primary ReplicaSet to fetch the metadata. They are also known as bootstrap servers.

This option is deprecated in MySQL Router 8.0.14 and no longer generated by the bootstrap process. Instead, the dynamic_state option was added as a replacement.

user (MySQL)

A generated MySQL user with privileges to access the MySQL server's metadata schema. This user's password is auto-generated and stored in an encrypted keyring. By default, the encryption key for this keyring is stored in a read protected master key store file, which is defined in the configuration file. Most commonly, this user and associated password are automatically generated during bootstrap. Related command line options are --force-password-validation and --password-retries. By default, the generated password passes the STRONG validate_password strength.

The password is entirely managed by Router and never exposed, and is stored in a local keyring system using the operating system's account that MySQL Router is running as. It can then be used by Router to connect to InnoDB Cluster and retrieve current topology information. Sessions between Router and metadata server are encrypted with SSL by default.

Where the generated keyring files are stored depends on how bootstrap is configured. For self-contained installations (when --directory is used), it is stored under run/ in the self-contained directory. For system-wide installations, it is stored in the system-wide runtime state directory, and that path is platform specific. For additional information, see master_key_path and keyring_path

This user is assigned (and requires) the following privileges:

Privileges needed by the Router account:

	On Metadata Server:

		SELECT ON mysql_innodb_cluster_metadata.*

	On Target Replica Sets:

		SELECT ON performance_schema.replication_group_members
		SELECT ON performance_schema.replication_group_member_stats

The generated username follows this pattern: mysql_router_[0-9]{1,6}_[0-9a-z]{12}, where [0-9]{1,6} is the numeric router id and [0-9a-z]{12} is 12 random lowercase alphanumeric characters. The router id is reused if already present in mysqlrouter.conf and its length can not exceed 6 digits.

metadata_cluster

Name of the InnoDB Cluster.

use_gr_notifications

Enables Group Replication notifications. When enabled, Router is asynchronously notified about most cluster changes. It can be enabled manually in mysqlrouter.conf or enabled there using the --conf-use-gr-notifications command-line option during bootstrap.

When Router receives any of the following notifications from Group Replication, it refreshes the cluster metadata:

When enabled, the Group Replication notification feature allows a higher ttl value because the metadata refreshes carried out at ttl intervals become an additional safeguard, rather than the primary means of keeping the information about the cluster state up to date. When disabled, a low ttl value (such as 0.5s, the default) is recommended to avoid the overhead of reconnecting to the instances and querying them for metadata changes often.

ttl

Time to live (in seconds) of information in the metadata cache.

Accepts either an integer or a floating point value. The granularity is limited to milliseconds, where 0.001 equates to one millisecond. Precision is truncated to the supported range; for example ttl=0.0119 is treated as 11 milliseconds. The value 0 means that the metadata cache module queries the metadata continuously in a tight loop.

The only supported decimal separator is '.' (a period) regardless of locale, and scientific notation, such as ttl=1.6E-2, is supported.

Floating point support was added in MySQL Router 8.0.12.

destination

Direct console log output to this device destination; set under the [consolelog] section. Defaults to /dev/stderr and an empty value uses the default.

Available values are: /dev/stdout, /dev/stderr, and /dev/null; or CON and NUL on Windows.

[DEFAULT]
logging_folder=

[consolelog]
destination=/dev/null

filename

Redirect log output to a specific file named filename that resides in the logging_folder directory. It must be defined as a file name and not a file path, and works with both the [logger] and [filelog] sections.

Using filename with [logger] to define the default value for the [filelog] section, and it also changes Router's log file from mysqlrouter.log to this new value.

[DEFAULT]
logging_folder=/path/to/logs/

[logger]
filename = router_error.log

Router does not report an error if filename is set under [logger] but no file-based logger is used.

Using filename with [filelog]:

[DEFAULT]
logging_folder=/path/to/logs/

[filelog:a]
filename = a_router_error.log

[filelog:b]
filename = b_router_error.log

If filename is empty or not set under [filelog] then the filename definition under [logger] is used; and the default log file is used (mysqlrouter.log) if filename is not set under [logger] either.

Related, directing console output to /dev/null:

[DEFAULT]
logging_folder=

[consolelog]
destination=/dev/null

level

Use the logger plugin to log notices, errors, and debugging information. The available log levels are DEBUG, NOTE, INFO (default), WARNING, ERROR, SYSTEM, and FATAL. These values are case-insensitive.

The INFO level displays all informational messages, warnings, and error messages. The DEBUG level displays additional diagnostic information from the Router code, including successful routes. SYSTEM includes messages such as startup messages.

[logger]
level = DEBUG

Output behavior depends on the logging_folder option. Setting logging_folder to a folder saves a log file named mysqlrouter.log to that folder. Setting logging_folder to an empty value, or not setting it, outputs the log to the console. It is set in the [DEFAULT] section.

Bootstrapping accepts a configuration file using --config and utilizes the logger level definition.

timestamp_precision

The logger timestamp precision; the available definitions with example values are:

port

The TCP port listening for HTTP requests; it defaults to 8881.

bind_address

IP address bound to the HTTP port; it defaults to 0.0.0.0.

static_folder

Base directory for static file requests; it's empty by default. An empty value means no static files are served.

require_realm

Name of the [http_auth_realm] instance.

ssl

The value 1 enables SSL, and 0 disables it. TLS clients supporting TLSv1.2 or later are required. This is defined under the [http_server] section.

ssl_cert

File name of the certificate and its chain certifications in PEM format; required if ssl=1. This is defined under the [http_server] section.

ssl_key

File name of the key in PEM format; required if ssl=1. This is defined under the [http_server] section.

ssl_cipher

The cipher-spec (see openssl's 'ciphers' list). Defaults to a comma-separated list of all approved ciphers. Unknown ciphers are silently ignored. Fails if list of ciphers is empty and ssl=1. This is defined under the [http_server] section.

ssl_dh_param

Read the DH parameter from this file in PEM format. Uses the dh-param from RFC 5114 by default if ssl=1. This is defined under the [http_server] section.

backend

The IO backend that handles async operations. The generic poll backend is available on all platforms, while each platform may provide alternative backends.

Options are poll (all platforms) and linux_epoll (Linux). Defaults to linux_epoll on Linux.

[io]
backend=linux_epoll
threads=32

threads

The number of IO threads that handles connections.

Defaults to 0 (uses all available CPU cores/threads) but also accepts a number between 1 and 1024. At runtime the system may restrict the upper limit beyond this value.

[io]
backend=linux_epoll
threads=32

backend

Name of the [http_auth_backend] section.

method

The HTTP authentication method; defaults to basic.

name

Name of the realm presented to the authentication user.

require

Requires that the user validates with the authentication backend; defaults to valid-user, which enables this check.

backend

Name of the backend implementation; accepted values are 'file' (default) or 'metadata_cache'.

[http_auth_backend:name]
backend=metadata_cache

[metadata_cache]
auth_cache_refresh_interval=2
auth_cache_ttl=-1

filename

Name of the backend storage file, is relative to the data_folder directory.

cluster_type

The type of AdminAPI object that the Router was bootstrapped against, which is either an InnoDB ReplicaSet (rs) or InnoDB Cluster (gr).

Bootstrapping evaluates the target instance and sets this option accordingly in the generated configuration file.

This option was added in MySQL Router 8.0.19; the same version InnoDB ReplicaSet support was added.