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
memberId; and general statistics about the number of transactions checked, proposed, and rejected by members issue:
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:
In addition, in previous versions the URI-type string shown for
groupInformationSourceMemberin the output of
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
groupInformationSourceMemberalways shows the correct
report_host, value and
report_port, value of the instance which provided the group information. (Bug #28636963, Bug #26519466, Bug #27824265, Bug #28366027)
AdminAPI no longer relies on the mysqlprovision check command. This work has resulted in the following:
errorsfield 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.
dba.verbosevalue no longer influences the amount of debug information displayed for
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
expelTimeoutoption to the
dba.createCluster()operation, which configures the
group_replication_member_expel_timeoutvariable 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_timeoutvalue as configured on the seed instance.
You can now configure an InnoDB Cluster's mode while the cluster remains online. This enables you to configure the underlying Group Replication group to choose a specific instance as the new primary in single-primary mode, or to change between multi-primary and single-primary modes without taking the cluster offline. This uses the group coordinator and the UDFs added in WL#10378, see Configuring an Online Group. Use the following operations:
, which forces the election of
instanceas the new primary by overriding any election process.
, which switches the cluster to multi-primary mode. All instances become primaries.
, which switches the cluster to single-primary mode. If
instanceis specified, it becomes the primary and all the other instances become secondaries. If
instanceis not specified, the new primary is the instance with the highest member weight (and the lowest UUID in case of a tie on member weight).
You can now check and modify the settings in place for an InnoDB Cluster while the instances are online. To check the current settings of a cluster, use the following operation:
, which lists the cluster configuration options for its ReplicaSets and instances. A boolean option
allcan also be specified to include information about all Group Replication system variables in the output.
This work also enables you to configure the InnoDB Cluster options at a cluster level or instance level, while instances remain online. This avoids the need to remove, reconfigure and then again add the instance to change InnoDB Cluster options. Use the following operations:
to change the settings of all cluster instances globally
to change the settings of individual cluster instances
Cluster.setInstanceOption(instance, option, value)
The way which you use InnoDB Cluster options with the operations listed depends on whether the option can be changed to be the same on all instances or not. These options are changeable at both the cluster (all instances) and per instance level:
This option is changeable at the per instance level only:
These options are changeable at the cluster level only:
operation has been extended to enable you to detect changes to the cluster's topology, and modify the cluster metadata, for example to remove old instance data. Now you can:
updateTopologyModeoption 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
options added in WL#12052.
addInstancesoption to specify a list of new instances to add to the metadata, or the
removeInstancesoption to specify a list of obsolete instances to remove from the metadata. Pass the
autovalue 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 noninteractive mode, making it consistent with the other AdminAPI operations.
In addition, a new interactive option has been added to the
operation, to enable or disable interactive mode prompts specifically for the
References: See also: Bug #28997465, Bug #28529362, Bug #28889563, Bug #25675665, Bug #28542904.
In 8.0.14, Group Replication introduces the ability to specify the failover guarantees (eventual or “read your writes”) if a primary failover happens in single-primary mode (see WL#11123). Configure the failover guarantees of an InnoDB Cluster at creation by passing the new
failoverConsistencyoption to the
dba.createCluster()operation, which configures the
group_replication_consistencysystem variable on the seed instance. This option defines the behavior of a new fencing mechanism used when a new primary is elected in a single-primary group. The fencing restricts connections from writing and reading from the new primary until it has applied any pending backlog of changes that came from the old primary (sometimes referred to as “read your writes”). While the fencing mechanism is in place, applications effectively do not see time going backward for a short period of time while any backlog is applied. This ensures that applications do not read stale information from the newly elected primary.
failoverConsistencyoption is only supported if the target MySQL server version is 8.0.14 or later, and instances added to a cluster which has been configured with the
failoverConsistencyoption are automatically configured to have
group_replication_consistencythe same on all cluster members that have support for the option. The variable default value is controlled by Group Replication and is
EVENTUAL, change the
BEFORE_ON_PRIMARY_FAILOVERto enable the fencing mechanism. Alternatively use
failoverConsistencyoption on a multi-primary InnoDB Cluster has no effect but is allowed because the cluster can later be changed into single-primary mode with the
The default value for
ABORT_SERVER, but AdminAPI now overrides this and sets the default on instances to
READ_ONLY. This ensures that instances which leave the group unexpectedly continue running and can be rejoined to the cluster. (Bug #28701263)
When a cluster was created on a server that did not have the X Plugin enabled, a silent assumption was being made about the X Protocol port value. Now the value of an X Protocol port is only stored for instances on which X Plugin is enabled. (Bug #27677227)
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
dba.checkInstanceConfiguration()checks that the Performance Schema is enabled on instances. (Bug #25867733)
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)
dba.checkInstanceConfiguration()operation did not recognize privileges when they were associated to a user through a role (available in MySQL server 8.0 and higher). In such a case, a missing privileges error was being incorrectly issued despite the user possessing all the required privileges. Now users with their privileges assigned by roles are recognized by AdminAPI operations correctly. (Bug #91394, Bug #28236922)
X DevAPI: The
Collectionobjects now support the
.count()method, part of the X DevAPI.
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
defaultCompressto enable compression for every global session.
For MySQL Shell connections that use Unix socket files, the
--socketcommand line option can now be specified with no argument to connect using the default Unix socket file for the protocol. (Bug #28730149)
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
convertBsonTypesoption 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
showColumnTypeInfoand command line option
--column-type-infohave 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,
DBTypeis as returned by the protocol, and for X Protocol connections,
DBTypeis 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
utilglobal 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
syslogon 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
.frmfile 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.
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
resultFormatcan 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-formatcan be used at startup to specify the output format for a session. The existing command line options
--verticalare now aliases for the
--result-formatoption given with the corresponding value.
The existing command line option
--jsoncontrols JSON wrapping for all MySQL Shell output from a session. Specifying
--json=prettyturns on JSON wrapping and generates pretty-printed JSON. Specifying
--json=rawturns on JSON wrapping and generates raw JSON. With any of these options, the value of the
resultFormatMySQL Shell configuration option is ignored. Specifying
--json=offor not specifying the
--jsonoption turns off JSON wrapping, and result sets are output as normal in the format specified by the
outputFormatMySQL 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:
outputFormatactivates JSON wrapping with pretty or raw JSON respectively.
outputFormatturns off JSON wrapping and sets the
resultFormatMySQL 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.
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
PASSWORD, or other strings that you configure using the
--histignorecommand option or
shell.options["history.sql.ignorePattern"]. However, this previously meant that filtered-out statements were not available to be corrected immediately after entry, and had to be re-typed in case of any errors. MySQL Shell now always makes the last executed statement available to be recalled by pressing the Up arrow, regardless of the filters set in the history ignore list. If filtering applies to the last executed statement, it is removed from the history as soon as another statement is entered, or if you exit MySQL Shell immediately after executing the statement. (Bug #28749037)
The result printing logic in MySQL Shell has been refactored to use back-end rather than high-level result data, delivering performance improvements for all types of result data and more accurate representation for JSON data. (Bug #28710831)
A memory leak was fixed that occurred when the new MySQL Shell command-line syntax was used. (Bug #28705373)
The check for partitioned tables in shared tablespaces in the upgrade checker utility provided by MySQL Shell (the
util.checkForServerUpgrade()operation) did not return correct results for the 8.0.11 and 8.0.12 target versions. The check now uses alternative Information Schema tables that are populated with the required information in these versions. (Bug #28701423)
The MySQL Shell command
\optionignored 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.storeCredentialmethod, 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.storeCredentialmethod, 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
coutobject, 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
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:
\character appearing at the beginning of a statement is interpreted as the start of a multi-letter MySQL Shell command.
\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.
\character appearing after the end of a statement is interpreted as the start of a single-letter command.
(Bug #27959016, Bug #25689071)
The handling of Windows named pipe connections by MySQL Shell has been improved and systematized. Now, if you specify the host name as a period (.) on Windows, MySQL Shell connects using a named pipe.
If you are connecting using a URI type string, specify
If you are connecting using a data dictionary, specify
If you are connecting using individual parameters, specify
By default, the pipe name
MySQLis used. You can specify an alternative named pipe using the
--socketoption 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:
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)