Changes in MySQL Shell 8.1.0 (2023-07-18, Innovation Release)

AdminAPI Added or Changed Functionality
  • Important Change: MySQL Shell now supports Read Replicas.

    InnoDB Cluster Read Replicas are read-only copies of a Cluster member. Asynchronous replication keeps the replica up to date, enabling you to scale out your workload, offload read requests from your Cluster to one, or more, dedicated read-only instances, and provide additional redundancy to your dataset. In the event of a failure of the source, the Read Replica automatically connects to another Cluster member and resumes replication.

    The following methods were added:

    • Cluster.addReplicaInstance(): Adds a Read Replica to the Cluster.

    The following methods were extended to support InnoDB Cluster Read Replicas:

    • Cluster.removeInstance()

    • Cluster.rejoinInstance()

    • Cluster.setRoutingOption()

    • Cluster.status()

    • Cluster.describe()

    • Cluster.routingOption()

    • Cluster.dissolve()

    • Cluster.forceQuorumUsingPartitionOf()

    • ClusterSet.removeCluster()

    • ClusterSet.routingOptions()

    • Cluster.setInstanceOption()

    • Cluster.fenceAllTraffic()

    See MySQL InnoDB Cluster Read Replicas. (WL #15056)

  • The status_update_frequency changes introduced for ClusterSets by Bug#34190956 in MySQL Shell 8.0.31 are extended to apply to Clusters and ReplicaSets.

    The following methods were added:

    • ReplicaSet.setRoutingOption()

    • ReplicaSet.routingOptions()

    The following methods were extended to include status_update_frequency:

    • Cluster.setRoutingOption()

    • Cluster.routingOptions()

    (WL #15601)

    References: See also: Bug #34190956.

AdminAPI Bugs Fixed
  • Rebooting a replica cluster from complete outage could result in the cluster rejoining the ClusterSet, but not the instance members of the replica cluster. This happened only if the primary cluster was under heavy load or the replica cluster was missing transactions from the ClusterSet. (Bug #35444244)

  • If a Cluster was rebooted with dba.rebootClusterFromCompleteOutage(), and the communication stack was changed to mysql, the seed instance was not rebooted with the correct SSL options. (Bug #35416666)

  • If the X Protocol port was changed for a cluster member and that member restarted, the AdminAPI did not update the metadata with the new port number, leading to connection errors and so on.

    As of this release, cluster.status() checks for port changes and cluster.rescan() updates the metadata with the new port number. (Bug #35410360)

  • Operations which permitted clone-based recovery, such as ClusterSet.createReplicaCluster, did not validate the donor and recipient unless cloneDonor was explicitly specified. As a result, under certain circumstances, clone-based recovery could fail due to incompatibilities in the automatically chosen donor. (Bug #35358531)

  • Under certain circumstances, dba.rebootClusterFromCompleteOutage() failed with malformed GTID errors relating to GROUP_CONCAT. dba.rebootClusterFromCompleteOutage() must query the complete GTID set of the channel and this query failed if the default GROUP_CONCAT_MAX_LEN value was too low.

    As of this release, queries which do not require the GROUP_CONCAT function, do not use it and queries which require it, use a GROUP_CONCAT_MAX_LEN value of 1GB. (Bug #35356006)

  • Running clusterSet.rejoinCluster() on a cluster which was ONLINE and a healthy member of the ClusterSet, left the cluster in an invalid state. The following warning was displayed in the instanceErrors field of the status message:

            "WARNING: The value of 
            'group_replication_transaction_size_limit' does not match the 
            Cluster's configured value. Use Cluster.rescan() to repair."

    (Bug #35354749)

  • During a failover of a ClusterSet replication channel, the ClusterSet.status() value clusterSetReplicationStatus reported ERROR and globalStatus returned OK_NOT_REPLICATING. Errors and warnings relating to misconfigured or stopped channels were also returned. These statuses and errors were misleading as the channel was attempting to connect to another source or replica.

    As of this release, clusterSetReplicationStatus returns CONNECTING, and globalStatus returns OK while a channel connection attempt is ongoing. If there is an error, it is ignored until the channel state updates to either ON or OFF.

    Additionally, the ReplicaSet.status() field, status, also returns CONNECTING. (Bug #34614769)

Utilities Added or Changed Functionality
  • It is now possible to dump data to a Bucket or Prefix Pre-Authenticated Request (PAR) using the following utilities:

    • util.dumpInstance(outputUrl[, options])

    • util.dumpSchemas(schemas, outputUrl[, options])

    • util.dumpTables(schema, tables, outputUrl[, options])

    where outputURL now supports PARs. (WL #14646)

  • It is now possible to copy an instance, schemas, and tables from one instance to another with the new MySQL Shell copy utilities. The copy utilities enable you to copy DDL and data between MySQL instances, without the need for intermediate storage. The data is stored in memory.

    The following methods were added:

    • util.copyInstance(): Enables copying of an entire instance to another server.

    • util.copySchemas(): Enables copying of one or more schemas to another server.

    • util.copyTables(): Enables copying of one or more tables from a schema to another server.

    See Copy Instance, Schemas, and Tables. (WL #15298)

Utilities Bugs Fixed
  • Under certain circumstances, util.loadDump() could fail when retrieving a file from AWS S3, Oracle Cloud Infrastructure Object Storage, or Azure Blob Storage, even though the file was downloadable by other means.

    As of this release, if CURL errors occur, such as 52: CURLE_GOT_NOTHING. 56 CURLE_RECV_ERROR, or 28: CURLE_OPERATION_TIMEDOUT utils.loadDump() retries the download. (Bug #35362775, Bug #35392531)

  • In previous versions, loading a dump from the previous version resulted in an error, unless the ignoreVersion option was set to true.

    As of this release, migration from a version to the next consecutive version, such as 5.7 to 8.0, no longer results in an error and no longer requires the ignoreVersion option.

    Note

    The behavior remains unchanged for migration between non-consecutive versions, such as 5.6 to 8.0.

    (Bug #35359364)

  • If an exception occurred while importing a single, uncompressed file with util.import_table(), MySQL Shell crashed. (Bug #35313366)

  • util.loadDump() did not log warnings about rows replaced during the load. (Bug #35304391)

  • Under certain circumstances, loading a dump with ignoreExistingObjects enabled to an instance with existing DDL objects could fail with an error similar to the following:

            columns dictionary object is invalid. 
            (There are no elements supplied.)

    As of this release, DDL for existing tables and views is not processed, if ignoreExistingObjects is enabled.

    Additionally, duplicate triggers are now reported and excluded routines and events are no longer reported as duplicates. (Bug #35102738)

  • The upgrade checker utility did not check stored procedures and routines for the deprecated qualifier syntax .tbl_name. (Bug #35046623)

  • If chunking was enabled for a dump of tables, but the primary key or unique index used to chunk the table contained an ENUM column, some of the tables rows were not exported to the dump. This occurred if the ENUM column's values were not ordered alphabetically.

    As of this release, primary keys or unique indexes which contain one or more ENUM columns, are ignored when selecting an index for chunking. (Bug #110352, Bug #35180061)

Functionality Added or Changed
  • MySQL Shell now supports the --loose prefix.

    For more information on this prefix, see Program Option Modifiers. (Bug #110141, Bug #35112454)

  • It is now possible to specify the Kerberos client authentication mode on Microsoft Windows platforms, using a new option plugin-authentication-kerberos-client-mode=SSPI | GSSAPI.

    Note

    This option is only available on Microsoft Windows platforms. Attempting to use it on non-Windows platforms results in an error.

    (WL #15556)

  • You can now specify the OCI config file and profile used when connecting to a MySQL HeatWave Service DB System with the OCI Authentication plugin. The following options are available from the command line, options file, and MySQL Shell connection options as attributes in a dictionary or in a connection URI:

    • oci-config-file: defines the location of the OCI config file to use with the OCI Authentication Plugin. The value defined here overrides the value defined in the oci.configFile option.

    • authentication-oci-client-config-profile: defines the profile in the OCI config file to use with the OCI Authentication Plugin. The value defined here overrides the value defined in the oci.profile option.

    Note

    These options are only available for connections with the OCI Authentication Plugin.

    (WL #15561)

  • MySQL Shell now supports setting query attributes. The following commands and API methods were added:

    • SQL: \query_attributes

    • JavaScript: session.setQueryAttributes()

    • Python: session.set_query_attributes()

    See MySQL Shell Commands. (WL #15571)

  • MySQL Shell now supports the STATEMENT_ID session tracker. If the server system variable session_track_system_variables is set to * or STATEMENT_ID, the statement ID is returned for statements.

    Note

    This applies to classic protocol only. The statement ID is not returned over X Protocol.

    The following property is added to enable you to retrieve the statement ID:

    • ClassicResult.statementId: Same behavior as the getStatementId() method.

    (WL #15574)

Bugs Fixed
  • The MySQL configuration utility mysql_config_editor was not bundled with MySQL Shell 8.0.33. (Bug #35459202)

    References: This issue is a regression of: Bug #34097411.

  • It was not possible to use the Python function json.dumps with MySQL Shell dictionaries. (Bug #35450521)

  • MySQL Shell command line did not correctly handle missing optional arguments. A NULL value was used instead of a valid value, resulting in an error. (Bug #109827, Bug #35068427)