MySQL Blog Archive
For the latest blogs go to
MySQL InnoDB Cluster - What's New in the GA Release

We carefully listened to the feedback we got from the last release candidate and incorporated some of the suggested changes. On top of that, we have fixed several bugs to reach the desired maturity state.

Here are the highlights of this release!

MySQL Shell

For this release we have focused on fixing bugs within the AdminAPI (dba.*) and core Shell functionality in order to reach GA status. Below are some important highlights, starting with the one new feature that was added.

Vertical results

Queries which return a resultset containing many columns can be difficult to virtually impossible for a human to read. For example:

By introducing the support for displaying the SQL result vertically we overcome this issue. Also, a new command-line option to display all result sets vertically was added:

  • --vertical (or -E)

So now coming back to the original example, this time displaying the results vertically by ending the statement with “\G” instead of “;” (just as in the mysql command-line client):


In the scenario where we lack permissions to read or edit the MySQL configuration file, dba.configureLocalInstance() failed with a confusing and unclear error: “Unexpected error checking instance: append() takes exactly one argument (2 given)”.

The cause of this internal issue was fixed and a clear error message was added which states the actual problem:


Having online help available directly within the client is certainly very convenient to obtain information about all of the AdminAPI commands. Each global object of the Shell has its own helper method which can be executed using .help():

However, if you tried to obtain the help for dba.checkInstanceConfiguration() you noticed that the output was completely empty. This has been addressed as shown below:

Dissolving a Cluster

One would expect that after dissolving a cluster, the cluster object would become invalid–thus returning an error when used–since the cluster is dissolved. However, before 1.0.9 GA, this wasn’t entirely true and several inconsistent and erroneous scenarios could occur as a result.

Proper invalidation was added in this release so the user gets an error when you try to execute any method on a previously dissolved cluster:

Metadata Not in Sync With Topology Change

If a change in the cluster’s topology happened due to manually changing from the default single primary mode to multi-primary then the metadata wasn’t getting updated properly. This lead to erroneous behavior within the InnoDB cluster.

For example, when turning off single primary mode (group_replication_single_primary_mode=OFF), one could see incorrect status output like the following:

As you can see, the cluster status output is wrong, since it shows all instances as being in read-only mode when they should all be read-write. Apart from the wrong status output, the metadata still contained information marking the cluster’s topology as single-primary.

This issue has been fixed so that both the cluster status and metadata information are correctly updated when there’s any change to the topology.


One of the critical features of the AdminAPI is adding MySQL Server instances to a cluster by using a simple and straightforward command: cluster.addInstance(). However, in the past it would allow you to specify "localhost" when doing so, rather than a valid IP address or hostname. This could lead to later issues, so we now enforce the correct procedure, which is: in order to deploy a cluster using remote instances, first connect to the instance on which the cluster will be initialized using a valid IP address or hostname, and then create the cluster. For example:

SSL Support on Windows

If the user’s Python installation didn’t support SSL, an error would occur making it impossible to move forward on a cluster setup through an SSL connection:

This has been greatly improved by providing a clear error message indicating to the user what should be done:


mysqlprovision is one of the core internal components of the AdminAPI that is used “under the hood” for much of the orchestration. We also fixed a number of issues with this internal component in the GA release.

Since mysqlprovision is a separate binary (deployed together with the Shell), there was the option and in some cases a need to set a value for the MYSQLPROVISION environment variable. This environment variable has been removed.

If one requires or decides to build the Shell from source, the mysqlprovision binary wasn’t being built by default. That has also been fixed for this release.

Access to Schema Objects

Before GA, access to schema objects using the property syntax wasn’t automatically available upon Shell initialization. Not even if the global schema was specified on the connection data, nor after changing the global schema with \use. For example:

To be able to use the property syntax, one had to perform a db.getCollection() operation first.

This has now been fixed by automatically updating the schema cache on the following times:

  • When establishing a global session with a default schema via the \connect command
  • When establishing a global session with a default schema via the shell.connect function
  • When establishing a global session with a default schema through command line arguments
  • When changing the global schema via the \use command

Crash When Executing a Print in Python Mode

When executing print while in Python mode via the --execute option, a crash of the Shell would occur:

This has been fixed in this release.

Failure Importing a Dump File With Multi-Line Comments

Another bug fixed in this release is a failure that happened when importing an SQL dump file which contained multi-line comments (which is quite common).

In addition to fixing that specific issue, we have also added support for:

  • Multi-line MySQL Extensions (the /*! MySQL-specific code */ syntax)
  • Single-line Optimizer Hints
  • Multi-line Optimizer Hints

Global DB Object Properties Could Change Their Semantics at Runtime

Shadowing of object properties could happen, leading to inconsistent behaviour.

For example, the “name” property of a schema, could later be displayed as a table object:

As you can see, printed the name of the database while there could also be a table in the schema with the name “name”, e.g. storing customer names. is now fixed to return the actual table object. The schema name must now be accessed by calling the db.getName() function on the schema object. For example:

This was related to how cached objects were given precedence. Now, on object retrieval, the cache is accessed only if the requested member is not a fixed member of the class.

MySQL Router

The main focus for MySQL Router was also on bug fixing, just as with MySQL Shell. Still, one new feature as added.

Scanning for Configuration Files

We added functionality to scan for Router configuration files with the .ini extension, to provide backwards compatibility with previous Router versions. Router also looks in the initial directory for the .conf version, then checks for a .ini version, and then repeats the process in the second directory that’s typically the user’s home directory.

Wrong Default Configuration Files on Linux Services

On systemd based Linux distributions the mysqlrouter.service file specified a default configuration file of /etc/mysqlrouter/mysqlrouter.ini, while the MySQL Router 2.1 binary now uses /etc/mysqlrouter/mysqlrouter.conf.

This led to MySQL Router running without the expected configuration.

Super User Bootstrapping Issue

On UNIX/Linux, when bootstrapping the Router as the super-user (using sudo), the configuration file was owned by the super-user and not accessible by others. If the router was installed as a service–and since systemd uses the mysqlrouter user–the Router would not be able to read its configuration file.

We have fixed this issue by adding a new requirement for the bootstrap operation when using a super-user account, which is that you must explicitly specify a user account to use with the --user option. Still, using a super user for bootstrapping it not recommended.

OpenSSL Build Failures

The Router wouldn’t build using OpenSSL, but only using yaSSL. This has been fixed and now one can build the Router using OpenSSL.

MySQL Router Failed to Start on Solaris

Before the GA release it was impossible to start the Router on Solaris due to an error loading the logger library. This has been fixed in this release.

Unit-Test Failures on FreeBSD

On FreeBSD some unit-tests were failing due to the lack of some exception handling.


After two labs releases and a subsequent Release Candidate, we are proud to announce the General Availability (GA) release!

We have reached a state of maturity for the components of InnoDB Cluster, both in terms of features and stability, which fulfill our intended goals and requirements for the first release. Our continuous work to improve the ease-of-use and accessibility of the High Availability technologies now baked into MySQL has reached the first milestone!

But we also have many more milestones to come, as we continue our efforts in simultaneously making MySQL easier for the common user and giving full advanced control and capabilities to power users. And throughout this process we will be eagerly listening to the community and analyzing all of the feedback given in order to help us improve InnoDB Cluster–always having the mindset that we want to bring simplicity and power together.

We are looking forward to your feedback! Please let us know your thoughts here in the comments, via a bug report, or a support ticket.

Thank you for using MySQL!