The Cluster.status() operation has been extended to enable you to display information about the underlying Group Replication group used by the cluster. Now you can retrieve information from all members of a cluster without having to connect to each member individually.

To see information about the groupName and memberId; and general statistics about the number of transactions checked, proposed, and rejected by members issue:

Cluster.status({extended:true})

To see information about recovery and regular transaction I/O, applier worker thread statistics and any lags; applier coordinator statistics, if parallel apply is enabled; error, and other information from I/O and applier threads issue:

Cluster.status({queryMembers:true})

In addition, in previous versions the URI-type string shown for groupInformationSourceMember in the output of Cluster.status() could be the cluster's MySQL Router address, rather than the address of the instance which provided the displayed group information. 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. (Bug #28636963, Bug #26519466, Bug #27824265, Bug #28366027, WL #11997)

AdminAPI no longer relies on the mysqlprovision check command. This work has resulted in the following:

(WL #12006)

References: See also: Bug #28737777, Bug #27305806, Bug #28768627, Bug #27702439, Bug #28733883.

When you create a cluster, you can set the timeout before instances are expelled from the cluster, for example when they become unreachable. Pass the new expelTimeout option to the dba.createCluster() operation, which configures the group_replication_member_expel_timeout variable on the seed instance. All instances running MySQL server 8.0.13 and later which are added to the cluster are automatically configured to have the same group_replication_member_expel_timeout value as configured on the seed instance. (WL #12050)

You can now configure an InnoDB Cluster's mode while the cluster remains online. This enables you to configure the underlying Group Replication group to choose a specific instance as the new primary in single-primary mode, or to change between multi-primary and single-primary modes without taking the cluster offline. This uses the group coordinator and the functions added in WL#10378, see Configuring an Online Group. Use the following operations:

(WL #12052)

You can now check and modify the settings in place for an InnoDB Cluster while the instances are online. To check the current settings of a cluster, use the following operation:

This work also enables you to configure the InnoDB Cluster options at a cluster level or instance level, while instances remain online. This avoids the need to remove, reconfigure and then again add the instance to change InnoDB Cluster options. Use the following operations:

The way which you use InnoDB Cluster options with the operations listed depends on whether the option can be changed to be the same on all instances or not. These options are changeable at both the cluster (all instances) and per instance level:

This option is changeable at the per instance level only:

These options are changeable at the cluster level only:

(WL #11465)

The Cluster.rescan() operation has been extended to enable you to detect changes to the cluster's topology, and modify the cluster metadata, for example to remove old instance data. Now you can:

(WL #10644)

References: See also: Bug #28997465, Bug #28529362, Bug #28889563, Bug #25675665, Bug #28542904.

In 8.0.14, Group Replication introduces the ability to specify the failover guarantees (eventual or “read your writes”) if a primary failover happens in single-primary mode (see WL#11123). Configure the failover guarantees of an InnoDB Cluster at creation by passing the new failoverConsistency option to the dba.createCluster() operation, which configures the group_replication_consistency system variable on the seed instance. This option defines the behavior of a new fencing mechanism used when a new primary is elected in a single-primary group. The fencing restricts connections from writing and reading from the new primary until it has applied any pending backlog of changes that came from the old primary (sometimes referred to as “read your writes”). While the fencing mechanism is in place, applications effectively do not see time going backward for a short period of time while any backlog is applied. This ensures that applications do not read stale information from the newly elected primary.

The failoverConsistency option is only supported if the target MySQL server version is 8.0.14 or later, and instances added to a cluster which has been configured with the failoverConsistency option are automatically configured to have group_replication_consistency the same on all cluster members that have support for the option. The variable default value is controlled by Group Replication and is EVENTUAL, change the failoverConsistency option to BEFORE_ON_PRIMARY_FAILOVER to enable the fencing mechanism. Alternatively use failoverConsistency=0 for EVENTUAL and failoverConsistency=1 for BEFORE_ON_PRIMARY_FAILOVER.

(WL #12067)

The default value for group_replication_exit_state_action is ABORT_SERVER, but AdminAPI now overrides this and sets the default on instances to READ_ONLY. This ensures that instances which leave the group unexpectedly continue running and can be rejoined to the cluster. (Bug #28701263)

When a cluster was created on a server that did not have the X Plugin enabled, a silent assumption was being made about the X Protocol port value. Now the value of an X Protocol port is only stored for instances on which X Plugin is enabled. (Bug #27677227)

The dba.checkInstanceConfiguration() operation was not checking if the Performance Schema was enabled on the target instance. This could result in a situation where you could create a cluster but could not run several management operations on it, for example the Cluster.status() operation. Now, dba.checkInstanceConfiguration() checks that the Performance Schema is enabled on instances. (Bug #25867733)

When Cluster.checkInstanceState() was executed on an instance which was already a member of the current cluster, the output indicated that the instance was fully recoverable. This was misleading and was caused by a missing validation to ensure the instance does not belong to a cluster. (Bug #24942875)

The dba.checkInstanceConfiguration() operation did not recognize privileges when they were associated to a user through a role (available in MySQL server 8.0 and higher). In such a case, a missing privileges error was being incorrectly issued despite the user possessing all the required privileges. Now users with their privileges assigned by roles are recognized by AdminAPI operations correctly. (Bug #91394, Bug #28236922)

X DevAPI: The Table and Collection objects now support the .count() method, part of the X DevAPI. (WL #12447)

When started from the command line, MySQL Shell prints information about the product, information about the session (such as the default schema and connection ID), warning messages, and any errors that are returned during startup and connection. You can now suppress printing of information that you do not need by using the --quiet-start[=1|2] mysqlsh command-line option. With a value of 1 (the default when the option is specified), information about the MySQL Shell product is not printed, but session information, warnings, and errors are printed. With a value of 2, only errors are printed.

As part of this work, the printed information was tidied up so that the information about the MySQL Shell product is printed before the information about the session. Also, the handling of error printing was normalized to send diagnostic data to stderr, and errors to stdout. (Bug #28833718, Bug #28855291, WL #12631)

MySQL Shell connections using classic MySQL protocol now support compression for information sent between the client and the server. You can specify compression when you start MySQL Shell and connect using command line options, or in a URI string or a key-value pair when you create a session using other interfaces. You can also use the MySQL Shell configuration option defaultCompress to enable compression for every global session.

For MySQL Shell connections that use Unix socket files, the --socket command line option can now be specified with no argument to connect using the default Unix socket file for the protocol. (Bug #28730149, WL #12537)

The MySQL Shell JSON import utility can now process BSON (binary JSON) data types that are represented in JSON documents. The data types used in BSON documents are not all natively supported by JSON, but can be represented using extensions to the JSON format. The import utility can process documents that use JSON extensions to represent BSON data types, convert them to an identical or compatible MySQL representation, and import the data value using that representation. The resulting converted data values can be used in expressions and indexes, and manipulated by SQL statements and X DevAPI functions.      

To convert JSON extensions for BSON types into MySQL types in this way, you must specify the convertBsonTypes option when you run the import utility. Additional options are available to control the mapping and conversion for specific BSON data types. If you import documents with JSON extensions for BSON types and do not use this option, the documents are imported in the same way as they are represented in the input file. (WL #12134)

A MySQL Shell configuration option showColumnTypeInfo and command line option --column-type-info have been added to display metadata for each column in a returned result set, such as the column type and collation. The metadata is printed before the result set, and is only shown in SQL mode.

In the metadata, the column type is returned as both the type used by MySQL Shell (Type), and the type used by the original database (DBType). For MySQL Shell connections using classic MySQL protocol, DBType is as returned by the protocol, and for X Protocol connections, DBType is inferred from the available information. The column length (Length) is returned in bytes. (WL #12426)

The upgrade checker utility provided by MySQL Shell, which is the checkForServerUpgrade() function of the util global object, has several enhancements:

You can access the upgrade checker utility from within MySQL Shell or start it from the command line. For instructions and further information, see MySQL Shell Utilities. (WL #12506)

MySQL Shell can print results in table, tabbed, or vertical format, or as pretty or raw JSON output. From MySQL Shell 8.0.14, the new MySQL Shell configuration option resultFormat can be used to specify any of these output formats as a persistent default for all sessions, or just for the current session. Changing this option takes effect immediately. Alternatively, the new command line option --result-format can be used at startup to specify the output format for a session. The existing command line options --table, --tabbed, and --vertical are now aliases for the --result-format option given with the corresponding value.

The existing command line option --json controls JSON wrapping for all MySQL Shell output from a session. Specifying --json or --json=pretty turns on JSON wrapping and generates pretty-printed JSON. Specifying --json=raw turns on JSON wrapping and generates raw JSON. With any of these options, the value of the resultFormat MySQL Shell configuration option is ignored. Specifying --json=off or not specifying the --json option turns off JSON wrapping, and result sets are output as normal in the format specified by the resultFormat configuration option.

The outputFormat MySQL Shell configuration option is now deprecated. This option combined the JSON wrapping and result printing functions, which have now been separated. If this option is still specified in your MySQL Shell configuration file or scripts, the behavior is as follows:

(WL #12141)

The V8 library used by MySQL Shell has been updated to version 6.7.288.46. (WL #12264)

The TAR build of MySQL Shell comes with Python 2.7. When attempting to include the site package, an error was emitted because of missing build files needed by the include. (Bug #28973138)

Handling procedures for user-supplied data in MySQL Shell were refactored to ensure correct cleanup after use. (Bug #28915716)

The exception type and error messages returned by MySQL Shell functions for parameter errors have been standardized across the different functions. (Bug #28838958)

MySQL Shell stopped unexpectedly if the shell.setCurrentSchema() method was called to set the default schema before an active session had been established. MySQL Shell now validates that there is an active session when the operation takes place. (Bug #28814112)

The MySQL Shell JSON import utility no longer requires an empty dictionary to be supplied if there are no import options. (Bug #28768585)

In SQL mode, MySQL Shell does not add statements to the history if they include the strings IDENTIFIED or PASSWORD, or other strings that you configure using the --histignore command option or shell.options["history.sql.ignorePattern"]. However, this previously meant that filtered-out statements were not available to be corrected immediately after entry, and had to be re-typed in case of any errors. MySQL Shell now always makes the last executed statement available to be recalled by pressing the Up arrow, regardless of the filters set in the history ignore list. If filtering applies to the last executed statement, it is removed from the history as soon as another statement is entered, or if you exit MySQL Shell immediately after executing the statement. (Bug #28749037)

The result printing logic in MySQL Shell has been refactored to use back-end rather than high-level result data, delivering performance improvements for all types of result data and more accurate representation for JSON data. (Bug #28710831)

A memory leak was fixed that occurred when the new MySQL Shell command-line syntax was used. (Bug #28705373)

The check for partitioned tables in shared tablespaces in the upgrade checker utility provided by MySQL Shell (the util.checkForServerUpgrade() operation) did not return correct results for the 8.0.11 and 8.0.12 target versions. The check now uses alternative Information Schema tables that are populated with the required information in these versions. (Bug #28701423)

The MySQL Shell command \option ignored additional arguments separated by spaces that were specified for an option after the initial value. (Bug #28658632)

MySQL Shell permitted newline characters (line feed and carriage return) in passwords to be passed to a Secret Store Helper using the shell.storeCredential method, resulting in an error in the Secret Store Helper. MySQL Shell now returns an exception if newline characters are used in supplied passwords for the shell.storeCredential method, and does not pass them to the Secret Store Helper. (Bug #28597766)

On the Windows platform, UTF-8 encoded strings were printed to the console using the cout object, which transfers a byte at a time. This resulted in multi-byte Unicode characters, such as a single quotation mark, being displayed and handled incorrectly. MySQL Shell now uses alternative functions for printing, and verifies that multi-byte UTF-8 characters are emitted as a complete unit. (Bug #28596692)

When executing an SQL script in MySQL Shell, an inaccurate line number was reported for the location of syntax errors in the script. The number referenced the current SQL block rather than the line number in the script. The error message now uses the global line number. (Bug #28545982)

The SQL statement splitting logic in MySQL Shell has been refactored to fix a number of issues and to match behaviors of the MySQL command-line tool mysql:

(Bug #27959016, Bug #25689071)

The handling of Windows named pipe connections by MySQL Shell has been improved and systematized. Now, if you specify the host name as a period (.) on Windows, MySQL Shell connects using a named pipe.

By default, the pipe name MySQL is used. You can specify an alternative named pipe using the --socket option or as part of the URI type string. If a URI type string is used, the named pipe must be prepended with the characters \\.\ as well as being either encoded using percent encoding or surrounded with parentheses, as shown in the following examples:

(\\.\named:pipe)
\\.\named%3Apipe

(Bug #27381738)

When JSON format output was enabled for MySQL Shell, the properties of the Shell API Options class (shell.options) and AdminAPI Cluster class (dba.getCluster) were not printed, only the class name. (Bug #25027181)