MySQL Shell 8.0.19 for MySQL Server 8.0 and 5.7 has been released

Posted on January 13, 2020 by MySQL Release Engineering

Dear MySQL users,

MySQL Shell 8.0.19 is a maintenance release of MySQL Shell 8.0 Series (a
component of the MySQL Server). The MySQL Shell is provided under
Oracle’s dual-license.

MySQL Shell 8.0 is highly recommended for use with MySQL Server 8.0 and
5.7. Please upgrade to MySQL Shell 8.0.19.

MySQL Shell is an interactive JavaScript, Python and SQL console
interface, supporting development and administration for the MySQL
Server. It provides APIs implemented in JavaScript and Python that
enable you to work with MySQL InnoDB cluster and use MySQL as a document
store.

The AdminAPI enables you to work with MySQL InnoDB cluster, providing an
integrated solution for high availability and scalability using InnoDB
based MySQL databases, without requiring advanced MySQL expertise. For
more information about how to configure and work with MySQL InnoDB
cluster see

https://dev.mysql.com/doc/refman/en/mysql-innodb-cluster-userguide.html

The X DevAPI enables you to create “schema-less” JSON document
collections and perform Create, Update, Read, Delete (CRUD) operations
on those collections from your favorite scripting language.  For more
information about how to use MySQL Shell and the MySQL Document Store
support see

https://dev.mysql.com/doc/refman/en/document-store.html

For more information about the X DevAPI see

https://dev.mysql.com/doc/x-devapi-userguide/en/

If you want to write applications that use the the CRUD based X DevAPI
you can also use the latest MySQL Connectors for your language of
choice. For more information about Connectors see

https://dev.mysql.com/doc/index-connectors.html

For more information on the APIs provided with MySQL Shell see

https://dev.mysql.com/doc/dev/mysqlsh-api-javascript/8.0/

and

https://dev.mysql.com/doc/dev/mysqlsh-api-python/8.0/

Using MySQL Shell’s SQL mode you can communicate with servers using the
legacy MySQL protocol. Additionally, MySQL Shell provides partial
compatibility with the mysql client by supporting many of the same
command line options.

For full documentation on MySQL Server, MySQL Shell and related topics,
see

https://dev.mysql.com/doc/mysql-shell/8.0/en/

For more information about how to download MySQL Shell 8.0.19, see the
“General Availability (GA) Releases” tab at

http://dev.mysql.com/downloads/shell/

We welcome and appreciate your feedback and bug reports, see

http://bugs.mysql.com/

Enjoy and thanks for the support!

Changes in MySQL Shell 8.0.19 (2020-01-13, General Availability)

InnoDB Cluster Added or Changed Functionality

     * Incompatible Change: The AdminAPI now includes InnoDB
       ReplicaSets, that enables you to administer asynchronous
       replication set ups in a similar way to InnoDB cluster.
       The addition of InnoDB ReplicaSet means that the InnoDB
       cluster metadata schema has been upgraded to version 2.0.
       Regardless of whether you plan to use InnoDB ReplicaSet
       or not, to use MySQL Shell 8.0.19 and AdminAPI you must
       upgrade the metadata of your clusters. Connect MySQL
       Shell’s global session to your cluster and use the new
       dba.upgradeMetadata() operation to upgrade the cluster’s
       metadata to use the new metadata.
       Warning
       Without upgrading the metadata you cannot use MySQL Shell
       8.0.19 to change the configuration of a cluster created
       with earlier versions. You can only read the
       configuration of the cluster, for example using
       Cluster.status().
       The dba.upgradeMetadata() operation upgrades any
       automatically created MySQL Router users to have the
       correct privileges. Manually created MySQL Router users
       with a name not starting with mysql_router_ are not
       automatically upgraded. This is an important step in
       upgrading your cluster, only then can the MySQL Router
       application be upgraded.
       Warning
       A cluster which is using the new metadata cannot be
       administered by earlier MySQL Shell versions, for example
       once you upgrade to version 8.0.19 you can no longer use
       version 8.0.18 or earlier to administer the cluster.
       To get information on which of the MySQL Router instances
       registered with a cluster require the metadata upgrade,
       issue
       cluster.listRouters({‘onlyUpgradeRequired’:’true’}).

     * AdminAPI now supports socket connections to be used for
       cluster and replica set operations. (Bug #26265826)

     * You can now get information about the MySQL Router
       instances registered with a InnoDB cluster, and
       unregister a Router from a cluster, for example when you
       stop using it. The list of Routers registered with a
       cluster contains information about whether the Router
       instance is compatible with the version of MySQL on the
       cluster instances, which guides you when upgrading a
       cluster. Use the Cluster.listRouters() operation to show
       a list of all Routers registered with the cluster. The
       returned JSON object provides information such as the
       hostname, ports, and if an upgrade is required. To filter
       the list to only show Router instances that do not
       support the latest metadata version use the
       onlyUpgradeRequired option, for example by issuing
       Cluster.listRouters({‘onlyUpgradeRequired’:’true’}). To
       remove a registered Router from a cluster, use the
       Cluster.removeRouterMetadata(router) operation.

     * The AdminAPI includes support for InnoDB ReplicaSet, that
       enables you to administer asynchronous replication sets
       in a similar way to InnoDB cluster. InnoDB ReplicaSet
       enables you to deploy an asynchronous replication set
       consisting of a single primary and multiple secondaries
       (traditionally referred to as the MySQL replication
       master and slaves). You administer a ReplicaSet using
       AdminAPI operations, for example to check the status of
       the InnoDB ReplicaSet, and manually failover to a new
       primary in the event of a failure. Similar to InnoDB
       cluster, MySQL Router supports bootstrapping against
       InnoDB ReplicaSet, which means you can automatically
       configure MySQL Router to use your InnoDB ReplicaSet
       without having to manually configure files. This makes
       InnoDB ReplicaSet a quick and easy way to get MySQL
       replication and MySQL Router up and running, making it
       well suited to scaling out reads, development
       environments, and applications that do not require the
       high availability offered by InnoDB cluster.

InnoDB Cluster Bugs Fixed

     * The dba.configureLocalInstance() operation could fail
       with a key not found (LogicError) error when executed on
       a non-sandbox instance where it did not have access to
       the my.cnf option file and the operation requested an
       output configuration file to be specified. (Bug
       #30657204)

     * If a cluster had been deployed with MySQL Shell version
       8.0.14 or earlier, the metadata contained an invalid port
       number for X Protocol connections. The metadata upgrade
       catches such ports and removes the invalid number. To
       avoid problems with routing due to this incorrect port,
       upgrade your cluster’s metadata. (Bug #30618264)

     * When a replication slave was configured to read from an
       InnoDB cluster primary, even with the appropriate
       replication filtering to ignore the metadata replication
       was failing when an instance was added to the cluster
       using MySQL Clone as the recovery method. This was
       because the recovery process was granting a privilege on
       an account, which failed and broke replication. (Bug
       #30609075)

     * The Cluster.removeInstance() operation was issuing a
       misleading error message when the instance was
       unreachable, indicating that it did not belong to the
       cluster when an alternative valid host or IP was used.
       Now, the error indicates that the instance is
       unreachable. (Bug #30580393)

     * Although MySQL Shell version 8.0.18 added support for
       IPv6 in WL#12758
       (https://dev.mysql.com/worklog/task/?id=12758), using an
       InnoDB cluster which consisted of MySQL Shell version
       8.0.18 and MySQL Router 8.0.18 with IPv6 addresses was
       not possible. With the release of version 8.0.19 of both
       MySQL Shell and MySQL Router, be aware that:

          + combining MySQL Shell version 8.0.18 with MySQL
            Router 8.0.18 causes Router to fail, due to no IPv6
            support. (BUG#30354273)

          + combining MySQL Shell version 8.0.18 with Router
            8.0.19 in a cluster which uses X Protocol
            connections, results in AdminAPI storing mysqlX IPv6
            values incorrectly in the metadata, causing Router
            to fail. (BUG#30548843) However, combining MySQL
            Shell version 8.0.18 with Router 8.0.19 in a cluster
            which uses MySQL classic protocol connections, is
            possible.
       Therefore, to use InnoDB cluster with IPv6 addresses,
       regardless of the protocol used, the recommended
       deployment is MySQL Shell 8.0.19 and MySQL Router 8.0.19.
       (Bug #30548843)
       References: See also: Bug #30354273.

     * When using automatic rejoin, if a target instance was
       rejoining the cluster, operations such as
       dba.rebootClusterFromCompleteOutage(), Cluster.status(),
       and so on were failing. Now, clusters consider automatic
       rejoin as an instance state instead of a check that
       always aborts the operation. This ensures that
       Cluster.status() is reported even for instances which are
       rejoining the cluster, and that
       dba.rebootClusterFromCompleteOutage() can detect
       instances which are rejoining the cluster and override
       the rejoin operation so that the cluster can be properly
       rebooted. (Bug #30501590)

     * SSL client certificate options for the clusterAdmin user
       were not being copied when setting up connection options,
       which made them fail when connecting. (Bug #30494198)

     * When the automatically calculated localAddress is not
       valid, for example when it exceeds the valid range, the
       error message has now been improved. See Configuring
       Ports
       (https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-production-deployment.html#configuring-instance-ports).
       (Bug #30405569)

     * The AdminAPI ensures that all members of a cluster have
       the same consistency level as configured at cluster
       creation time. However, when high and non-default
       consistency levels were chosen for the cluster, adding
       instances to it resulted in an error 3796 which indicates
       that group_replication_consistency cannot be used on the
       target instance. This happened because the consistency
       values of BEFORE, AFTER and BEFORE_AND_AFTER cannot be
       used on instances that are RECOVERING and several
       transactions happen while the instance is in the
       RECOVERING phase. Other AdminAPI commands result in the
       same error for the same scenario (high global consistency
       levels) whenever at least one member of the cluster is
       RECOVERING. For example, dba.getCluster(). The fix
       ensures that all sessions used by the AdminAPI use the
       consistency level of EVENTUAL when the cluster’s
       consistency level is BEFORE, AFTER or BEFORE_AND_AFTER.
       (Bug #30394258, Bug #30401048)

     * Some privileges required for persisting configuration
       changes on MySQL 8.0 servers were missing for the
       clusterAdmin users created by AdminAPI. In particular, an
       Access Denied error was being issued indicating the
       SYSTEM_VARIABLES_ADMIN and PERSIST_RO_VARIABLES_ADMIN
       privileges were required. Now these privileges are added
       for the clusterAdmin user on MySQL 8.0 servers. (Bug
       #30339460)

     * When using MySQL Clone as the recovery method, trying to
       add an instance that did not support RESTART to a cluster
       caused MySQL Shell to stop unexpectedly. Now, in such a
       situation a message explains that Cluster.rescan() must
       be used to ensure the instance is added to the metadata.
       (Bug #30281908)

     * The autocommit and sql_mode system variables are session
       settings, but they can be set globally to different
       values. AdminAPI was failing if these variables had
       non-default values in several different ways, for example
       DML was failing, system variables could not be set and so
       on. (Bug #30202883, Bug #30324461)

     * Attempting to bootstrap MySQL Router against an InnoDB
       cluster which had had the cluster administration user
       modified or removed was failing. This was caused by the
       privileges granted on the InnoDB cluster metadata table.
       The recommended solution is to upgrade to metadata 2.0,
       which changes the privileges on the metadata to ensure
       this issue does not occur. (Bug #29868432)

     * When you created a multi-primary cluster, the
       group_replication_enforce_update_everywhere_checks system
       variable was not being set automatically. However,
       switching to multi-primary mode automatically enables
       group_replication_enforce_update_everywhere_checks and
       switching to single-primary disables it. Now, the
       dba.createCluster() operation sets the
       group_replication_enforce_update_everywhere_checks
       variable as appropriate for single-primary or
       multi-primary clusters. (Bug #29794779)

     * In version 8.0.16, the autoRejoinTries option was added
       to define the number of times an instance attempts to
       rejoin the cluster after being expelled. The option is a
       valid cluster setting, configurable through the AdminAPI
       like many other options. However, the autoRejoinTries
       option was not being listed by Cluster.options(). (Bug
       #29654346)

     * The InnoDB cluster metadata now supports host names up to
       265 characters long, where 255 characters can be the host
       part and the remaining characters can be the port number.
       (Bug #29507913)

     * dba.createCluster() could fail if the instance had been
       started with innodb_default_row_format=COMPACT or
       innodb_default_row_format=REDUNDANT. This was because no
       ROW_FORMAT was specified on the InnoDB cluster metadata
       tables, which caused them to use the one defined in
       innodb_default_row_format. The metadata schema has been
       updated to use ROW_FORMAT = DYNAMIC. (Bug #28531271)

     * When an instance restarted, for example after a complete
       outage, it could have super_read_only disabled. This
       meant that instances which were not the primary could be
       written to, resulting in the instances no longer being in
       synchrony. This could result in
       dba.rebootClusterFromCompleteOutage() failing with a
       Conflicting transaction sets error. The fix ensures that
       all instances have super_read_only=1 persisted while they
       belong to the cluster, either through SET PERSIST_ONLY,
       or through dba.configureLocalInstance() for instances
       which do not support persisting. (Bug #97279, Bug
       #30545872)

     * The Cluster.status() operation could report an error
       get_uint(24): field value out of the allowed range
       because it was always expecting a positive value for some
       fields that could in fact have negative values. For
       example, this could happen when the clocks of different
       instances were offset. (Bug #95191, Bug #29705983)

     * If you changed the name of the clusterAdmin user once a
       cluster had been created, you could encounter an error
       such as The user specified as a definer does not exist.
       This was because the clusterAdmin user was used as the
       DEFINER of the views required by InnoDB cluster, and if
       this user is renamed then the definer is in effect
       missing. In version 8.0.19 the InnoDB cluster metadata
       has been changed to avoid this problem, use
       dba.upgradeMetadata() to upgrade the cluster. Clusters
       deployed with 8.0.19 and later do not suffer from this
       issue. (Bug #92128, Bug #28541069)

     * It was not possible to create a multi-primary cluster due
       to to cascading constraints on the InnoDB cluster
       metadata tables. This has been fixed in version 8.0.19
       and so to solve this issue upgrade your cluster using
       dba.upgradeMetadata(). (Bug #91972, Bug #29137199)

Functionality Added or Changed

     * The JavaScript function require() has been improved in
       MySQL Shell to support loading of local modules, in
       addition to built-in modules and modules that are on
       module search paths already known to MySQL Shell. If you
       specify the module name or path prefixed with ./ or ../,
       MySQL Shell now searches for the specified module in the
       folder that contains the JavaScript file or module
       currently being executed, or in interactive mode,
       searches in the current working directory. If the module
       is not found in that folder, MySQL Shell proceeds to
       check the well-known module search paths specified by the
       sys.path variable.

     * MySQL Shell’s upgrade checker utility (the
       util.checkForServerUpgrade() operation) includes the
       following new and extended checks:

          + The utility now flags all date, datetime, and
            timestamp columns that have a default value of zero,
            and states if the SQL mode (either global or for the
            current session) allows the insertion of zero values
            for these column types. By default, these are no
            longer permitted in MySQL, and it is strongly
            advised to replace zero values with valid ones, as
            they might not work correctly in the future.

          + The check for usage of removed functions now
            includes the PASSWORD() function.

          + The utility now checks for any orphaned tables which
            are recognized by InnoDB, but the SQL layer thinks
            they are handled by a different storage engine. This
            situation can happen if manual updates are made in
            the data directory. Orphaned tables can stall the
            upgrade process if they are present.

     * In MySQL Shell’s interactive mode, for JavaScript,
       Python, or SQL, the \source command or its alias \. can
       be used to execute code from a script file at a given
       path. For compatibility with the mysql client, in SQL
       mode only, you can now execute code from a script file
       using the source command with no backslash and an
       optional SQL delimiter. source can be used both in MySQL
       Shell’s interactive mode for SQL, to execute a script
       directly, and in a file of SQL code processed in batch
       mode, to execute a further script from within the file.
       In SQL mode only, you can also now use the \source
       command’s alias \. (which does not use a SQL delimiter)
       in a file of SQL code processed in batch mode. So with
       MySQL Shell in SQL mode, you could now execute the script
       in the /tmp/mydata.sql file from either interactive mode
       or batch mode using any of these three commands:
        source /tmp/mydata.sql;
        source /tmp/mydata.sql
        \. /tmp/mydata.sql

       The command \source /tmp/mydata.sql is also valid, but in
       interactive mode only.

Bugs Fixed

     * When searching for startup scripts in the platform’s
       standard global configuration path (in the folder
       %PROGRAMDATA%\MySQL\mysqlsh on Windows, or
/etc/mysql/mysqlsh/ on Unix), MySQL Shell checked for the
       incorrect script name shellrc, rather than the correct
       name mysqlshrc. (Bug #30656548)

     * On Windows, MySQL Shell passed UTF-8 encoded strings to
       the NTFS file system, which stores file names in UTF-16
       encoding. The mismatch caused files and folders to be
       incorrectly named or located when non-ASCII characters
       were used. MySQL Shell now converts all strings used in
       operations on NTFS from UTF-8 to UTF-16, and converts
       back to UTF-8 all strings received from Unicode function
       versions of Windows API calls. (Bug #30538516)

     * Some host names were not parsed correctly in the
       connection data provided when running MySQL Shell’s
       upgrade checker utility checkForServerUpgrade(). (Bug
       #30536355)

     * If the MySQL Server environment variable MYSQL_UNIX_PORT
       (which specifies the default Unix socket file) was
       updated by the same process that was then used to create
       a MySQL Shell connection to a MySQL server using a socket
       file, MySQL Shell cached and connected using the socket
       file path that had previously been set, but reported that
       a connection had been made using the updated socket file
       path. The correct socket file used for the connection is
       now displayed. (Bug #30533318)

     * If a prompt theme file used to customize the MySQL Shell
       prompt contained an ill-formed UTF-8 sequence, on startup
       an error message was displayed in place of the prompt
       text. MySQL Shell now validates the prompt theme file
       before loading it, and if there is a problem, uses a
       default prompt instead and issues an error message. (Bug
       #30406283)

     * If MySQL Shell was installed on Microsoft Windows at a
       non-default location, and subsequently uninstalled, files
       created after installation by the Python library used by
       MySQL Shell were not removed. These files are now removed
       when MySQL Shell is uninstalled from any location. (Bug
       #30333801)

     * Previously, most MySQL Shell options that expected an
       integer value could be set with an empty value, in which
       case the value 1 was applied. The exception was the
       logLevel option, which required a value. The behavior has
       now been standardized so all MySQL Shell options that
       expect a non-string value must be specified with a value,
       with the exception of options set on the command line.
       The affected options are dba.gtidWaitTimeout, dba.logSql,
       history.maxSize, and verbose. (Bug #30320839)

     * When using MySQL Shell in interactive mode, using a
       template literal in a multiple-line JavaScript statement
       resulted in an error. The issue has now been fixed. (Bug
       #30248651)

     * In Python mode, when multiple statements were input to
       MySQL Shell at the same time for execution in interactive
       mode, only the first statement was executed correctly.
       (Bug #30029568)

     * The Debian control file for MySQL Shell has been
       corrected to remove packaging errors that occurred when
       certain variables were not defined. Thanks to Evgeniy
       Patlan for the fix. (Bug #29802600, Bug #95158)

     * In MySQL Shell’s parser for URI-like connection strings,
       handling of path separators was previously platform
       dependent. Unified parsing has now been introduced so
       that Windows named pipes can be parsed correctly on Unix
       platforms, and Unix socket files can be parsed correctly
       on Windows platforms. (Bug #29456981)

     * MySQL Shell now looks up host names by obtaining the
       fully qualified domain name of the provided address and
       using the absolute form of this name (with a trailing
       dot). This method avoids potential issues caused by some
       network configurations that resolve host names as
       loopback addresses when they are actually addressable
       externally. (Bug #27704559)

On Behalf of Oracle/MySQL Release Engineering Team,
Hery Ramilison

MySQL Shell 8.0.18 for MySQL Server 8.0 and 5.7 has been released

Posted on October 14, 2019 by MySQL Release Engineering

Dear MySQL users,

MySQL Shell 8.0.18 is a maintenance release of MySQL Shell 8.0 Series (a
component of the MySQL Server). The MySQL Shell is provided under
Oracle’s dual-license.

MySQL Shell 8.0 is highly recommended for use with MySQL Server 8.0 and
5.7. Please upgrade to MySQL Shell 8.0.18.

MySQL Shell is an interactive JavaScript, Python and SQL console
interface, supporting development and administration for the MySQL
Server. It provides APIs implemented in JavaScript and Python that
enable you to work with MySQL InnoDB cluster and use MySQL as a document
store.

The AdminAPI enables you to work with MySQL InnoDB cluster, providing an
integrated solution for high availability and scalability using InnoDB
based MySQL databases, without requiring advanced MySQL expertise. For
more information about how to configure and work with MySQL InnoDB
cluster see

https://dev.mysql.com/doc/refman/en/mysql-innodb-cluster-userguide.html

The X DevAPI enables you to create “schema-less” JSON document
collections and perform Create, Update, Read, Delete (CRUD) operations
on those collections from your favorite scripting language. For more
information about how to use MySQL Shell and the MySQL Document Store
support see

https://dev.mysql.com/doc/refman/en/document-store.html

For more information about the X DevAPI see

https://dev.mysql.com/doc/x-devapi-userguide/en/

If you want to write applications that use the the CRUD based X DevAPI
you can also use the latest MySQL Connectors for your language of
choice. For more information about Connectors see

https://dev.mysql.com/doc/index-connectors.html

For more information on the APIs provided with MySQL Shell see

https://dev.mysql.com/doc/dev/mysqlsh-api-javascript/8.0/

and

https://dev.mysql.com/doc/dev/mysqlsh-api-python/8.0/

Using MySQL Shell’s SQL mode you can communicate with servers using the
legacy MySQL protocol. Additionally, MySQL Shell provides partial
compatibility with the mysql client by supporting many of the same
command line options.

For full documentation on MySQL Server, MySQL Shell and related topics,
see

https://dev.mysql.com/doc/mysql-shell/8.0/en/

For more information about how to download MySQL Shell 8.0.18, see the
“General Availability (GA) Releases” tab at

http://dev.mysql.com/downloads/shell/

We welcome and appreciate your feedback and bug reports, see

http://bugs.mysql.com/

Enjoy and thanks for the support!

Changes in MySQL Shell 8.0.18 (2019-10-14, General Availability)

     * InnoDB Cluster Added or Changed Functionality

     * InnoDB Cluster Bugs Fixed

     * Functionality Added or Changed

     * Bugs Fixed

InnoDB Cluster Added or Changed Functionality

     * MySQL Shell can now optionally log SQL statements that
       are executed by AdminAPI operations, and output them to
       the console if the –verbose option is set. The
       dba.logSql MySQL Shell configuration option or
       –dba-log-sql command line option activates logging for
       these statements. Statements executed by sandbox
       operations are excluded. Viewing the statements lets you
       observe the progress of the AdminAPI operations in terms
       of SQL execution, which can help with problem diagnosis
       for any errors.

     * AdminAPI now supports IPv6 addresses if the target MySQL
       Server version is higher than 8.0.13. When using MySQL
       Shell 8.0.18 or higher, if all cluster instances are
       running 8.0.14 or higher then you can use an IPv6 or
       hostname that resolves to an IPv6 address for instance
       connection strings and with options such as localAddress,
       groupSeeds and ipWhitelist. For more information on using
       IPv6 see Support For IPv6 And For Mixed IPv6 And IPv4
       Groups
(https://dev.mysql.com/doc/refman/8.0/en/group-replication-ipv6.html).
       References: See also: Bug #29557250, Bug #30111022, Bug
       #28982989.

     * You can now reset the passwords for the internal recovery
       accounts created by InnoDB cluster, for example to follow
       a custom password lifetime policy. Use the
       Cluster.resetRecoveryAccountsPassword() operation to
       reset the passwords for all internal recovery accounts
       used by the cluster. The operation sets a new random
       password for the internal recovery account on each
       instance which is ONLINE. If an instance cannot be
       reached, the operation fails. You can use the force
       option to ignore such instances, but this is not
       recommended, and it is safer to bring the instance back
       online before using this operation. This operation only
       applies to the passwords created by InnoDB cluster and
       cannot be used to update manually created passwords.
       Note
       The user which executes this operation must have all the
       required clusterAdmin privileges, in particular CREATE
       USER, in order to ensure that the password of recovery
       accounts can be changed regardless of the password
       verification-required policy. In other words, independent
       of whether the password_require_current system variable
       is enabled or not.

     * MySQL Shell now supports specifying TLS version 1.3 and
       TLS cipher suites for classic MySQL protocol connections.
       You can use:

          + the –tls-version command option to specify TLS
            version 1.3.

          + the –tls-ciphersuites command option to specify
            cipher suites.

          + the tls-versions and tls-ciphersuites connection
            parameters as part of a URI-type connection string.
       Note
       tls-versions (plural) does not have a key-value
       equivalent, it is only supported in URI-type connection
       strings. Use tls-version to specify TLSv1.3 in a
       key-value connection string.
       To use TLS version 1.3, both MySQL Shell and MySQL server
       must have been compiled with OpenSSL 1.1.1 or higher. For
       more information see Using Encrypted Connections
(https://dev.mysql.com/doc/refman/8.0/en/encrypted-connections.html).

InnoDB Cluster Bugs Fixed

     * The Cluster.rejoinInstance() operation was not setting
       the auto increment values defined for InnoDB cluster,
       leading to the use of the default Group Replication
       behavior if the instance configuration was not properly
       persisted, for example on 5.7 servers. The fix ensures
       that the Cluster.rejoinInstance() operation updates the
       auto increment settings of the target instance. (Bug
       #30174191)

     * The output of Cluster.status() now includes the
       replicationLag field. The value is displayed in HH:MM:SS
       format and shows the time difference between the last
       transaction commit timestamp and the last transaction
       applied timestamp. This enables you to monitor the amount
       of time between the most recent transaction being
       committed and being applied on an instance. (Bug
       #30003034)

     * Cluster.addInstance() did not ensure that the MySQL Clone
       plugin was installed or loaded on all cluster instances,
       when available and not disabled. This meant that whenever
       a cluster was created using an older MySQL Shell version,
       on a target MySQL instance supporting clone, the instance
       would not have the clone plugin installed. The result was
       that any Cluster.addInstance() call that used clone would
       fail. The same issue happened if an instance was added to
       a cluster consisting of one instance using the
       incremental recovery type and afterwards the seed
       instance was removed. This resulted in all cluster
       instances not having the clone plugin installed and
       therefore any instance added using the clone recovery
       method would fail. The fix ensures that the clone plugin
       is installed on all cluster members (if available and not
       disabled) at cluster creation time and also whenever an
       instance is added to a cluster. (Bug #29954085)

     * The Cluster.rejoinInstance() operation was not checking
       the GTID consistency of an instance being rejoined to a
       cluster, which could result in data diverging. Now, the
       GTID consistency checks conducted as part of the
       Cluster.rejoinInstance() operation have been improved to
       check for irrecoverable or diverged data-sets and also
       for empty GTID sets. If an instance is found to not be
       consistent with the cluster, it is not rejoined and the
       operation fails with a descriptive error. You are also
       shown the list of errant transactions, possible outcomes
       and solutions. (Bug #29953812)

     * Cluster.describe() was retrieving information about the
       cluster’s topology and the MySQL version installed on
       instances directly from the current session. Now, the
       information is retrieved from the Metadata schema, and
       the MySQL version is not included in the information
       output by Cluster.describe(). (Bug #29648806)

     * Using a password containing the ‘ character caused
       dba.deploySandbox() to fail. Now, all sensitive data is
       correctly wrapped to avoid such issues. (Bug #29637581)

     * The Cluster.addInstance() operation creates internal
       recovery users which are required by the Group
       Replication recovery process. If the
       Cluster.addInstance() operation failed, for example
       because Group Replication could not start, the created
       recovery users were not removed. Now, in the event of a
       failure any internal users are removed. (Bug #25503159)

     * When a cluster had lost quorum and the majority of the
       cluster instances were offline except the primary, after
       reestablishing quorum and adding a new instance to the
       cluster, it was not possible to remove and add the
       previous primary instance to the cluster. This was
       because the operation failed when trying to contact
       offline instances, which was because the feature to
       verify if a Group Replication protocol upgrade is
       required was not considering the possibility of some
       cluster instances being offline (not reachable). The fix
       improves the Group Replication protocol upgrade handling
       for the Cluster.removeInstance() operation, which now
       attempts to connect to other cluster instances and use
       the first reachable instance for this purpose. (Bug
       #25267603)

     * The dba.configureInstance() operation was not setting the
       binlog_checksum option with the required value (NONE) in
       the option file for instances that did not support SET
       PERSIST (for example instances running MySQL 5.7), when
       the option file path was not provided as an input
       parameter but instead specified though the operation
       wizard in interactive mode. (Bug #96489, Bug #30171090)

Functionality Added or Changed

     * MySQL Shell’s upgrade checker utility (the
       util.checkForServerUpgrade() operation) includes the
       following new and extended checks:

          + The utility now checks for tablespace names
            containing the string “FTS”, which can be
            incorrectly identified as tablespaces of full-text
            index tables, preventing upgrade. The issue has been
            fixed in MySQL 8.0.18, but affects upgrades to
            earlier MySQL 8.0 releases.

          + The check for database objects with names that
            conflict with reserved keywords now covers the
            additional keywords ARRAY, MEMBER, and LATERAL.

          + – The checks for obsolete sql_mode flags now check
            the global sql_mode setting.
       Running the upgrade checker utility no longer alters the
       gtid_executed value, meaning that the utility can be used
       on Group Replication group members without affecting
       their synchronization with the group. The upgrade checker
       also now works correctly with the ANSI_QUOTES SQL mode.
       (Bug #30002732, Bug #30103683, Bug #96351)
       References: See also: Bug #29992589.

     * MySQL Shell has two new built-in reports, which provide
       information drawn from various sources including MySQL’s
       Performance Schema:

          + threads lists the current threads in the connected
            MySQL server which belong to the user account that
            is used to run the report. Using the report-specific
            options, you can choose to show foreground threads,
            background threads, or all threads. You can report a
            default set of information for each thread, or
            select specific information to include in the report
            from a larger number of available choices. You can
            filter, sort, and limit the output.

          + thread provides detailed information about a
            specific thread in the connected MySQL server. By
            default, the report shows information on the thread
            used by the current connection, or you can identify
            a thread by its ID or by the connection ID. You can
            select one or more categories of information, or
            view all of the available information about the
            thread.
       You can run the new reports using MySQL Shell’s \show and
       \watch commands. The reports work with servers running
       all supported MySQL 5.7 and MySQL 8.0 versions. If any
       item of information is not available in the MySQL Server
       version of the target server, the reports leave it out.

     * MySQL Shell has two new control commands:

          + The \edit (\e) command opens a command in the
            default system editor for editing. If you specify an
            argument to the command, this text is placed in the
            editor, and if you do not, the last command in the
            MySQL Shell history is placed in the editor. When
            you have finished editing, MySQL Shell presents your
            edited text ready for you to execute or cancel. The
            command can also be invoked using the short form \e
            or the key combination Ctrl-X Ctrl-E.

          + The \system (\!) command runs the operating system
            command that you specify as an argument to the
            command, then displays the output from the command
            in MySQL Shell. MySQL Shell returns an error if it
            was unable to execute the command.

     * MySQL Shell now uses Python 3. For platforms that include
       a system supported installation of Python 3, MySQL Shell
       uses the most recent version available, with a minimum
       supported version of Python 3.4.3. For platforms where
       Python 3 is not included, MySQL Shell bundles Python
       3.7.4. MySQL Shell maintains code compatibility with
       Python 2.6 and Python 2.7, so if you require one of these
       older versions, you can build MySQL Shell from source
       using the appropriate Python version.

Bugs Fixed

     * In debug mode, MySQL Shell raised an assertion when
       handling a character contained in SQL strings. (Bug
       #30286680)

     * If a Python lambda was added as a member of a MySQL Shell
       extension object, the Python object was not released
       correctly when MySQL Shell shut down, causing a
       segmentation fault. (Bug #30156304)

     * A memory leak could occur when Python code was executed
       in interactive mode. (Bug #30138755)

     * Help information for a MySQL Shell report could not be
       displayed unless there was an active session. MySQL Shell
       now checks for an open session only before actually
       running the report. (Bug #30083371)

     * If a default schema was set for the MySQL Shell
       connection, and a different default schema was set after
       the connection was made, MySQL Shell’s \reconnect command
       attempted to use the default schema from the original
       connection. The user’s current default schema is now used
       for the reconnection attempt. (Bug #30059354)

     * Due to a bug introduced by a change in MySQL Shell
       8.0.16, the MSI file that is used by Windows Installer to
       install MySQL Shell overwrote the Windows PATH
       environment variable with the path to the application
       binary (mysqlsh), removing any other paths present. The
       issue has now been fixed. (Bug #29972020, Bug #95432)

     * When the \reconnect command is used to attempt
       reconnection to a server, if the last active schema set
       by the user appears to be no longer available, MySQL
       Shell now attempts to connect with no schema set. (Bug
       #29954572)

     * In interactive mode, MySQL Shell now handles multiline
       comments beginning with a slash and asterisk (/*) and
       ending with an asterisk and slash (*/). (Bug #29938424)

     * The MySQL Shell \source command was not handled correctly
       when used in combination with SQL statements. (Bug
       #29889926)

     * With MySQL Shell in SQL mode, if multiple SQL statements
       including a USE statement were issued on a single line
       with delimiters, the USE statement was not handled
       correctly. (Bug #29881615)

     * If MySQL Shell’s JSON import utility was used to send a
       large number of JSON documents to a server with
       insufficient processing capacity, the utility could fill
       up the write queue with batches of prepared documents,
       causing the connection to time out and the import to
       fail. The utility now waits to read the response from the
       server before sending the next batch of prepared
       documents to the server. (Bug #29878964)

     * When MySQL Shell was built from source with a bundled
       OpenSSL package, the required linker flags were not set.
       The issue has now been fixed. (Bug #29862189)

     * If a new query was executed in MySQL Shell while a result
       was still active, resulting in rows being cached, not all
       rows were returned by the old query. (Bug #29818714)

On Behalf of Oracle/MySQL Release Engineering Team,
Balasubramanian Kandasamy

MySQL Shell 8.0.16 for MySQL Server 8.0 and 5.7 has been released

Posted on April 25, 2019 by MySQL Release Engineering

Dear MySQL users,

MySQL Shell 8.0.16 is a maintenance release of MySQL Shell 8.0 Series (a
component of the MySQL Server). The MySQL Shell is provided under
Oracle’s dual-license.

MySQL Shell 8.0 is highly recommended for use with MySQL Server 8.0 and
5.7. Please upgrade to MySQL Shell 8.0.16.

MySQL Shell is an interactive JavaScript, Python and SQL console
interface, supporting development and administration for the MySQL
Server. It provides APIs implemented in JavaScript and Python that
enable you to work with MySQL InnoDB cluster and use MySQL as a document
store.

The AdminAPI enables you to work with MySQL InnoDB cluster, providing an
integrated solution for high availability and scalability using InnoDB
based MySQL databases, without requiring advanced MySQL expertise. For
more information about how to configure and work with MySQL InnoDB
cluster see

https://dev.mysql.com/doc/refman/en/mysql-innodb-cluster-userguide.html

The X DevAPI enables you to create “schema-less” JSON document
collections and perform Create, Update, Read, Delete (CRUD) operations
on those collections from your favorite scripting language. For more
information about how to use MySQL Shell and the MySQL Document Store
support see

https://dev.mysql.com/doc/refman/en/document-store.html

For more information about the X DevAPI see

https://dev.mysql.com/doc/x-devapi-userguide/en/

If you want to write applications that use the the CRUD based X DevAPI
you can also use the latest MySQL Connectors for your language of
choice. For more information about Connectors see

https://dev.mysql.com/doc/index-connectors.html

For more information on the APIs provided with MySQL Shell see

https://dev.mysql.com/doc/dev/mysqlsh-api-javascript/8.0/

and

https://dev.mysql.com/doc/dev/mysqlsh-api-python/8.0/

Using MySQL Shell’s SQL mode you can communicate with servers using the
legacy MySQL protocol. Additionally, MySQL Shell provides partial
compatibility with the mysql client by supporting many of the same
command line options.

For full documentation on MySQL Server, MySQL Shell and related topics,
see

https://dev.mysql.com/doc/mysql-shell/8.0/en/

For more information about how to download MySQL Shell 8.0.16, see the
“Generally Available (GA) Releases” tab at

http://dev.mysql.com/downloads/shell/

We welcome and appreciate your feedback and bug reports, see

http://bugs.mysql.com/

Enjoy and thanks for the support!

Changes in MySQL Shell 8.0.16 (2019-04-25, General Availability)

* Functionality Added or Changed

* Bugs Fixed

Functionality Added or Changed

* Important Change: Attempting to connect to an X Protocol
port, 33060 by default, using the classic MySQL protocol resulted
in the following error: ERROR 2013 (HY000): Lost connection to
MySQL server at 'reading initial communication packet', system
error: 0 This was because of differences in X Protocol and
classic MySQL protocol clients expectations on how connections
were initialized. Now, in such a situation the generated error
message is ERROR 2007 (HY000): Protocol mismatch; server version
= 11, client version = 10. If you encounter this error then you
are probably trying to use the wrong port for the protocol your
client is using. As part of this improvement the
mysqlx_enable_hello_notice system variable has been added, which
controls messages sent to classic MySQL protocol clients that try
to connect over X Protocol. When enabled, clients which do not
support X Protocol that attempt to connect to the server X
Protocol port receive an error explaining they are using the
wrong protocol. Set mysqlx_enable_hello_notice to false to permit
clients which do not recognize the hello message to still
connect.

* MySQL Shell's upgrade checker utility can now check the
configuration file (my.cnf or my.ini) for the server instance.
The utility checks for any system variables that are defined in
the configuration file but have been removed in the target MySQL
Server release, and also for any system variables that are not
defined in the configuration file and will have a different
default value in the target MySQL Server release. For these
checks, when you invoke checkForServerUpgrade(), you must provide
the file path to the configuration file. If you omit the file
path and the upgrade checker utility needs to run a check that
requires the configuration file, that check fails with a message
informing you that you must specify the file path. (Bug
#27801824, Bug #29222179)

* MySQL InnoDB cluster automatically and transparently
manages the communication protocol versions of its members,
whenever the cluster topology is changed using AdminAPI
operations. An InnoDB cluster always uses the most recent
communication protocol version that is supported by all instances
that are part of the cluster or joining it.

+ When an instance is added to, removed from, or
rejoins the cluster, or a rescan or reboot operation
is carried out on the cluster, the communication
protocol version is automatically set to a version
supported by the instance that is now at the
earliest MySQL Server version.

+ When you carry out a rolling upgrade by removing
instances from the cluster, upgrading them, and
adding them back into the cluster, the communication
protocol version is automatically upgraded when the
last remaining instance at the old MySQL Server
version is removed from the cluster prior to its
upgrade.
To see the communication protocol version in use in an
InnoDB cluster, use the Cluster.status() function with
the 'extended' option enabled. The communication protocol
version is returned in the 'GRProtocolVersion' field,
provided that the cluster has quorum and no cluster
members are unreachable.

* MySQL Shell now has a framework and commands that you can
use to set up and run reports to display live information from a
MySQL server, such as status and performance information. Reports
can be run once using the MySQL Shell \show command, or run then
refreshed continuously in a MySQL Shell session using the \watch
command. They can also be accessed as API functions in the
shell.reports object. The reporting facility supports both
built-in reports and user-defined reports. User-defined reports
can be created in the supported scripting languages JavaScript
and Python, and can be run in any MySQL Shell mode (JavaScript,
Python, or SQL), regardless of the language that the report was
written in. Reports can be saved in a folder in the MySQL Shell
configuration path and automatically loaded at startup. You can
also create a report directly in the MySQL Shell prompt. You
register a report to MySQL Shell using the shell.registerReport
method to provide information about the report and the options
and arguments that it supports. For more information, see
Reporting with MySQL Shell
(http://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-reporting.html).

* When running MySQL Shell in interactive mode, you can now
execute an SQL statement without switching to SQL mode and back
again afterwards. This function enables you to conveniently issue
some SQL statements in the context of a longer AdminAPI workflow
in JavaScript or Python mode. Use the \sql command immediately
followed by the SQL statement, for example:
\sql select * from sakila.actor limit 3;
The SQL statement does not need any additional quoting, and the
statement delimiter is optional. With this format, MySQL Shell
does not switch mode as it would if you entered the \sql command.
After the SQL statement has been executed, MySQL Shell remains in
JavaScript or Python mode.
You cannot use multiple line mode when you use the \sql command
with a query to execute single SQL statements while another
language is active. The command only accepts a single SQL query
on a single line.

* MySQL Shell history is now split per active language
which the command was issued under. This means that your history
now matches the active language, for example when you are running
in JavaScript mode having issued \js, the history contains the
previous JavaScript statements you issued, and when you issue
\sql to change to SQL mode your history contains the previous SQL
statements you issued. Similarly, now any history related
commands such as \history clear or \history delete are performed
on the history of the current active language. When you install
this version, any existing MySQL Shell history files are
duplicated to ensure that existing history is not lost.
Subsequent operations are then added to the language specific
history file.

* The new autoRejoinTries option enables you to configure
how many times an instance tries to rejoin a group after being
expelled. In scenarios where network glitches happen but recover
quickly, setting this option prevents you from having to manually
add the expelled instance back to the group. The autoRejoinTries
option accepts positive integer values between 0 and 2016 and the
default value is 0, which means that instances do not try to
automatically rejoin. Set the value to a valid integer to
configure the number of attempts expelled instances should make
to rejoin the group. You can pass the autoRejoinTries option to
these AdminAPI operations:

+ dba.createCluster()

+ Cluster.addInstance()

+ Cluster.setOption()

+ Cluster.setInstanceOption()
When you configure the autoRejoinTries option, it sets
the group_replication_autorejoin_tries system variable.
Passing the option to dba.createCluster(),
Cluster.addInstance() or Cluster.setInstanceOption()
configures the automatic rejoin for specific cluster
instances. Passing the option to Cluster.setOption()
configures the automatic rejoin for all cluster
instances.
For more information, see Responses to Failure Detection
and Network Partitioning
(http://dev.mysql.com/doc/refman/8.0/en/group-replication-responses-failure.html).

* When resultFormat was set to json or json/raw, every
result was being returned as a JSON document. This behavior was
expected when JSON wrapping is off (in other words the --json
command option was not used when starting MySQL Shell). Now, for
consistency reasons when JSON wrapping is off and resultFormat is
set to json or json/raw, every record is printed in a separate
document and statistics and warnings are printed in plain text.
For example if MySQL Shell is started without --json and
resultFormat=json/raw:
mysqlsh-sql> SHOW DATABASES;
{"Database":"information_schema"}
{"Database":"mysql"}
{"Database":"performance_schema"}
{"Database":"sys"}
4 rows in set (0.0035 sec)

If MySQL Shell is started with --json and with
resultFormat=json/raw:
mysqlsh-sql> SHOW DATABASES;
{
"hasData": true,
"rows": [
{
"Database": "information_schema"
},
{
"Database": "mysql"
},
{
"Database": "performance_schema"
},
{
"Database": "sys"
}
],
"executionTime": "0.0018 sec",
"affectedRowCount": 0,
"affectedItemsCount": 0,
"warningCount": 0,
"warningsCount": 0,
"warnings": [],
"info": "",
"autoIncrementValue": 0
}

* AdminAPI now reports information about the version of
MySQL running on instances. This information is available from
the following operations:

+ Cluster.status()

+ Cluster.describe()

+ Cluster.rescan()

See Checking the MySQL Version on Instances
(http://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-working-
with-cluster.html#checking-version-on-instances) for
more information.

Bugs Fixed

* Removing an instance from a cluster when the instance to
be removed had no user defined for the group_replication_recovery
channel resulted in dropping users on the remaining instances of
the cluster. (Bug #29617572)

* MySQL Shell could be installed in an environment where
Python was not present, but the application has a dependency on
many standard Python modules, resulting in error messages at
startup. The RPM and Debian packages for MySQL Shell now
explicitly specify the dependency on Python. (Bug #29469201)

* The MSI file that is used by Windows Installer to install
MySQL Shell now adds the path to the application binary (mysqlsh)
to the Windows PATH environment variable, so that the application
can be started from a command prompt. (Bug #29457639)

* In the instructions to build MySQL Shell from source (the
INSTALL document), the required version of the optional V8
dependency has been updated from 3.28.71.19 to 6.7.288.46. Thanks
to Evgeniy Patlan for spotting this. (Bug #29430049, Bug #94529)

* The failoverConsistency option has been deprecated and a
new option named consistency has been added, to make it more
consistent with the target Group Replication
group_replication_consistency system variable name. The MySQL
Shell online documentation now also correctly describes all of
the values you can assign to the consistency option. (Bug
#29356599)

* The dba.configureLocalInstance() operation would remove
any section that did not start with mysqld from the provided
option file. This could remove sections such as the client
section from the option file. (Bug #29349014)

* MySQL Shell's upgrade checker utility
checkForServerUpgrade() could incorrectly report a schema
inconsistency error for a table whose name included a special
character such as a hyphen. (Bug #29346836, Bug #94303)

* When an instance with X Plugin disabled was added to an
InnoDB cluster, if the instance was later removed from the
cluster using Cluster.removeInstance() the operation failed with
LogicError "get_string(7): field is NULL". This was a regression
introduced by the fix for Bug#27677227. (Bug #29304183)

* There was an inconsistency between the behavior of
dba.checkInstanceConfiguration() and the commands to add
instances to the cluster (dba.createCluster() and
Cluster.addInstance()) regarding the localhost and loopback
address validation. In particular, a simple error was printed by
dba.checkInstanceConfiguration() but the execution of the
operation continued showing that everything was correct at the
end of the operation, while an error was issued and the execution
stopped for dba.createCluster() and Cluster.addInstance(). As
part of fixing this issue, it was decided that the existing
localhost and loopback address validations are no longer needed
and should be removed. In particular, whatever address is
specified for report_host, even if it is localhost or the
loopback address (127.0.0.1), should be allowed, because it was
explicitly specified by the user to use it. (Bug #29279941)

* The dba.rebootClusterFromCompleteOutage() operation was
not preserving the existing Group Replication configurations
previously set for the instances. In particular, the Group
Replication local address and exit state action values were being
changed. Now all settings are read at the time of rebooting the
cluster. (Bug #29265869)

* On Windows, MySQL Shell's upgrade checker utility
checkForServerUpgrade() incorrectly reported a schema
inconsistency error for partitioned tables. (Bug #29256562)

* Using either Cluster.setOption() or
Cluster.setInstanceOption() to set an option which only exists in
MySQL 8.0 on an instance running MySQL 5.7 was not being caught
correctly. (Bug #29246657)

* On Debian-based platforms (such as Ubuntu), if the
hostname resolved to 127.0.1.1 - which is the default on these
platforms - it was not possible to create a cluster using the
default settings. Now, in such situations a proper validation of
the instance is performed before creating a cluster and adding
instances to it. (Bug #29246110)

* MySQL Shell stopped unexpectedly if Python code was
running in interactive mode and threw exceptions from C++
libraries. These exceptions are now caught and translated to
Python's built-in RuntimeError exceptions. (Bug #29057116)

* The dba.checkInstanceConfiguration() operation did not
validate host restrictions for the account provided for cluster
administration, for example if the account could actually connect
to all of the instances in the cluster. In particular, now an
error is issued if the provided user account is only able to
connect through localhost. (Bug #29018457)

* When a connection is specified using key-value pairs in
MySQL Shell's shell.connect() method, the host name cannot be an
empty string. MySQL Shell now handles this situation consistently
and returns an error if the supplied host name is an empty
string. (Bug #28899522)

* InnoDB cluster configured auto_increment_increment and
auto_increment_offset on instances for clusters running in
multi-primary mode and consisting of up to 7 instances based on
the logic described at InnoDB cluster and Auto-increment
(http://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-working-with-
cluster.html#mysql-innodb-cluster-auto-increment). But Group
Replication permits groups to contain up to 9 members, and
Cluster.addInstance() and Cluster.removeInstance() were not
following the logic used for other operations. Now, InnoDB
cluster uses the same logic for auto increment regardless of the
operation used and correctly handles multi-primary clusters with
more than 7 instances. (Bug #28812763)

* MySQL Shell's JSON import utility can now accept input
from FIFO special files (named pipes) when you invoke the utility
using the util.importJSON function, so you can carry out large
imports by this method without needing to put the data into a
file. (Bug #28785527)

* When you use the MySQL Shell command \help (or \h, or \?)
with a search pattern to search for help on a specific subject,
multiple help topic titles can match the pattern and be returned
as a list, to be selected by entering the command again with an
extended search pattern. With this system, it was possible for
help topics with a single-word title to be inaccessible from such
a list because there was nothing further to add to the search
pattern. To avoid this situation, the handling of multiple
matches has now been improved. If a topic title is found that
matches the given search pattern exactly (case-sensitive in the
event of multiple topic matches, and case-insensitive in the
event of no case-sensitive matches), the topic is identified as
the exact match and its help data is printed. The rest of the
topics with pattern matches in their titles are listed in a "see
also" section and can be selected by further pattern matching.
(Bug #28393119)

* MySQL Shell uses the host value of the provided
connection parameters as the target hostname used for AdminAPI
operations, namely to register the instance in the metadata (for
the dba.createCluster() and cluster.addInstance() operations).
However, the host used for the connection parameters might not
match the hostname that is used or reported by Group Replication,
which uses the value of the report_host system variable when it
is defined (in other words it is not NULL), otherwise the value
of hostname is used. Therefore, AdminAPI now follows the same
logic to register the target instance in the metadata and as the
default value for the group_replication_local_address variable on
instances, instead of using the host value from the instance
connection parameters. During this fix it was detected that when
the report_host variable was set to empty, Group Replication uses
an empty value for the host but AdminAPI (for example in commands
such as dba.checkInstanceConfiguration(),
dba.configureInstance(), dba.createCluster()) reports the
hostname as the value used which is inconsistent with the value
reported by Group Replication. An error is now issued by AdminAPI
if an empty value is set for the report_host system variable.
(Bug #28285389)

* In the event that dba.createCluster() failed and a
rollback was performed to remove the created replication
(recovery) users, the account created at localhost and any of the
ipWhitelist addresses were not being removed. The fix ensures
that the replication accounts are removed whenever a rollback
related to dba.createCluster() is performed. This work was based
on a code contribution from Bin Hong. (Bug #94182, Bug #29308037)

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

383

384

385

386

387

388

389

390

391

392

393

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

430

431

432

433

434

435

436

437

438

439

440

441

442

443

444

445

446

447

448

449

450

451

452

453

454

455

456

457

458

459

460

461

462

463

464

465

466

467

468

469

470

471

472

473

474

475

476

477

478

479

480

481

482

483

484

485

486

487

488

489

490

491

492

493

494

495

496

497

498

499

500

501

502

503

504

505

506

507

508

509

510

511

512

513

514

515

516

517

518

519

520

521

522

523

524

525

526

527

528

529

530

531

532

533

534

535

536

537

538

539

540

541

542

543

544

545

546

547

548

549

550

551

552

553

554

555

556

557

558

559

560

561

562

563

564

565

566

567

568

569

570

571

572

573

574

575

576

577

578

579

580

581

582

583

584

585

586

587

588

589

590

591

592

593

594

595

596

597

598

599

600

601

602

603

604

605

606

607

608

609

610

611

612

613

614

615

616

617

618

619

620

621

622

623

624

625

626

627

628

629

630

631

632

633

634

635

636

637

638

639

640

641

642

643

644

645

646

647

648

649

650

651

652

653

654

655

656

657

658

659

660

661

662

663

664

665

666

667

668

669

670

671

672

673

674

675

676

677

678

679

680

681

682

683

684

685

686

687

688

689

690

691

692

693

694

695

696

697

698

699

700

701

702

703

704

705

706

707

708

709

710

711

712

713

714

715

716

717

718

719

720

721

722

723

724

725

726

727

728

729

730

731

732

733

734

735

736

737

738

739

740

741

742

743

744

745

746

747

748

749

750

751

752

753

754

755

756

757

758

759

760

761

Changes in MySQL Shell 8.0.16 (2019-04-25, General Availability)

* Functionality Added or Changed

* Bugs Fixed

Functionality Added or Changed

* Important Change: Attempting to connect to an X Protocol

port, 33060 by default, using the classic MySQL protocol resulted

in the following error: ERROR 2013 (HY000): Lost connection to

MySQL server at 'reading initial communication packet', system

error: 0 This was because of differences in X Protocol and

classic MySQL protocol clients expectations on how connections

were initialized. Now, in such a situation the generated error

message is ERROR 2007 (HY000): Protocol mismatch; server version

= 11, client version = 10. If you encounter this error then you

are probably trying to use the wrong port for the protocol your

client is using. As part of this improvement the

mysqlx_enable_hello_notice system variable has been added, which

controls messages sent to classic MySQL protocol clients that try

to connect over X Protocol. When enabled, clients which do not

support X Protocol that attempt to connect to the server X

Protocol port receive an error explaining they are using the

wrong protocol. Set mysqlx_enable_hello_notice to false to permit

clients which do not recognize the hello message to still

connect.

* MySQL Shell's upgrade checker utility can now check the

configuration file (my.cnf or my.ini) for the server instance.

The utility checks for any system variables that are defined in

the configuration file but have been removed in the target MySQL

Server release, and also for any system variables that are not

defined in the configuration file and will have a different

default value in the target MySQL Server release. For these

checks, when you invoke checkForServerUpgrade(), you must provide

the file path to the configuration file. If you omit the file

path and the upgrade checker utility needs to run a check that

requires the configuration file, that check fails with a message

informing you that you must specify the file path. (Bug

#27801824, Bug #29222179)

* MySQL InnoDB cluster automatically and transparently

manages the communication protocol versions of its members,

whenever the cluster topology is changed using AdminAPI

operations. An InnoDB cluster always uses the most recent

communication protocol version that is supported by all instances

that are part of the cluster or joining it.

+ When an instance is added to, removed from, or

rejoins the cluster, or a rescan or reboot operation

is carried out on the cluster, the communication

protocol version is automatically set to a version

supported by the instance that is now at the

earliest MySQL Server version.

+ When you carry out a rolling upgrade by removing

instances from the cluster, upgrading them, and

adding them back into the cluster, the communication

protocol version is automatically upgraded when the

last remaining instance at the old MySQL Server

version is removed from the cluster prior to its

upgrade.

To see the communication protocol version in use in an

InnoDB cluster, use the Cluster.status() function with

the 'extended' option enabled. The communication protocol

version is returned in the 'GRProtocolVersion' field,

provided that the cluster has quorum and no cluster

members are unreachable.

* MySQL Shell now has a framework and commands that you can

use to set up and run reports to display live information from a

MySQL server, such as status and performance information. Reports

can be run once using the MySQL Shell \show command, or run then

refreshed continuously in a MySQL Shell session using the \watch

command. They can also be accessed as API functions in the

shell.reports object. The reporting facility supports both

built-in reports and user-defined reports. User-defined reports

can be created in the supported scripting languages JavaScript

and Python, and can be run in any MySQL Shell mode (JavaScript,

Python, or SQL), regardless of the language that the report was

written in. Reports can be saved in a folder in the MySQL Shell

configuration path and automatically loaded at startup. You can

also create a report directly in the MySQL Shell prompt. You

method to provide information about the report and the options

and arguments that it supports. For more information, see

Reporting with MySQL Shell

(http://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-reporting.html).

* When running MySQL Shell in interactive mode, you can now

execute an SQL statement without switching to SQL mode and back

again afterwards. This function enables you to conveniently issue

some SQL statements in the context of a longer AdminAPI workflow

in JavaScript or Python mode. Use the \sql command immediately

followed by the SQL statement, for example:

\sql select * from sakila.actor limit 3;

The SQL statement does not need any additional quoting, and the

statement delimiter is optional. With this format, MySQL Shell

does not switch mode as it would if you entered the \sql command.

After the SQL statement has been executed, MySQL Shell remains in

JavaScript or Python mode.

You cannot use multiple line mode when you use the \sql command

with a query to execute single SQL statements while another

language is active. The command only accepts a single SQL query

on a single line.

* MySQL Shell history is now split per active language

which the command was issued under. This means that your history

now matches the active language, for example when you are running

in JavaScript mode having issued \js, the history contains the

previous JavaScript statements you issued, and when you issue

\sql to change to SQL mode your history contains the previous SQL

statements you issued. Similarly, now any history related

commands such as \history clear or \history delete are performed

on the history of the current active language. When you install

this version, any existing MySQL Shell history files are

duplicated to ensure that existing history is not lost.

Subsequent operations are then added to the language specific

history file.

* The new autoRejoinTries option enables you to configure

how many times an instance tries to rejoin a group after being

expelled. In scenarios where network glitches happen but recover

quickly, setting this option prevents you from having to manually

add the expelled instance back to the group. The autoRejoinTries

option accepts positive integer values between 0 and 2016 and the

default value is 0, which means that instances do not try to

automatically rejoin. Set the value to a valid integer to

configure the number of attempts expelled instances should make

to rejoin the group. You can pass the autoRejoinTries option to

these AdminAPI operations:

+ dba.createCluster()

+ Cluster.addInstance()

+ Cluster.setOption()

+ Cluster.setInstanceOption()

When you configure the autoRejoinTries option, it sets

the group_replication_autorejoin_tries system variable.

Passing the option to dba.createCluster(),

Cluster.addInstance() or Cluster.setInstanceOption()

configures the automatic rejoin for specific cluster

instances. Passing the option to Cluster.setOption()

configures the automatic rejoin for all cluster

instances.

For more information, see Responses to Failure Detection

and Network Partitioning

(http://dev.mysql.com/doc/refman/8.0/en/group-replication-responses-failure.html).

* When resultFormat was set to json or json/raw, every

result was being returned as a JSON document. This behavior was

expected when JSON wrapping is off (in other words the --json

command option was not used when starting MySQL Shell). Now, for

consistency reasons when JSON wrapping is off and resultFormat is

set to json or json/raw, every record is printed in a separate

document and statistics and warnings are printed in plain text.

For example if MySQL Shell is started without --json and

resultFormat=json/raw:

mysqlsh-sql> SHOW DATABASES;

{"Database":"information_schema"}

{"Database":"mysql"}

{"Database":"performance_schema"}

{"Database":"sys"}

4 rows in set (0.0035 sec)

If MySQL Shell is started with --json and with

resultFormat=json/raw:

mysqlsh-sql> SHOW DATABASES;

{

"hasData": true,

"rows": [

{

"Database": "information_schema"

{

"Database": "mysql"

{

"Database": "performance_schema"

{

"Database": "sys"

}

"executionTime": "0.0018 sec",

"affectedRowCount": 0,

"affectedItemsCount": 0,

"warningCount": 0,

"warningsCount": 0,

"warnings": [],

"info": "",

"autoIncrementValue": 0

}

* AdminAPI now reports information about the version of

MySQL running on instances. This information is available from

the following operations:

+ Cluster.status()

+ Cluster.describe()

+ Cluster.rescan()

See Checking the MySQL Version on Instances

(http://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-working-

with-cluster.html#checking-version-on-instances) for

more information.

Bugs Fixed

* Removing an instance from a cluster when the instance to

be removed had no user defined for the group_replication_recovery

channel resulted in dropping users on the remaining instances of

the cluster. (Bug #29617572)

* MySQL Shell could be installed in an environment where

Python was not present, but the application has a dependency on

many standard Python modules, resulting in error messages at

startup. The RPM and Debian packages for MySQL Shell now

explicitly specify the dependency on Python. (Bug #29469201)

* The MSI file that is used by Windows Installer to install

MySQL Shell now adds the path to the application binary (mysqlsh)

to the Windows PATH environment variable, so that the application

can be started from a command prompt. (Bug #29457639)

* In the instructions to build MySQL Shell from source (the

INSTALL document), the required version of the optional V8

dependency has been updated from 3.28.71.19 to 6.7.288.46. Thanks

to Evgeniy Patlan for spotting this. (Bug #29430049, Bug #94529)

* The failoverConsistency option has been deprecated and a

new option named consistency has been added, to make it more

consistent with the target Group Replication

group_replication_consistency system variable name. The MySQL

Shell online documentation now also correctly describes all of

the values you can assign to the consistency option. (Bug

#29356599)

* The dba.configureLocalInstance() operation would remove

any section that did not start with mysqld from the provided

option file. This could remove sections such as the client

section from the option file. (Bug #29349014)

* MySQL Shell's upgrade checker utility

checkForServerUpgrade() could incorrectly report a schema

inconsistency error for a table whose name included a special

character such as a hyphen. (Bug #29346836, Bug #94303)

* When an instance with X Plugin disabled was added to an

InnoDB cluster, if the instance was later removed from the

cluster using Cluster.removeInstance() the operation failed with

LogicError "get_string(7): field is NULL". This was a regression

introduced by the fix for Bug#27677227. (Bug #29304183)

* There was an inconsistency between the behavior of

dba.checkInstanceConfiguration() and the commands to add

instances to the cluster (dba.createCluster() and

Cluster.addInstance()) regarding the localhost and loopback

address validation. In particular, a simple error was printed by

dba.checkInstanceConfiguration() but the execution of the

operation continued showing that everything was correct at the

end of the operation, while an error was issued and the execution

stopped for dba.createCluster() and Cluster.addInstance(). As

part of fixing this issue, it was decided that the existing

localhost and loopback address validations are no longer needed

and should be removed. In particular, whatever address is

specified for report_host, even if it is localhost or the

loopback address (127.0.0.1), should be allowed, because it was

explicitly specified by the user to use it. (Bug #29279941)

* The dba.rebootClusterFromCompleteOutage() operation was

not preserving the existing Group Replication configurations

previously set for the instances. In particular, the Group

Replication local address and exit state action values were being

changed. Now all settings are read at the time of rebooting the

cluster. (Bug #29265869)

* On Windows, MySQL Shell's upgrade checker utility

checkForServerUpgrade() incorrectly reported a schema

inconsistency error for partitioned tables. (Bug #29256562)

* Using either Cluster.setOption() or

Cluster.setInstanceOption() to set an option which only exists in

MySQL 8.0 on an instance running MySQL 5.7 was not being caught

correctly. (Bug #29246657)

* On Debian-based platforms (such as Ubuntu), if the

hostname resolved to 127.0.1.1 - which is the default on these

platforms - it was not possible to create a cluster using the

default settings. Now, in such situations a proper validation of

the instance is performed before creating a cluster and adding

instances to it. (Bug #29246110)

* MySQL Shell stopped unexpectedly if Python code was

running in interactive mode and threw exceptions from C++

libraries. These exceptions are now caught and translated to

Python's built-in RuntimeError exceptions. (Bug #29057116)

* The dba.checkInstanceConfiguration() operation did not

validate host restrictions for the account provided for cluster

administration, for example if the account could actually connect

to all of the instances in the cluster. In particular, now an

error is issued if the provided user account is only able to

connect through localhost. (Bug #29018457)

* When a connection is specified using key-value pairs in

MySQL Shell's shell.connect() method, the host name cannot be an

empty string. MySQL Shell now handles this situation consistently

and returns an error if the supplied host name is an empty

string. (Bug #28899522)

* InnoDB cluster configured auto_increment_increment and

auto_increment_offset on instances for clusters running in

multi-primary mode and consisting of up to 7 instances based on

the logic described at InnoDB cluster and Auto-increment

(http://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-working-with-

cluster.html#mysql-innodb-cluster-auto-increment). But Group

Replication permits groups to contain up to 9 members, and

Cluster.addInstance() and Cluster.removeInstance() were not

following the logic used for other operations. Now, InnoDB

cluster uses the same logic for auto increment regardless of the

operation used and correctly handles multi-primary clusters with

more than 7 instances. (Bug #28812763)

* MySQL Shell's JSON import utility can now accept input

from FIFO special files (named pipes) when you invoke the utility

using the util.importJSON function, so you can carry out large

imports by this method without needing to put the data into a

file. (Bug #28785527)

* When you use the MySQL Shell command \help (or \h, or \?)

with a search pattern to search for help on a specific subject,

multiple help topic titles can match the pattern and be returned

as a list, to be selected by entering the command again with an

extended search pattern. With this system, it was possible for

help topics with a single-word title to be inaccessible from such

a list because there was nothing further to add to the search

pattern. To avoid this situation, the handling of multiple

matches has now been improved. If a topic title is found that

matches the given search pattern exactly (case-sensitive in the

event of multiple topic matches, and case-insensitive in the

event of no case-sensitive matches), the topic is identified as

the exact match and its help data is printed. The rest of the

topics with pattern matches in their titles are listed in a "see

also" section and can be selected by further pattern matching.

(Bug #28393119)

* MySQL Shell uses the host value of the provided

connection parameters as the target hostname used for AdminAPI

operations, namely to register the instance in the metadata (for

the dba.createCluster() and cluster.addInstance() operations).

However, the host used for the connection parameters might not

match the hostname that is used or reported by Group Replication,

which uses the value of the report_host system variable when it

is defined (in other words it is not NULL), otherwise the value

of hostname is used. Therefore, AdminAPI now follows the same

logic to register the target instance in the metadata and as the

default value for the group_replication_local_address variable on

instances, instead of using the host value from the instance

connection parameters. During this fix it was detected that when

the report_host variable was set to empty, Group Replication uses

an empty value for the host but AdminAPI (for example in commands

such as dba.checkInstanceConfiguration(),

dba.configureInstance(), dba.createCluster()) reports the

hostname as the value used which is inconsistent with the value

reported by Group Replication. An error is now issued by AdminAPI

if an empty value is set for the report_host system variable.

(Bug #28285389)

* In the event that dba.createCluster() failed and a

rollback was performed to remove the created replication

(recovery) users, the account created at localhost and any of the

ipWhitelist addresses were not being removed. The fix ensures

that the replication accounts are removed whenever a rollback

related to dba.createCluster() is performed. This work was based

on a code contribution from Bin Hong. (Bug #94182, Bug #29308037)

On Behalf of Oracle/MySQL Release Engineering Team,
Nawaz Nazeer Ahamed

InsideMySQL.com

Latest news and insight directly from MySQL Engineering

Category Archives: mysql-shell

MySQL Shell 8.0.19 for MySQL Server 8.0 and 5.7 has been released

MySQL Shell 8.0.18 for MySQL Server 8.0 and 5.7 has been released

MySQL Shell 8.0.16 for MySQL Server 8.0 and 5.7 has been released