MySQL Shell 8.0.33 was released last week. Apart from several bugfixes, there are some new, important, and long-desired features related to security, concurrency control, and performance settings.

Passwordless authentication (certificate-based authentication)

The AdminAPI enables an easy set-up and maintenance of MySQL deployments, either for High Availability or Disaster Recovery. Security is crucial and InnoDB Cluster has support for SSL/TLS, however, it was limited to group communication connections between Cluster members. Similarly, InnoDB ClusterSet has support for enabling SSL on the asynchronous replication channel between Clusters.

Nevertheless, enabling certificate-based authentication in the replication machinery and SSL in ReplicaSet was not supported.

Since MySQL Shell 8.0.33, it is now possible and easy to configure MySQL InnoDB Cluster, ClusterSet, and ReplicaSet to fully use SSL/TLS and certificate-based authentication in every aspect of the deployment. Namely, to:

  • Encrypt Group Replication and Asynchronous replication channels.
    • All connections opened by replication from one endpoint to the other are encrypted and (optionally) with also performing SSL certificate verification and identity validation.
    • Configurable in:
      • InnoDB Cluster (GR channels)
      • InnoDB ReplicaSet (asynchronous channels)
      • InnoDB ClusterSet (inter-cluster asynchronous channels)
  • Enable Replicas to use certificate-based authentication
    • Authentication of internal replication accounts uses SSL certificates instead of passwords and (optionally) also verifies the identity of the source.
  • Authentication with client SSL certificates for the AdminAPI Administrator Accounts and MySQL Router accounts, or, alternatively, to configure a password expiration policy.

For more details, please stay tuned for the upcoming blog post that will cover this feature in more detail with deployment examples.

Concurrency control

It is always possible more than one administrator is using MySQL Shell simultaneously. Concurrent operations on the same MySQL deployment may suffer from unexpected results or even resource starvation. For example, if a DBA is removing a secondary member of a Cluster while another selects it to become the new primary in a switchover.

Although such scenarios won’t be common, the AdminAPI was improved to include concurrency control for all operations on InnoDB Clusters, ReplicaSets and, ClusterSets.

By making use of the MySQL Locking Service and an extensive analysis of every operation, we have introduced two types of locks to ensure proper concurrency control:

  • Read or shared lock: Allows concurrent execution of some operations while blocking exclusive operations.
  • Write or exclusive lock: blocks execution of all other operations until the current operation is complete.

The following table lists the types of locks for InnoDB ClusterSet commands:

AdminAPI Locks ClusterSet

For more information and the list of locks for all management operations, please see https://dev.mysql.com/doc/mysql-shell/8.0/en/adminapi-locking.html

Enable Paxos single leader

MySQL Group Replication is based on the Database State Machine Approach and uses a Paxos implementation.

By default, Paxos operates using every member of the Cluster as a Leader, even in single primary mode. As of MySQL Shell 8.0.33, it is possible to configure the Cluster to use a single leader on creation:

cluster = dba.createCluster("myCluster", {paxosSingleLeader: true})
replica_cluster = clusterset.createReplicaCluster("myReplica", {paxosSingleLeader: true})

This configuration improves performance and resilience, particularly when when secondary members are unreachable.

With this release, not only the AdminAPI enables configuring Clusters to use a single paxos leader but also ensures new members added to the Cluster are automatically configured accordingly.

It also permits switching to a different setting while rebooting a Cluster from complete outage and, additionally, includes information about it in the monitoring commands.

dba.rebootClusterFromCompleteOutage("myCluster", {paxosSingleLeader: false})

Note: This can only be set by MySQL Shell on MySQL Server 8.0.31, or higher, because MySQL Shell requires the information provided by WRITE_CONSENSUS_SINGLE_LEADER_CAPABLE in the Performance Schema table replication_group_communication_information

MySQL Enterprise Authentication Plugins

MySQL Shell now bundles the following client authentication plugins:

MySQL Shell Dump & Load

  • The Dump Loading utility (loadDump()) progress file now includes information on index creation status.
  • AWS S3: Retry if the request fails with a HTTP 400 error and the reported error is ExpiredToken or TokenRefreshRequired

Notable Bugfixes

Bug#108905 (community), Bug#34778797

The AdminAPI disabled and persisted offline_mode when an instance was added or rejoined to a Cluster, either at Cluster creation time or when rebooting from a complete outage. If this variable was enabled explicitly by the user, it was silently overwritten by MySQL Shell.

As of this release, offline_mode is disabled globally, not persisted, and a new warning is added to Cluster.status to inform the user of the risks of enabling this variable.

Bug#108759 (community), Bug#34711038

When adding a member to a cluster, the values of auto_increment_increment and auto_increment_offset were miscalculated and were off by 1. As a result, when adding or rejoining an eighth member to a cluster, the new member was configured with the correct values, while the other seven members continued with the configuration of a seven-member cluster.

Bug#34837601

If using ‘NO_BACKSLASH_ESCAPES‘ in the Server’s SQL Mode (sql_mode), creating a Replica Cluster (ClusterSet.createReplicaCluster()) failed with an error “malformed GTID SET”.

This was caused by a wrong initialization of the AdminAPI internal connetion after a clone-based recovery finishes.

Bug#34324165

The ‘globalStatus’ value of a Replica Cluster, returned by ClusterSet.status(), was incorrectly reported as NOT_OK if the ClusterSet’s primary Cluster was unreachable, but the Replica was functioning normally.

The value has been corrected to OK_NOT_REPLICATING, which truthfully indicates the Replica is functioning normally but is not replicating since the Primary Cluster is offline or unreachable.

More Information

Find the full list of features and bugfixes on https://dev.mysql.com/doc/relnotes/mysql-shell/8.0/en/news-8-0-33.html

As always, we are eager to listen to the community feedback. You can reach us at #shell and #mysql_innodb_cluster in Slack: https://mysqlcommunity.slack.com/

If you encounter a problem or a missing feature, please reach out to us via a bug report, or a support ticket.

Resources:

  • Download our MySQL Community Shell & Server packages at https://dev.mysql.com/downloads/.
  • MySQL Enterprise binaries are available on My Oracle Support: https://support.oracle.com (Choose the “Patches & Updates” tab, and then choose the “Product or Family (Advanced Search)” side tab in the “Patch Search” portlet.)
  • or use Oracle Software Delivery Cloud on http://edelivery.oracle.com/ to download MySQL Enterprise binaries.

Enjoy, and Thank you for using MySQL!