Changes in MySQL 8.0.19 (2020-01-13)


     * Account Management Notes

     * Audit Log Notes

     * Compilation Notes

     * Configuration Notes

     * Deprecation and Removal Notes

     * Error Handling

     * Function and Operator Notes

     * INFORMATION_SCHEMA Notes

     * Keyring Notes

     * Logging Notes

     * Packaging Notes

     * SQL Syntax Notes

     * sys Schema Notes

     * Thread Pool Notes

     * X Plugin Notes

     * Functionality Added or Changed

     * Bugs Fixed

Account Management Notes


     * MySQL now enables administrators to configure user
       accounts such that too many consecutive login failures
       due to incorrect passwords cause temporary account
       locking. The required number of failures and the lock
       time are configurable per account, using the
       FAILED_LOGIN_ATTEMPTS and PASSWORD_LOCK_TIME options of
       the CREATE USER and ALTER USER statements. See Password
       Management
       (https://dev.mysql.com/doc/refman/8.0/en/password-management.html).
       (Bug #27733694, Bug #90169)

Audit Log Notes


     * ANALYZE TABLE statements now produce read audit events.
       (Bug #29625461)

     * Audit log connect events now include any connection
       attributes passed by the client. Connection attribute
       logging is supported for new-style XML log file format
       and JSON format, but not old-style XML format. See Audit
       Log File Formats
       (https://dev.mysql.com/doc/refman/8.0/en/audit-log-file-formats.html).

Compilation Notes


     * Microsoft Windows: On Windows, the minimum version of
       CMake for builds from the command line is now 3.15. (Bug
       #30332632, Bug #96954)

Configuration Notes


     * New FPROFILE_GENERATE and FPROFILE_USE CMake options are
       available for experimenting with profile guided
       optimization (PGO) with GCC. See the cmake/fprofile.cmake
       in a MySQL source distribution for information about
       using them. These options have been tested with GCC 8 and
       9, and with Clang.
       Enabling FPROFILE_USE also enables WITH_LTO (link time
       optimization). (Bug #30089834, Bug #96314, Bug #30133324,
       Bug #96410, Bug #30164113, Bug #96486)

     * Innodb_system_rows_read, Innodb_system_rows_inserted,
       Innodb_system_rows_deleted status variables were added
       for counting row operations on InnoDB tables that belong
       to system-created schemas. The new status variables are
       similar to the existing Innodb_rows_read,
       Innodb_rows_inserted, Innodb_rows_deleted status
       variables, which count operations on InnoDB tables that
       belong to both user-created and system-created schemas.
       The new status variables are useful in replication
       environments where relay_log_info_repository and
       master_info_repository variables are set to TABLE,
       resulting in higher row operation counts on slaves due to
       operations performed on the slave_master_info,
       slave_replay_log_info, and slave_worker_info tables,
       which belong to the system-created mysql schema. For a
       valid comparison of master and slave row operation
       counts, operations on tables in system-created schemas
       can now be excluded using the count data provided by the
       new status variables.
       Thanks to Facebook for the contribution. (Bug #27724674)

Deprecation and Removal Notes


     * Setting the hash_join optimizer switch (see
       optimizer_switch system variable) no longer has any
       effect. The same applies with respect to the HASH_JOIN
       and NO_HASH_JOIN optimizer hints. Both the optimizer
       switch and the optimizer hint are now deprecated, and
       subject to removal in a future release of MySQL. (Bug
       #30471809)

     * Support for the YEAR(2) data type was removed in MySQL
       5.7.5, leaving only YEAR and YEAR(4) as valid
       specifications for year-valued data. Because YEAR and
       YEAR(4) are semantically identical, specifying a display
       width is unnecessary, so YEAR(4) is now deprecated and
       support for it will be removed in a future MySQL version.
       Statements that include data type definitions in their
       output no longer show the display width for YEAR. This
       change applies to tables, views, and stored routines, and
       affects the output from SHOW CREATE and DESCRIBE
       statements, and from INFORMATION_SCHEMA tables.
       For DESCRIBE statements and INFORMATION_SCHEMA queries,
       output is unaffected for objects created in previous
       MySQL 8.0 versions because information already stored in
       the data dictionary remains unchanged. This exception
       does not apply for upgrades from MySQL 5.7 to 8.0, for
       which all data dictionary information is re-created such
       that data type definitions do not include display width.
       The (undocumented) UNSIGNED attribute for YEAR is also
       now deprecated and support for it will be removed in a
       future MySQL version.

Error Handling


     * Error messages regarding crash recovery for XA were
       revised to indicate XA context to distinguish them from
       non-XA crash recovery messages. (Bug #30578290, Bug
       #97743)

     * Previously, the server returned this error message for
       attempts to use LOAD DATA LOCAL with LOCAL capability
       disabled: The used command is not allowed with this MySQL
       version. This was misleading because the error condition
       is not related to the MySQL version. The server now
       returns an error code of ER_CLIENT_LOCAL_FILES_DISABLED
       and this message: Loading local data is disabled; this
       must be enabled on both the client and server side. (Bug
       #30375698, Bug #29377985, Bug #94396)

Function and Operator Notes


     * Previously, user-defined functions (UDFs) took no account
       of the character set or collation of string arguments or
       return values. In effect, string arguments and return
       values were treated as binary strings, with the
       implication that only string arguments containing
       single-byte characters could be handled reliably.
       UDF behavior is still the same by default, but the
       interface for writing UDFs has been extended to enable
       UDFs to determine the character set and collation of
       string arguments, and to return strings that have a
       particular character set and collation. These
       capabilities are optional for UDF writers, who may take
       advantage of them as desired. See User-Defined Function
       Character Set Handling
(https://dev.mysql.com/doc/refman/8.0/en/adding-udf.html#udf-charset-handling)
       Of the UDFs distributed with MySQL, those associated with
       the following features and extensions have been modified
       to take advantage of the new capabilities: MySQL
       Enterprise Audit, MySQL Enterprise Firewall, MySQL
       Enterprise Data Masking and De-Identification, MySQL
       Keyring (the general-purpose keyring UDFs only), and
       Group Replication. The modification applies only where it
       make sense. For example, a UDF that returns encrypted
       data is intended to return a binary string, not a
       character string.
       Character-set capabilities for UDFs are implemented using
       the mysql_udf_metadata server component service. For
       information about this service, see the MySQL Server
       Doxygen documentation, available at
       https://dev.mysql.com/doc/index-other.html (search for
       s_mysql_mysql_udf_metadata and udf_metadata_imp). Source
       code for the MySQL Keyring UDFs is available in Community
       source distributions and may be examined as examples for
       third-party UDF writers who wish to modify their own UDFs
       to be character set-aware.

INFORMATION_SCHEMA Notes


     * The INFORMATION_SCHEMA contains several new tables that
       expose role information:

          + ADMINISTRABLE_ROLE_AUTHORIZATIONS: Roles the current
            user can grant; see The INFORMATION_SCHEMA
            ADMINISTRABLE_ROLE_AUTHORIZATIONS Table
(https://dev.mysql.com/doc/refman/8.0/en/administrable-role-authorizations-table.html).

          + APPLICABLE_ROLES: Roles applicable for the current
            user; see The INFORMATION_SCHEMA APPLICABLE_ROLES
            Table
(https://dev.mysql.com/doc/refman/8.0/en/applicable-roles-table.html).

          + ENABLED_ROLES: Roles enabled within the current
            session; see The INFORMATION_SCHEMA ENABLED_ROLES
            Table
            (https://dev.mysql.com/doc/refman/8.0/en/enabled-roles-table.html).

          + ROLE_COLUMN_GRANTS: Column privileges for roles for
            the current user; see The INFORMATION_SCHEMA
            ROLE_COLUMN_GRANTS Table
(https://dev.mysql.com/doc/refman/8.0/en/role-column-grants-table.html).

          + ROLE_ROUTINE_GRANTS: Routine privileges for roles
            for the current user; see The INFORMATION_SCHEMA
            ROLE_ROUTINE_GRANTS Table
(https://dev.mysql.com/doc/refman/8.0/en/role-routine-grants-table.html).

          + ROLE_TABLE_GRANTS: Table privileges for roles for
            the current user; see The INFORMATION_SCHEMA
            ROLE_TABLE_GRANTS Table
(https://dev.mysql.com/doc/refman/8.0/en/role-table-grants-table.html).

Keyring Notes


     * A new SECRET key type is available that is intended for
       general-purpose storage of sensitive data using the MySQL
       keyring. The keyring encrypts and decrypts SECRET data as
       a byte stream upon storage and retrieval. The SECRET key
       type is supported by all keyring plugins. See Supported
       Keyring Key Types and Lengths
       (https://dev.mysql.com/doc/refman/8.0/en/keyring-key-types.html).

Logging Notes


     * The SIGUSR1 signal now causes the server to flush the
       error log, general query log, and slow query log. One use
       for SIGUSR1 is to implement log rotation without having
       to connect to the server (which to flush logs requires an
       account that has the RELOAD privilege). The server
       response to SIGUSR1 is a subset of the response to
       SIGHUP, enabling SIGUSR1 to be used as a more
       "lightweight" signal that flushes certain logs without
       the other SIGHUP effects such as flushing the thread and
       host caches and writing a status report to the error log.
       See Unix Signal Handling in MySQL
       (https://dev.mysql.com/doc/refman/8.0/en/unix-signal-response.html).

Packaging Notes


     * The zstd library bundled with MySQL has been upgraded
       from version 1.3.3 to 1.4.3. MySQL uses the zstd library
       to support connection compression. (Bug #30236685)

     * For package types for which OpenSSL shared libraries are
       included, they are now also included under lib/private if
       the package has private-to-MySQL libraries located there
       that need OpenSSL. (Bug #29966296)

SQL Syntax Notes


     * Important Change: MySQL now supports explicit table
       clauses and table value constructors according to the SQL
       standard. These have now been implemented, respectively,
       as the TABLE statement and the VALUES statement, each
       described in brief here:

          + TABLE table_name is equivalent to SELECT * FROM
            table_name, and can be used anywhere that the
            equivalent SELECT statement would be accepted; this
            includes joins, unions, INSERT ... SELECT
            statements, REPLACE statements, CREATE TABLE ...
            SELECT statements, and subqueries. TABLE also
            supports ORDER BY and LIMIT.

          + VALUES consists of the VALUES keyword followed by a
            series of row constructors (ROW()), separated by
            commas. It can be used to supply row values in an
            SQL-compliant fashion to an INSERT statement or
            REPLACE statement. For example, the following two
            statements are equivalent:
INSERT INTO t1 VALUES ROW(1,2,3), ROW(4,5,6), ROW(7,8,9);

INSERT INTO t1 VALUES (1,2,3), (4,5,6), (7,8,9);
            You can also select from a VALUES table value
            constructor just as you would a table, bearing in
            mind that you must supply a table alias when doing
            so. Using column aliases, you can also select
            individual columns, like this:
mysql> SELECT a,c FROM (VALUES ROW(1,2,3), ROW(4,5,6)) AS t(a,b,c);
+---+---+
| a | c |
+---+---+
| 1 | 3 |
| 4 | 6 |
+---+---+

            You can employ such SELECT statements in joins,
            unions, subqueries, and other constructs in which
            you normally expect to be able to use such
            statements.
       For more information and examples, see TABLE Statement
       (https://dev.mysql.com/doc/refman/8.0/en/table.html), and
       VALUES Statement
       (https://dev.mysql.com/doc/refman/8.0/en/values.html), as
       well as INSERT ... SELECT Statement
       (https://dev.mysql.com/doc/refman/8.0/en/insert-select.html),
       CREATE TABLE ... SELECT Statement
       (https://dev.mysql.com/doc/refman/8.0/en/create-table-select.html),
       JOIN Clause
       (https://dev.mysql.com/doc/refman/8.0/en/join.html),
       UNION Clause
       (https://dev.mysql.com/doc/refman/8.0/en/union.html), and
       Subqueries
       (https://dev.mysql.com/doc/refman/8.0/en/subqueries.html).
       (Bug #77639)

     * Previously, it was not possible to use LIMIT in the
       recursive SELECT
       (https://dev.mysql.com/doc/refman/8.0/en/select.html)
       part of a recursive common table expression (CTE). LIMIT
       is now supported in such cases, along with an optional
       OFFSET clause. An example of such a recursive CTE is
       shown here:
WITH RECURSIVE cte AS  (
  SELECT CAST("x" AS CHAR(100)) AS a FROM DUAL
  UNION ALL
  SELECT CONCAT("x",cte.a) FROM qn
    WHERE LENGTH(cte.a) < 10
    LIMIT 3 OFFSET 2;
)
SELECT * FROM cte;
       Specifying LIMIT in this fashion can make execution of
       the CTE more efficient than doing so in the outermost
       SELECT, since only the requested number of rows is
       generated.
       For more information, see Recursive Common Table
       Expressions
(https://dev.mysql.com/doc/refman/8.0/en/with.html#common-table-expressions-recursive).
       (Bug #92857, Bug #28816906)

     * When CHECK constraints were implemented in MySQL 8.0.16,
       ALTER TABLE supported DROP CHECK and ALTER CHECK syntax
       as MySQL extensions to standard SQL for modifying check
       constraints, but did not support the more general (and
       SQL standard) DROP CONSTRAINT and ALTER CONSTRAINT syntax
       for modifying existing constraints of any type. That
       syntax is now supported; the constraint type is
       determined from the constraint name.

     * MySQL now supports aliases in the VALUES and SET clauses
       of INSERT INTO ... ON DUPLICATE KEY UPDATE statement for
       the row to be inserted and its columns. Consider a
       statement such as this one:
INSERT INTO t
    VALUES (9,5), (7,7), (11,-1)
    ON DUPLICATE KEY UPDATE a = a + VALUES(a) - VALUES(b);
       Using the alias new for the inserted row, you can now
       rewrite the statement, referring back to the row alias in
       the ON DUPLICATE KEY UPDATE clause, like this:
INSERT INTO t
    VALUES (9,5), (7,7), (11,-1) AS new
    ON DUPLICATE KEY UPDATE a = a + new.a - new.b;
       Using the same row alias, and, additionally, the column
       aliases m and n for the columns of the inserted row, you
       can omit the row alias and use only the column aliases,
       as shown here:
INSERT INTO t
    VALUES (9,5), (7,7), (11,-1) AS new(m,n)
    ON DUPLICATE KEY UPDATE a = a + m - n;
       The row alias must be distinct from the table name;
       column aliases must be distinct from one another.
       See INSERT ... ON DUPLICATE KEY UPDATE Statement
       (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html),
       for more information and examples.

sys Schema Notes


     * sys schema objects have been reimplemented not to invoke
       the deprecated sys.format_bytes(), sys.format_time(), and
       sys.ps_thread_id() stored functions. Instead, they invoke
       the equivalent built-in SQL functions implemented in
       MySQL 8.0.16 that format or retrieve Performance Schema
       data (see Changes in MySQL 8.0.16 (2019-04-25, General
       Availability)).
       sys.format_bytes(), sys.format_time(), and
       sys.ps_thread_id() will be removed in a future MySQL
       version, so applications that use them should be adjusted
       to use the built-in functions instead, keeping in mind
       some minor differences between the sys functions and the
       built-in functions. See Performance Schema Functions
(https://dev.mysql.com/doc/refman/8.0/en/performance-schema-functions.html).

Thread Pool Notes


     * By default, the thread pool plugin tries to ensure a
       maximum of one thread executing in each group at any
       time. The default algorithm takes stalled threads into
       account and may temporarily permit more active threads.
       The plugin now implements a new
       thread_pool_max_active_query_threads system variable for
       controlling number of active threads per group. If
       thread_pool_max_active_query_threads is 0, the default
       algorithm applies. If
       thread_pool_max_active_query_threads is greater than 0,
       it places a limit on the number of active threads per
       group. See Thread Pool Operation
       (https://dev.mysql.com/doc/refman/8.0/en/thread-pool-operation.html).

X Plugin Notes


     * X Plugin could not be compiled on Debian with GCC 9. The
       --no-as-needed linker option was added to provide a
       workaround for the issue. (Bug #30445201)

     * Using X Protocol to query the Information Schema table
       TRIGGERS could result in errors being returned or some
       rows not being returned. (Bug #30318917)

     * In MySQL 5.7.14, the mysqlx namespace parameter was
       introduced for X Protocol's StmtExecute request,
       replacing the xplugin parameter, which was therefore
       deprecated. X Plugin continued to support the deprecated
       xplugin namespace for backward compatibility. In MySQL
       8.0.19, the xplugin namespace has now been removed. If
       the xplugin namespace is used from this release on, an
       error message is returned as for an unknown namespace. X
       Plugin's Mysqlx_stmt_execute_xplugin status variable,
       which counted the number of StmtExecute requests received
       for the xplugin namespace, is no longer used from MySQL
       8.0.19.

Functionality Added or Changed


     * Microsoft Windows: Previously, the system (\!) command
       for the mysql command-line client worked only for Unix
       systems. It now works on Windows as well. For example,
       system cls or \! cls may be used to clear the screen.
       (Bug #11765690, Bug #58680)

     * JSON: When using JSON_SCHEMA_VALID() to specify a CHECK
       constraint on a table containing one or more JSON columns
       and experiencing a validation failure, MySQL now provides
       detailed information about the reasons for such failures.
       A new error
       ER_JSON_SCHEMA_VALIDATION_ERROR_WITH_DETAILED_REPORT is
       implemented containing this information, which can be
       viewed in the mysql client by issuing SHOW WARNINGS when
       an INSERT statement is rejected by the server.
       For more information and examples, see
       JSON_SCHEMA_VALID() and CHECK constraints
(https://dev.mysql.com/doc/refman/8.0/en/json-validation-functions.html#json-validation-functions-constraints).
       For more general information, see also CHECK Constraints
(https://dev.mysql.com/doc/refman/8.0/en/create-table-check-constraints.html).

     * Display width specification for integer data types was
       deprecated in MySQL 8.0.17, and now statements that
       include data type definitions in their output no longer
       show the display width for integer types, with these
       exceptions:

          + The type is TINYINT(1). MySQL Connectors make the
            assumption that TINYINT(1) columns originated as
            BOOLEAN columns; this exception enables them to
            continue to make that assumption.

          + The type includes the ZEROFILL attribute.
       This change applies to tables, views, and stored
       routines, and affects the output from SHOW CREATE and
       DESCRIBE statements, and from INFORMATION_SCHEMA tables.
       For DESCRIBE statements and INFORMATION_SCHEMA queries,
       output is unaffected for objects created in previous
       MySQL 8.0 versions because information already stored in
       the data dictionary remains unchanged. This exception
       does not apply for upgrades from MySQL 5.7 to 8.0, for
       which all data dictionary information is re-created such
       that data type definitions do not include display width.
       (Bug #30556657, Bug #97680)

     * Replication connections to a replication slave, and Group
       Replication connections for distributed recovery, now
       have full client side configuration options for the
       TLSv1.3 protocol. In MySQL releases where TLSv1.3 support
       was available but these configuration options were not
       available, if TLSv1.3 was used for these connection
       types, the client in the connection (the replication
       slave or the Group Replication joining member that
       initiated distributed recovery) could not be configured.
       This meant that the server in the connection (the
       replication master or the Group Replication existing
       member that was the donor for distributed recovery) had
       to permit the use of at least one TLSv1.3 ciphersuite
       that is enabled by default. From MySQL 8.0.19, you can
       use the configuration options to specify any selection of
       ciphersuites for these connections, including only
       non-default ciphersuites if you want.
       The new configuration options are as follows:

          + Group Replication system variables
            group_replication_recovery_tls_version and
            group_replication_recovery_tls ciphersuites.
            group_replication_recovery_tls_version specifies a
            list of permitted TLS protocols for connection
            encryption for the client instance (the joining
            member) in the distributed recovery connection.
            group_replication_recovery_tls ciphersuites
            specifies a list of permitted ciphersuites when
            TLSv1.3 is used for that connection.

          + A MASTER_TLS_CIPHERSUITES option on the CHANGE
            MASTER TO command, to specify a list of TLSv1.3
            ciphersuites permitted by the replication slave for
            the connection to the replication master. (The
            CHANGE MASTER TO command already had a
            MASTER_TLS_VERSION option to specify the permitted
            TLS protocol versions for the connection.)
       (Bug #29960735)

     * Debian packages now contain more general systemd support
       that better supports manual mysqld execution. (Bug
       #29702050, Bug #95163)

     * The Group Replication plugin interacts with MySQL Server
       using internal sessions to perform SQL API operations.
       Previously, these sessions counted towards the client
       connections limit specified by the max_connections
(https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_connections)
       server system
       variable. If the server had reached this limit when Group
       Replication was started or attempted to perform an
       operation, the operation was unsuccessful and Group
       Replication or the server itself might stop. From MySQL
       8.0.19, Group Replication's interactions with MySQL
       Server use a new component service that handles the
       internal sessions separately, which means that they do
       not count towards the max_connections
(https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_connections)
       limit and are not refused if the server has reached this
       limit. (Bug #29635001)

     * Duplicate key error information was extended to include
       the table name of the key. Previously, duplicate key
       error information included only the key value and key
       name. Thanks to Facebook for the contribution. (Bug
       #28686224, Bug #925308)

     * When the mysql client operates in interactive mode, the
       --binary-as-hex option now is enabled by default. In
       addition, output from the status (or \s) command includes
       this line when the option is enabled implicitly or
       explicitly:
Binary data as: Hexadecimal
       To disable hexadecimal notation, use --skip-binary-as-hex
       (Bug #24432545)

     * MySQL now supports datetime literals with time zone
       offsets, such as '2019-12-11 10:40:30-05:00', '2003-04-14
       03:30:00+10:00', and '2020-01-01 15:35:45+05:30'; these
       offsets are respected but not stored when inserting such
       values into TIMESTAMP and DATETIME columns; that is,
       offsets are not displayed when retrieving the values.
       The supported range for a timezone offset is -14:00 to
       +14:00, inclusive. Time zone names such as 'CET' or
       'America/Argentina/Buenos_Aires', including the special
       value 'SYSTEM', are not supported in datetime literals.
       In addition, in this context, a leading zero is required
       for an hour value less than 10, and MySQL rejects the
       offset '-00:00' as invalid.
       Datetime literals with time zone offsets can also be used
       as parameter values in prepared statements.
       As part of this work, the allowed range of numeric values
       for the time_zone system variable has been changed, so
       that it is now also -14:00 to +14:00, inclusive.
       For additional information and examples, see The DATE,
       DATETIME, and TIMESTAMP Types
       (https://dev.mysql.com/doc/refman/8.0/en/datetime.html),
       and MySQL Server Time Zone Support
       (https://dev.mysql.com/doc/refman/8.0/en/time-zone-support.html).
       (Bug #83852, Bug #25108148)

     * From MySQL 8.0.19, compression is supported for messages
       sent over X Protocol connections. Connections can be
       compressed if the server and the client agree on a
       compression algorithm to use. By default, X Protocol
       announces support for the deflate, lz4, and zstd
       compression algorithms. You can disallow any of these
       algorithms by setting the new
       mysqlx_compression_algorithms system variable to include
       only the ones you permit. X Protocol always allows
       uncompressed connections if the client does not request
       compression during capability negotiation. Note that X
       Protocol's list of permitted compression algorithms
       operates independently of the list of compression
       algorithms announced by MySQL Server, and X Protocol does
       not fall back to using MySQL Server's compression
       settings. You can monitor the effects of message
       compression for X Protocol using new X Plugin status
       variables.

     * For multithreaded slaves (replication slaves on which
       slave_parallel_workers is set to a value greater than 0),
       setting slave_preserve_commit_order=1 ensures that
       transactions are executed and committed on the slave in
       the same order as they appear in the slave's relay log,
       preserving the same transaction history on the slave as
       on the master. Previously, this setting required binary
       logging and slave update logging to be enabled on the
       slave, with the associated execution costs and disk space
       requirements. Now, slave_preserve_commit_order=1 can be
       set on a slave with no binary log and no slave update
       logging. This enables you to preserve commit order on the
       slave, and avoid gaps in the sequence of transactions,
       without the overhead of binary logging.
       A limitation to preserving the commit order on the slave
       can occur if statement-based replication is in use, and
       both transactional and non-transactional storage engines
       participate in a non-XA transaction that is rolled back
       on the master. Normally, non-XA transactions that are
       rolled back on the master are not replicated to the
       slave, but in this particular situation, the transaction
       might be replicated to the slave. If this does happen, a
       multithreaded slave without binary logging does not
       handle the transaction rollback, so the commit order on
       the slave diverges from the relay log order of the
       transactions in that case.

     * The MySQL 8.0.18 release introduced the ability to
       specify a PRIVILEGE_CHECKS_USER account for a replication
       channel (using a CHANGE MASTER TO statement), against
       which MySQL makes privilege checks when replicated
       transactions are applied. The use of a
       PRIVILEGE_CHECKS_USER account helps secure a replication
       channel against the unauthorized or accidental use of
       privileged or unwanted operations. The use of row-based
       binary logging is strongly recommended when replication
       channels are secured with privilege checks.
       In MySQL 8.0.19, a new setting REQUIRE_ROW_FORMAT is
       added for replication channels, which makes the channel
       accept only row-based replication events. You can specify
       REQUIRE_ROW_FORMAT using a CHANGE MASTER TO statement to
       enforce row-based binary logging for a replication
       channel that is secured with privilege checks, or to
       increase the security of a channel that is not secured in
       this way. By allowing only row-based replication events,
       REQUIRE_ROW_FORMAT prevents the replication applier from
       taking actions such as creating temporary tables and
       executing LOAD DATA INFILE requests, which protects the
       replication channel against some known attack vectors.
       Row-based binary logging (binlog_format=ROW) must be used
       on the replication master when REQUIRE_ROW_FORMAT is set.
       Group Replication already requires row-based binary
       logging, so from MySQL 8.0.19, Group Replication's
       channels are automatically created with
       REQUIRE_ROW_FORMAT set, and you cannot change the option
       for those channels. The setting is also applied to all
       Group Replication channels on upgrade.
       mysqlbinlog has a new --require-row-format option, which
       enforces row-based replication events for mysqlbinlog's
       output. The stream of events produced with this option
       would be accepted by a replication channel that is
       secured using the REQUIRE_ROW_FORMAT option.

     * MySQL uses delimiter strings when constructing tablespace
       names and file names for table partitions. A "#p#"
       delimiter string precedes partition names, and an "#sp#"
       delimiter string precedes subpartition names, as shown:
schema_name.table_name#p#partition_name#sp#subpartition_name
table_name#p#partition_name#sp#subpartition_name.ibd

       Historically, delimiter strings have been uppercase (#P#
       and #SP#) on case-sensitive file systems such as Linux,
       and lowercase (#p# and #sp#) on case-insensitive file
       systems such as Windows. To avoid issues when migrating
       data directories between case-sensitive and
       case-insensitive file systems, delimiter strings are now
       lowercase on all file systems. Uppercase delimiter
       strings are no longer used.
       Additionally, partition tablespace names and file names
       generated based on user-specified partition or
       subpartition names, which can be specified in uppercase
       or lowercase, are now generated (and stored internally)
       in lowercase regardless of the lower_case_table_names
       setting to ensure case-insensitivity. For example, if a
       table partition is created with the name PART_1, the
       tablespace name and file name are generated in lowercase:
schema_name.table_name#p#part_1
table_name#p#part_1.ibd

       During upgrade, MySQL now checks and modifies if
       necessary:

          + Partition file names on disk and in the data
            dictionary to ensure lowercase delimiters and
            partition names.

          + Partition metadata in the data dictionary for
            related issues introduced by previous bug fixes.

          + InnoDB statistics data for related issues introduced
            by previous bug fixes.
       During tablespace import operations, partition tablespace
       file names on disk are checked and modified if necessary
       to ensure lowercase delimiters and partition names.
       References: See also: Bug #26925260, Bug #29823032, Bug
       #30012621, Bug #29426720, Bug #30024653.

     * Support was added for efficient sampling of InnoDB data
       for the purpose of generating histogram statistics. The
       default sampling implementation used by MySQL when
       storage engines do not provide their own requires a full
       table scan, which is costly for large tables. The InnoDB
       sampling implementation improves sampling performance by
       avoiding full table scans. The sampled_pages_read and
       sampled_pages_skipped INNODB_METRICS counters can be used
       to monitor sampling of InnoDB data pages. See Histogram
       Statistics Analysis
(https://dev.mysql.com/doc/refman/8.0/en/analyze-table.html#analyze-table-histogram-statistics-analysis).

Bugs Fixed


     * Important Change: Character set resolution has been
       changed for the following string functions:

          + REPLACE(str, from_str, to_str)

          + SUBSTRING_INDEX(str, delim, count)

          + TRIM([{BOTH | LEADING | TRAILING} [remstr] FROM]
            str)
       Previously, character set information for all arguments
       to these functions was aggregated, which could lead to
       results that were not well formed. This also caused
       issues with LPAD(), which assumes that both input and
       output are well formed. Now each of the three listed
       functions always uses the character set employed by str,
       and converts all other arguments to this character set at
       execution time; if any such conversion fails, the
       function returns an error. (Bug #30114420)
       References: This issue is a regression of: Bug #28197977.

     * Important Change: Subquery materialization no longer
       requires strict matching of inner and outer types.
       Different types can now be materialized when one of the
       following conditions is true:

          + The inner type is numeric (since there is always a
            way to cast the outer type to a number)

          + The inner type is temporal (since there is always a
            way to cast the outer type to a temporal)

          + Both types are strings
       (Bug #13960580)

     * NDB Cluster: Password masking was incomplete for some NDB
       logging options. (Bug #97335, Bug #30453137)

     * InnoDB: Initialization of certain internal data
       structures at startup depend on internal variables
       derived from the max_connections setting. InnoDB failed
       to resize the internal data structures when the
       max_connections setting was modified after startup using
       SET PERSIST. (Bug #30628872)

     * InnoDB: os_file_get_parent_dir warnings were encountered
       when compiling MySQL with GCC 9.2.0. (Bug #30499288, Bug
       #97466)

     * InnoDB: An attempt to access a large object (LOB) value
       using a null reference raised an assertion failure. To
       prevent this issue form occurring, a check was added to
       determine if LOB references are null before they are
       accessed. (Bug #30499064)

     * InnoDB: An assertion failure occurred after upgrading the
       data directory. Prepared XA transaction were still
       present, which prevented undo tablespaces from being
       upgraded. Undo tablespaces containing prepared
       transaction changes must remain active until all prepared
       XA transactions are committed or rolled back.
       Prepared XA transactions also prevented the completion of
       an explicit undo tablespace truncation operation after a
       restart. (Bug #30489497)

     * InnoDB: Attempting to upgrade a MySQL 5.7 instance on
       Linux with uppercase table names (partitioned or
       otherwise) to MySQL 8.0 on macOS raised an assertion
       failure. Partition file format changes in MySQL 8.0
       prevented migration of the data directory to a different
       platform, and the lower_case_table_names setting was
       changed at upgrade time, which can cause an upgrade
       failure. Instead of a failure occurring under these
       circumstances, an error is now reported. (Bug #30450968,
       Bug #30450979)

     * InnoDB: On macOS, a failure occurred when attempting to
       upgrade a MySQL 5.7 instance with uppercase table names
       to MySQL 8.0. Uppercase table names were not normalized
       to lowercase. The following errors were reported: Table
       is not found in InnoDB dictionary and Error in fixing SE
       data errors. (Bug #30450944)

     * InnoDB: On Windows, a failure occurred when attempting to
       upgrade a MySQL 5.7 instance with uppercase partitioned
       table names to MySQL 8.0. Opening the table returned a
       null pointer, which caused a segmentation fault when
       closing the table. (Bug #30450918)

     * InnoDB: On Windows, a mysqld exception was raised when
       attempting to upgrade a MySQL 5.7 instance with uppercase
       partitioned table names to MySQL 8.0. (Bug #30447790)

     * InnoDB: On Windows, a failure occurred when attempting to
       upgrade a MySQL 5.7 instance containing general
       tablespace defined with an uppercase name to MySQL 8.0.
       The following errors were reported: Error in fixing SE
       data and Failed to Populate DD. (Bug #30446798)

     * InnoDB: Introduction of local minitransactions (mtrs) in
       LOB-related code resulted in an assertion failure during
       recovery. (Bug #30417719)

     * InnoDB: A failure occurred when attempting to upgrade a
       MySQL 5.7 instance on Windows with uppercase partitioned
       table names to MySQL 8.0 on Linux. Partition file format
       changes in MySQL 8.0 prevented migration of the data
       directory to a different platform. Instead of a failure,
       an error is now reported. (Bug #30411118)

     * InnoDB: Updating the same compressed LOB data repeatedly
       caused the tablespace file to increase in size. (Bug
       #30353812)

     * InnoDB: When the temptable_max_ram limit was reached, the
       TempTable storage engine incorrectly reported an
       out-of-memory error instead of falling back to disk-based
       storage. (Bug #30314972, Bug #96893)

     * InnoDB: After importing an encrypted table and restarting
       the server, the following error was returned when
       attempting to access the table: ERROR 3185 (HY000): Can't
       find master key from keyring, please check in the server
       log if a keyring plugin is loaded and initialized
       successfully. The tablespace key was not written to disk
       after it was encrypted with the destination master key.
       (Bug #30313734)

     * InnoDB: The internal InnoDB
       dict_create_foreign_constraints() function that parsed
       SQL statements and performed foreign key related DDL
       checks was removed. The function became redundant with
       introduction of the data dictionary in MySQL 8.0 and the
       subsequent relocation of foreign key related DDL checks
       to the SQL layer.
       Removal of the dict_create_foreign_constraints() function
       also addressed the following foreign key issues:

          + Spaces around dots (".") in a fully qualified
            referenced table name were not permitted by the
            InnoDB parser.

          + Adding a foreign key and removing partitioning in
            the same ALTER TABLE statement was not permitted.
            The InnoDB parser did not detect that the new table
            version was no longer partitioned.

          + A foreign key constraint could not reference a table
            inside a schema named "AUX". The function that
            parsed referenced table names did not recognize that
            special names such as AUX are encoded.

          + Conditional comments in foreign key definitions were
            ignored.
       Additionally, a check was added to the SQL layer to
       detect attempts to create multiple foreign keys of the
       same name on a table at an early stage in the execution
       of an ALTER TABLE statement. (Bug #30287895, Bug
       #22364336, Bug #28486106, Bug #28703793, Bug #16904122,
       Bug #92567, Bug #11754659, Bug #46293)

     * InnoDB: A comparison function found two records to be
       equal when attempting to merge non-leaf pages of a
       spatial index. The function was unable to handle this
       unexpected condition, which resulted in a long semaphore
       wait and an eventual assertion failure. (Bug #30287668)

     * InnoDB: A locally acquired latch required for freeing a
       large object (LOB) page could have caused a deadlock if a
       subsequent caller attempted to acquire a latch for the
       same page before the page was freed. Similarly, a latch
       taken on a compressed or uncompressed LOB during a
       rollback related operation could have caused a deadlock
       due to a latching order issue. (Bug #30258536)
       References: This issue is a regression of: Bug #29846292.

     * InnoDB: A race condition between a purge thread that was
       purging a compressed LOB page and an update thread that
       is using a delete-marked record caused an assertion
       failure. (Bug #30197056)

     * InnoDB: Importing a tablespace from a location outside of
       the data directory raised an assertion failure. (Bug
       #30190227)

     * InnoDB: Importing a tablespace with a data directory
       definition that did not match the destination data
       directory returned an insufficiently descriptive schema
       mismatch error. (Bug #30190199)

     * InnoDB: A purge operation failed when attempting to purge
       a LOB value larger than the buffer pool. (Bug #30183982)

     * InnoDB: Update operations that moved externally stored
       LOB data to inline storage failed to mark the old LOB
       data as purgeable. (Bug #30178056, Bug #96466)

     * InnoDB: Index key part sort order information was not
       stored to the .cfg metadata file used by ALTER TABLE ...
       IMPORT TABLESPACE operations. The index key part sort
       order was therefore assumed to be ascending, which is the
       default. As a result, records could be sorted in an
       unintended order if one table involved in the import
       operation is defined with a DESC index key part sort
       order and the other table is not. To address this issue,
       the .cfg file format was updated to include index key
       part sort order information. (Bug #30128418)

     * InnoDB: Criteria used by the btr_cur_will_modify_tree()
       function, which detects whether a modifying record needs
       a modifying tree structure, was insufficient. (Bug
       #30113362)

     * InnoDB: Startup was slow on instances with a large number
       of tables due the tablespace file scan that occurs at
       startup to retrieve space IDs. A multithreaded scan was
       only initiated if the number of tablespace files exceed
       50,000, and three tablespace pages were read to retrieve
       a space ID. To improve startup times, additional threads
       are now allocated for the tablespace file scan, and only
       the first tablespace page is read to retrieve a space ID.
       If a space ID is not found on the first page of the
       tablespace, three pages are read to determine the space
       ID, as before. (Bug #30108154, Bug #96340)

     * InnoDB: Startup failed on a case insensitive file system
       with an error indicating that multiple files were found
       for the same tablespace ID. A file path comparison did
       not recognize that innodb_data_home_dir and datadir paths
       were the same due to the paths having different
       lettercases. (Bug #30040815)

     * InnoDB: A storage engine error occurred when accessing
       the mysql.innodb_index_stats and mysql.innodb_table_stats
       persistent optimizer statistics tables after upgrading a
       MySQL 8.0.13 instance on Linux with partitioned tables
       and a lower_case_table_name=1 setting to MySQL 8.0.14 or
       MySQL 8.0.15. The persistent optimizer statistics tables
       contained duplicate entries. (Bug #30012621)
       References: This issue is a regression of: Bug #26925260.

     * InnoDB: CREATE TABLESPACE failed with an error indicating
       that the tablespace already exists. The error was due to
       the failure of a preceding CREATE TABLESPACE operation
       where the DDL failed but related changes were not rolled
       back due to rollback being disabled prior to transaction
       commit. Rollback is now disabled after the transaction
       commits successfully. (Bug #29959193, Bug #95994)

     * InnoDB: Changed pages belonging to imported tablespaces
       were not being tracked. (Bug #29917343)

     * InnoDB: Renaming of full-text search auxiliary tables
       during upgrade failed due to a tablespace name conflict
       when upgrading from MySQL 5.7 to MySQL 8.0 on a
       case-insensitive file system. (Bug #29906115)

     * InnoDB: Rollback of an INSERT operation that inserted a
       LOB value larger than a buffer pool caused a deadlock.
       (Bug #29846292)

     * InnoDB: A code regression was addressed by prohibiting
       unnecessary implicit to explicit secondary index lock
       conversions for session temporary tables. (Bug #29718243)

     * InnoDB: A tablespace import operation raised an assertion
       when the cursor was positioned on a corrupted page while
       purging delete-marked records. Instead of asserting when
       encountering a corrupted page, the import operation is
       now terminated and an error is reported. (Bug #29454828,
       Bug #94541)

     * InnoDB: Delete marked rows were able to acquire an
       external read lock before a partial rollback was
       completed. The external read lock prevented conversion of
       an implicit lock to an explicit lock during the partial
       rollback, causing an assertion failure. (Bug #29195848)

     * InnoDB: Throughput stalled under a heavy workload with a
       small max_io_capacity setting, a single page cleaner
       thread, and multiple buffer pool instances. (Bug
       #29029294)

     * InnoDB: After a server exit that occurred while an undo
       tablespace truncation operation was in progress, warning
       messages were printed at startup stating that doublewrite
       pages could not be restored for undo tablespace pages.
       The warning messages are no longer printed for undo
       tablespaces that are being truncated. (Bug #28590016)

     * InnoDB: In read-only mode (innodb_read_only=ON), SHOW
       CREATE TABLE output did not include information about
       foreign key constraints. (Bug #21966795, Bug #78754)

     * Partitioning: When upgrading a database with a
       subpartitioned table from MySQL 8.0.16 or lower and then
       executing ALTER TABLE ADD COLUMN, an assertion or error
       would occur. (Bug #30360695, Bug #97054)

     * Partitioning: During upgrade of partitioned tables from
       MySQL 5.7 to 8.0, when a prefix key was used by the
       partitioning function, the prefix length was ignored, and
       the full column length was considered instead.
       Consequently, the table might incorrectly be rejected
       from being upgraded because its partition field length
       was found to be too large. (Bug #29941988, Bug #95921)

     * Partitioning: ALTER TABLE ... EXCHANGE PARTITION could
       cause indexes to become corrupted. This was due to the
       fact that the server assumed that the order in which an
       index is created in a partitioned table is the same as
       that of the table which is not partitioned. This led to
       the wrong index data being exchanged. (Bug #29706669)

     * Replication: When a member is joining or rejoining a
       replication group, if Group Replication detects an error
       in the distributed recovery process (during which the
       joining member receives state transfer from an existing
       online member), it automatically switches over to a new
       donor, and retries the state transfer. The number of
       times the joining member retries before giving up is set
       by the group_replication_recovery_retry_count system
       variable. The Performance Schema table
       replication_applier_status_by_worker displays the error
       that caused the last retry. Previously, this error was
       only shown if the group member was configured with
       parallel replication applier threads (as set by the
       slave_parallel_workers system variable). If the group
       member was configured with a single applier thread, the
       error was cleared after each retry by an internal RESET
       SLAVE operation, so it could not be viewed. This was also
       the case for the output of the SHOW SLAVE STATUS command
       whether there were single or multiple applier threads.
       The RESET SLAVE operation is now no longer carried out
       after retrying distributed recovery, so the error that
       caused the last retry can always be viewed. (Bug
       #30517160, Bug #30517172)

     * Replication: An assertion was raised when privilege
       checks were carried out for a replication channel if the
       slave had more columns in the relevant table than the
       master. The check now references the number of columns in
       the event, rather than in the table definition. (Bug
       #30343310)

     * Replication: When a replication group member leaves a
       group, either because STOP GROUP_REPLICATION was issued
       or due to an error, Group Replication now stops the
       binary log dump thread so that the former group member
       cannot send unwanted binary log data to the members that
       have remained in the group. (Bug #30315614)

     * Replication: Replication connection parameters that are
       held in the mysql.slave_relay_log_info table are now
       preserved in the event of a server crash or deliberate
       restart after issuing RESET SLAVE but before issuing
       START SLAVE. This action applies to the
       PRIVILEGE_CHECKS_USER account setting for replication
       privilege checks (introduced in MySQL 8.0.18) and the
       REQUIRE_ROW_FORMAT setting (introduced in MySQL 8.0.19).
       Note that if relay_log_info_repository=FILE is set on the
       server (which is not the default and is deprecated),
       replication connection parameters are not preserved in
       this situation. (Bug #30311908)

     * Replication: When a replication channel is secured by
       specifying a PRIVILEGE_CHECKS_USER account, which should
       not have ACL privileges, a GRANT statement that is
       replicated to the channel causes the replication applier
       to stop. In this situation, the behavior was correct but
       an assertion was being raised. The assertion has now been
       removed. (Bug #30273684)

     * Replication: When Group Replication was started following
       either provisioning with a cloning operation, execution
       of RESET MASTER, or removal of a partial transaction from
       the relay log, RESET SLAVE ALL was used internally to
       clear any unwanted state on the server. However, in MySQL
       8.0.18, this caused any PRIVILEGE_CHECKS_USER account
       that was specified for a Group Replication channel to be
       removed. RESET SLAVE is now used instead, which does not
       remove the account. (Bug #30262225)

     * Replication: For multithreaded replication slaves,
       setting slave_preserve_commit_order=1 now preserves the
       order of statements with an IF EXISTS clause when the
       object concerned does not exist. Previously, these
       updates might have committed before transactions that
       preceded them in the relay log, which might have resulted
       in gaps in the sequence of transactions that have been
       executed from the slave's relay log. (Bug #30262096)

     * Replication: When privilege checks were carried out for a
       replication channel, the permissions required for setting
       the session value of the sql_require_primary_key system
       variable were not being checked. The check is now carried
       out. (Bug #30254917)

     * Replication: A memory leak could occur when a failed
       replication group member tried to rejoin a minority group
       and was disallowed from doing so. (Bug #30162547, Bug
       #96471)

     * Replication: When a group member rejoins a replication
       group, it begins the distributed recovery process by
       checking the relay log for its group_replication_applier
       channel for any transactions that it already received
       from the group, and applying these. The joining member
       then initiates state transfer from an existing online
       member, which might begin with a remote cloning
       operation. Previously, the group_replication_applier
       channel was not explicitly stopped when a remote cloning
       operation was started, so it was possible that the
       applier might still be applying existing transactions at
       that time, which might lead to errors. The
       group_replication_applier channel is now stopped before a
       remote cloning operation is requested, and restarted when
       the distributed recovery process moves on to state
       transfer from a donor's binary log. (Bug #30152028)

     * Replication: If STOP GROUP_REPLICATION was issued while
       the member's XCom port was blocked, the XCom thread hung
       and the shutdown did not complete. XCom is now terminated
       in this situation. (Bug #30139794)

     * Replication: When Group Replication is running in
       single-primary mode, and a new primary server is elected,
       the messages logged at this time now provide the newly
       elected primary server's gtid_executed set, and the set
       of GTIDs retrieved by the replication applier. (Bug
       #30049310)

     * Replication: The slave status logs
       mysql.slave_relay_log_info (the relay log info log) and
       mysql.slave_worker_info (the slave worker log) are now
       copied from the donor to the recipient during a local or
       remote cloning operation. The slave status logs hold
       information that can be used to resume replication
       correctly after the cloning operation, including the
       relay log position from which to restart replication, the
       PRIVILEGE_CHECKS_USER account setting, and the new
       REQUIRE_ROW_FORMAT setting. Note that the relay logs
       themselves are not copied from the donor to the
       recipient, only the information about them that is held
       in these tables. Also note that if
       relay_log_info_repository=FILE is set on the server
       (which is not the default and is deprecated), the slave
       status logs are not cloned; they are only cloned if TABLE
       is set.
       Before this patch, the following replication-related
       behaviors occurred on a replication slave that had been
       provisioned by a cloning operation:

          + The default replication channel would fail to start
            if it was the only channel on the slave, because it
            was considered to be not initialized due to the
            missing relay log information.

          + Any PRIVILEGE_CHECKS_USER account setting that had
            been applied to replication channels on the donor
            was absent and had to be respecified.

          + Replication channels that used GTID auto-positioning
            (as specified by the MASTER_AUTO_POSITION option on
            the CHANGE MASTER TO statement) were able to resume
            replication automatically.

          + Replication channels that used binary log file
            position based replication (as specified by the
            MASTER_LOG_FILE and MASTER_LOG_POS options on the
            CHANGE MASTER TO statement) had to have the
            MASTER_LOG_FILE and MASTER_LOG_POS options reapplied
            manually before restarting replication in order to
            resume correctly. If the channels were configured to
            start replication automatically at server startup,
            without the options reapplied they would attempt to
            start replication from the beginning. They were
            therefore likely to attempt to replicate data that
            had already been copied to the slave by the cloning
            operation, causing replication to stop and possibly
            corrupting the data on the slave.
       With this patch, the following replication-related
       behaviors now occur on a replication slave that has been
       provisioned by a cloning operation:

          + The default replication channel can now always start
            after the cloning operation if it is configured to
            do so.

          + All channels now have the donor's
            PRIVILEGE_CHECKS_USER account setting and
            REQUIRE_ROW_FORMAT setting.

          + Replication channels that use GTID auto-positioning
            (as specified by the MASTER_AUTO_POSITION option on
            the CHANGE MASTER TO statement) are still able to
            resume replication automatically. For Group
            Replication channels, which use GTID
            auto-positioning, an internal equivalent of the
            RESET MASTER statement is now used to ensure that
            replication resumes optimally.

          + Replication channels that use binary log file
            position based replication now have the correct
            MASTER_LOG_FILE and MASTER_LOG_POS options in place
            after cloning. Because the relay logs themselves are
            not cloned, these channels now attempt to carry out
            the relay log recovery process, using the cloned
            relay log information, before restarting
            replication. For a single-threaded slave
            (slave_parallel_workers is set to 0), relay log
            recovery should succeed in the absence of any other
            issues, enabling the channel to resume replication
            correctly. For a multithreaded slave
            (slave_parallel_workers is greater than 0), relay
            log recovery is likely to fail because it cannot
            usually be completed automatically, but an
            informative error message is issued, and the data
            will not be corrupted.
       (Bug #29995256, Bug #30510766)

     * Replication: An internal deadlock could occur on a
       multi-threaded replication slave when the
       relay_log_space_limit system variable was set to limit
       the size of relay logs on the slave, and the coordinator
       thread acquired locks related to this limit and to the
       end position of the log. (Bug #29842426)

     * Replication: If a replication group member stops
       unexpectedly and is immediately restarted (for example,
       because it was started with mysqld_safe), it
       automatically attempts to rejoin the group if
       group_replication_start_on_boot=on is set. Previously, if
       the restart and rejoin attempt took place before the
       member's previous incarnation had been expelled from the
       group, the member could not rejoin. Now in this scenario,
       Group Replication automatically uses a Group
       Communication System (GCS) feature to retry the rejoin
       attempt for the member 10 times, with a 5-second interval
       between each retry. This should cover most cases and
       allow enough time for the previous incarnation to be
       expelled from the group, letting the member rejoin. Note
       that if the group_replication_member_expel_timeout system
       variable is set to specify a longer waiting period before
       the member is expelled, the automatic rejoin attempts
       might still not succeed. (Bug #29801773)

     * Replication: If a replication slave was set up using a
       CHANGE MASTER TO statement that did not specify the
       master log file name and master log position, then shut
       down before START SLAVE was issued, then restarted with
       the option --relay-log-recovery set, replication did not
       start. This happened because the receiver thread had not
       been started before relay log recovery was attempted, so
       no log rotation event was available in the relay log to
       provide the master log file name and master log position.
       In this situation, the slave now skips relay log recovery
       and logs a warning, then proceeds to start replication.
       (Bug #28996606, Bug #93397)

     * macOS: On macOS, configuring MySQL with -DWITH_SSL=system
       caused mysql_config output to incorrectly include
       internal CMake names for the static SSL libraries. (Bug
       #30541879, Bug #97632)

     * macOS: Builds on macOS with Ninja could fail with an
       error trying to create a symbolic link multiple times.
       (Bug #30368985)

     * Microsoft Windows; JSON: On Windows platforms, memory
       used for a multi-valued index was not released after the
       table containing it was dropped. (Bug #30227756)

     * Microsoft Windows: On Windows, -DWITH_SSL=system failed
       to find the installed OpenSSL headers if Strawberry Perl
       was installed. (Bug #30359287)

     * Microsoft Windows: On Windows, the -DWITH_SSL=system
       option did not work if the path name leading to the
       system OpenSSL libraries contained a space. This is now
       handled. Also, -DWITH_SSL=yes is treated like
       -DWITH_SSL=system, as on other platforms. (Bug #30261942,
       Bug #96739)

     * Microsoft Windows: MSVC 2019 produced garbled source file
       names for compilation errors. A workaround in the CMake
       configuration was implemented to correct for this. (Bug
       #30255096, Bug #96720)

     * JSON: Updating a value in a JSON column by replacing a
       character string element with a binary string containing
       the same byte sequence as the utf8mb4 representation of
       the character string had no effect.
       The root cause of this issue was a change in the behavior
       of comparisons between JSON strings and JSON opaque
       values introduced by the implementation of multi-valued
       indexes in MySQL 8.0.17, previous to which, JSON strings
       and JSON opaque values were never considered equal. After
       the change, they were considered equal if their binary
       data matched.
       An analysis of this change showed that it was not needed;
       in addition, the new behavior conflicted with the
       existing documentation for comparisons of JSON values.
       This issue is fixed by restoring the original behavior.
       (Bug #30348554)

     * JSON: A view that used JSON_TABLE() did not preserve the
       character set in which JSON path arguments were encoded.
       This meant that, if the view was evaluated with a
       different character set in effect from the one in which
       it was defined, it could produce wrong results. This is
       fixed by ensuring that JSON_TABLE() preserves the
       original character set in such cases. (Bug #30310265)

     * JSON: Adding a functional index on a JSON column changed
       the collation used for comparing strings, causing the
       result returned by the same query selecting the column to
       differ from that obtained without the index. (Bug
       #29723353)

     * JSON: If the first argument to JSON_TABLE() was const
       during the execution of a stored procedure, but not
       during preparation, it was not re-evaluated when a
       statement was subsequently executed again, causing an
       empty result to be returned each time following the first
       execution of the procedure. (Bug #97097, Bug #30382156)

     * JSON: In some cases, such as when a query uses FORCE
       INDEX, the cost of reading the table is DBL_MAX; this was
       rounded up to 2e308 when printed, which is too large for
       the JSON parser, so that it was not possible to extract
       parts of the optimizer trace using a query such as SELECT
       JSON_EXTRACT(trace, '$**.table_scan') FROM
       INFORMATION_SCHEMA.OPTIMIZER_TRACE. Now in such cases,
       values greater than 1.5e308 are rounded down and printed
       as 1e308 instead. (Bug #96751, Bug #30226767)

     * After upgrading from MySQL 5.7 to MySQL 8.0, a CLONE
       INSTANCE operation failed with the following error: ERROR
       3862 (HY000): Clone Donor Error: 1016 : Can't open file:
       './undo001'. The upgrade process left behind orphaned
       in-memory undo tablespaces.
       Thanks to Satya Bodapati for the contribution. (Bug
       #30602218, Bug #97784, Bug #30239255, Bug #96637)

     * The thread_pool plugin used display widths in definitions
       for integer columns of Performance Schema tables. This
       resulted in warnings written to the error log because
       integer column display widths are now deprecated. (Bug
       #30597673)

     * The MySQL optimizer's hash join algorithm uses the join
       buffer to store intermediate results. If this buffer
       overflows, the server uses a spill-to-disk algorithm,
       which writes one of the hash join operands to a temporary
       file, to handle this gracefully. If one of the operands
       was a table that was a member of a pushed join operation,
       this strategy conflicted with the pushed join requirement
       for all child result rows to use nested-loop reads
       whenever one of their pushed join ancestors was the
       current row in the join evaluation, which could in some
       cases result in incorrect query results being returned.
       (Bug #30573733)

     * Access to the INFORMATION_SCHEMA.VIEWS table was not
       properly restricted to the correct user. (Bug #30542333)

     * When creating hash values used for lookups during a hash
       join, the server did not respect the PAD SPACE attribute,
       meaning that 'foo' and 'foo ' did not match when using a
       PAD SPACE collation. This is fixed by padding all strings
       up to the same length as the longest possible string,
       where the longest possible string is deduced from the
       data type length specifier N in CHAR(N) or VARCHAR(N).
       (Bug #30535541)

     * When retrieving large result sets containing DECIMAL
       columns from a secondary engine, conversion of the column
       values to strings for transport over the text protocol
       acted as a bottleneck. The performance of the functions
       responsible for such conversions has been improved in
       some cases by as much as 50%, as reflected in internal
       testing. (Bug #30528427)

     * When the FORMAT_PICO_TIME() function was invoked to
       process several rows, once a NULL argument was found in a
       row, every result after that was set to NULL. (Bug
       #30525561)

     * When a Performance Schema event was timed, the event
       duration reported in events_xxx tables could be NULL
       instead of 0 for events where the timer start and end
       values are equal. (Bug #30525560)

     * Adding a LIMIT clause to a parenthesized query suppressed
       locking clauses within the parentheses. For example, this
       query would not lock the table:
(SELECT ... FOR UPDATE) LIMIT ...;
       Adding a LIMIT clause outside of a parenthesized query is
       intended to override a LIMIT clause within the
       parentheses. However, the outer LIMIT suppressed ORDER BY
       within the parentheses as well. For example, for this
       query, the ORDER BY was suppressed:
(SELECT ... ORDER BY ... LIMIT a) LIMIT b;
       Now inner locking and ORDER BY clauses are not suppressed
       by an outer LIMIT clause. (Bug #30521098, Bug #30521803)

     * When optimizer extracts conditions on constant tables for
       early evaluation, it does not include WHERE conditions
       that are expensive to evaluate, including conditions
       involving stored functions. When the extracted condition
       evaluated to true because it involved only const tables,
       the entire WHERE condition was incorrectly removed. Now
       in such cases, a check for expensive conditions is
       performed prior to any removal of the WHERE condition.
       (Bug #30520714)

     * When a lateral materialized derived table used DISTINCT,
       the derived table was not rematerialized for each outer
       row as expected. (Bug #30515233)

     * EXPLAIN ANALYZE did not work correctly with a common
       table expression using WITH RECURSIVE. (Bug #30509580)

     * The GNU gold loader could cause memory exhaustion on some
       platforms. Now it is used by default only on Intel 64-bit
       platforms. (Bug #30504760, Bug #96698)

     * Some Linux platforms experienced high overhead with
       EXPLAIN ANALYZE due to use of a system call by libstdc++
       instead of clock_gettime(). (Bug #30483025)

     * On Solaris 11.4, the LDAP authentication plugins could
       not be built. (Bug #30482553)

     * Queries that used the MEMBER OF() operator were not
       always handled correctly. (Bug #30477993)

     * Boost compilation failed under Visual Studio due to a
       Boost workaround for a VC++ 2013 bug that has since been
       fixed. The workaround is now patched for Boost
       compilation with MySQL. (Bug #30474056, Bug #97391)

     * When retrieving large result sets containing many
       integers from a secondary engine, conversion of the
       integers to strings for sending over the text protocol
       could act as a bottleneck. To avoid this problem, the
       performance of internal functions performing such
       conversions has been improved. (Bug #30472888)

     * Docker packages were missing the LDAP authentication
       plugins. (Bug #30465247)

     * Corrected a typo in a mysys/my_handler_errors.h error
       message. Thanks to Nikolai Kostrigin for the
       contribution. (Bug #30462329, Bug #97361)

     * A GTID table update while innodb_force_recovery was
       enabled caused a debug assertion failure. (Bug #30449531,
       Bug #97312)

     * MySQL failed to compile against Protobuf 3.10. (Bug
       #30428543, Bug #97246)

     * Buffered log lines during system startup could be lost.
       (Bug #30422941, Bug #97225)

     * If the mysql.user system table was renamed, the server
       could exit. (Bug #30418070)

     * Revoking a role specified with no host name could cause a
       server exit. (Bug #30416389)

     * When determining whether to pull out a semijoin table
       when other tables inside the semijoin depended on this
       table, only those semijoin tables which were base tables
       were considered; those in nested joins were ignored. (Bug
       #30406241)
       References: See also: Bug #12714094, Bug #11752543, Bug
       #43768.

     * The AppArmor profile on Ubuntu platforms was not able to
       read the OpenSSL configuration. (Bug #30375723)

     * Some Fedora 30 packages had missing obsoletes information
       that could cause problems upgrading an existing MySQL
       installation. (Bug #30348549, Bug #96969)

     * Altering only the default encryption in an ALTER SCHEMA
       statement caused the schema default character set and
       collation to be reset to the system defaults. (Bug
       #30344462, Bug #96994)

     * Columns declared with both AUTO_INCREMENT and DEFAULT
       value expressions (a nonpermitted combination) could
       raise an assertion or cause a server exit. (Bug
       #30331053)

     * SHOW GRANTS for an anonymous user could result in a
       server exit under some conditions. (Bug #30329114)

     * GREATEST() and LEAST() did not always handle time values
       correctly. (Bug #30326848)
       References: This issue is a regression of: Bug #25123839.

     * The list of subpartitions in partition objects was not
       serialized and therefore not included in serialized
       dictionary information (SDI). To address this issue,
       support was added for serialization and deserialization
       of subpartition dictionary information. The patch for
       this bug also includes minor SDI code refactoring and
       format changes. Due to the format changes, the SDI
       version number was incremented. (Bug #30326020, Bug
       #96943)

     * Following execution of ANALYZE TABLE, the optimizer trace
       for a given query differed when another query was
       executed previously to it, but also after the ANALYZE
       TABLE. (Bug #30321546)

     * innodb_buffer_pool_instances was not initialized
       correctly at server startup if it had been set using SET
       PERSIST or PERSIST_ONLY. (Bug #30318828)

     * A low max_allowed_packet value caused the following
       error: ERROR 1153 (08S01) at line 1: Got a packet bigger
       than 'max_allowed_packet' bytes. The error message was
       revised to indicate the minimum required
       max_allowed_packet value for cloning operations. (Bug
       #30315486, Bug #96891)

     * An assertion could be raised when server code tried to
       send to clients an error code intended to be written to
       the error log. These instances are fixed by sending a
       code intended to be sent to clients. (Bug #30312874)

     * CREATE VIEW did not always succeed when the body of the
       view definition contained a join and multiple subselects.
       (Bug #30309982)
       References: This issue is a regression of: Bug #25466100.

     * Dependency information for SLES 12 RPM packages was
       incorrect, causing MySQL installation failure. (Bug
       #30308305)

     * When restoring GEOMETRY data from hash join chunk files
       to a GEOMETRY column, the server did not copy the data to
       the column, but instead stored a pointer to the data,
       which resided in a temporary buffer, meaning that the
       GEOMETRY column pointed to random data as soon as this
       buffer was reused. Now, the server always copies the data
       from this buffer into the GEOMETRY column when executing
       a hash join. (Bug #30306279)

     * Some ALTER TABLE operations using the COPY algorithm did
       not handle columns with expression default values
       properly. (Bug #30302907, Bug #96864)

     * The CONV() function did not always handle returning the
       proper number of characters correctly. (Bug #30301543)

     * Parser recursion checks were insufficient to prevent
       stack overflow. (Bug #30299881)

     * The removal of a subquery because the condition in which
       it occurred was always false was expected to be performed
       during resolution, but when the subquery did not involve
       any tables, the server executed it while resolving it.
       This resulted in the failure of a subsequent check to
       confirm that the subquery was only being resolved and not
       yet optimized. Now in such cases, the server also checks
       to see whether the subquery was already executed. (Bug
       #30273827)

     * For debug builds, attempts to add to an empty temporary
       table a column with an expression default that was not
       valid raised an assertion. (Bug #30271792)

     * Construction of the iterator tree may yield a
       non-hierarchical structure; this can happen when, for
       example, b and c from a LEFT JOIN b LEFT JOIN c also make
       up the right side of a semijoin. The iterator executor
       solves this by adding a weedout on top of the entire
       query, which means that is is also necessary to iterators
       interacting with row IDs that they need to store and
       restore them. This was not done in all such cases,
       causing wrong results. Now the addition of a top-level
       weedout is always communicated to the iterators as soon
       as it is known that this is being done, before any
       affected iterators are constructed. (Bug #30267889)

     * Foreign key-handling code duplication between the SQL
       layer and the data dictionary was eliminated. A side
       effect is that some error messages now are more
       informative and clear. (Bug #30267236, Bug #96765)

     * During startup, the server could handle incorrect option
       values for persisted variables improperly, resulting in a
       server exit. (Bug #30263773)

     * In some queries involving materialized semijoins, when
       using the iterator executor, conditions were evaluated
       outside the materialization, causing inefficient query
       plans to be used and sometimes also producing wrong
       results. (Bug #30250091)

     * ALTER TABLE statements that renamed a column used in
       CHECK constraints could result in an incorrect error
       message. (Bug #30239721)

     * For SELECT statements, an INTO var_name clause prior to a
       locking clause is legal but the parser rejected it. (Bug
       #30237291, Bug #96677)

     * FLUSH TABLES WITH READ LOCK caused a deadlock when a LOCK
       INSTANCE FOR BACKUP statement was previously executed
       within the same session and there was a concurrent ALTER
       DATABASE statement running in another session against the
       same database specified (implicitly or explicitly) for
       the FLUSH TABLES WITH READ LOCK statement. (Bug
       #30226264)

     * Slow query logging could result in a server exit for
       connections that did not use the classic client/server
       protocol. (Bug #30221187)

     * A statement that added a foreign key without an explicit
       name failed when re-executed as a prepared statement or
       in a stored program with an unwarranted duplicate foreign
       key name error. (Bug #30214965, Bug #96611)
       References: This issue is a regression of: Bug #30171959.

     * With multiple sessions executing concurrent INSERT ... ON
       DUPLICATE KEY UPDATE statements into a table with an
       AUTO_INCREMENT column but not specifying the
       AUTO_INCREMENT value, inserts could fail with a unique
       index violation. (Bug #30194841, Bug #96578)

     * Client programs could load authentication plugins from
       outside the plugin library. (Bug #30191834)

     * When switching between table scans and index lookups,
       AlternativeIterator did not reset the handler, which
       could lead to assertion failures. (Bug #30191394)

     * Setting open_files_limit to a large value, or setting it
       when the operating system rlimit had a value that was
       large but not equal to RLIM_INF could cause the server to
       run out of memory. As part of this fix, the server now
       caps the effective open_files_limit value to the the
       maximum unsigned integer value. (Bug #30183865, Bug
       #96525)

     * References to fully qualified INFORMATION_SCHEMA tables
       could fail depending on the lettercase in which
       INFORMATION_SCHEMA was specified. (Bug #30158484)

     * Slow queries with an execution time greater than 35 days
       could cause corruption of the mysql.slow_log system table
       requiring a REPAIR TABLE operation. (Bug #30113119, Bug
       #96373)

     * MySQL did not support sending systemd notification
       messages to a socket specified using the NOTIFY_SOCKET
       environment variable, if the variable named an abstract
       namespace socket. (Bug #30102279)

     * Using SET PERSIST_ONLY to set a boolean system variable
       to a numeric value resulted in the server being unable to
       restart. (Bug #30094645, Bug #30298191, Bug #96848)

     * A fix for a previous issue combined two TABLE_LIST
       constructors in an unfortunate way. One of these created
       a TABLE_LIST object from a TABLE object representing a
       temporary table. Previously, the table name was made the
       same as the alias; this was changed to copying the name
       from the TABLE object. Due to the fact that, for a
       temporary table, the table name is a file path, it was
       possible to exceed the limit for MDL_key names, leading
       to a failed assertion. Fixed by reintroducing dedicated
       constructors which behave in the manner that they did
       prior to the fix. (Bug #30083125)
       References: This issue is a regression of: Bug #27482976.

     * For UNIX_TIMESTAMP() errors occurring within stored
       functions, the number of fractional seconds for
       subsequent function invocations could be incorrect. (Bug
       #30034972, Bug #96166)

     * When a common table expression contained a
       nondeterministic expression (such one that used RAND())
       and the common table expression was referenced more than
       once in the outer query, it was merged in some cases.
       This caused the common table expression to return a
       different result for each reference. Now in such cases,
       the common table expression is not merged, but rather is
       materialized instead. (Bug #30026353)

     * In debug build of MySQL started on Linux with a
       lower_case_table_names=1 setting, discarding a tablespace
       for a partitioned table after an in-place upgrade from
       MySQL 8.0.16 caused a serious error. The partition
       tablespace name stored in the data dictionary was
       invalid, and the metadata lock key prepared for the
       partition tablespace in MySQL 8.0.17 did not match the
       key stored in the mysql.tablespaces table. (Bug
       #30024653)

     * KILL QUERY could kill the statement subsequent to the one
       intended. (Bug #29969769)

     * With lower_case_table_names=2, SHOW TABLES could fail to
       display tables with uppercase names. (Bug #29957361)

     * The error message reported when attempting to upgrade
       tables with invalid expressions for generated columns did
       not provided sufficient information. The error message
       now includes the generated column name and the expression
       used to create the generated column. (Bug #29941887, Bug
       #95918)

     * Attempting to display an unresolvable view could result
       in a server exit rather than an error. (Bug #29939279)

     * Incorrect checking of temporal literals for CREATE TABLE
       statements could lead to a server exit. (Bug #29906966,
       Bug #95794)

     * Writing unexpected values to the mysql.global_grants
       system table could cause a server exit. (Bug #29873343)

     * The LAST_EXECUTED value in the INFORMATION_SCHEMA.EVENTS
       table was incorrectly reported in UTC, not in the event
       time zone. (Bug #29871530, Bug #95649)

     * With keyring_encrypted_file_password set on the command
       line at server startup, the password value could be
       visible to system utilities. (Bug #29848634)

     * Changing the lower_case_table_name setting when upgrading
       from MySQL 5.7 to MySQL 8.0 could cause a failure due to
       a schema or table name lettercase mismatch. If
       lower_case_table_names=1, table and schema names are now
       checked by the upgrade process to ensure that all
       characters are lowercase. If table or schema names are
       found to contain uppercase characters, the upgrade
       process fails with an error. For related information, see
       Preparing Your Installation for Upgrade
       (https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html).
       (Bug #29842749, Bug #95559)

     * Attempting to spawn a thread for a parallel read
       operation while system resources were temporary
       unavailable raised system error. (Bug #29842749, Bug
       #95559)

     * With a LOCK TABLES statement in effect, a metadata change
       for the locked table could cause Performance Schema or
       SHOW queries for session variables to hang in the
       opening_tables state. (Bug #29836204, Bug #92387)

     * A SELECT using a WHERE condition of the form A AND (B OR
       C [OR ...]) resulting in an impossible range led to an
       unplanned exit of the server. (Bug #29770705)

     * For JSON-format audit logging, the id field now may
       contain values larger than 65535. Previously, with
       heaving logging activity, more than 65536 queries per
       second could be executed, exceeding the 16 bits permitted
       for id values. (Bug #29661920)

     * An incomplete connection packet could cause clients not
       to properly initialize the authentication plugin name.
       (Bug #29630767)

     * Out-of-memory errors from the parser could be ignored,
       resulting in a server exit. (Bug #29614521)

     * On Linux, an assertion could be raised when the
       Performance Schema file instrumentation was disabled and
       re-enabled. (Bug #29607570)

     * For a column defined as a PRIMARY KEY in a CREATE TABLE
       statement, a default value given as an expression was
       ignored. (Bug #29596969, Bug #94668)

     * The TABLE_ENCRYPTION_ADMIN privilege, added in MySQL
       8.0.16, was incorrectly granted to the system-defined
       mysql.session user during upgrade. (Bug #29596053, Bug
       #94888)

     * For connections encrypted with OpenSSL, network I/O at
       the socket level was not reported by the Performance
       Schema. Also, network I/O performed while the server was
       in an IDLE state was not reported by the Performance
       Schema. (Bug #29205129, Bug #30535558, Bug #97600)

     * When a query used a subquery that was merged into the
       outer query block (due to a semijoin transformation or
       merge of a derived table), and the subquery itself
       contained a subquery with an aggregate function with an
       aggregation query block that differed from its base query
       block, the query could sometimes fail to return any rows
       unless executed a second time or preceded with FLUSH
       TABLES. This was because, when merging, the information
       regarded tables used and the aggregation information for
       the aggregate function was not updated properly. In the
       case which raised this bug report, this meant that the
       comparison operation containing a scalar subquery was
       regarded as const-for-execution and therefore the range
       optimizer attempted to evaluate it, and the scalar
       subquery contained a MIN() function referring to an outer
       reference which had not yet been read. Thus, when the
       aggregator object was populated, it was based on
       uninitialized data, leading to unpredictable results.
       (Bug #28941154)

     * Changing the mandatory_roles system variable could cause
       SHOW GRANTS in concurrent sessions to produce incorrect
       results. (Bug #28699403)

     * Failure of keyring_aws initialization caused failure of
       SSL socket initialization. (Bug #28591098)

     * Under certain conditions, enabling the read_only or
       super_read_only system variable did not block concurrent
       DDL statements executed by users without the SUPER
       privilege. (Bug #28438114, Bug #91852)

     * For slow query logging, the Slow_queries was not
       implemented unless the slow query log was enabled,
       contrary to the documentation. (Bug #28268680, Bug
       #91496)

     * The current GROUP BY plan is improved so that every gap
       attribute is allowed to have a disjunction of equality
       predicates. Predicates from different attributes must
       still be conjunctive to each other in order to take
       advantage of this enhancement.
       Our thanks to Facebook for this contribution. (Bug
       #28056998, Bug #15947433)

     * In some cases, BIGINT arguments to the FLOOR() and
       CEILING() functions were resolved as the wrong type. (Bug
       #27125612)

     * mysqlpump exits rather than dumping databases that
       contain an invalid view, by design, but it also failed if
       an invalid view existed but was not in any of the
       databases to be dumped. (Bug #27096081)

     * Foreign key information is now retrieved from the data
       dictionary, not from InnoDB. (Bug #25583288)

     * Foreign key definitions used in CREATE TABLE and ALTER
       TABLE statements for InnoDB tables were ignored if the
       statements were wrapped in conditional comments (such as
       /*!50101 ... */ or /*! ... */). (Bug #21919887, Bug
       #78631)

     * The --log-raw option is now available at runtime as the
       log_raw system variable. The system variable is set at
       startup to the option value, and may be set at runtime to
       change password masking behavior. (Bug #16636373, Bug
       #68936)

     * EXPLAIN ANALYZE did not execute subqueries in the SELECT
       list, and thus did not take them into account in its
       calculations of time or cost. (Bug #97296, Bug #30444266)

     * An inner scalar subquery containing an outer reference
       did not return the same result using a nested set of
       SELECT expressions on the right hand side as when using a
       single SELECT that was equivalent. (Bug #97063, Bug
       #30381092)

     * A materialized subquery could yield different results
       depending on whether it used an index. (Bug #96823, Bug
       #30289052)

     * When a query terminated due to exceeding the time
       specified using the MAX_EXECUTION_TIME hint, the error
       produced differed depending on the stage of the query. In
       particular, if the query terminated during a filesort,
       the error raised was ER_FILSORT_ABORT, even though in
       such cases the query should always exit with
       ER_QUERY_TIMEOUT. This made it unnecessarily difficult to
       trap such errors and to handle them correctly.
       This fix removes the error codes ER_FILSORT_ABORT and
       ER_FILESORT_TERMINATED. (Bug #96577, Bug #30186874)

     * If a stored procedure had a parameter named member or
       array, and it had been defined without quoting the
       parameter names, the database in which it was defined
       could not be upgraded to 8.0.17 or 8.0.18. (Bug #96288,
       Bug #30084237)
       References: See also: Bug #96350, Bug #30103640.

     * When a function such as COALESCE() or IFNULL() was passed
       a BIGINT column value, casting a negative return value
       from this function to UNSIGNED unexpectedly yielded zero.
       Our thanks to Oleksandr Peresypkin for this contribution.
       (Bug #95954, Bug #29952066)

     * EXPLAIN output showed Select tables optimized away for a
       query using MAX() on an indexed column, but if MAX() on
       the same column was called in a user function, it showed
       Using index instead. (Bug #94862, Bug #29596977)

Changes in MySQL Enterprise Backup 8.0.19 (2020-01-13)

     * Functionality Added or Changed

     * Bugs Fixed

Functionality Added or Changed


     * Important Change: For the backup-to-image, extract,
       list-image, and copy-back-and-apply-log commands, any
       relative path specified with --backup-image is now taken
       to be relative to the current directory in which the
       command is run. (Bug #29943103)

     * Important Change: The storage engine for the
       mysql.backup_progress table on a backed-up server has
       switched from CSV to InnoDB. Also, an auto-increment
       primary key id column plus a composite index on the
       table's backup_id and current_timestamp columns have been
       added. When working with a Group Replication setup,
       mysqlbackup now makes the backup_progress table available
       to all members of the server group by making sure that
       the table is updated on a primary node during each
       mysqlbackup operation.
       When MySQL Enterprise Backup 8.0.19 or later tries to
       perform its first full backup on a database, it
       automatically checks the format of the
       mysql.backup_progress table. If it detects that the table
       is in the old format (which means the server has been
       upgraded from 8.0.18 or earlier and has been backed up by
       MySQL Enterprise Backup before), it attempts to perform
       an update on the table automatically. Grant these
       privileges required for the table upgrade to the
       mysqlbackup user on the server:
GRANT ALTER ON mysql.backup_progress TO 'mysqlbackup'@'localhost';
GRANT CREATE, INSERT, DROP ON mysql.backup_progress_old TO 'mysqlbacku
p'@'localhost';
GRANT CREATE, INSERT, DROP, ALTER ON mysql.backup_progress_new TO 'mys
qlbackup'@'localhost';
       See Appendix E Backup Progress Table Update for details.
       (Bug #29882544, Bug #28695518)

     * Important Change: Due to the added protection for the
       backups against inconsistency caused by parallel DDL
       operations (see discussions on the new feature below),
       the user by which mysqlbackup connects to the MySQL
       server must now be granted the SELECT ON *.* privilege;
       see Grant MySQL Privileges to Backup Administrator
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/mysqlbackup.privileges.html).

     * The logging for backup restore has been improved: at the
       steps for setting the sizes of the log files, the names
       of the log files are now included. (Bug #30380310)

     * mysqlbackup now prints a stack trace after being
       terminated by a signal. (Bug #30042338)

     * When mysqlbackup fails to connect to a server, the
       warning returned by mysqlbackup now includes the hostname
       and port number for TCP connections, and the socket
       information for socket connections. This is particularly
       helpful for a Group Replication setup, for which
       mysqlbackup might attempt to connect to more than one
       host. (Bug #30040027)

     * If a binary log file could not be opened during a
       non-incremental backup, the backup would still be
       completed, but the backup_history table would indicate
       the backup had failed. With this fix, backups of all
       types fail if any relevant binary log files could not be
       opened, and a proper error is thrown. (Bug #29882381)

     * mysqlbackup now includes the configuration files auto.cnf
       and mysqld-auto.cnf from a server in its backup (except
       for a TTS backup). They are restored to the target
       server's data directory as backup-auto.cnf and
       backup-mysqld-auto.cnf respectively. To use those files
       to configure your restored server, rename them to their
       original names before starting the server. (Bug
       #27121423, Bug #30033486)

     * Master key rotation for binary log encryption
(https://dev.mysql.com/doc/refman/8.0/en/replication-binlog-encryption-key-rotation.html)
       on the server in between
       a full and an incremental backup, as well as between two
       incremental backups performed by mysqlbackup, is now
       supported. During an incremental backup, mysqlbackup now
       records encryption information for all the encrypted
       binary log files (including those already backed up in
       earlier full or incremental backups) unless the
       --skip-binlog option is used, in which case a warning is
       given that the older binary log files might become
       unrestorable.
       Also, the --skip-binlog option now makes binary log to be
       skipped not just for the current backup operation, but
       also for all subsequent incremental backups that are
       based on the current backup.

     * In the past, if DDL operations took place when a backup
       was in progress, the backup might become inconsistent. It
       is now safe to have DDL operations (CREATE TABLE
       (https://dev.mysql.com/doc/refman/8.0/en/create-table.html),
       RENAME TABLE
       (https://dev.mysql.com/doc/refman/8.0/en/rename-table.html),
       DROP TABLE
       (https://dev.mysql.com/doc/refman/8.0/en/drop-table.html),
       ALTER TABLE
       (https://dev.mysql.com/doc/refman/8.0/en/alter-table.html),
       and operations that map to ALTER TABLE
       (https://dev.mysql.com/doc/refman/8.0/en/alter-table.html)
       like CREATE INDEX
       (https://dev.mysql.com/doc/refman/8.0/en/create-index.html))
       happening on the server in parallel with a backup
       operation as long as:

          + The tables involved exist in their own tablespaces,
            instead of being in the system tablespace or some
            general tablespaces.

          + These server features have not been applied to the
            tables involved:
               o Data-at-rest encryption
(https://dev.mysql.com/doc/refman/8.0/en/innodb-data-encryption.html)
               o Page-level compression
(https://dev.mysql.com/doc/refman/8.0/en/innodb-page-compression.html)
               o Full-text indexing
(https://dev.mysql.com/doc/refman/8.0/en/innodb-fulltext-index.html)

          + The backup is not taken with the following
            mysqlbackup features:
               o Optimistic backup
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-backup-optimistic.html)
               o Transportable tablespace (TTS)
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/glossary.html#glos_transportable_tab
                 lespace)
               o Redo log archiving
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-redo-log-archiving.html)
               o Incremental backups with-redo-log-only
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/mysqlbackup.incremental.html#meb-creating-incremental-redo-log-only)
               o Incremental backup using page-tracking
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/mysqlbackup.incremental.html#mysqlbackup.page-tracking.incremental)

Bugs Fixed


     * mysqlbackup reported that an extract operation succeeded
       even if --src-entry specified a file that did not exist
       in the backup. This fix adds a validation for the
       --src-entry value and makes mysqlbackup throw an error if
       the validation fails. (Bug #30461566)

     * During an extract operation, the extracted file contents
       did not go into stdout as expected when --dst-entry=-,
       but into a file named "-" instead. (Bug #30451238)

     * Sometimes, after receiving a signal 6 due to some errors,
       mysqlbackup quit without printing any error messages.
       (Bug #30423128)

     * mysqlbackup sometimes hung during a backup when redo log
       archiving
(https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/meb-redo-log-archiving.html)
       had been enabled. It was
       due to the way mysqlbackup switched between reading the
       redo log files and the redo log archive, which has been
       corrected by this fix. (Bug #30387689)

     * At restart, a restored server someimtes gave the warning
       Doublewrite page ### for {space: ###, page_no:###} could
       not be restored. This happened because the doublewrite
       buffer, being restored from the backed up server,
       contained pages that were no longer relevant. With this
       fix, the doublewrite buffer in the backup was cleared
       during the backup process, so that it is no longer
       restored. (Bug #30286862)

     * When OpenSSL 1.1.1 was used for connecting mysqlbackup to
       the server and the --tls-version option was not
       specified, TLSv1.3 was used, but the output of
       mysqlbackup indicated it was using TLSv1.2. (Bug
       #30268505)

     * Backups for a server using the keyring_file
       (https://dev.mysql.com/doc/refman/8.0/en/keyring-file-plugin.html)
       or keyring_encrypted_file
(https://dev.mysql.com/doc/refman/8.0/en/keyring-encrypted-file-plugin.html)
       plugin failed with the error Opening
       of file master_keyring_kef failed if the keyring file was
       located in the server's data directory. This was because
       in that case, the plugin returned a path for the keyring
       file that was relative to the data directory, with which
       mysqlbackup could not locate the file. With this fix, the
       plugin returns a full path of the file to mysqlbackup.
       (Bug #30238406)

     * mysqlbackup quit unexpectedly when the validate command
       was issued without specifying any command options. With
       this fix, mysqlbackup quits gracefully in the situation
       by throwing a proper error. (Bug #30204114)

     * The default value of the --page-reread-time option was 0
       millisecond, instead of 100 milliseconds as documented in
       the manual. (Bug #30036877)

     * When a copy-back-and-apply-log operation was applied on a
       prepared backup, the warning Apply-log operation has
       already been done on that backup appeared twice in the
       output of mysqlbackup. (Bug #29941423)

     * A backup sometimes failed with mysqlbackup reporting that
       an undo log file looked corrupted when the system
       variable innodb_undo_log_encrypt had been set to ON on
       the server. It was because the encryption information had
       not yet propagated to the undo log file hearer when the
       file was copied. With this fix, in the situation,
       mysqlbackup waited until an undo log file's header is
       updated before copying it. (Bug #29545236)

     * When restoring an incremental backup, mysqlbackup deleted
       tables on the server that were not included in the
       incremental backup. (Bug #29399666)

     * A backup failed if the server has two external undo
       tablespaces on different file paths but with the same
       file name. This was because mysqlbackup copied all undo
       tablespaces into the same directory during a backup,
       causing a file name conflict. With this fix, when copying
       undo tablespaces, the pathname of a tablespace relative
       to innodb_undo_directory is preserved, so there will be
       no more file name clashes. (Bug #29340016)

     * A backup failed at the step when mysqlbackup applied the
       FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK
       statement on all non-InnoDB tables if any table names
       contained reserved words or special characters. It was
       because mysqlbackup did not enclose table names in
       backticks when issuing the statement, and this fix makes
       sure that is done. (Bug #19709505, Bug #74144)

Changes in MySQL Router 8.0.19 (2020-01-13)


     * Functionality Added or Changed

     * Bugs Fixed

Functionality Added or Changed


     * Router now utilizes metadata version 2.0 whereas all
       previous Router versions used metadata v1.0.1. Router is
       backwards compatible with metadata v1.0.1, except
       bootstrapping is not supported with v1.0.1. The Router
       bootstrapping error log was updated to reflect this
       requirement, in that MySQL Shell's dba.upgradeMetadata()
       exists to perform a metadata upgrade. (Bug #30381549)

     * Added MySQL InnoDB ReplicaSet Cluster support.
       Added a new cluster_type configuration option to the
       [metadata_cache] section. Accepted values are "ar" (Async
       ReplicaSet) or "gr" (Group Replication). Bootstrapping
       checks the target instance type and sets this value
       accordingly.

     * Added new --account and --account-create options to
       configure Router's bootstrap user.

     * Metadata version checking functionality was added.
       Versions checked include 0.0.0 (a metadata upgrade is in
       process), 1.x.x (old metadata version), and 2.x.x
       (current metadata version). The metadata version is saved
       to Router's new routers.version field.

Bugs Fixed


     * Fixed gcc 5.5 compilation warnings. (Bug #30505196, Bug
       #97475)

     * The Router's table was extended to include the username
       that accesses the metadata. (Bug #30435133)

     * Improved GCC 5.5.0 support as it does not support
       constexpr. (Bug #30406328)

     * An implicit move-assign generated an error when built
       with DevStudio 12.6; making it explicit eliminated the
       error. (Bug #30396902)

     * Fixed IPv6 metadata handling. (Bug #30354273)

     * Building Router with AddressSanitizer (ASan) now uses
       ASAN's crash handler on all systems, when before it would
       use a generic crash handler on POSIX systems. (Bug
       #30298740)

     * The HTTP REST API bind_address configuration option only
       accepted IPv4 addresses. (Bug #30287987)

     * The bootstrap process did not properly store the
       configured access ports. (Bug #29969566)

     * On shut down, Router now removes the pid-file it
       generated during start up. (Bug #29441087)

Dear MySQL users,

MySQL Connector/ODBC 8.0.19 is a new version in the MySQL Connector/ODBC
8.0 series, the ODBC driver for the MySQL Server.

The available downloads include both a Unicode driver and an ANSI driver
based on the same modern codebase. Please select the driver type you
need based on the type of your application - Unicode or ANSI.
Server-side prepared statements are enabled by default. It is suitable
for use with the latest MySQL server version 8.0.

This release of the MySQL ODBC driver is conforming to the ODBC 3.8
specification.  It contains implementations of key 3.8 features,
including self-identification as a ODBC 3.8 driver, streaming of out for
binary types only), and support of the SQL_ATTR_RESET_CONNECTION
connection attribute (for the Unicode driver only).

The release is now available in source and binary form for a number of
platforms from our download pages at

https://dev.mysql.com/downloads/connector/odbc/

For information on installing, please see the documentation at

https://dev.mysql.com/doc/connector-odbc/en/connector-odbc-installation.html

Enjoy and thanks for the support!

==============================================================================

Changes in MySQL Connector/ODBC 8.0.19 (2020-01-13, General Availability)


     * Functionality Added or Changed

     * Bugs Fixed

Functionality Added or Changed


     * Added DNS SRV support.
       To automatically resolve any SRV record available in a
       target DNS server or service discovery endpoint, specify
       ENABLE_DNS_SRV=1 in the DSN; the host is passed for SRV
       lookup without a port and with a full lookup name. For
       example: DRIVER={MySQL ODBC 8.0
Driver};SERVER=_mysql._tcp.foo.abc.com;ENABLE_DNS_SRV=1;U
       SER=user;PWD=passwd;

     * Confirmed support for compiling with VS2019, and for
       supporting the Visual C++ 2019 redistributable.

     * When creating a new connection using the classic MySQL
       protocol, multiple hosts can be tried until a successful
       connection is established. A list of hosts can be given
       in a connection string, along with passing MULTI_HOST=1
       to to enable this functionality. The connection string
       looks similar to
SERVER=address1[:port1],address2[:port2]....;MULTI_HOST=1
       ;.
       Other notes: the default port is used if port is not
       specified, the connector randomly picks hosts, and if a
       host fails then a new host is chosen. An error is
       returned if SERVER contains multiple hosts when
       MULTI_HOST is not enabled.

Bugs Fixed


     * With prepared SELECT statements the fixed-length numeric
       types such as INT were set to 0 instead of their stored
       value. (Bug #30428851, Bug #97191)

     * Connector/ODBC failed to compile when dynamically linking
       to the MySQL client library
       (MYSQLCLIENT_STATIC_LINKING=0); due to a mismatch between
       an internal copy of the library headers and the version
       of code implementing the library internals. (Bug
       #30292290, Bug #96835)

     * Improved handling for stored procedures and the INOUT
       parameter.
       For example, if a stored procedure had one or more
       parameters then an incomplete result set could be
       returned. (Bug #29467224, Bug #94623)

On Behalf of Oracle/MySQL Engineering Team
Prashant Tekriwal

Dear MySQL users,

MySQL Connector/Python 8.0.19 is the latest GA release version of the
MySQL Connector Python 8.0 series. The X DevAPI enables application
developers to write code that combines the strengths of the relational
and document models using a modern, NoSQL-like syntax that does not
assume previous experience writing traditional SQL.

To learn more about how to write applications using the X DevAPI, see

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

For more information about how the X DevAPI is implemented in MySQL
Connector/Python, and its usage, see

http://dev.mysql.com/doc/dev/connector-python

Please note that the X DevAPI requires at least MySQL Server version 8.0
or higher with the X Plugin enabled. For general documentation about how
to get started using MySQL as a document store, see

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

To download MySQL Connector/Python 8.0.19, see the "General Availability
(GA) Releases" tab at

http://dev.mysql.com/downloads/connector/python/

Enjoy!

==============================================================================

Changes in MySQL Connector/Python 8.0.19 (2020-01-13, General Availability)


     * Functionality Added or Changed

     * Bugs Fixed

Functionality Added or Changed


     * Added DNS SRV support.
       To automatically resolve any SRV record available in a
       target DNS server or service discovery endpoint, use the
       mysqlx+srv scheme+extension in a X DevAPI connection
       string, or mysqlx+srv for the classic protocol, or by
       enabling the dns-srv=True (or dns_srv=True) connection
       option when using keyword arguments or dictionaries.

     * Added two new connection options that evaluate during the
       TLS handshake to restrict the negotiated TLS protocols
       and ciphers; along with those configured on the server
       that can further restrict the final choices. The new
       options are tls-versions to define the allowed TLS
       protocol versions, and tls-ciphersuites for the allowed
       cipher suitess. These definitions are comma-separated,
       and accepted by the getSession() and getClient() methods.
       tls-versions: accepts one or more of the following:
       TLSv1, TLSv1.1, TLSv1.2, and TLSv1.3. Other values
       generate an error. Example usage:
mysqlx://myserver/db?tls-versions=[TLSv1.2,TLSv1.3]
       tls-ciphersuites: accepts IANA cipher suite names, as
       listed on IANA's TLS Cipher Suites
(https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4)
       page. Unsupported or
       unknown values are ignored. Example usage:
mysqlx://myserver/db?tls-ciphersuites=[TLS_DHE_PSK_WITH_A
       ES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256]

     * The internal X Protocol namespace changed from xplugin to
       mysqlx.
       MySQL Server removed xplugin namespace support in
       v8.0.19; for Connector/Python this means:

          + Connector/Python v8.0.19 and higher cannot connect
            to MySQL Server 8.0.18 and lower using the X DevAPI
            Protocol.

          + Connector/Python v8.0.18 and lower cannot connect to
            MySQL Server 8.0.19 and higher using the X DevAPI
            Protocol.

Bugs Fixed


     * Fixed the reserved SSL authentication filed; it changed
       from 23 to 22. Thanks to Qianqian Bu for the patch. (Bug
       #30270760, Bug #96770)
       References: This issue is a regression of: Bug #29855733.

     * Fixed LOAD DATA INFILE LOCAL handling; the file handle
       was not closed. Thanks to Micah Gale for the patch. (Bug
       #29417117, Bug #94496)


On Behalf of Oracle/MySQL Engineering Team
Prashant Tekriwal

Dear MySQL users,

MySQL Connector/J 8.0.19 is the latest General Availability release of
the MySQL Connector/J 8.0 series.  It is suitable for use with MySQL
Server versions 8.0, 5.7, and 5.6.  It supports the Java Database
Connectivity (JDBC) 4.2 API, and implements the X DevAPI.

This release includes the following new features and changes, also
described in more detail on

https://dev.mysql.com/doc/relnotes/connector-j/8.0/en/news-8-0-19.html

As always, we recommend that you check the "CHANGES" file in the
download archive to be aware of changes in behavior that might affect
your application.

To download MySQL Connector/J 8.0.19 GA, see the "General Availability
(GA) Releases" tab at http://dev.mysql.com/downloads/connector/j/

Enjoy!

Changes in MySQL Connector/J 8.0.19 (2020-01-13, General Availability)

Functionality Added or Changed


     * Connector/J now supports the use of DNS SRV records for
       connections.  Here is a brief summary for Connector/J's support
       for DNS SRV records:

          + These new schemas in the connection URLs enable DNS
            SRV support:
               o jdbc:mysql+srv: For ordinary and basic failover
                 JDBC connections that make use of DNS SRV
                 records.
               o jdbc:mysql+srv:loadbalance: For load-balancing
                 JDBC connections that make use of DNS SRV
                 records.
               o jdbc:mysql+srv:replication: For replication
                 JDBC connections that make use of DNS SRV
                 records.
               o mysqlx+srv: For X DevAPI connections that make
                 use of DNS SRV records.

          + Besides using the new schemas in the connection
            URLs, DNS SRV record support can also be enabled or
            disabled using the two new connection properties,
            dnsSrv and xdevapi.dns-srv, for JDBC and X DevAPI
            connections respectively.
       See Support for DNS SRV Records
(https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-dns-srv.html)
       in the Connector/J 8.0 Developer Guide
(https://dev.mysql.com/doc/connector-j/8.0/en/) for
       details.

     * X DevAPI: The server failover support for connections
       using X DevAPI has been enhanced with the following features:

          + When the priority property is NOT set for each host
            in the connection URL, failover connections are
            attempted on the hosts in a random order, until a
            connection is successfully established (Connector/J
            used to attempt connections to the hosts in the
            sequence they appear in the connection URL).

          + Once all hosts have been tried and no connections
            can be made, Connector/J throws a
            com.mysql.cj.exceptions.CJCommunicationsException
            and returns the message Unable to connect to any of
            the target hosts.

          + When using connection pooling, Connector/J keeps
            track of any host it failed to connect to and, for a
            short waiting period after the failure, avoids
            connecting to it during the creation or retrieval of
            a Session. However, if all other hosts have already
            been tried, those excluded hosts will be retried
            without waiting. Once all hosts have been tried and
            no connections can be established, Connector/J
            throws a
            com.mysql.cj.exceptions.CJCommunicationsException
            and returns the message Unable to connect to any of
            the target hosts.

     * X DevAPI: The allowed TLS versions and cipher suites for
       X DevAPI connections can now be restricted by two new
       connection properties:

          + xdevapi.tls-versions restricts the allowable TLS
            protocol versions to be used for X DevAPI
            connections.

          + xdevapi.tls-ciphersuites restricts the allowable
            cipher suites to be used for X DevAPI connections.
       See the descriptions for them in Configuration Properties
(https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-configuration-properties.html)
       and also Connecting Securely Using SSL
(https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-using-ssl.html)
       for details.

     * MySQL Server 8.0.17 deprecated the display width for the
       TINYINT, SMALLINT, MEDIUMINT, INT, and BIGINT data types when the
       ZEROFILL modifier is not used, and MySQL Server 8.0.19 has
       removed the display width for those data types from results of
       SHOW CREATE TABLE, SHOW CREATE FUNCTION, and queries on
       INFORMATION_SCHEMA.COLUMNS, INFORMATION_SCHEMA.ROUTINES, and
       INFORMATION_SCHEMA.PARAMETERS (except for the display width for
       signed TINYINT(1)). This patch adjusts Connector/J to those
       recent changes of MySQL Server and, as a result,
       DatabaseMetaData, ParameterMetaData, and ResultSetMetaData now
       report identical results for all the above-mentioned integer
       types and also for the FLOAT and DOUBLE data types.
       (Bug #30477722)

     * The cipher suites usable by Connector/J are now
       pre-restricted by a properties file that can be found at
       src/main/resources/com/mysql/cj/TlsSettings.properties inside the
       src folder on the source tree or in the platform-independent
       distribution archive (in .tar.gz or .zip format) for Connector/J.
       See Connecting Securely Using SSL
(https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-using-ssl.html)
       for details.

     * The allowable versions of TLS protocol used for
       connecting to the server, when no restrictions have been set
       using the connection properties enabledTLSProtocols, have been
       changed to:

          + TLSv1, TLSv1.1, TLSv1.2, and TLSv1.3 for MySQL
            Community Servers 8.0, 5.7.28 and later, and 5.6.46
            and later, and for all commercial versions of MySQL
            Servers.

          + TLSv1 and TLSv1.1 for all other versions of MySQL
            Servers.

Bugs Fixed


     * The RPM package for Connection/J provided by the MySQL
       Yum repository did not have its epoch set; as a result, the
       package could not be installed on an Enterprise Linux or Fedora
       system even if the MySQL Yum repository has been enabled, because
       the Connector/J package in the native repository had the epoch
       set to 1. This fix sets the epoch also to 1 for the RPM package
       provided by the MySQL Yum repository, in order to prevent the
       installation problem. (Bug #30566384, Bug #97700)

     * For some prepared statements, calling getMetaData() on
       them resulted in an Incorrect DATE error, even when no DATE
       values were involved. This was due to some recent changes on the
       MySQL 8.0 Server, to which this patch adjusts Connector/J. (Bug
       #30151808, Bug #96442) References: See also: Bug #29025656,
       Bug #28940878.

     * When retrieving TIME values using
       ResultSet.getTimestamp(), the fractional seconds are truncated
       when useCursorFetch=true. This patch corrects the problem by
       fixing the TIME value decoding in the MysqlBinaryValueDecoder. It
       also corrects some inconsistencies in formatting the fractional
       seconds when returning the TIME values as strings.
       (Bug #30119545, Bug #96383)

     * Streaming of multiple result sets failed with an error.
       It was due to an error in switching the streamer source from one
       result set to another, and this fix corrects the issue.
       (Bug #29999318, Bug #96059)

Enjoy and thanks for the support!

On behalf of the MySQL Release Team,
Nawaz Nazeer Ahamed

Dear MySQL users,

MySQL Connector/Node.js is a new Node.js driver for use with the X
DevAPI. This release, v8.0.19, is a maintenance release of the
MySQL Connector/Node.js 8.0 series.

The X DevAPI enables application developers to write code that combines
the strengths of the relational and document models using a modern,
NoSQL-like syntax that does not assume previous experience writing
traditional SQL.

MySQL Connector/Node.js can be downloaded through npm (see
  https://www.npmjs.com/package/@mysql/xdevapi for details) or from
  https://dev.mysql.com/downloads/connector/nodejs/.

To learn more about how to write applications using the X DevAPI, see
  http://dev.mysql.com/doc/x-devapi-userguide/en/.
For more information about how the X DevAPI is implemented in MySQL
Connector/Node.js, and its usage, see
  http://dev.mysql.com/doc/dev/connector-nodejs/.

Please note that the X DevAPI requires at least MySQL Server version
8.0 or higher with the X Plugin enabled. For general documentation
about how to get started using MySQL as a document store, see
  http://dev.mysql.com/doc/refman/8.0/en/document-store.html.

Changes in MySQL Connector/Node.js 8.0.19 (2020-01-13, General Availability)

Functionality Added or Changed

     * Added DNS SRV support.
       Using the mysqlx+srv scheme+extension in a connection
       string (or enabling the resolveSrv option in a connection
       configuration object) allows to automatically resolve any
       SRV record available in a target DNS server or service
       discovery endpoint.

Bugs Fixed

     * Improved the CRUD API error messages. (Bug #30423556)

     * The getAffectedItemsCount() method did not function on
       result sets in v8.0.18. (Bug #30401962)

     * The Collection.existsInDatabase() method did not
       function. (Bug #30401432)

On Behalf of MySQL/ORACLE RE Team
Gipson Pulla

Dear MySQL users,

MySQL Server 5.6.47, a new version of the popular Open Source
Database Management System, has been released. MySQL 5.6.47 is
recommended for use on production systems.

For an overview of what's new in MySQL 5.6, please see

  http://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html

     Starting with 5.6.11, Microsoft Windows packages for MySQL 5.6
     are available both as a "full" installer and as a "web" installer.
     The full installer is significantly larger and comes bundled with
     the latest software releases available. This bundle makes it easy
     to download and configure a full server and development suite.

     The web installer doesn't come bundled with any actual products
     and instead relies on download-on-demand to fetch only the
     products you choose to install. This makes the initial download
     much smaller but increases install time as the individual products
     will need to be downloaded.

For information on installing MySQL 5.6.47 on new servers or upgrading
to MySQL 5.6.47 from previous MySQL releases, please see

  http://dev.mysql.com/doc/refman/5.6/en/installing.html

MySQL Server 5.6.47, is available in source and binary form for a number of
platforms from our download pages at

  http://dev.mysql.com/downloads

We welcome and appreciate your feedback, bug reports, bug fixes,
patches, etc:

  http://bugs.mysql.com/report.php

The following link lists the changes in the MySQL 5.6 since
the release of MySQL 5.6.46. It may also be viewed
online at

  http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-47.html

Enjoy!

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

Bugs Fixed


     * Replication: When GTIDs are enabled on a replication
       master and slave, and the slave connects to the master
       with the MASTER_AUTO_POSITION=1 option set, the master
       must send the slave all the transactions that the slave
       has not already received, committed, or both. If any of
       the transactions that should be sent by the master have
       been already purged from the master's binary log, the
       master sends the error
       ER_MASTER_HAS_PURGED_REQUIRED_GTIDS (1789) to the slave,
       and replication does not start.
       The message provided for the error
       ER_MASTER_HAS_PURGED_REQUIRED_GTIDS has been changed to
       provide advice on the correct action in this situation,
       which is for the slave to replicate the missing
       transactions from another source, or for the slave to be
       replaced by a new slave created from a more recent
       backup. The message advises that the master's binary log
       expiration period can be revised to avoid the situation
       in future. In addition, the master now identifies the
       GTIDs of the purged transactions and supplies them in its
       error log in the warning message ER_FOUND_MISSING_GTIDS
       (11809), so that you do not need to calculate the missing
       GTIDs manually. (Bug #26004541, Bug #29769293)

     * With multiple sessions executing concurrent INSERT ... ON
       DUPLICATE KEY UPDATE statements into a table with an
       AUTO_INCREMENT column but not specifying the
       AUTO_INCREMENT value, inserts could fail with a unique
       index violation. (Bug #30194841, Bug #96578)

     * A SELECT using a WHERE condition of the form A AND (B OR
       C [OR ...]) resulting in an impossible range led to an
       unplanned exit of the server. (Bug #29770705)

     * An incomplete connection packet could cause clients not
       to properly initialize the authentication plugin name.
       (Bug #29630767)

On Behalf of MySQL/ORACLE RE Team
Gipson Pulla

Dear MySQL users,

The MySQL developer tools team announces 8.0.19 as our General Availability
(GA) for MySQL Workbench 8.0.

For the full list of changes in this revision, visit
https://dev.mysql.com/doc/relnotes/workbench/en/news-8-0.html

For discussion, join the MySQL Workbench Forums:
http://forums.mysql.com/index.php?152

The release is now available in source and binary form for a number of
platforms from our download pages at:

http://dev.mysql.com/downloads/tools/workbench/

Enjoy!

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

Functionality Added or Changed

     * Important Note:
       MySQL Workbench 8.0.19 is unable to open a new connection to
       MySQL Server from the home screen if the server is not started
       and you cannot start a server by using the Workbench
       Administration feature. Administrative and SQL editing tasks
       require an online server for the duration of this issue. Feature
       tasks that you performed with an offline server in previous
       releases now return an error message indicating that the server
       is unreachable.  This issue is limited to MySQL Workbench 8.0.19.
       Thank you for your patience.
       Workaround: Start MySQL Server independently before opening the
       Administration and SQL Query tabs in MySQL Workbench. On Linux,
       you can replace the MySQL Connector/C++ 8.0.19 library with the
       8.0.18 library.

     * A new context menu item now copies the headers and rows
       of queried data with tabs as separators, making it convenient to
       copy and paste query results into Excel.  Thanks to Raj Rao for
       the patch. (Bug #30568824, Bug #97712)

     * The following MySQL server language features are now
       supported: value references in INSERT statements, new options
       (TLS version, cipher suite, compression, and privilege check) in
       CHANGE MASTER TO replication statements, random passwords in
       CREATE USER and ALTER USER statements, EXPLAIN ANALYZE, and
       binary collation names.

     * Context help for the keywords and functions in SQL
       queries now includes updated syntax and usage information.

Bugs Fixed


     * When attempting to export MySQL 5.7 data using MySQL
       Workbench 8.0, the server returned an error indicating that
       INFORMATION_SCHEMA.COLUMN_STATISTICS was an unknown table.
       Consistent parameter use with mysqldump now skips the table as
       expected. (Bug #30515899, Bug #97520)

     * The SQL editor applied syntax-error highlighting to the
       EXPLAIN keyword in a valid statement prefixed with EXPLAIN
       ANALYZE, but the statement executed as expected.  (Bug #30478023,
       Bug #97416)

     * A syntax error was generated for valid ANALYZE TABLE
       statements with either the UPDATE HISTOGRAM or DROP HISTOGRAM
       clause. (Bug #30449796, Bug #97281)

     * Storage engines not supported by MySQL were listed as
       possible engines that could be selected for tables.  Unsupported
       storage engines now are removed from the suggestion list.
       (Bug #30338754, Bug #96968)

     * An existing stored connection could not be replaced with
       a new connection having the same name when the attempt was made
       from the Source Selection step of the MySQL Workbench Migration
       Wizard. (Bug #30269513)

     * On macOS, the Cancel and Export buttons in the Export
       Recordset context window (for SQL INSERT statements) were mostly
       hidden. (Bug #30244028, Bug #96689)

     * If the ls command produced an error message together with
       a list of files, no audit log for the error appeared in the
       Enterprise MySQL Audit Log Inspector. (Bug #30135391)

     * An original SQL Server record (for example, 1020.6) was
       copied inaccurately to the corresponding MySQL column (1020.0)
       when migrated using the DECIMAL data type.  Similarly, data
       migrated using the NUMERIC type generated a type-conversion
       error. Now, both decimal and numeric values are stored as DECIMAL
       types to fix the resolution of the decimal value or to fix the
       type conversion. (Bug #30062094, Bug #96230, Bug #30263415,
       Bug #96744)

     * The uniqueidentifier data type in a SQL Server source
       table was interpreted during migration as type VARCHAR(64) UNIQUE
       in the MySQL target column, instead of a VARCHAR column to
       represent a GUID (UUID) that is not unique. (Bug #29355468,
       Bug #94066)

     * The relationship arrows within an EER diagram were not
       visible when the Dark Mode theme was enabled on a macOS host and
       the diagram was exported as a single page PDF file. This fix
       disables the theme in models to prevent conflicts with the colors
       assigned by the model editor.  (Bug #29307893, Bug #94174)

     * An empty file list was shown when the audit_log_file
       value was set to any location other than the MySQL server data
       directory. (Bug #22673089)

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

Dear MySQL users,

MySQL Server 5.7.29, a new version of the popular Open Source Database
Management System, has been released. MySQL 5.7.29 is recommended for
use on production systems.

For an overview of what's new in MySQL 5.7, please see

http://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html

For information on installing MySQL 5.7.29 on new servers, please see
the MySQL installation documentation at

 http://dev.mysql.com/doc/refman/5.7/en/installing.html

MySQL Server 5.7.29 is available in source and binary form for a number
of platforms from our download pages at

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

MySQL Server 5.7.29 is also available from our repository for Linux
platforms, go here for details:

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

Windows packages are available via the Installer for Windows or .ZIP
(no-install) packages for more advanced needs. The point and click
configuration wizards and all MySQL products are available in the
unified Installer for Windows:

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

5.7.29 also comes with a web installer as an alternative to the full
installer.

The web installer doesn't come bundled with any actual products and
instead relies on download-on-demand to fetch only the products you
choose to install. This makes the initial download much smaller but
increases install time as the individual products will need to be
downloaded.

We welcome and appreciate your feedback, bug reports, bug fixes,
patches, etc.:

 http://bugs.mysql.com/report.php

The following link lists the changes in the MySQL 5.7 since the release
of MySQL 5.7.28. It may also be viewed online at

 http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-29.html

Enjoy!


==============================================================================
Changes in MySQL 5.7.29 (2020-01-13, General Availability)


     * Audit Log Notes

     * Bugs Fixed

Audit Log Notes


     * ANALYZE TABLE statements now produce read audit events.
       (Bug #29625461)

Bugs Fixed


     * InnoDB: os_file_get_parent_dir warnings were encountered
       when compiling MySQL with GCC 9.2.0. (Bug #30499288, Bug #97466)

     * InnoDB: An internal function
       (btr_push_update_extern_fields()) used to fetch newly added
       externally stored fields and update them during a pessimistic
       update or when going back to a previous version of a record was
       no longer required. Newly added externally stored fields are
       updated by a different function. Also, the method used to
       determine the number of externally stored fields was corrected.
       (Bug #30342846)

     * InnoDB: A comparison function found two records to be
       equal when attempting to merge non-leaf pages of a spatial index.
       The function was unable to handle this unexpected condition,
       which resulted in a long semaphore wait and an eventual assertion
       failure. (Bug #30287668)

     * InnoDB: Importing a tablespace from a location outside of
       the data directory raised an assertion failure. (Bug #30190227)

     * InnoDB: Importing a tablespace with a data directory
       definition that did not match the destination data directory
       returned an insufficiently descriptive schema mismatch error.
       (Bug #30190199)

     * InnoDB: Criteria used by the btr_cur_will_modify_tree()
       function, which detects whether a modifying record needs a
       modifying tree structure, was insufficient. (Bug #30113362)

     * InnoDB: An ALTER TABLE ... DISCARD TABLESPACE operation
       caused a hang condition. (Bug #29942556, Bug #30324703)

     * InnoDB: A code regression was addressed by prohibiting
       unnecessary implicit to explicit secondary index lock conversions
       for session temporary tables. (Bug #29718243)

     * InnoDB: A tablespace import operation raised an assertion
       when the cursor was positioned on a corrupted page while purging
       delete-marked records. Instead of asserting when encountering a
       corrupted page, the import operation is now terminated and an
       error is reported. (Bug #29454828, Bug #94541)

     * Replication: When a member is joining or rejoining a
       replication group, if Group Replication detects an error in the
       distributed recovery process (during which the joining member
       receives state transfer from an existing online member), it
       automatically switches over to a new donor, and retries the state
       transfer. The number of times the joining member retries before
       giving up is set by the group_replication_recovery_retry_count
       system variable. The Performance Schema table
       replication_applier_status_by_worker displays the error that
       caused the last retry. Previously, this error was only shown if
       the group member was configured with parallel replication applier
       threads (as set by the slave_parallel_workers system variable).
       If the group member was configured with a single applier thread,
       the error was cleared after each retry by an internal RESET SLAVE
       operation, so it could not be viewed. This was also the case for
       the output of the SHOW SLAVE STATUS command whether there were
       single or multiple applier threads.  The RESET SLAVE operation is
       now no longer carried out after retrying distributed recovery, so
       the error that caused the last retry can always be viewed. (Bug
       #30517160, Bug #30517172)

     * Replication: A memory leak could occur when a failed
       replication group member tried to rejoin a minority group and was
       disallowed from doing so. (Bug #30162547, Bug #96471)

     * Replication: If a replication slave was set up using a
       CHANGE MASTER TO statement that did not specify the master log
       file name and master log position, then shut down before START
       SLAVE was issued, then restarted with the option
       --relay-log-recovery set, replication did not start. This
       happened because the receiver thread had not been started before
       relay log recovery was attempted, so no log rotation event was
       available in the relay log to provide the master log file name
       and master log position.  In this situation, the slave now skips
       relay log recovery and logs a warning, then proceeds to start
       replication.  (Bug #28996606, Bug #93397)

     * Replication: When GTIDs are enabled on a replication
       master and slave, and the slave connects to the master with the
       MASTER_AUTO_POSITION=1 option set, the master must send the slave
       all the transactions that the slave has not already received,
       committed, or both. If any of the transactions that should be
       sent by the master have been already purged from the master's
       binary log, the master sends the error
       ER_MASTER_HAS_PURGED_REQUIRED_GTIDS (1789) to the slave, and
       replication does not start.  The message provided for the error
       ER_MASTER_HAS_PURGED_REQUIRED_GTIDS has been changed to provide
       advice on the correct action in this situation, which is for the
       slave to replicate the missing transactions from another source,
       or for the slave to be replaced by a new slave created from a
       more recent backup. The message advises that the master's binary
       log expiration period can be revised to avoid the situation in
       future. In addition, the master now identifies the GTIDs of the
       purged transactions and supplies them in its error log in the
       warning message ER_FOUND_MISSING_GTIDS (11809), so that you do
       not need to calculate the missing GTIDs manually. (Bug #26004541,
       Bug #29769293)

     * macOS: On macOS, configuring MySQL with -DWITH_SSL=system
       caused mysql_config output to incorrectly include internal CMake
       names for the static SSL libraries. (Bug #30541879, Bug #97632)

     * Docker packages were missing the LDAP authentication
       plugins. (Bug #30465247)

     * The original table name for a field in a derived table
       was not always displayed correctly. (Bug #30362898) References:
       See also: Bug #24611344. This issue is a regression of: Bug
       #22364401.

     * MySQL Installer was unable to uninstall MySQL 5.7 on
       Windows Server 2012. (Bug #30323924, Bug #96940)

     * With multiple sessions executing concurrent INSERT ... ON
       DUPLICATE KEY UPDATE statements into a table with an
       AUTO_INCREMENT column but not specifying the AUTO_INCREMENT
       value, inserts could fail with a unique index violation. (Bug
       #30194841, Bug #96578)

     * With lower_case_table_names=2, SHOW TABLES could fail to
       display tables with uppercase names. (Bug #29957361)

     * With keyring_encrypted_file_password set on the command
       line at server startup, the password value could be visible to
       system utilities. (Bug #29848634)

     * With a LOCK TABLES statement in effect, a metadata change
       for the locked table could cause Performance Schema or SHOW
       queries for session variables to hang in the opening_tables
       state. (Bug #29836204, Bug #92387)

     * A SELECT using a WHERE condition of the form A AND (B OR
       C [OR ...]) resulting in an impossible range led to an unplanned
       exit of the server. (Bug #29770705)

     * For JSON-format audit logging, the id field now may
       contain values larger than 65535. Previously, with heaving
       logging activity, more than 65536 queries per second could be
       executed, exceeding the 16 bits permitted for id values. (Bug
       #29661920)

     * An incomplete connection packet could cause clients not
       to properly initialize the authentication plugin name.  (Bug
       #29630767)

     * Client programs that used the libmysqlclient C client
       library could exit upon receipt of an OK packet containing
       malformed session-tracking information. (Bug #29297620, Bug
       #29630735)

     * Under certain conditions, enabling the read_only or
       super_read_only system variable did not block concurrent DDL
       statements executed by users without the SUPER privilege. (Bug
       #28438114, Bug #91852)

     * mysqlpump exits rather than dumping databases that
       contain an invalid view, by design, but it also failed if an
       invalid view existed but was not in any of the databases to be
       dumped. (Bug #27096081)


On Behalf of MySQL Release Engineering Team,
Surabhi Bhat

Dear MySQL users,

MySQL Connector/C++ 8.0.19 is a new release version of the MySQL
Connector/C++ 8.0 series.

Connector/C++ 8.0 can be used to access MySQL implementing Document
Store or in a traditional way, using SQL queries. It allows writing
both C++ and plain C applications using X DevAPI and X DevAPI for C.
It also supports the legacy API of Connector/C++ 1.1 based on JDBC4.

To learn more about how to write applications using X DevAPI, see
"X DevAPI User Guide" at

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

See also "X DevAPI Reference" at

  https://dev.mysql.com/doc/dev/connector-cpp/devapi_ref.html

and "X DevAPI for C Reference" at

  https://dev.mysql.com/doc/dev/connector-cpp/xapi_ref.html

For generic information on using Connector/C++ 8.0, see

  https://dev.mysql.com/doc/dev/connector-cpp/

For general documentation about how to get started using MySQL
as a document store, see

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

To download MySQL Connector/C++ 8.0.19, see the "General Availability (GA)
Releases" tab at

  https://dev.mysql.com/downloads/connector/cpp/

==================================================

Changes in MySQL Connector/C++ 8.0.19 (2020-01-13, General Availability)

     * Error Handling

     * Legacy (JDBC API) Notes

     * Packaging Notes

     * X DevAPI Notes

     * Functionality Added or Changed

     * Bugs Fixed

Error Handling


     * If an application tries to obtain a result set from a
       statement that does not produce one, an exception occurs.
       For applications that do not catch such exceptions,
       Connector/C++ now produces a more informative error
       message to indicate why the exception occurred. (Bug
       #28591814, Bug #92263)

Legacy (JDBC API) Notes


     * For applications that use the legacy JDBC API (that is,
       not made using X DevAPI or X DevAPI for C), it is now
       possible when creating a new session to specify multiple
       hosts to be tried until a successful connection is
       established. A list of hosts can be given in the session
       creation options.
       The new OPT_MULTI_HOST option is disabled by default for
       backward compatibility, but if enabled in the
       ConnectionOptionsMap parameter passed to connect() calls,
       it permits other map parameters to specify multiple
       hosts. Examples:
sql::ConnectOptionsMap opts;
opts["hostName"]="host1,host2:13001,localhost:13000";
opts["schema"]="test";
opts["OPT_MULTI_HOST"] = true;
opts["userName"]="user";
opts["password"]="password";
driver->connect(opts);

sql::ConnectOptionsMap opts;
opts["hostName"]="tcp://host1,host2:13001,localhost:13000/test";
opts["OPT_MULTI_HOST"] = true;
opts["userName"]="user";
opts["password"]="password";
driver->connect(opts);

sql::ConnectOptionsMap opts;
opts["hostName"]="mysql://host1,host2:13001,localhost:13000/test";
opts["OPT_MULTI_HOST"] = true;
opts["userName"]="user";
opts["password"]="password";
driver->connect(opts);

       Port values are host specific. If a host is specified
       without a port number, the default port is used.
       These rules apply:

          + If OPT_MULTI_HOST is disabled and multiple hosts are
            specified, an error occurs.

          + If OPT_MULTI_HOST is disabled and a single host that
            resolves to multiple hosts is specified, the first
            host is used for backward compatibility.

          + If OPT_MULTI_HOST is enabled and multiple hosts are
            specified, one of them is randomly chosen as the
            connection target. If the target fails, another host
            is randomly chosen from those that remain. If all
            targets fail, an error occurs.

          + The hostName parameter can accept a URI that
            contains a list of comma-separated hosts. The URI
            scheme can be mysql://, which works like tcp://. The
            URI scheme can also be omitted, so the parameter can
            be a list of comma-separated hosts.

          + The connect() syntax that takes URI, user, and
            password parameters does not permit multiple hosts
            because in that case OPT_MULTI_HOST is disabled.

Packaging Notes


     * Connector/C++ now is compatible with MSVC 2019, while
       retaining compatibility with MSVC 2017:

          + Previously, Connector/C++ binary distributions were
            compatible with projects built using MSVC 2017 or
            2015. Binary distributions now are compatible with
            projects built using MSVC 2019 (using either dynamic
            or static connector libraries) or MSVC 2017 (using
            dynamic connector libraries). Building using MSVC
            2015 might work, but is not supported.

          + Previously, Connector/C++ source distributions could
            be built using MSVC 2017 or 2015. Source
            distributions now can be built using MSVC 2019 or
            2017. Building using MSVC 2015 might work, but is
            not supported.

          + Previously, the MSI installer accepted the Visual
            C++ Redistributable for Visual Studio 2017 or 2015.
            The MSI installer now accepts the Visual C++
            Redistributable for Visual Studio 2019 or 2017.

X DevAPI Notes


     * For applications that use X DevAPI or X DevAPI for C,
       Connector/C++ now provides options that enable specifying
       the permitted TLS protocols and ciphersuites for TLS
       connection negotiation:

          + TLS protocols must be chosen from this list: TLSv1,
            TLSv1.1, TLSv1.2, TLSv1.3. (TLSv1.3 requires that
            both the server and Connector/C++ be compiled with
            OpenSSL 1.1.1 or higher.)

          + Ciphersuite values must be IANA ciphersuite names.
       TLS protocols and ciphersuites now may be specified in
       these contexts:

          + Connection strings permit tls-versions and
            tls-ciphersuites options. The tls-versions value is
            a list of one or more comma-separated TLS protocol
            versions. The tls-ciphersuites value is a list of
            one or more comma-separated ciphersuite names.
            Examples:
...?tls-versions=[TLSv1.3]&...
...?tls-versions=[TLSv1.2,TLSv1.3]&...
...?tls-ciphersuites=[
     TLS_DHE_PSK_WITH_AES_128_GCM_SHA256,
     TLS_CHACHA20_POLY1305_SHA256
   ]&...

          + SessionSettings objects permit TLS_VERSIONS and
            TLS_CIPHERSUITES options. Each value is either a
            string containing one or more comma-separated items
            or a container with strings (that is, any type that
            can be iterated with a loop that yields string
            values).
            Example of single string values:
Session s(...,
  TLS_VERSIONS, "TLSv1.2,TLSv1.3",
  TLS_CIPHERSUITES,
    "TLS_DHE_PSK_WITH_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256"
,
...);
            Example of string container values:
std::list<std::string> tls_versions = {
  "TLSv1.2",
  "TLSv1.3"
};

std::list<std::string> ciphers = {
  "TLS_DHE_PSK_WITH_AES_128_GCM_SHA256",
  "TLS_CHACHA20_POLY1305_SHA256"
};

Session s(...,
  TLS_VERSIONS, tls_versions
  TLS_CIPHERSUITES, ciphers,
...);

Session s(...,
  TLS_VERSIONS, std::vector{"TLSv1.2","TLSv1.3"},
  TLS_CIPHERSUITES, std::vector{"TLS_DHE_PSK_WITH_AES_128_GCM_SHA256",
 "TLS_CHACHA20_POLY1305_SHA256"},
...);

          + mysqlx_session_option_set() and friends permit
            MYSQLX_OPT_TLS_VERSIONS and
            MYSQLX_OPT_TLS_CIPHERSUITES session option
            constants, together with the corresponding
            OPT_TLS_VERSIONS() and OPT_TLS_CIPHERSUITES()
            macros. MYSQLX_OPT_TLS_VERSIONS and
            MYSQLX_OPT_TLS_CIPHERSUITES accept a string
            containing one or more comma-separated items.
            Examples:
mysqlx_session_option_set(opts, ...,
  OPT_TLS_VERSIONS("TLSv1.2,TLSv1.3"),
  OPT_TLS_CIPHERSUITES(
    "TLS_DHE_PSK_WITH_AES_128_GCM_SHA256,TLS_CHACHA20_POLY1305_SHA256"
  ),
...)
       For more information about TLS protocols and ciphersuites
       in MySQL, see Encrypted Connection TLS Protocols and
       Ciphers
       ( https://dev.mysql.com/doc/refman/8.0/en/encrypted-connection-protocols-ciphers.html ). 
       (Bug #28964583, Bug #93299)

     * For X DevAPI or X DevAPI for C, when creating a new
       connection (given by a connection string or other means),
       if the connection data contains several target hosts that
       have no explicit priority assigned, the behavior of the
       failover logic now is the same as if all those target
       hosts have the same priority. That is, the next candidate
       for making a connection is chosen randomly from the
       remaining available hosts.
       This is a change from previous behavior, where hosts with
       no explicit priority were assigned implicit decreasing
       priorities and tried in the same order as listed in the
       connection data.

Functionality Added or Changed


     * Connector/C++ now supports the use of DNS SRV records to
       specify multiple hosts:

          + Session and session-pool creation accepts a URI
            scheme of mysqlx+srv:// that enables the DNS SRV
            feature in connect strings. Example:
mysqlx+srv://example.com/db?options


          + For X DevAPI, mysqlx::Session objects permit a
            SessionOption::DNS_SRV entry to enable use of a DNS
            SRV record to specify available services. Example:
mysqlx::Session sess(
    SessionOption::HOST, "example.com",
    SessionOption::DNS_SRV, true,
    SessionOption::USER, "user",
    SessionOption::PWD, "password");

            Similarly, for X DevAPI for C, the
            mysqlx_session_option_set() function permits an
            OPT_DNS_SRV() option in the argument list. Example:
mysqlx_session_option_set(opt,
    OPT_HOST("example.com"),
    OPT_DNS_SRV(true)
    OPT_USER("user"),
    OPT_PWD("password"),
    PARAM_END));


          + For applications that use the legacy JDBC API (that
            is, not made using X DevAPI or X DevAPI for C),
            connection maps permit an OPT_DNS_SRV element. A map
            should specify the host for SRV lookup as a full
            lookup name and without a port. Example:
sql::ConnectOptionsMap opts;
opts["hostName"] = "_mysql._tcp.host1.example.com";
opts["OPT_DNS_SRV"] = true;
opts["userName"] = "user";
opts["password"] = "password";
driver->connect(opts);

            In legacy applications, DNS SRV resolution cannot be
            enabled in URI connect strings because parameters
            are not supported in such strings.

Bugs Fixed


     * Connector/C++ failed to compile using Clang on Linux.
       (Bug #30450484)

     * Connector/C++ set the transaction isolation level to
       REPEATABLE READ at connect time, regardless of the
       current server setting. (Bug #22038313, Bug #78852, Bug
       #30294415)


On Behalf of MySQL Release Engineering Team,
Surabhi Bhat

Dear MySQL Users,

MySQL Cluster is the distributed, shared-nothing variant of MySQL.
This storage engine provides:

  - In-Memory storage - Real-time performance (with optional
    checkpointing to disk)
  - Transparent Auto-Sharding - Read & write scalability
  - Active-Active/Multi-Master geographic replication
  - 99.999% High Availability with no single point of failure
    and on-line maintenance
  - NoSQL and SQL APIs (including C++, Java, http, Memcached
    and JavaScript/Node.js)

MySQL Cluster 8.0.19 has been released and can be downloaded from

  http://www.mysql.com/downloads/cluster/

where you will also find Quick Start guides to help you get your
first MySQL Cluster database up and running.

MySQL Cluster 8.0 is also available from our repository for Linux
platforms, go here for details:

  https://dev.mysql.com/downloads/

The release notes are available from

  http://dev.mysql.com/doc/relnotes/mysql-cluster/8.0/en/index.html

MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.

More details can be found at

  http://www.mysql.com/products/cluster/

Enjoy !

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

   MySQL NDB Cluster 8.0.19 is a new release of NDB
   8.0, based on MySQL Server 8.0 and including features in
   version 8.0 of the NDB storage engine, as well as fixing
   recently discovered bugs in previous NDB Cluster releases.

   Obtaining NDB Cluster 8.0.  NDB Cluster 8.0 source code and
   binaries can be obtained from
   https://dev.mysql.com/downloads/cluster/.

   For an overview of changes made in NDB Cluster 8.0, see What
   is New in NDB Cluster
   (https://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-what-is-new.html).

   This release also incorporates all bug fixes and changes made
   in previous NDB Cluster releases, as well as all bug fixes
   and feature changes which were added in mainline MySQL 8.0
   through MySQL 8.0.19 (see Changes in MySQL 8.0.19
   (2020-01-13, General Availability)
   (https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-19.html)).

Functionality Added or Changed


     * Important Change: The default value for the
       ndb_autoincrement_prefetch_sz server system variable has
       been increased to 512. (Bug #30316314)

     * Important Change: NDB now supports more than 2 replicas
       (up to a maximum of 4). Setting NoOfReplicas=3 or
       NoOfReplicas=4 is now fully covered in our internal
       testing and thus supported for use in production. (Bug
       #97479, Bug #97579, Bug #25261716, Bug #30501414, Bug
       #30528105)

     * Important Change: Added the TransactionMemory data node
       configuration parameter which simplifies configuration of
       data node memory allocation for transaction operations.
       This part of ongoing work on pooling of transactional and
       Local Data Manager (LDM) memory.
       This new parameter is intended to supersede several older
       transactional memory parameters which have been
       deprecated (and which are thus subject to removal in a
       future release of NDB Cluster). In particular, the
       following parameters are incompatible with
       TransactionMemory and cannot be set in the config.ini
       configuration file if this parameter has been set:

          + MaxNoOfConcurrentIndexOperations

          + MaxNoOfFiredTriggers

          + MaxNoOfLocalOperations

          + MaxNoOfLocalScans
       If you attempt to set any of these incompatible
       parameters concurrently with TransactionMemory, the
       cluster management server cannot start.
       For more information, see the description of the
       TransactionMemory parameter and Parameters incompatible
       with TransactionMemory
       (https://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbd-definition.html#mysql-cluster-transactionmemory-incompatible).
       See also Data Node Memory Management
       (https://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-data-node-memory-management.html),
       for information about how memory resources are allocated
       by NDB Cluster data nodes. (Bug #96995, Bug #30344471)

     * Important Change: The maximum or default values for
       several NDB Cluster data node configuration parameters
       have been changed in this release. These changes are
       listed here:

          + The maximum value for DataMemory is increased from 1
            terabyte to 16 TB.

          + The maximum value for DiskPageBufferMemory is also
            increased from 1 TB to 16 TB.

          + The default value for StringMemory is decreased to 5
            percent. Previously, this was 25 percent.

          + The default value for LcpScanProgressTimeout is
            increased from 60 seconds to 180 seconds.

     * Performance: Read from any replica, which greatly
       improves the performance of table reads at a very low
       cost to table write performance, is now enabled by
       default for all NDB tables. This means both that the
       default value for the ndb_read_backup system variable is
       now ON, and that the value of the NDB_TABLE comment
       option READ_BACKUP is 1 when creating a new NDB table.
       (Previously, the default values were OFF and 0,
       respectively.)
       For more information, see Setting NDB_TABLE Options
       (https://dev.mysql.com/doc/refman/8.0/en/create-table-ndb-table-comment-options.html),
       as well as the description
       of the ndb_read_backup system variable.

     * NDB Disk Data: The latency of checkpoints for Disk Data
       files has been reduced when using non-volatile memory
       devices such as solid-state drives (especially those
       using NVMe for data transfer), separate physical drives
       for Disk Data files, or both. As part of this work, two
       new data node configuration parameters, listed here, have
       been introduced:

          + MaxDiskDataLatency sets a maximum on allowed latency
            for disk access, aborting transactions exceeding
            this amount of time to complete

          + DiskDataUsingSameDisk makes it possible to take
            advantage of keeping Disk Data files on separate
            disks by increasing the rate at which Disk Data
            checkpoints can be made
       This release also adds three new tables to the ndbinfo
       database. These tables, listed here, can assist with
       performance monitoring of Disk Data checkpointing:

          + diskstat provides information about Disk Data
            tablespace reads, writes, and page requests during
            the previous 1 second

          + diskstats_1sec provides information similar to that
            given by the diskstat table, but does so for each of
            the last 20 seconds

          + pgman_time_track_stats table reports on the latency
            of disk operations affecting Disk Data tablespaces
       For additional information, see Disk Data latency
       parameters
       (https://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbd-definition.html#mysql-cluster-ndbd-definition-disk-data-latency-parameters).

     * Added the ndb_metadata_sync server system variable, which
       simplifies knowing when metadata synchronization has
       completed successfully. Setting this variable to true
       triggers immediate synchronization of all changes between
       the NDB dictionary and the MySQL data dictionary without
       regard to any values set for ndb_metadata_check or
       ndb_metadata_check_interval. When synchronization has
       completed, its value is automatically reset to false.
       (Bug #30406657)

     * A stack trace is now written to the data node log on
       abnormal termination of a data node.

     * Automatic synchronization of metadata from the MySQL data
       dictionary to NDB now includes databases containing NDB
       tables. With this enhancement, if a table exists in NDB,
       and the table and the database it belongs to do not exist
       on a given SQL node, it is no longer necessary to create
       the database manually. Instead, the database, along with
       all NDB tables belonging to this database, should be
       created on the SQL node automatically.

Bugs Fixed


     * Incompatible Change: ndb_restore no longer restores
       shared users and grants to the mysql.ndb_sql_metadata
       table by default. A new command-line option
       --include-stored-grants is added to override this
       behavior and enable restoring of shared user and grant
       data and metadata.
       As part of this fix, ndb_restore can now also correctly
       handle an ordered index on a system table. (Bug
       #30237657)
       References: See also: Bug #29534239, Bug #30459246.

     * Incompatible Change: The minimum value for the
       RedoOverCommitCounter data node configuration parameter
       has been increased from 0 to 1. The minimum value for the
       RedoOverCommitLimit data node configuration parameter has
       also been increased from 0 to 1.
       You should check the cluster global configuration file
       and make any necessary adjustments to values set for
       these parameters before upgrading. (Bug #29752703)

     * macOS: On MacOS, SQL nodes sometimes shut down
       unexpectedly during the binary log setup phase when
       starting the cluster. This occurred when there existed
       schemas whose names used uppercase letters and
       lower_case_table_names was set to 2. This caused
       acquisition of metadata locks to be attempted using keys
       having the incorrect lettercase, and, subsequently, these
       locks to fail. (Bug #30192373)

     * Microsoft Windows; NDB Disk Data: On Windows, restarting
       a data node other than the master when using Disk Data
       tables led to a failure in TSMAN. (Bug #97436, Bug
       #30484272)

     * Solaris: When debugging, ndbmtd consumed all available
       swap space on Solaris 11.4 SRU 12 and later. (Bug
       #30446577)

     * Solaris: The byte order used for numeric values stored in
       the mysql.ndb_sql_metadata table was incorrect on
       Solaris/Sparc. This could be seen when using
       ndb_select_all or ndb_restore --print. (Bug #30265016)

     * NDB Disk Data: After dropping a disk data table on one
       SQL node, trying to execute a query against
       INFORMATION_SCHEMA.FILES on a different SQL node stalled
       at Waiting for tablespace metadata lock. (Bug #30152258)
       References: See also: Bug #29871406.

     * NDB Disk Data: ALTER TABLESPACE ... ADD DATAFILE could
       sometimes hang while trying to acquire a metadata lock.
       (Bug #29871406)

     * The fix made in NDB 8.0.18 for an issue in which a
       transaction was committed prematurely aborted the
       transaction if the table definition had changed midway,
       but failed in testing to free memory allocated by
       getExtraMetadata(). Now this memory is properly freed
       before aborting the transaction. (Bug #30576983)
       References: This issue is a regression of: Bug #29911440.

     * Excessive allocation of attribute buffer when
       initializing data in DBTC led to preallocation of api
       connection records failing due to unexpectedly running
       out of memory. (Bug #30570264)

     * Improved error handling in the case where NDB attempted
       to update a local user having the NDB_STORED_USER
       privilege but which could not be found in the
       ndb_sql_metadata table. (Bug #30556487)

     * Failure of a transaction during execution of an ALTER
       TABLE ... ALGORITHM=COPY statement following the rename
       of the new table to the name of the original table but
       before dropping the original table caused mysqld to exit
       prematurely. (Bug #30548209)

     * Non-MSI builds on Windows using -DWITH_NDBCLUSTER did not
       succeed unless the WiX toolkit was installed. (Bug
       #30536837)

     * The allowed_values output from ndb_config --xml
       --configinfo for the Arbitration data node configuration
       parameter in NDB 8.0.18 was not consistent with that
       obtained in previous releases. (Bug #30529220)
       References: See also: Bug #30505003.

     * A faulty ndbrequire() introduced when implementing
       partial local checkpoints assumed that m_participatingLQH
       must be clear when receiving START_LCP_REQ, which is not
       necessarily true when a failure happens for the master
       after sending START_LCP_REQ and before handling any
       START_LCP_CONF signals. (Bug #30523457)

     * A local checkpoint sometimes hung when the master node
       failed while sending an LCP_COMPLETE_REP signal and it
       was sent to some nodes, but not all of them. (Bug
       #30520818)

     * Added the DUMP 9988 and DUMP 9989 commands. (Bug
       #30520103)

     * The management server did not handle all cases of
       NODE_FAILREP correctly. (Bug #30520066)

     * With SharedGlobalMemory set to 0, some resources did not
       meet required minimums. (Bug #30411835)

     * Execution of ndb_restore --rebuild-indexes together with
       the --rewrite-database and --exclude-missing-tables
       options did not create indexes for any tables in the
       target database. (Bug #30411122)

     * When writing the schema operation into the ndb_schema
       table failed, the states in the NDB_SCHEMA object were
       not cleared, which led to the SQL node shutting down when
       it tried to free the object. (Bug #30402362)
       References: See also: Bug #30371590.

     * If a transaction was aborted while getting a page from
       the disk page buffer and the disk system was overloaded,
       the transaction hung indefinitely. This could also cause
       restarts to hang and node failure handling to fail. (Bug
       #30397083, Bug #30360681)
       References: See also: Bug #30152258.

     * When synchronizing extent pages it was possible for the
       current local checkpoint (LCP) to stall indefinitely if a
       CONTINUEB signal for handling the LCP was still
       outstanding when receiving the FSWRITECONF signal for the
       last page written in the extent synchronization page. The
       LCP could also be restarted if another page was written
       from the data pages. It was also possible that this issue
       caused PREP_LCP pages to be written at times when they
       should not have been. (Bug #30397083)

     * Data node failures with the error Another node failed
       during system restart... occurred during a partial
       restart. (Bug #30368622)

     * Automatic synchronization could potentially trigger an
       increase in the number of locks being taken on a
       particular metadata object at a given time, such as when
       a synchronization attempt coincided with a DDL or DML
       statement involving the same metadata object; competing
       locks could lead to the NDB deadlock detection logic
       penalizing the user action rather than the background
       synchronization. We fix this by changing all exclusive
       metadata lock acquisition attempts during
       auto-synchronization so that they use a timeout of 0
       (rather than the 10 seconds previously allowed), which
       avoids deadlock detection and gives priority to the user
       action. (Bug #30358470)

     * If a SYNC_EXTENT_PAGES_REQ signal was received by PGMAN
       while dropping a log file group as part of a partial
       local checkpoint, and thus dropping the page locked by
       this block for processing next, the LCP terminated due to
       trying to access the page after it had already been
       dropped. (Bug #30305315)

     * The wrong number of bytes was reported in the cluster log
       for a completed local checkpoint. (Bug #30274618)
       References: See also: Bug #29942998.

     * Added the new ndb_mgm client debugging commands DUMP 2356
       and DUMP 2357. (Bug #30265415)

     * Executing ndb_drop_table using the --help option caused
       this program to terminate prematurely, and without
       producing any help output. (Bug #30259264)

     * A mysqld trying to connect to the cluster, and thus
       trying to acquire the global schema lock (GSL) during
       setup, ignored the setting for ndb_wait_setup and hung
       indefinitely when the GSL had already been acquired by
       another mysqld, such as when it was executing an ALTER
       TABLE statement. (Bug #30242141)

     * When a table containing self-referential foreign key (in
       other words, a foreign key referencing another column of
       the same table) was altered using the COPY algorithm, the
       foreign key definition was removed. (Bug #30233405)

     * In MySQL 8.0, names of foreign keys explicitly provided
       by user are generated automatically in the SQL layer and
       stored in the data dictionary. Such names are of the form
       [table_name]_ibfk_[#] which align with the names
       generated by the InnoDB storage engine in MySQL 5.7. NDB
       8.0.18 introduced a change in behavior by NDB such that
       it also uses the generated names, but in some cases, such
       as when tables were renamed, NDB still generated and used
       its own format for such names internally rather than
       those generated by the SQL layer and stored in the data
       dictionary, which led to the following issues:

          + Discrepancies in SHOW CREATE TABLE output and the
            contents of I_S.REFENTIAL_CONSTRAINTS

          + Improper metadata locking for foreign keys

          + Confusing names for foreign keys in error messages
       Now NDB also renames the foreign keys in such cases,
       using the names provided by the MySQL server, to align
       fully with those used by InnoDB. (Bug #30210839)
       References: See also: Bug #96508, Bug #30171959.

     * When a table referenced by a foreign key was renamed,
       participating SQL nodes did not properly update the
       foreign key definitions for the referencing table in
       their data dictionaries during schema distribution. (Bug
       #30191068)

     * Data node handling of failures of other data nodes could
       sometimes not be synchronized properly, such that two or
       more data nodes could see different nodes as the master
       node. (Bug #30188414)

     * Some scan operations failed due to the presence of an old
       assert in DbtupBuffer.cpp that checked whether API nodes
       were using a version of the software previous to NDB 6.4.
       This was no longer necessary or correct, and has been
       removed. (Bug #30188411)

     * When executing a global schema lock (GSL), NDB used a
       single Ndb_table_guard object for successive retires when
       attempting to obtain a table object reference; it was not
       possible for this to succeed after failing on the first
       attempt, since Ndb_table_guard assumes that the
       underlying object pointer is determined once only---at
       initialisation---with the previously retrieved pointer
       being returned from a cached reference thereafter.
       This resulted in infinite waits to obtain the GSL,
       causing the binlog injector thread to hang so that mysqld
       considered all NDB tables to be read-only. To avoid this
       problem, NDB now uses a fresh instance of Ndb_table_guard
       for each such retry. (Bug #30120858)
       References: This issue is a regression of: Bug #30086352.

     * When upgrading an SQL node to NDB 8.0 from a previous
       release series, the .frm file whose contents are read and
       then installed in the data dictionary does not contain
       any information about foreign keys. This meant that
       foreign key information was not installed in the SQL
       node's data dictionary. This is fixed by using the
       foreign key information available in the NDB data
       dictionary to update the local MySQL data dictionary
       during table metadata upgrade. (Bug #30071043)

     * Restoring tables with the --disable-indexes option
       resulted in the wrong table definition being installed in
       the MySQL data dictionary. This is because the serialized
       dictionary information (SDI) packed into the NDB
       dictionary's table definition is used to create the table
       object; the SDI definition is updated only when the DDL
       change is done through the MySQL server. Installation of
       the wrong table definition meant that the table could not
       be opened until the indexes were re-created in the NDB
       dictionary again using --rebuild-indexes.
       This is fixed by extending auto-synchronization such that
       it compares the SDI to the NDB dictionary table
       information and fails in cases in which the column
       definitions do not match. Mismatches involving indexes
       only are treated as temporary errors, with the table in
       question being detected again during the next round of
       change detection. (Bug #30000202, Bug #30414514)

     * Restoring tables for which MAX_ROWS was used to alter
       partitioning from a backup made from NDB 7.4 to a cluster
       running NDB 7.6 did not work correctly. This is fixed by
       ensuring that the upgrade code handling PartitionBalance
       supplies a valid table specification to the NDB
       dictionary. (Bug #29955656)

     * The number of data bytes for the summary event written in
       the cluster log when a backup completed was truncated to
       32 bits, so that there was a significant mismatch between
       the number of log records and the number of data records
       printed in the log for this event. (Bug #29942998)

     * mysqld sometimes aborted during a long ALTER TABLE
       operation that timed out. (Bug #29894768)
       References: See also: Bug #29192097.

     * When an SQL node connected to NDB, it did not know
       whether it had previously connected to that cluster, and
       thus could not determine whether its data dictionary
       information was merely out of date, or completely
       invalid. This issue is solved by implementing a unique
       schema version identifier (schema UUID) to the ndb_schema
       table in NDB as well as to the ndb_schema table object in
       the data dictionary. Now, whenever a mysqld connects to a
       cluster as an SQL node, it can compare the schema UUID
       stored in its data dictionary against that which is
       stored in the ndb_schema table, and so know whether it is
       connecting for the first time. If so, the SQL node
       removes any entries that may be in its data dictionary.
       (Bug #29894166)
       References: See also: Bug #27543602.

     * Improved log messages generated by table discovery and
       table metadata upgrades. (Bug #29894127)

     * Using 2 LDM threads on a 2-node cluster with 10 threads
       per node could result in a partition imbalance, such that
       one of the LDM threads on each node was the primary for
       zero fragments. Trying to restore a multi-threaded backup
       from this cluster failed because the datafile for one LDM
       contained only the 12-byte data file header, which
       ndb_restore was unable to read. The same problem could
       occur in other cases, such as when taking a backup
       immediately after adding an empty node online.
       It was found that this occurred when ODirect was enabled
       for an EOF backup data file write whose size was less
       than 512 bytes and the backup was in the STOPPING state.
       This normally occurs only for an aborted backup, but
       could also happen for a successful backup for which an
       LDM had no fragments. We fix the issue by introducing an
       additional check to ensure that writes are skipped only
       if the backup actually contains an error which should
       cause it to abort. (Bug #29892660)
       References: See also: Bug #30371389.

     * For NDB tables, ALTER TABLE ... ALTER INDEX did not work
       with ALGORITHM=INPLACE. (Bug #29700197)

     * ndb_restore failed in testing on 32-bit platforms. This
       issue is fixed by increasing the size of the thread stack
       used by this tool from 64 KB to 128 KB. (Bug #29699887)
       References: See also: Bug #30406046.

     * An unplanned shutdown of the cluster occurred due to an
       error in DBTUP while deleting rows from a table following
       an online upgrade. (Bug #29616383)

     * In some cases the SignalSender class, used as part of the
       implementation of ndb_mgmd and ndbinfo, buffered
       excessive numbers of unneeded SUB_GCP_COMPLETE_REP and
       API_REGCONF signals, leading to unnecessary consumption
       of memory. (Bug #29520353)
       References: See also: Bug #20075747, Bug #29474136.

     * The setting for the BackupLogBufferSize configuration
       parameter was not honored. (Bug #29415012)

     * When mysqld was run with the --upgrade=FORCE option, it
       reported the following issues:
      [Warning]  Table 'mysql.ndb_apply_status' requires repair.
      [ERROR]    Table 'mysql.ndb_apply_status' repair failed.
       This was because --upgrade=FORCE causes a bootstrap
       system thread to run CHECK TABLE FOR UPGRADE, but
       ha_ndbcluster::open() refused to open the table before
       schema synchronization had completed, which eventually
       led to the reported conditions. (Bug #29305977)
       References: See also: Bug #29205142.

     * When using explicit SHM connections, with ShmSize set to
       a value larger than the system's available shared memory,
       mysqld hung indefinitely on startup and produced no
       useful error messages. (Bug #28875553)

     * The maximum global checkpoint (GCP) commit lag and GCP
       save timeout are recalculated whenever a node shuts down,
       to take into account the change in number of data nodes.
       This could lead to the unintentional shutdown of a viable
       node when the threshold decreased below the previous
       value. (Bug #27664092)
       References: See also: Bug #26364729.

     * A transaction which inserts a child row may run
       concurrently with a transaction which deletes the parent
       row for that child. One of the transactions should be
       aborted in this case, lest an orphaned child row result.
       Before committing an insert on a child row, a read of the
       parent row is triggered to confirm that the parent
       exists. Similarly, before committing a delete on a parent
       row, a read or scan is performed to confirm that no child
       rows exist. When insert and delete transactions were run
       concurrently, their prepare and commit operations could
       interact in such a way that both transactions committed.
       This occurred because the triggered reads were performed
       using LM_CommittedRead locks (see
       NdbOperation::LockMode), which are not strong enough to
       prevent such error scenarios.
       This problem is fixed by using the stronger LM_SimpleRead
       lock mode for both triggered reads. The use of
       LM_SimpleRead rather than LM_CommittedRead locks ensures
       that at least one transaction aborts in every possible
       scenario involving transactions which concurrently insert
       into child rows and delete from parent rows. (Bug
       #22180583)

     * Concurrent SELECT and ALTER TABLE statements on the same
       SQL node could sometimes block one another while waiting
       for locks to be released. (Bug #17812505, Bug #30383887)

     * Failure handling in schema synchronization involves
       pushing warnings and errors to the binary logging thread.
       Schema synchronization is also retried in case of certain
       failures which could lead to an accumulation of warnings
       in the thread. Now such warnings and errors are cleared
       following each attempt at schema synchronization. (Bug
       #2991036)

     * An INCL_NODECONF signal from any local blocks should be
       ignored when a node has failed, except in order to reset
       c_nodeStartSlave.nodeId. (Bug #96550, Bug #30187779)

     * When returning Error 1022, NDB did not print the name of
       the affected table. (Bug #74218, Bug #19763093)
       References: See also: Bug #29700174.

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

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

Dear MySQL Users,

MySQL Cluster is the distributed, shared-nothing variant of MySQL.
This storage engine provides:

  - In-Memory storage - Real-time performance (with optional
    checkpointing to disk)
  - Transparent Auto-Sharding - Read & write scalability
  - Active-Active/Multi-Master geographic replication
  - 99.999% High Availability with no single point of failure
    and on-line maintenance
  - NoSQL and SQL APIs (including C++, Java, http, Memcached
    and JavaScript/Node.js)

MySQL Cluster 7.5.17 has been released and can be downloaded from

  http://www.mysql.com/downloads/cluster/

where you will also find Quick Start guides to help you get your
first MySQL Cluster database up and running.

MySQL Cluster 7.5 is also available from our repository for Linux
platforms, go here for details:

  https://dev.mysql.com/downloads/

The release notes are available from

http://dev.mysql.com/doc/relnotes/mysql-cluster/7.5/en/index.html

MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.

More details can be found at

  http://www.mysql.com/products/cluster/

Enjoy !



==============================================================================

Changes in MySQL NDB Cluster 7.5.17 (5.7.29-ndb-7.5.17) (2020-01-14, General Availability)

   MySQL NDB Cluster 7.5.17 is a new release of MySQL NDB
   Cluster 7.5, based on MySQL Server 5.7 and including features
   in version 7.5 of the NDB
   (https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster.html)
   storage engine, as well as fixing recently discovered bugs in
   previous NDB Cluster releases.

   Obtaining MySQL NDB Cluster 7.5.  MySQL NDB Cluster 7.5
   source code and binaries can be obtained from
   https://dev.mysql.com/downloads/cluster/.

   For an overview of changes made in MySQL NDB Cluster 7.5, see
   What is New in NDB Cluster 7.5
(https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-what-is-new-7-5.html).

   This release also incorporates all bug fixes and changes made
   in previous NDB Cluster releases, as well as all bug fixes
   and feature changes which were added in mainline MySQL 5.7
   through MySQL 5.7.29 .

Bugs Fixed


     * Incompatible Change: The minimum value for the
       RedoOverCommitCounter
(https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-ndbd-definition.html#ndbparam-ndbd-redoovercommitcounter)
       data node configuration parameter has been increased from
       0 to 1. The minimum value for the RedoOverCommitLimit
(https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-ndbd-definition.html#ndbparam-ndbd-redoovercommitlimit)
       data node configuration parameter has also been increased
       from 0 to 1.
       You should check the cluster global configuration file
       and make any necessary adjustments to values set for
       these parameters before upgrading. (Bug #29752703)

     * Added the DUMP 9988
(https://dev.mysql.com/doc/ndb-internals/en/dump-command-9988.html)
       and DUMP 9989
(https://dev.mysql.com/doc/ndb-internals/en/dump-command-9989.html)
       commands. (Bug #30520103)

     * Execution of ndb_restore --rebuild-indexes
(https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-programs-ndb-restore.html#option_ndb_restore_rebuild-indexes)
       together with the --rewrite-database
(https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-programs-ndb-restore.html#option_ndb_restore_rewrite-database)
       and --exclude-missing-tables
(https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-programs-ndb-restore.html#option_ndb_restore_exclude-missing-tables)
       options did not create indexes for any tables
       in the target database. (Bug #30411122)

     * If a transaction was aborted while getting a page from
       the disk page buffer and the disk system was overloaded,
       the transaction hung indefinitely. This could also cause
       restarts to hang and node failure handling to fail. (Bug
       #30397083, Bug #30360681)
       References: See also: Bug #30152258.

     * Data node failures with the error Another node failed
       during system restart... occurred during a partial
       restart. (Bug #30368622)

     * The wrong number of bytes was reported in the cluster log
       for a completed local checkpoint. (Bug #30274618)
       References: See also: Bug #29942998.

     * The number of data bytes for the summary event written in
       the cluster log when a backup completed was truncated to
       32 bits, so that there was a significant mismatch between
       the number of log records and the number of data records
       printed in the log for this event. (Bug #29942998)

     * Using 2 LDM threads on a 2-node cluster with 10 threads
       per node could result in a partition imbalance, such that
       one of the LDM threads on each node was the primary for
       zero fragments. Trying to restore a multi-threaded backup
       from this cluster failed because the datafile for one LDM
       contained only the 12-byte data file header, which
       ndb_restore was unable to read. The same problem could
       occur in other cases, such as when taking a backup
       immediately after adding an empty node online.
       It was found that this occurred when ODirect
(https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-ndbd-definition.html#ndbparam-ndbd-odirect)
       was enabled for
       an EOF backup data file write whose size was less than
       512 bytes and the backup was in the STOPPING state. This
       normally occurs only for an aborted backup, but could
       also happen for a successful backup for which an LDM had
       no fragments. We fix the issue by introducing an
       additional check to ensure that writes are skipped only
       if the backup actually contains an error which should
       cause it to abort. (Bug #29892660)
       References: See also: Bug #30371389.

     * In some cases the SignalSender class, used as part of the
       implementation of ndb_mgmd and ndbinfo
(https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-ndbinfo.html),
       buffered excessive numbers of unneeded
       SUB_GCP_COMPLETE_REP and API_REGCONF signals, leading to
       unnecessary consumption of memory. (Bug #29520353)
       References: See also: Bug #20075747, Bug #29474136.

     * The maximum global checkpoint (GCP) commit lag and GCP
       save timeout are recalculated whenever a node shuts down,
       to take into account the change in number of data nodes.
       This could lead to the unintentional shutdown of a viable
       node when the threshold decreased below the previous
       value. (Bug #27664092)
       References: See also: Bug #26364729.

     * A transaction which inserts a child row may run
       concurrently with a transaction which deletes the parent
       row for that child. One of the transactions should be
       aborted in this case, lest an orphaned child row result.
       Before committing an insert on a child row, a read of the
       parent row is triggered to confirm that the parent
       exists. Similarly, before committing a delete on a parent
       row, a read or scan is performed to confirm that no child
       rows exist. When insert and delete transactions were run
       concurrently, their prepare and commit operations could
       interact in such a way that both transactions committed.
       This occurred because the triggered reads were performed
       using LM_CommittedRead locks (see NdbOperation::LockMode
(https://dev.mysql.com/doc/ndbapi/en/ndb-ndboperation-lockmode.html)),
       which are not strong enough to prevent such error scenarios.
       This problem is fixed by using the stronger LM_SimpleRead
       lock mode for both triggered reads. The use of
       LM_SimpleRead rather than LM_CommittedRead locks ensures
       that at least one transaction aborts in every possible
       scenario involving transactions which concurrently insert
       into child rows and delete from parent rows. (Bug
       #22180583)

     * Concurrent SELECT
       (https://dev.mysql.com/doc/refman/5.7/en/select.html) and
       ALTER TABLE
       (https://dev.mysql.com/doc/refman/5.7/en/alter-table.html
       ) statements on the same SQL node could sometimes block
       one another while waiting for locks to be released. (Bug
       #17812505, Bug #30383887)


On Behalf of MySQL Release Engineering Team

Piotr Obrzut 

Dear MySQL Users,

MySQL Cluster is the distributed, shared-nothing variant of MySQL.
This storage engine provides:

  - In-Memory storage - Real-time performance (with optional
    checkpointing to disk)
  - Transparent Auto-Sharding - Read & write scalability
  - Active-Active/Multi-Master geographic replication
  - 99.999% High Availability with no single point of failure
    and on-line maintenance
  - NoSQL and SQL APIs (including C++, Java, http, Memcached
    and JavaScript/Node.js)

MySQL Cluster 7.3.28 has been released and can be downloaded from

  http://www.mysql.com/downloads/cluster/

where you will also find Quick Start guides to help you get your
first MySQL Cluster database up and running.

The release notes are available from

  http://dev.mysql.com/doc/relnotes/mysql-cluster/7.3/en/index.html

MySQL Cluster enables users to meet the database challenges of next
generation web, cloud, and communications services with uncompromising
scalability, uptime and agility.

More details can be found at

  http://www.mysql.com/products/cluster/

Enjoy !


==============================================================================
Changes in MySQL NDB Cluster 7.3.28 (5.6.47-ndb-7.3.28) (2020-01-14, General Availability)

*  MySQL NDB Cluster 7.3.28 is a new release of NDB Cluster
   which upgrades the included MySQL Server from version 5.6.46
   to 5.6.47. No changes have been made in the NDB storage
   engine for this release, which is identical in this respect
   with NDB 7.3.27.

*  Obtaining MySQL NDB Cluster 7.3.  MySQL NDB Cluster 7.3
   source code and binaries can be obtained from
   https://dev.mysql.com/downloads/cluster/.

*  For an overview of changes made in MySQL NDB Cluster 7.3, see
   What is New in NDB Cluster 7.3
   (https://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-what-is-new-7-3.html).

*  This release also incorporates all bug fixes and changes made
   in previous NDB Cluster releases, as well as all bug fixes
   and feature changes which were added in mainline MySQL 5.6
   through MySQL 5.6.47 .

*  Version 5.6.47-ndb-7.3.28 has no release notes, or they have
   not been published because the product version has not been
   released.

On Behalf of MySQL Release Engineering Team,
Rafal Molenda

==============================================================================

Changes in MySQL NDB Cluster 7.6.13 (5.7.29-ndb-7.6.13) (2020-01-14,
General Availability)

   MySQL NDB Cluster 7.6.13 is a new release of NDB 7.6, based
   on MySQL Server 5.7 and including features in version 7.6 of
   the NDB storage engine, as well as fixing recently discovered
   bugs in previous NDB Cluster releases.

   Obtaining NDB Cluster 7.6.  NDB Cluster 7.6 source code and
   binaries can be obtained from

     https://dev.mysql.com/downloads/cluster/

   For an overview of changes made in NDB Cluster 7.6, see What
   is New in NDB Cluster 7.6

     https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-what-is-new-7-6.html

   This release also incorporates all bug fixes and changes made
   in previous NDB Cluster releases, as well as all bug fixes
   and feature changes which were added in mainline MySQL 5.7
   through MySQL 5.7.29 .


Functionality Added or Changed

     * Important Change: It is now possible to divide a backup
       into slices and to restore these in parallel using two
       new options implemented for the ndb_restore utility,
       making it possible to employ multiple instances of
       ndb_restore to restore subsets of roughly the same size
       of the backup in parallel, which should help to reduce
       the length of time required to restore an NDB Cluster
       from backup.

       The --num-slices options determines the number of slices
       into which the backup should be divided; --slice-id
       provides the ID of the slice (0 to 1 less than the number
       of slices) to be restored by ndb_restore.
       Up to 1024 slices are supported.
       For more information, see the descriptions of the
       --num-slices and --slice-id options. (Bug #30383937)

Bugs Fixed

     * Incompatible Change: The minimum value for the
       RedoOverCommitCounter data node configuration parameter
       has been increased from 0 to 1. The minimum value for the
       RedoOverCommitLimit data node configuration parameter has
       also been increased from 0 to 1.

       You should check the cluster global configuration file
       and make any necessary adjustments to values set for
       these parameters before upgrading. (Bug #29752703)

     * Microsoft Windows; NDB Disk Data: On Windows, restarting
       a data node other than the master when using Disk Data
       tables led to a failure in TSMAN.
       (Bug #97436, Bug #30484272)

     * A faulty ndbrequire() introduced when implementing
       partial local checkpoints assumed that m_participatingLQH
       must be clear when receiving START_LCP_REQ, which is not
       necessarily true when a failure happens for the master
       after sending START_LCP_REQ and before handling any
       START_LCP_CONF signals. (Bug #30523457)

     * A local checkpoint sometimes hung when the master node
       failed while sending an LCP_COMPLETE_REP signal and it
       was sent to some nodes, but not all of them.
       (Bug #30520818)

     * Added the DUMP 9988 and DUMP 9989 commands.
       (Bug #30520103)

     * Execution of ndb_restore --rebuild-indexes together with
       the --rewrite-database and --exclude-missing-tables
       options did not create indexes for any tables in the
       target database. (Bug #30411122)

     * If a transaction was aborted while getting a page from
       the disk page buffer and the disk system was overloaded,
       the transaction hung indefinitely. This could also cause
       restarts to hang and node failure handling to fail.
       (Bug #30397083, Bug #30360681)
       References: See also: Bug #30152258.

     * When synchronizing extent pages it was possible for the
       current local checkpoint (LCP) to stall indefinitely if a
       CONTINUEB signal for handling the LCP was still
       outstanding when receiving the FSWRITECONF signal for the
       last page written in the extent synchronization page. The
       LCP could also be restarted if another page was written
       from the data pages. It was also possible that this issue
       caused PREP_LCP pages to be written at times when they
       should not have been. (Bug #30397083)

     * Data node failures with the error Another node failed
       during system restart... occurred during a partial
       restart. (Bug #30368622)

     * If a SYNC_EXTENT_PAGES_REQ signal was received by PGMAN
       while dropping a log file group as part of a partial
       local checkpoint, and thus dropping the page locked by
       this block for processing next, the LCP terminated due to
       trying to access the page after it had already been
       dropped. (Bug #30305315)

     * The wrong number of bytes was reported in the cluster log
       for a completed local checkpoint. (Bug #30274618)
       References: See also: Bug #29942998.

     * The number of data bytes for the summary event written in
       the cluster log when a backup completed was truncated to
       32 bits, so that there was a significant mismatch between
       the number of log records and the number of data records
       printed in the log for this event. (Bug #29942998)

     * Using 2 LDM threads on a 2-node cluster with 10 threads
       per node could result in a partition imbalance, such that
       one of the LDM threads on each node was the primary for
       zero fragments. Trying to restore a multi-threaded backup
       from this cluster failed because the datafile for one LDM
       contained only the 12-byte data file header, which
       ndb_restore was unable to read. The same problem could
       occur in other cases, such as when taking a backup
       immediately after adding an empty node online.

       It was found that this occurred when ODirect was enabled
       for an EOF backup data file write whose size was less
       than 512 bytes and the backup was in the STOPPING state.
       This normally occurs only for an aborted backup, but
       could also happen for a successful backup for which an
       LDM had no fragments. We fix the issue by introducing an
       additional check to ensure that writes are skipped only
       if the backup actually contains an error which should
       cause it to abort. (Bug #29892660)
       References: See also: Bug #30371389.

     * In some cases the SignalSender class, used as part of the
       implementation of ndb_mgmd and ndbinfo, buffered
       excessive numbers of unneeded SUB_GCP_COMPLETE_REP and
       API_REGCONF signals, leading to unnecessary consumption
       of memory. (Bug #29520353)
       References: See also: Bug #20075747, Bug #29474136.

     * The setting for the BackupLogBufferSize configuration
       parameter was not honored. (Bug #29415012)

     * The maximum global checkpoint (GCP) commit lag and GCP
       save timeout are recalculated whenever a node shuts down,
       to take into account the change in number of data nodes.
       This could lead to the unintentional shutdown of a viable
       node when the threshold decreased below the previous
       value. (Bug #27664092)
       References: See also: Bug #26364729.

     * A transaction which inserts a child row may run
       concurrently with a transaction which deletes the parent
       row for that child. One of the transactions should be
       aborted in this case, lest an orphaned child row result.
       Before committing an insert on a child row, a read of the
       parent row is triggered to confirm that the parent
       exists. Similarly, before committing a delete on a parent
       row, a read or scan is performed to confirm that no child
       rows exist. When insert and delete transactions were run
       concurrently, their prepare and commit operations could
       interact in such a way that both transactions committed.
       This occurred because the triggered reads were performed
       using LM_CommittedRead locks (see
       NdbOperation::LockMode), which are not strong enough to
       prevent such error scenarios.

       This problem is fixed by using the stronger LM_SimpleRead
       lock mode for both triggered reads. The use of
       LM_SimpleRead rather than LM_CommittedRead locks ensures
       that at least one transaction aborts in every possible
       scenario involving transactions which concurrently insert
       into child rows and delete from parent rows.
       (Bug #22180583)

     * Concurrent SELECT and ALTER TABLE statements on the same
       SQL node could sometimes block one another while waiting
       for locks to be released. (Bug #17812505, Bug #30383887)

Dear MySQL Users,

MySQL Cluster Manager 1.4.8 can be downloaded from
the My Oracle Support (MOS) website. It will also be available
on Oracle Software Delivery Cloud at http://edelivery.oracle.com with
the next monthly update

MySQL Cluster Manager is an optional component of the MySQL Cluster Carrier
Grade Edition, providing a command-line interface that automates common
management tasks, including the following online operations:
 - Configuring and starting MySQL Cluster
 - Upgrades
 - Adding and removing cluster nodes
 - Adding and removing site hosts
 - Configuration changes
 - Backup and restore

MySQL Cluster Manager is a commercial extension to the MySQL family of products.
More details can be found at http://www.mysql.com/products/cluster/mcm/

A brief summary of changes in MySQL Cluster Manager version 1.4.8 is listed below:

 Changes in MySQL Cluster Manager 1.4.8 (2020-01-24)


     * Experimental support for MySQL NDB Cluster 8.0

     * Functionality Added or Changed

     * Bugs Fixed

Experimental support for MySQL NDB Cluster 8.0


     * MySQL Cluster Manager now supports NDB Cluster 8.0 on an
       experimental basis; see Supported Platforms and MySQL NDB
       Cluster Versions
(https://dev.mysql.com/doc/mysql-cluster-manager/1.4/en/mcm-install-cluster-compatibility.html)
        for limitations.

Functionality Added or Changed


     * Incompatible Change; Agent: When managing NDB Cluster
       8.0.19 and later, the restore cluster command no longer
       restores shared users and grants
(https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-privilege-distribution.html)
       to the mysql.ndb_sql_metadata
       table by default. A new command option,
       --include-stored-grants, has been added for overriding
       this behavior and enabling the restore of shared user and
       grant data and metadata. (Bug #30375672)

     * Packaging: MySQL Cluster Manager is now built and shipped
       with OpenSSL 1.1.1d. (Bug #30612140)

     * Agent: By default, a rolling restart for a cluster is
       performed on the nodes in a parallel manner (that is,
       half of the nodes are stopped and restarted together,
       followed by the second half of the nodes). Now, rolling
       restarts can be performed in a sequential manner by using
       the --sequential-restart option with commands that
       perform rolling restarts, in which case the nodes are
       stopped and restarted one after another. The option can
       be used with the restart cluster, change process, add
       process, set, reset, and autotune commands. (Bug
       #30062392)

     * Agent: Some parameters could only be set before the
       initial start of a node (for example,
       NoOfFragmentLogparts); it then became impossible to set
       them after an initial start of a cluster had failed. It
       is now possible to set such parameters again, as long as
       the node involved had not yet been assigned to any
       nodegroup during the failed initial start. (Bug
       #29718127)

     * Agent: Following changes in NDB Cluster 8.0.18, the
       maximum number of data nodes supported by a NDB 8.0
       cluster managed by MySQL Cluster Manager is now 145, and
       the maximum number of node groups supported is now 72.
       With that change, when a NDB 8.0 Cluster is bootstrapped
       by mcmd with the --bootstrap option, ndb_mgmd, mysqld,
       and ndbapi nodes are assigned node IDs of 145 and above.
       (Bug #29459428)

     * Client: The --disable-indexes option for the restore
       cluster command has been removed, to avoid having the
       cluster restored into a bad state. (Bug #30728256)

     * Client: The message for ERROR 6020 has been expanded to
       include the reason why a configuration parameter cannot
       be set given the current process states. (Bug #30526906)

     * Client: The log message for a failed connection to mcmd
       by an mcm client has been expanded, warning users to make
       sure the correct hostname or IP address is specified, and
       that no firewall is blocking connection attempts. (Bug
       #30288338)

Bugs Fixed


     * Agent: The update process command failed when no ndb_mgmd
       node was running. It was due to an excessive restriction
       asserted by mcmd that this patch has relieved, so that a
       running ndb_mgmd node is required now only when update
       process is applied to a data node or mysqld node. (Bug
       #30723002)

     * Agent: During an MySQL Cluster Manager upgrade, when mcmd
       was upgrading its repository. it was over aggressive in
       removing old configuration objects that did not need to
       be upgraded, resulting sometimes in inconsistency of the
       repository and mcmd quitting unexpectedly. With this fix,
       mcmd only deletes configuration objects that it is
       supposed to. (Bug #30666263)

     * Agent: When running the import cluster command, there
       were a lot of unnecessary critical messages issued to the
       agent log. (Bug #30572723)

     * Agent: A cluster restart failed after the cluster has
       been imported by mcmd if the Arbitration parameter was
       specified in the config.ini file of the imported cluster.
       It was because the import config command, which was
       always run before the import cluster command, imported
       the parameter's value wrongly, and that has been
       corrected by this fix. (Bug #30505003)

     * Agent: After an add process command failed and the remove
       process command was used to clean up the processes that
       were not successfully added, a subsequent restart cluster
       command caused mcmd to quite unexpectedly. With this fix,
       mcmd issues a warning in the situation and then finishes
       the restart. (Bug #30498301)

     * Agent: When the stop cluster command was run and mcmd had
       to force a mysqld node to stop, the node got stuck in the
       stopping state, while mcm reported that the cluster had
       been stopped successfully. (Bug #30375807)

     * Agent: The restore cluster command timed out when the
       cluster to be backed up contained more than 2000 schemas.
       With this fix, the mcmd agents are informed of the
       progress of the restore on a more frequent basis, so that
       even if the process takes a longer time to finish, the
       agents would wait instead of timing out. (Bug #30360453)

     * Agent: When running the restore cluster command, a schema
       or table name containing a comma was taken by mcmd as a
       comma-separated list of multiple schemas or tables,
       resulting in the schema or table being restored wrongly.
       With this fix, mcmd honors the comma as part of the
       schema or table name. (Bug #30360401)

     * Agent: When managing an NDB 8.0 cluster, during the
       initial startup of the cluster, the start cluster command
       sometimes failed due to a failure to create the mcmd user
       on the cluster. That was because while the grants for the
       mcmd user are automatically synchronized to all mysqld
       nodes in NDB 8.0, mcmd still tried to create the user on
       individual nodes, thus creating conflicts. With this
       patch, the mcmd user is now only created on one mysqld
       node, and the grants are synchronized to other nodes by
       the cluster. (Bug #30015430)

     * Agent: When running an add process command, if multiple
       new nodegroups are to be created, mcmd misassigned nodes
       already in a nodegroup to a new group, causing an error
       to be thrown. It was due to the way mcmd reported
       nodegroup membership information internally, which this
       patch corrects. (Bug #29723329)

     * Agent: On Windows platforms, the rotate log command gave
       a wrong name to the new log file. (Bug #29478833)

     * Agent: For MySQL NDB Cluster 8.0, after a set
       skip_grant_tables:mysqld=true command has been issued
       from the mcm client, mcmd lost connection to the mysqld
       node. It was because on a mysqld node, remote connections
       were disabled when skip-grant-tables was true. With this
       fix, for MySQL servers started by mcmd, setting or
       resetting skip-grant-tables no longer disables remote
       connections, as long as the setting or resetting is
       performed when the mysqld node has been stopped. (Bug
       #29329690)

     * Agent: For a NDB Cluster without any mysqld nodes, a
       rolling restart might sometime cause some of the mcmd
       agents to quit unexpectedly. (Bug #29289945)

     * Agent: A slow increase in memory use was observed over
       time for mcmd, which might potentially add up to a
       significant amount if mcmd was not restarted for a long
       time. This fix eliminates the problem by removing a task
       that was executed repeatedly and unnecessarily by mcmd.
       (Bug #29166492)

     * Agent: The import config command took a long time to run
       on SPARC systems. With this fix the process for
       retrieving the configuration from the MySQL Server has
       been optimized for SPARC systems, so that the command
       does not run longer than on other platforms. (Bug
       #22673589)

     * Client: When the delete package command specified with
       the --hosts option a host name that mcmd did not
       recognize as a site member, mcmd quit unexpectedly. With
       this fix, mcmd throws a proper error in the situation.
       (Bug #29584728)


On Behalf of MySQL Release Engineering team,
Balasubramanian Kandasamy