The MySQL Development Team is very happy to announce a new 8.0 GA Maintenance Release of InnoDB Cluster – 8.0.16!
In addition to important bug fixes, 8.0.16 brings very useful new features!
This blog post will cover MySQL Shell and the AdminAPI, for detailed information of what’s new in MySQL Router stay tuned for an upcoming blog post!
MySQL Shell
For this release, we focused on extending the AdminAPI with several highly desired features. But also, as always, we extended it to support every new Group Replication feature. On top of that, many bug fixes were addressed.
Here are the highlights of this release:
- Provide information about the version of MySQL running on the cluster members
- Enable configuration of how many times an instance tries to rejoin a cluster after being expelled
- Support automatic handling of Group Replication protocol versions
There’s also a new feature, not entirely related with the AdminAPI but rather with DevOps and/or DBAs operations, which greatly improves the usability and makes it even more pleasant to use the MySQL Shell:
- Execute an SQL statement without changing to SQL mode and back again afterwards
Information about the MySQL version
The AdminAPI provides commands to obtain the information or status of a cluster. However, the information about the MySQL Server version running on each cluster member was not available.
Since clusters can be set up with instances of different versions, the information about the MySQL version running on the instances was added to the relevant AdminAPI commands. In addition, this improves the observability capabilities of the AdminAPI.
<Cluster>.status() now provides the information about the MySQL Server version running on each cluster members in a new attribute named version. By default, it provides the information if the current session is established to an 8.0 instance, however, when using 5.7 the command is only available to display the version information if the queryMembers option is enabled.
<Cluster>.status() – 8.0
<Cluster>.status() – 5.7
<Cluster>.rescan(), which is a very useful command to verify if there are any unexpected topology changes in an InnoDB cluster, has been extended to provide the information of the MySQL version of an instance which was found to be part of the cluster but not managed by the AdminAPI. This feature is only available if the <Cluster> object session is established to an 8.0 instance.
<Cluster>.rescan() – 8.0
Defining auto-rejoin for cluster members
Whenever a cluster member is detected as not working correctly, Group Replication’s failure detection mechanism expels it from the cluster. By default, the failure detector waits 5 seconds after a particular member is not communicating with the others and immediately expels it from the cluster. This increases the chance of having a cluster with the majority of members working correctly thus processing correctly the client’s requests. However, in some scenarios such as slow or flaky networks, or even networks with a high rate of transient failure, this can be very inconvenient. To avoid undesired member expels, now it’s possible to configure a number of automatic rejoins. A member that is able to resume the communication with the cluster can automatically try to rejoin the cluster, for a finite number of times.
Note: By default, the auto-rejoin setting is zero.
The AdminAPI has been extended to support defining such behavior. The following commands have been extended with a new option, named autorejoinRetries, that accepts positive integers between 0 and 2016:
dba.createCluster()<Cluster>.addInstance()<Cluster>.setOption()<Cluster>.setInstanceOption()
If feasible and it suits the DBA needs, the option can be set on all the members of the cluster, by using the <Cluster>.setOption() command.
Automatic handling of Group Replication protocol versions
With this 8.0.16 release, Group Replication introduces support for Data Fragmentation within its communication protocol. This ensures that larger transactions can be fragmented into smaller units enabling a higher rate in the communication layer. This support was introduced with a new protocol version, which is enabled by default. However, upgrade scenarios or members with different protocol versions can be troublesome. Having this in mind, and with usability being the top priority of the AdminAPI, 8.0.16 brings automatic and transparent handling of protocol versions.
In more detail, if an instance wants to join a cluster but does not support the cluster’s protocol version, it won’t be able to join it. Also, whenever upgrading the cluster members to a higher version, the protocol won’t be automatically upgraded to the latest available and supported version.
In 8.0.16, whenever the cluster topology is changed, the AdminAPI automatically and transparently manages the communication protocol version of its members ensuring the most recent protocol version supported is used by all instances that are part of the cluster or joining it. All of this configuration is automatic and does not require intervention from the DBA.
On top of that, <Cluster>.status() has been extended to include the information about the Group Replication Communication Protocol in its output, whenever the flag extended is enabled. That information is displayed in the new attribute named GRProtocolVersion.
Executing SQL without switching mode
A DBA/DevOps Engineer working with MySQL Shell and managing a cluster using the AdminAPI in either JavaScript or Python may need to execute some SQL statement. Up to now, that would require changing to SQL mode and then back to JS or PY mode to execute a single SQL command:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
mysql-js> \c root@localhost:3306 mysql-js> var cluster = dba.getCluster() mysql-js> \sql; Switching to SQL mode... Commands end with ; mysql-sql> SELECT "Hello, world!"; +--------------+ | hello world! | +--------------+ | hello world! | +--------------+ mysql-sql> \js Switching to JavaScript mode... mysql-js> cluster.status() |
In 8.0.16 a new feature has been introduced which allows executing a SQL query without changing mode. This greatly improves the usability of MySQL Shell. Example:
|
1
2
3
4
5
6
7
8
9
|
mysql-js> \c root@localhost:3306 mysql-js> var cluster = dba.getCluster() mysql-js> \sql SELECT "Hello, world!"; +--------------+ | hello world! | +--------------+ | hello world! | +--------------+ mysql-js> cluster.status() |
For more details, please stay tuned for the upcoming MySQL Shell release blog post that will cover this feature in more detail.
Notable Bugs fixed
For the full list of bugs fixed in this release, please consult the changelog. However, there are some that deserve the spotlight!
BUG#28285389 – Target Member Hostname Should Be Taken From Hostname Or Report_host Sysvars
The AdminAPI used the host value of the provided connection parameters as the hostname to register the instance in the Metadata. However, that host might not match the hostname that is reported by Group Replication. This could be a source of problems because an instance can be identified through multiple addresses (IP values, hostname, ‘localhost’, etc.) and other components need a canonical address to rely on. Now, the AdminAPI ensures that the canonical address is used to register the instance in the Metadata and for the Group Replication local address setting.
BUG#28812763 – Auto Correct Auto_increment_increment For Cluster Size > 7 To Prevent Collisions
Up to now, the algorithm to determine the best values for the auto_increment_increment and auto_increment_offset values was the following:
|
1
2
3
4
5
6
7
|
IF single-primary-mode set auto_increment_increment = 1 set auto_increment_offset = 2 ELSE set auto_increment_increment = 7 set auto_increment_offset = 1 + server_id % 7 ENDIF |
However, duplicate auto-increment values may arise with clusters that have more than 7 members. If a user plans to run a cluster with more than 7 members in
multi-primary mode, then a manual reconfiguration of the auto-increment settings was required.
To support such scenarios correctly, the algorithm was extended as follows:
|
1
2
3
4
5
6
7
8
|
IF single-primary-mode set auto_increment_increment = 1 set auto_increment_offset = 2 ELSE set auto_increment_increment = n set auto_increment_offset = 1 + server_id % n where n is the size of the GR group if > 7, otherwise n = 7. ENDIF |
BUG#29356599 – Failoverconsistency Purpose And Behavior Erroneous And Confusing
The failoverConsistency option name was not consistent with the target group replication system variable name. In addition, all of the allowed values were not documented leading to confusion regarding what should be expected when the option is assigned a specific value.
In 8.0.16, the failoverConsistency option was deprecated in favor of a consistency option, that supports all the values that Group Replication supports.
BUG#29308037 – Not Delete Mysql_innodb_cluster_rxxx@’localhost’
The community’s engagement with MySQL Shell continues increasing and the proof of it was a code contribution in this release. Even though the contribution wasn’t fully correct due to recent changes, it was a base to fix a bug seen whenever a rollback of the dba.createCluster() command happened that would not remove the created accounts.
Try it now and send us your feedback
MySQL Shell 8.0.16 GA is available for download from the following links:
- MySQL Community Downloads website: https://dev.mysql.com/downloads/shell/
- MySQL Shell is also available on GitHub: https://github.com/mysql/mysql-shell
And as always, we are eager to listen to the community feedback! So please let us know your thoughts here in the comments, via a bug report, or a support ticket.
You can also reach us at #shell and #router in Slack: https://mysqlcommunity.slack.com/
The documentation of MySQL Shell can be found in https://dev.mysql.com/doc/mysql-shell/8.0/en/ and the official documentation of InnoDB cluster can be found in the MySQL InnoDB Cluster User Guide.
The full list of changes and bug fixes can be found in the 8.0.16 Shell Release Notes.
Enjoy, and Thank you for using MySQL!