MySQL InnoDB Cluster – Extended cluster information and rescan

This blog post completes the series that we have been composing to detail every single new feature added in the latest MySQL InnoDB Cluster release, as mentioned in the release announcement of 8.0.14. We’ll close the series now with the details about the new features that improve the management capabilities of MySQL Shell: “Extended status information available from <Cluster.>status()” and “Redesigned and extended <Cluster.>rescan()”.

Extended status information available from <Cluster.>status()

MySQL Shell is the frontend management tool of InnoDB cluster, providing the AdminAPI to deploy, configure, and manage InnoDB clusters easily and without the technical knowledge and experience needed to manually set up Group Replication.

Creating and managing a cluster implies monitoring its status and current configuration. And with the <Cluster.>status() being one of the most widely AdminAPI commands, it got the spotlight on this release leading to several improvements and extensions.

Considering that Group Replication provides several metrics and detailed information about the underlying group in InnoDB clusters, we have analyzed and assessed which information should be also provided by the AdminAPI in its <Cluster.>status() command.

For that purpose, we have added two new options to the <Cluster.>status() command:

  • extended: if enabled, includes information about groupName and memberID for each member; and general statistics about the number of transactions checked, proposed, and rejected by members

  • queryMembers: if enabled, includes information about recovery and regular transaction I/O, applier worker thread statistic and any lags; applier coordinator statistic; if parallel apply is enabled; errors, and other information from I/O and the applier thread.

On top of that, in previous versions the URI-type string shown in the field ‘groupInformationSourceMember’ could be erroneous depending on whether the DBA was connecting to the Cluster through the MySQL Router or not. If the session established to the cluster was done through the Router, this field would show the Router’s address rather than the address of the instance which provided the displayed group information causing confusion. This has been improved to ensure groupInformationSourceMember always shows the correct hostname (or report_host) value and port (or report_port) value of the instance which provided the group information.

Redesigned and extended <Cluster.>rescan()

MySQL Shell is the frontend management tool of InnoDB Cluster, providing the AdminAPI to deploy, configure, and manage InnoDB clusters easily and without the technical knowledge and experience needed to manually set up Group Replication. However, if for some reason a DBA manually adds a MySQL server to an existent InnoDB cluster without using the Shell the server won’t be fully managed by InnoDB cluster as the Metadatada does not contain information about it. Also, whenever adopting an existing Group Replication group into InnoDB cluster the Metadata needs to be updated accordingly.

To manage this kind of scenarios, the AdminAPI includes the <Cluster.>rescan() command which, apart from several verifications and operations, rescans the cluster for new and obsolete Group Replication members/instances, as well as changes in the used topology mode (i.e., single-primary and multi-primary).

This command was originally implemented with interactive execution of MySQL Shell in mind, but not to be used in a script. To overcome this limitation, and meet the goals and expectations of a modern API, we have redesigned and extended the <Cluster.>rescan() command.

Up to now, if the command detected a new or obsolete instance, it would prompt the user to act accordingly (add or remove it from the cluster’s Metadata). But in non-interactive mode (e.g. in a script) the command would not do anything nor allow the caller to set the action desired. Therefore, the command was extended with the following new options:

  • addInstances: Option to specify a list with the connection data of the new active instances to add to the metadata, or “auto” to automatically add missing instances to the metadata.
  • removeInstances: Option to specify a list with the connection data of the obsolete instances to remove from the metadata, or “auto” to automatically remove obsolete instances from the metadata.
  • updateTopologyMode: If used, the function will detect if the Group Replication mode (single-primary or multi-primary mode) registered in the metadata matches the current mode of the cluster, updating that information in the metadata.
  • interactive: Boolean value used to disable/enable the wizards in the command execution, i.e. prompts and confirmations will be provided or not according to the value set. The default value is equal to MySQL Shell wizard mode.

Try it now and send us your feedback

MySQL Shell 8.0.14 GA is available for download from the following links.

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.

Enjoy, and Thank you for using MySQL!

About Miguel Araújo

Miguel Araújo is a Senior Software Engineer on the MySQL Team, at Oracle. He's the Tech Lead of the AdminAPI, core component of MySQL InnoDB Cluster, at the MySQL Shell team. In the past, he has worked on different projects and teams, mostly related to Middleware and High-Availability. He has a Computer Science Engineering degree and Master's degree, from the University of Minho, Portugal, where he was also a researcher. His backgrounds are on distributed systems, scalability, database replication and high-availability. He is based in Portugal.

One thought on “MySQL InnoDB Cluster – Extended cluster information and rescan

Leave a Reply

Your email address will not be published. Required fields are marked *