Support for the TLSv1 and TLSv1.1 connection protocols is removed from MySQL Server as of release 8.0.28. The protocols were deprecated from MySQL 8.0.26. For background, refer to the IETF memo Deprecating TLSv1.0 and TLSv1.1. Make connections between MySQL Shell and MySQL Server using the more-secure TLSv1.2 and TLSv1.3 protocols. TLSv1.3 requires that both the MySQL server and the client application be compiled with OpenSSL 1.1.1 or higher.

If you attempt to make a connection using TLS/SSL from any version of MySQL Shell to a MySQL Server instance at 8.0.28 or above, and you specify the TLSv1 or TLSv1.1 protocol using the --tls-version option, you will see the following results:

(WL #14771)

When you create an InnoDB Cluster, InnoDB ClusterSet, or InnoDB ReplicaSet using MySQL Shell 8.0.28 and later, if you have security requirements that all accounts created automatically by AdminAPI have strict authentication requirements, you can set a value for the replicationAllowedHost configuration option. The replicationAllowedHost option means that all accounts created automatically can only connect from allowed hosts, using strict subnet-based filtering.

You can use setOption option to set the replicationAllowedHost configuration on an existing InnoDB Cluster, InnoDB ClusterSet, or InnoDB ReplicaSet. (WL #14751)

From MySQL Shell 8.0.28, three fencing operations are available:

Even though you primarily use fencing on clusters belonging to a clusterset, it is also possible to fence standalone clusters using Cluster.fenceAllTraffic(). (WL #14537)

Following a regression in MySQL Shell 8.0.22, if an instance was part of an InnoDB Cluster and was removed from it, then added to a different InnoDB Cluster, the existing metadata schema for the first InnoDB Cluster was not cleared in the process. MySQL Shell now drops and re-creates the cluster metadata schema on the instance to ensure that it corresponds exactly to that for the new cluster. (Bug #33574005)

Due to an error in a metadata query, MySQL Shell 8.0.27 cannot be used to create or manage an InnoDB Cluster running MySQL Server 8.0.25. The query was verifying a setting that was introduced in the following release. To work around this issue, upgrade MySQL Server to the 8.0.26 or 8.0.27 release on the InnoDB Cluster member instances before using MySQL Shell 8.0.27 with the cluster. The issue is fixed in MySQL Shell 8.0.28. (Bug #33532056, Bug #33580945)

When the recovery method used to add an instance to an InnoDB Cluster was incremental state transfer from an existing member server's binary log (incremental recovery), AdminAPI uninstalled the clone plugin from the cluster members, which could cause subsequent auto-rejoin processes to fail. The uninstall no longer takes place. (Bug #33492812)

AdminAPI‘s cluster.addInstance(), cluster.rejoinInstance(), and dba.rebootClusterFromCompleteOutage() commands did not inspect the offline_mode system variable, so if the variable was enabled, connection and replication errors occurred. These operations now inspect the value of the system variable and disable it if necessary. (Bug #33396423)

The groupSeeds option is now deprecated for InnoDB Cluster creation commands and unsupported for InnoDB ClusterSet creation commands, and it has been undocumented. InnoDB Cluster’s handling of the list of Group Replication group seed members (the group_replication_group_seeds system variable) has been revised to update the list when an instance is added, removed, or rejoined, and to check the list in the cluster metadata rather than on individual member server instances. (Bug #33389693, Bug #33573834)

With an InnoDB ClusterSet deployment operating under heavy load, a replica cluster’s status could be intermittently reported as OK_NOT_CONSISTENT, meaning that the set of transactions on the replica cluster (the GTID set) had more transactions than that on the primary cluster. This was happening because transactions were sent to replica clusters before they were added to the primary cluster’s gtid_executed GTID set. Transactions that have been received but not yet applied are now subtracted from a replica cluster’s gtid_executed GTID set before it is compared to that on the primary cluster. The set of retrieved transactions is shown in the extended output of the clusterSet.status() command. If the ClusterSet replication channel is reset or has its source changed, the set of received transactions is reset, so the inconsistency may be reported until the primary has externalized all the transactions that took place before the reset. (Bug #33330871)

If an InnoDB Cluster was rebooted after an outage using the dba.rebootClusterFromCompleteOutage() command, and then rejoined to an InnoDB ClusterSet using the clusterSet.rejoinCluster() command, the rejoin failed if the rejoinInstances or removeInstances option had been used on the dba.rebootClusterFromCompleteOutage() command. These options now cannot be used if the InnoDB Cluster is part of an InnoDB ClusterSet and has been invalidated. (Bug #33301229)

The clusterSet.removeCluster() command for InnoDB ClusterSet now implicitly dissolves an InnoDB Cluster when it is removed from the ClusterSet, so that all the members become standalone instances. This enables the instances to be reused in a new cluster in the same or another ClusterSet without any conflicting metadata. (Bug #33267834)

MySQL 8.0.28 and higher includes Connection timeout MySQL Shell options, to allow users to set timeouts for sessions using both AdminAPI and non-AdminAPI connections.

Certain operations that open many connections to servers can take a long time to execute when one or more servers are indeed unreachable, for example, the cluster.status() command. The connection timeout may not provide enough time for a response.

From MySQL Shell 8.0.28, you can use the MySQL Shell configuration option connectTimeout to set the connection timeout in seconds for any session not using AdminAPI.

From MySQL Shell 8.0.28, you can use the MySQL Shell configuration option dba.connectTimeout to set the connection timeout in seconds for any session using AdminAPI. (WL #14698)

MySQL Shell now supports SSH tunneling for connections to MySQL server instances. Once established, an SSH tunnel can be shared between connections to the same host from the same user connecting from the same remote server instance. MySQL Shell’s Secret Store can store passwords and passphrases for connection to an SSH server and for the identity file, to be automatically retrieved for future connections. A new shell.listSshConnections() function returns a list of the active SSH tunnels. You can configure the buffer size for data transfer using the MySQL Shell configuration option ssh.bufferSize.

You can specify the SSH connection details in the standard SSH configuration file (~/.ssh/config), or a custom configuration file named by the MySQL Shell configuration option ssh.configFile. You can override the set defaults using the connection option ssh-config-file. The identity file can be the standard private key file in the SSH configuration folder (~/.ssh/id_rsa), or a key file named by the connection option ssh-identity-file. You can use the --ssh option on the MySQL Shell \connect command or the command line to provide the URI for connection to the SSH server, or you can use the shell.connect() method and specify the connection data as key-value pairs.

The use of AdminAPI commands is not supported over connections made using SSH tunneling, with the exception of the commands to deploy, start, stop, kill, and delete sandbox instances. (WL #14246)

MySQL 8.0.27 and higher includes support for multifactor authentication. This capability includes forms of MFA that require up to three authentication values (2FA and 3FA). The authentication_policy system variable defines how many authentication factors accounts may have (or are required to have) and the authentication methods that can be used for each factor. To enable authentication to the MySQL server using accounts that require multiple passwords, MySQL Shell now supports the --password1, --password2, and --password3 options for command-line connections, permitting up to three passwords to be specified. The existing --password option and the --password1 option are treated as equivalent. You can specify a password value following the option on the command line (which is insecure), or if the options are given without a password value, MySQL Shell prompts the user for each password in turn. These options are only supported for classic MySQL protocol connections made using command-line arguments. (WL #14649)

MySQL Shell's instance dump utility util.dumpInstance(), schema dump utility util.dumpSchemas(), table dump utility util.dumpTables(), and dump loading utility util.loadDump() have new filtering options to cover all objects that can be dumped and loaded. The options give you fine control over the content of the dump files and over what objects are loaded onto the destination server, and enable you to skip any objects that are causing issues. At an appropriate level for the utility, the options allow you to include or exclude a specified list of schemas, tables, routines, events, or triggers. (WL #14244)

MySQL Shell 8.0.28 does not support the following Linux distribution:

(Bug #33787657)

MySQL Shell's instance dump utility util.dumpInstance(), schema dump utility util.dumpSchemas(), and table dump utility util.dumpTables() could not be used with a MySQL server instance started with the --skip-grant-tables option, meaning that the utilities could not be used to extract data in this emergency situation. The utilities now detect the special account used for all connections in this situation and assume that account has all available privileges. The users option is also automatically set to false, because some grant information cannot be collected in this situation. (Bug #33592520)

When loading a dump from a manifest file, if the PARs in the file had expired, MySQL Shell's dump loading utility util.loadDump() would fail with an unclear message. The utility now compares the current time and the expiry time of the PARs, and if they have expired, returns an appropriate message and stops the load process. (Bug #33508311)

A hardcoded domain name was used in MySQL Shell code relating to PARs (pre-authenticated requests), resulting in an error if a domain name other than oraclecloud.com was used in a PAR. The issue has now been corrected and any domain name is permitted. (Bug #33506737)

MySQL Shell's instance dump utility util.dumpInstance() stopped the dump with an error if the instance had no schemas or filtering resulted in an empty set of schemas, so it was not possible to just dump the users from an instance. The operation now succeeds in that situation if the users option is set to true (the default), and continues to stop with an error if the users option is set to false. (Bug #33502098)

On Windows, when MySQL Shell was started by another application, a prompt expecting a yes or no answer (such as whether to store a supplied password in the credential manager) was repeated indefinitely even if a valid answer was received. This was due to the carriage return character (\r) not being trimmed in addition to the newline character (\n). The issue has now been fixed. (Bug #33499602)

When the --json=raw option was used to generate raw JSON from MySQL Shell's output, newlines were not included, resulting in unformatted text. (Bug #33486098)

On Windows, a regression meant that MySQL Shell could not connect to a server using a URI-like connection string that specified a default schema but did not specify a scheme element (such as mysqlx://). (Bug #33485693)

For an extension object registered with MySQL Shell, the help lookup function now searches for an exact match to the search string in the event that multiple topics are found. Plugin help, which was previously loaded only in local context, is now loaded in global or local context depending on where the plugin is loaded. (Bug #33468265)

For an extension object registered with MySQL Shell as a member of a higher-level extension object, Python decorators did not take naming conventions into account when looking for the object hierarchy, but the registration function did, which could cause incorrect results. The registration function now converts the object name using MySQL Shell’s algorithm so that the object is properly found. (Bug #33462107)

MySQL Shell could not be built from source using Python 3.10 due to API changes. The issue has now been corrected. (Bug #33454039)

For an extension object registered with MySQL Shell, the help lookup did not distinguish between objects with the same name where only one was available as a global object, and the other was a subsidiary object. The help registration and help lookup functions have now been updated to match the fully qualified ID of an object, and also prioritize any help item whose fully qualified ID exactly matches the search string. (Bug #33451028)

MySQL Shell's dump loading utility util.loadDump() can defer the creation of secondary indexes until after the table data is loaded, with the deferTableIndexes option. Previously, the deferred indexes could not be created on tables with a secondary engine defined, because DDL statements cannot be executed on these tables. The utility now removes the SECONDARY_ENGINE clause from the table if indexes are being deferred, and adds it back in after the indexes have been created. (Bug #33414321)

MySQL Shell's instance dump utility util.dumpInstance(), schema dump utility util.dumpSchemas(), and table dump utility util.dumpTables() now chunk tables with an index column of data type DECIMAL using arithmetic operations, which improves the execution speed. (Bug #33400387)

MySQL Shell's instance dump utility util.dumpInstance(), schema dump utility util.dumpSchemas(), and table dump utility util.dumpTables() now print a summary of the number of dumped schemas, tables, views, events, routines, triggers, and users, and the number of these objects that are available in the database. (Bug #33396153)

MySQL Shell stopped if it was not able to write to the directory specified by the $HOME environment variable. An error is now returned when MySQL Shell starts up if this is the case. (Bug #33390034)

When MySQL Shell's \source command was used to execute a script file, if the script did not contain a complete statement, MySQL Shell entered multiline mode instead of executing the script and returning an appropriate error. MySQL Shell's stream processing now disables multiline handling to force the cached code to be executed even if it is incomplete, so that an error is returned. (Bug #33337598)

When MySQL Shell's dump loading utility util.loadDump() was used to load a dump that was currently in progress, the utility’s progress reporting was inaccurate. (Bug #33332497)

When MySQL Shell's dump loading utility util.loadDump() was used to load a dump that was currently in progress using a prefix PAR, an error was reported for the dump’s index file. (Bug #33332080)

MySQL Shell masks passwords that are supplied after the user name in a URI-like string specified by the --uri command-line option. If the user name in the string was percent encoded and a password was supplied, the comparison to a plain user name was not made correctly, and the connection failed. MySQL Shell now removes the password from a URI-like string leaving only the user name before the comparison is carried out. (Bug #33273652, Bug #104714)

MySQL Shell’s built-in global objects can be accessed using Python’s subscript operator, for example, dba["help"](). However, an unspecified error was returned if an invalid type was used as a subscript. TypeError is now returned in this situation. (Bug #32315014)