Changes in MySQL Router 8.0.32 (2023-01-17, General Availability)

• Functionality Added or Changed

• Bugs Fixed

Functionality Added or Changed

• CPU usage was optimised by reducing the number of system calls per read/write operation. (Bug #34787879, Bug #34788019)

• A new option, use_replica_primary_as_rw is added to the MySQL Shell option <ClusterSet>.setRoutingOption().

  This option is read by MySQL Router and enables it to open or close a read-write (R/W) port on a router targeting a specific Cluster (where target_cluster is not set to primary), enabling you to use a R/W port on a ReplicaCluster. The ReplicaCluster continues to only accept R/O traffic. In the event of a switchover or failover, the R/W port remains unchanged.

  See MySQL Router Status for InnoDB ClusterSet. (WL #15321)

• The following configuration options are added to a new configuration section, [destination_status], in this release:

  • error_quarantine_interval: Defines the interval, in seconds, between checks on quarantined destination connectivity. If a connection is possible, the destination is moved out of quarantine and made available for connections.

  • error_quarantine_threshold: Defines the threshold of consecutive, failed attempts to connect to a routing destination before MySQL Router adds the destination to quarantine and stops using it as a destination until it is cleared by the quarantine mechanism. For example, if set to 5, the destination is quarantined after 5 consecutive, failed attempts to connect to it.

  The option unreachable_destination_refresh_interval is deprecated in this release. (WL #15329)

• Connection sharing is introduced in this release, extending upon the Connection Pool introduced in MySQL Router 8.0.29.

  Enabling connection sharing (connection_sharing) lets you define how long a server connection is idle (connection_sharing_delay) before it is reset and added to the connection pool, where it can be reused by another client connection.

  See Connection Sharing and Reuse. (WL #12772)

Bugs Fixed

• Connections made over Unix socket were not shared, even though connection sharing was enabled. (Bug #34806320)

• Configuring MySQL Router with client_ssl_mode=PREFERRED and server_ssl_mode=AS_CLIENT resulted in an unencrypted connection over Unix socket connections. (Bug #34801929)

• Connections through MySQL Router were not closed with COM_QUIT, incrementing the server's Aborted_clients count. (Bug #34801356)

• Under certain circumstances, such as MySQL Router running on an under-resourced server, traffic on one connection could be unfairly prioritized over other connections. (Bug #34787854)

• Pooled connections were not used if the [io] option threads value was larger than 1. (Bug #34781248)

• It was not possible to connect to the server over Unix socket, through MySQL Router, with a user configured to use caching_sha2_password. An error similar to the following was returned:

          HY000 (2013) Lost connection to MySQL server at 'reading final 
          connect information', system error: 95

  (Bug #34778017)

• Under certain circumstances, when the MySQL Router was setting up the x-protocol connection, if the client sent a valid, but unexpected message (unexpected for this phase of the setup process), the router attempted to forward it to the server, even though the server connection was not yet ready. This caused the router to close unexpectedly.

  As of this release, MySQL Router returns a Bad message error to the client, in response to the out-of-sequence message. (Bug #34597056)

• If a routing destination was removed from quarantine, reopening the bind_port could fail. If the router is part of an InnoDB cluster, an attempt is made to reopen it during a metadata cache refresh, but this is not available to statically-defined bind_port in standalone installations.

  As of this release, for standalone router installations, if reopening the bind_port fails, MySQL Router attempts to reopen it every 1 second. (Bug #34569676)

• Under certain circumstances, if max_connections was configured, attempting to connect to MySQL Router with X-Protocol resulted in an error, MySQL server has gone away, instead of the expected message: Too many connections to MySQL Router.

  This issue only occurred on Microsoft Windows platforms. (Bug #34548367)

• MySQL Router did not close connections if they were closed by the server, but not closed by the client. The connection persisted indefinitely.

  As of this release, MySQL Router closes the client connection when the server connection is closed. (Bug #34401798)

• If a socket was unexpectedly shutdown on both ends of the connection, but not closed, and the socket was still monitored by EPOLL_WAIT, EPOLLHUP or EPOLLERR events were returned. Neither event was handled, leading to a loop and high CPU usage until the socket was closed. (Bug #33674644)

• MySQL Router's logrotate did not send a HUP signal to the router process. As of this release, logrotate uses native systemctl commands when systemd is enabled. (Bug #108360, Bug #34565239)

• Under certain circumstances, on Microsoft Windows platforms, MySQL Router crashed repeatedly. (Bug #108228, Bug #34536085)