Dear MySQL users,
MySQL Shell 8.0.14 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.14. 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.14, 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.14 (2019-01-21) * Functionality Added or Changed * Bugs Fixed Functionality Added or Changed * When started from the command line, MySQL Shell prints information about the product, information about the session (such as the default schema and connection ID), warning messages, and any errors that are returned during startup and connection. You can now suppress printing of information that you do not need by using the --quiet-start[=1|2] mysqlsh command-line option. With a value of 1 (the default when the option is specified), information about the MySQL Shell product is not printed, but session information, warnings, and errors are printed. With a value of 2, only errors are printed. As part of this work, the printed information was tidied up so that the information about the MySQL Shell product is printed before the information about the session. Also, the handling of error printing was normalized to send diagnostic data to stderr, and errors to stdout. (Bug #28833718, Bug #28855291) * MySQL Shell connections using classic MySQL protocol now support compression for information sent between the client and the server. You can specify compression when you start MySQL Shell and connect using command line options, or in a URI string or a key-value pair when you create a session using other interfaces. You can also use the MySQL Shell configuration option defaultCompress to enable compression for every global session. For MySQL Shell connections that use Unix socket files, the --socket command line option can now be specified with no argument to connect using the default Unix socket file for the protocol. (Bug #28730149) * The Cluster.status() operation has been extended to enable you to display information about the underlying Group Replication group used by the cluster. Now you can retrieve information from all members of a cluster without having to connect to each member individually. To see information about the groupName and memberId; and general statistics about the number of transactions checked, proposed, and rejected by members issue: Cluster.status(extended:true) To see information about recovery and regular transaction I/O, applier worker thread statistics and any lags; applier coordinator statistics, if parallel apply is enabled; error, and other information from I/O and applier threads issue Cluster.status(queryMembers:true) In addition, in previous versions the URI-type string shown for groupInformationSourceMember in the output of Cluster.status() could be the cluster's MySQL Router address, rather than the address of the instance which provided the displayed group information. This has been improved to ensure groupInformationSourceMember always shows the correct hostname, or report_host, value and port, or report_port, value of the instance which provided the group information. As part of this work, the integration of MySQL Router to InnoDB cluster has been improved. (Bug #28636963, Bug #26519466, Bug #27824265, Bug #28366027) * The MySQL Shell JSON import utility can now process BSON (binary JSON) data types that are represented in JSON documents. The data types used in BSON documents are not all natively supported by JSON, but can be represented using extensions to the JSON format. The import utility can process documents that use JSON extensions to represent BSON data types, convert them to an identical or compatible MySQL representation, and import the data value using that representation. The resulting converted data values can be used in expressions and indexes, and manipulated by SQL statements and X DevAPI functions. To convert JSON extensions for BSON types into MySQL types in this way, you must specify the convertBsonTypes option when you run the import utility. Additional options are available to control the mapping and conversion for specific BSON data types. If you import documents with JSON extensions for BSON types and do not use this option, the documents are imported in the same way as they are represented in the input file. * A MySQL Shell configuration option showColumnTypeInfo and command line option --column-type-info have been added to display metadata for each column in a returned result set, such as the column type and collation. The metadata is printed before the result set, and is only shown in SQL mode. In the metadata, the column type is returned as both the type used by MySQL Shell (Type), and the type used by the original database (DBType). For MySQL Shell connections using classic MySQL protocol, DBType is as returned by the protocol, and for X Protocol connections, DBType is inferred from the available information. The column length (Length) is returned in bytes. * The upgrade checker utility provided by MySQL Shell, which is the checkForServerUpgrade() function of the util global object, has several enhancements: + The utility can now select and provide advice and instructions for relevant checks that cannot be automated, and must be performed manually. The manual checks are rated as either warning or notice (informational) level, and are listed after the automated checks. In MySQL Shell 8.0.14, the utility provides advice where relevant about the change of default authentication plugin in MySQL 8.0. + A check has been added for the removed log_syslog_* system variables that previously configured error logging to the system log (the Event Log on Windows, and syslog on Unix and Unix-like systems). + A check has been added for specific schema inconsistencies that can be caused by the deletion or corruption of a file, including the removal of the directory for a schema and the removal of a .frm file for a table. You can access the upgrade checker utility from within MySQL Shell or start it from the command line. For instructions and further information, see MySQL Shell Utilities (http://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities.html). * MySQL Shell can print results in table, tabbed, or vertical format, or as pretty or raw JSON output. From MySQL Shell 8.0.14, the new MySQL Shell configuration option resultFormat can be used to specify any of these output formats as a persistent default for all sessions, or just for the current session. Changing this option takes effect immediately. Alternatively, the new command line option --result-format can be used at startup to specify the output format for a session. The existing command line options --table, --tabbed, and --vertical are now aliases for the --result-format option given with the corresponding value. The existing command line option --json controls JSON wrapping for all MySQL Shell output from a session. Specifying --json or --json=pretty turns on JSON wrapping and generates pretty-printed JSON. Specifying --json=raw turns on JSON wrapping and generates raw JSON. With any of these options, the value of the resultFormat MySQL Shell configuration option is ignored. Specifying --json=off or not specifying the --json option turns off JSON wrapping, and result sets are output as normal in the format specified by the resultFormat configuration option. The outputFormat MySQL Shell configuration option is now deprecated. This option combined the JSON wrapping and result printing functions, which have now been separated. If this option is still specified in your MySQL Shell configuration file or scripts, the behavior is as follows: + With the json or json/raw value, outputFormat activates JSON wrapping with pretty or raw JSON respectively. + With the table, tabbed, or vertical value, outputFormat turns off JSON wrapping and sets the resultFormat MySQL Shell configuration option for the session to the appropriate value. * The V8 library used by MySQL Shell has been updated to version 6.7.288.46. * AdminAPI no longer relies on the mysqlprovision check command. This work has resulted in the following: + The errors field in the JSON returned by dba.checkInstanceConfiguration() has been removed, because it was only used to hold errors issued by mysqlprovision. Any errors are now reported directly, for example as RuntimeError. + The dba.verbose value no longer influences the amount of debug information displayed for dba.checkInstanceConfiguration() and dba.configureLocalInstance() because it was only used to control the verbosity of the information displayed from mysqlprovision. Instead, the generic verbose value from MySQL Shell is used to control the verbosity level for those functions. + In addition, the messages returned have been generally improved to make them more accurate. References: See also: Bug #28737777, Bug #27305806, Bug #28768627, Bug #27702439, Bug #28733883. * When you create a cluster, you can set the timeout before instances are expelled from the cluster, for example when they become unreachable. Pass the new expelTimeout option to the dba.createCluster() operation, which configures the group_replication_member_expel_timeout variable on the seed instance. All instances running MySQL server 8.0.13 and later which are added to the cluster are automatically configured to have the same group_replication_member_expel_timeout value as defined when the cluster was created using expelTimeout. * You can configure an InnoDB cluster's underlying Group Replication group while the cluster remains online. This enables you to choose a specific instance as the single primary, or to change between single-primary and multi-primary mode without taking the cluster offline. This uses the group coordinator and the equivalent UDFs added in WL#10378 (https://dev.mysql.com/worklog/task/?id=10378), see "Configuring an Online Group" (http://dev.mysql.com/doc/refman/8.0/en/group-replication-configuring-online-group.html). Use the following Cluster object operations: + Cluster.switchToSinglePrimaryMode([instance]), which runs group_replication_switch_to_single_primary_mode() on the underlying group, using instance as the primary, all other instances become secondaries + Cluster.switchToMultiPrimaryMode(), which runs group_replication_switch_to_multi_primary_mode() on the underlying group, all instances become primaries + Cluster.setPrimaryInstance(instance), which runs group_replication_set_as_primary() on the underlying group, configuring instance as the new primary * You can now configure the InnoDB cluster options of instances at a cluster level, while instances remain online. This avoids the need to remove, reconfigure and then again add the instance to change InnoDB cluster options. Use the following operations: + Cluster.options() to verify the settings of a cluster and its instances + Cluster.setOption(option, value) to change settings of all cluster instances globally + Cluster.setInstanceOption(instance, option, value) to change settings of individual cluster instances The way which you use InnoDB cluster options with the operations listed depends on whether the option can be changed to be the same on all instances or not. These options are changeable at both the cluster (all instances) and per instance level: + exitStateAction + memberWeight This option is changeable at the per instance level only: + label These options are changeable at the cluster level only: + failoverConsistency + expelTimeout + clusterName * The cluster.rescan() operation has been extended to enable you to detect changes to the cluster's topology, and modfiy the cluster metadata, for example to remove old instance data. Now you can: + use the updateTopologyMode option to detect if the Group Replication mode (single-primary or multi-primary mode) registered in the metadata matches the current mode of the cluster, updating that information in the metadata if requested through a new option or by a prompt confirmation. You can use this option to update the metadata after using the Cluster.switchToSinglePrimaryMode([instance]) and Cluster.switchToMultiPrimaryMode() options added in WL#12052 (https://dev.mysql.com/worklog/task/?id=12052). + use the addInstances option to specify a list of new instances to add to the metadata, or the removeInstances option to specify a list of obsolete instances to remove from the metadata. Pass the auto value to these options to automatically add or remove instances from the metadata, without having to specify an explicit list of instances. This enables the function to update the metadata even in non-interactive mode, making it consistent with the other AdminAPI operations. + In addition, a new interactive option has been added to the cluster.rescan() operation, to enable or disable interactive mode prompts specifically for the cluster.rescan() command. References: See also: Bug #28997465, Bug #28529362, Bug #28889563. Bugs Fixed * The TAR build of MySQL Shell comes with Python 2.7. When attempting to include the site package, an error was emitted because of missing build files needed by the include. (Bug #28973138) * Handling procedures for user-supplied data in MySQL Shell were refactored to ensure correct cleanup after use. (Bug #28915716) * The exception type and error messages returned by MySQL Shell functions for parameter errors have been standardized across the different functions. (Bug #28838958) * MySQL Shell stopped unexpectedly if the shell.setCurrentSchema() method was called to set the default schema before an active session had been established. MySQL Shell now validates that there is an active session when the operation takes place. (Bug #28814112) * The MySQL Shell JSON import utility no longer requires an empty dictionary to be supplied if there are no import options. (Bug #28768585) * In SQL mode, MySQL Shell does not add statements to the history if they include the strings IDENTIFIED or PASSWORD, or other strings that you configure using the --histignore command option or shell.options["history.sql.ignorePattern"]. However, this previously meant that filtered-out statements were not available to be corrected immediately after entry, and had to be re-typed in case of any errors. MySQL Shell now always makes the last executed statement available to be recalled by pressing the Up arrow, regardless of the filters set in the history ignore list. If filtering applies to the last executed statement, it is removed from the history as soon as another statement is entered, or if you exit MySQL Shell immediately after executing the statement. (Bug #28749037) * The result printing logic in MySQL Shell has been refactored to use back-end rather than high-level result data, delivering performance improvements for all types of result data and more accurate representation for JSON data. (Bug #28710831) * A memory leak was fixed that occurred when the new MySQL Shell command-line syntax was used. (Bug #28705373) * The check for partitioned tables in shared tablespaces in the upgrade checker utility provided by MySQL Shell (the util.checkForServerUpgrade() operation) did not return correct results for the 8.0.11 and 8.0.12 target versions. The check now uses alternative Information Schema tables that are populated with the required information in these versions. (Bug #28701423) * The default value for group_replication_exit_state_action is ABORT_SERVER, but AdminAPI now overrides this and sets the default on instances to READ_ONLY. This ensures that instances which leave the group unexpectedly continue running and can be rejoined to the cluster. (Bug #28701263) * The MySQL Shell command \option ignored additional arguments separated by spaces that were specified for an option after the initial value. (Bug #28658632) * MySQL Shell permitted newline characters (line feed and carriage return) in passwords to be passed to a Secret Store Helper using the shell.storeCredential method, resulting in an error in the Secret Store Helper. MySQL Shell now returns an exception if newline characters are used in supplied passwords for the shell.storeCredential method, and does not pass them to the Secret Store Helper. (Bug #28597766) * On the Windows platform, UTF-8 encoded strings were printed to the console using the cout object, which transfers a byte at a time. This resulted in multi-byte Unicode characters, such as a single quotation mark, being displayed and handled incorrectly. MySQL Shell now uses alternative functions for printing, and verifies that multi-byte UTF-8 characters are emitted as a complete unit. (Bug #28596692) * When executing an SQL script in MySQL Shell, an inaccurate line number was reported for the location of syntax errors in the script. The number referenced the current SQL block rather than the line number in the script. The error message now uses the global line number. (Bug #28545982) * The SQL statement splitting logic in MySQL Shell has been refactored to fix a number of issues and to match behaviors of the MySQL command-line tool mysql: + The backslash character (\) is no longer accepted in the delimiter string. + The use of the word "delimiter" in contexts other than as a command is now handled correctly. + In scripts, comments are not discarded, and groups of comments and statements are now split in the same way as mysql would split them. + Large scripts can now be successfully split into incremental chunks even when some tokens span across more than one chunk. + Scripts can now be parsed in the ANSI_QUOTES SQL mode. + Multi-line strings and comments that contain quotes are now parsed correctly. + Inline commands are handled in the same way as by mysql, as follows: o A \ character appearing at the beginning of a statement is interpreted as the start of a multi-letter MySQL Shell command. o A \ character appearing within a statement is interpreted as the start of a single-letter command. The command is executed immediately, then stripped out of the input statement. o A \ character appearing after the end of a statement is interpreted as the start of a single-letter command. (Bug #27959016, Bug #25689071) * When a cluster was created on a server that did not have the X Plugin enabled, a silent assumption was being made about the X Protocol port value. Now the value of an X Protocol port is only stored for instances on which X Plugin is enabled. (Bug #27677227) * The handling of Windows named pipe connections by MySQL Shell has been improved and systematized. Now, if you specify the host name as a period (.) on Windows, MySQL Shell connects using a named pipe. + If you are connecting using a URI type string, specify user@. + If you are connecting using a data dictionary, specify {"host": "."} + If you are connecting using individual parameters, specify --host=. or -h . By default, the pipe name MySQL is used. You can specify an alternative named pipe using the --socket option or as part of the URI type string. If a URI type string is used, the named pipe must be prepended with the characters \\.\ as well as being either encoded using percent encoding or surrounded with parentheses, as shown in the following examples: (\\.\named:pipe) \\.\named%3Apipe (Bug #27381738) * The dba.checkInstanceConfiguration() operation was not checking if the Performance Schema was enabled on the target instance. This could result in a situation where you could create a cluster but could not run several management operations on it, for example the Cluster.status() operation. Now, dba.checkInstanceConfiguration() checks that the Performance Schema is enabled on instances. (Bug #25867733) * When JSON format output was enabled for MySQL Shell, the properties of the Shell API Options class (shell.options) and AdminAPI Cluster class (dba.getCluster) were not printed, only the class name. (Bug #25027181) * When Cluster.checkInstanceState() was executed on an instance which was already a member of the current cluster, the output indicated that the instance was fully recoverable. This was misleading and was caused by a missing validation to ensure the instance does not belong to a cluster. (Bug #24942875) * The dba.checkInstanceConfiguration() operation did not recognize privileges when they were associated to a user through a role (available in MySQL server 8.0 and higher). In such a case, a missing privileges error was being incorrectly issued despite the user possessing all the required privileges. Now users with their privileges assigned by roles are recognized by AdminAPI operations correctly. (Bug #91394, Bug #28236922) On Behalf of Oracle/MySQL Release Engineering Team, Kent Boortz -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql
