Bugs Fixed


     * Important Note: The libevent library included with the
       MySQL Server was upgraded to version 2.1.8. (Bug
       #28207237)

     * InnoDB; Partitioning: Removed old InnoDB handler and
       partitioning code that referenced .frm files, and thus no
       longer had any purpose. (Bug #27995316)

     * InnoDB: An assertion was raised during a DROP TABLE
       operation. A thread that was accessing the table through
       the memcached API released metadata locks before
       releasing the table. (Bug #28531148)

     * InnoDB: The being_modified bit in a LOB reference was set
       but the bit modification was not logged, causing an
       assertion failure. (Bug #28443837)

     * InnoDB: Window functions returned incorrect results when
       the optimizer used the InnoDB storage engine for internal
       temporary tables. (Bug #28430650)

     * InnoDB: Adjusting the server time to an earlier time
       caused periodic redo flushes to be missed. (Bug
       #28430358, Bug #90670)

     * InnoDB: An ALTER TABLE operation that added a primary key
       produced a segmentation fault. (Bug #28395278)
       References: This issue is a regression of: Bug #27753193.

     * InnoDB: A conditional check was removed by removing the
       ReadView::complete() function and splitting its work
       among other functions. This change helps optimize
       performance on ARM 64-bit. (Bug #28385211, Bug #91759)

     * InnoDB: Leftover thread_mutex code was removed from
       InnoDB source code files. (Bug #28363673, Bug #91678)

     * InnoDB: Type changes were implemented to eliminate
       warnings that occurred when compiling InnoDB with
       Microsoft Visual Studio 2017. (Bug #28338720)

     * InnoDB: An invalid assertion was raised when a B-tree
       flag used to mark shared index locks was used to mark a
       shared-exclusive index lock. (Bug #28317172)

     * InnoDB: The sharp checkpoint mechanism no longer forces
       preflushing of dirty pages when requesting a checkpoint
       for the currently available LSN.
       The log checkpointer thread now takes the concurrency
       margin (the per thread margin for free space in the log)
       into account when determining if the next checkpoint
       write is required and whether to wake up page cleaners to
       force a sync-flush of dirty pages. Page cleaner threads
       take the concurrency margin into account when determining
       whether to flush dirty pages and how many pages to flush.
       (Bug #28297462)

     * InnoDB: A misplaced debug crash point caused a
       transaction timeout resulting in test failures. (Bug
       #28295814)

     * InnoDB: InnoDB error message format was modified to
       remove duplicate text. (Bug #28289789)

     * InnoDB: Unnecessary cycles of freeing and allocating
       memory caused JSON performance degradation on Windows.
       (Bug #28278737)

     * InnoDB: To avoid checking hardware support each time a
       hardware-optimized checksum is computed, asserts were
       converted to debug-only asserts. (Bug #28267334, Bug
       #91485)

     * InnoDB: A patch that combined Variance-Aware Transaction
       Scheduling (VATS) with functionality that releases read
       locks caused gap locks to be removed without granting
       locks to waiting transactions, resulting in transaction
       timeouts. (Bug #28261530)
       References: This issue is a regression of: Bug #28261530.

     * InnoDB: The log_checkpointer thread failed to write new
       checkpoints in a timely manner when the amount of redo
       was small. (Bug #28220222)

     * InnoDB: The server exited during an in-place upgrade from
       MySQL 5.7 to MySQL 8.0 due to an attempted eviction of a
       foreign-key-related table from the cache. At the end of
       the upgrade process, tables with FULLTEXT indexes were
       marked as ready for eviction without checking for foreign
       key relationships. (Bug #28212734, Bug #91325)

     * InnoDB: The format of the following Performance Schema
       and INFORMATION_SCHEMA table columns was modified:

          + data_locks.ENGINE_LOCK_ID

          + data_lock_waits.REQUESTING_ENGINE_LOCK_ID

          + data_lock_waits.BLOCKING_ENGINE_LOCK_ID

          + INNODB_TRX.TRX_REQUESTED_LOCK_ID
       The previous format was trx_id:table_id for table locks
       and trx_id:space_id:page_no:heap_no for record locks. The
       new format is trx_immutable_id:table_id:lock_immutable_id
       for table locks and
       trx_immutable_id:space_id:page_no:heap_no:lock_immutable_
       id for record locks.
       lock_immutable_id and trx_immutable_id are 64-bit values
       that do not change during the lifetime of a lock or
       transaction, respectively, and are unique among other
       instance object IDs. (Bug #28176910)

     * InnoDB: The list of permitted lock mode descriptors used
       by the LOCK_MODE column of the Performance Schema
       data_locks table was expanded to include REC_NOT_GAP,
       INSERT_INTENTION, PREDICATE, and PRDT_PAGE. REC_NOT_GAP
       indicates a record-only lock. INSERT_INTENTION indicates
       an insert intention lock. PREDICATE and PRDT_PAGE
       descriptors indicate a spatial index lock. (Bug
       #28176805)

     * InnoDB: Table names were not compared in lowercase on
       macOS with a setting of lower_case_table_names=2, which
       caused instability after restarting the server. (Bug
       #28170699, Bug #91204)

     * InnoDB: Macros used to define constant values in InnoDB
       source code were changed to constant expressions. (Bug
       #28152926)

     * InnoDB: A flag that prevents transactions from being
       rolled back during commit is now set earlier to prevent
       scenarios in which a high priority transaction could
       abort a transaction that is in the process of being
       committed. (Bug #28140462)

     * InnoDB: A query that scanned the primary key of a table
       did not return the expected result. (Bug #28104394, Bug
       #91032)

     * InnoDB: Unnecessary header file inclusions were removed
       from InnoDB source code files. (Bug #28086759)

     * InnoDB: An apparent hang due to the log writer running
       out of free space in the redo log caused the server to
       exit. (Bug #28072385, Bug #90993)

     * InnoDB: A query interruption during a lock wait caused an
       error. (Bug #28068293)

     * InnoDB: After upgrading from MySQL 5.7 to MySQL 8.0,
       invalid warnings indicated that undo tablespace IDs were
       not in the undo tablespace range. The warnings occurred
       if the MySQL 5.7 installation was configured to use
       separate undo tablespaces. (Bug #28060337)

     * InnoDB: Error messaging was improved for startup failures
       on an incomplete cloned data directory. (Bug #28032131)

     * InnoDB: A segmentation fault occurred during an XA COMMIT
       operation. (Bug #27995891)

     * InnoDB: Unused code was removed from the TempTable
       storage engine source code. (Bug #27978968)

     * InnoDB: An index record was not found when updating a
       secondary index defined on a generated column. (Bug
       #27968952)

     * InnoDB: A spurious negation operator in an IF condition
       caused the Variance-Aware Transaction Scheduling (VATS)
       algorithm to be used for table locks. (Bug #27944920)
       References: This issue is a regression of: Bug #27572937.

     * InnoDB: The update log applied as part of an online ALTER
       TABLE operation did not take into account the computed
       value of the generated column in the old row while
       updating the secondary index. (Bug #27921932)

     * InnoDB: Buffer pool memory allocation was not fully
       accounted for in Performance Schema
       memory/innodb/buf_buf_pool statistics. (Bug #27917595,
       Bug #90561)

     * InnoDB: An unsupported DDL operation involving a foreign
       key constraint raised an assertion. (Bug #27912873)

     * InnoDB: A lock-related debug assertion failure was raised
       when more than one lock matched a search condition, which
       could lead to releasing the wrong lock. (Bug #27898384)

     * InnoDB: A function that removes aborted indexes during
       the prepare phase of an online ALTER TABLE operation did
       not record its changes. (Bug #27879325)

     * InnoDB: A general tablespace created in MySQL 5.7 with no
       assigned table caused a failure when upgrading to MySQL
       8.0. (Bug #27877485)

     * InnoDB: Concurrent undo tablespace truncation and master
       key rotation operations raised an assertion. (Bug
       #27872369)

     * InnoDB: A boolean marker identifying whether a
       transaction holds a mutex was not placed in the correct
       location. (Bug #27870035)

     * InnoDB: An attempted foreign key check on a discarded
       table caused a segmentation fault. (Bug #27804668)

     * InnoDB: B-tree bulk load operations could leave a page in
       a partially initialized state. (Bug #27802098)

     * InnoDB: Starting the server inside a Docker container on
       a NUMA enabled operating system raised an "mbind:
       Operation not permitted" error. (Bug #27792853)

     * InnoDB: A partitioned table TABLE_ID value stored in a
       storage-engine-private data field in the data dictionary
       was not adjusted properly after an ALTER TABLE ...
       PARTITION operation. (Bug #27784462)

     * InnoDB: The server halted with a "log writer overwriting
       data after checkpoint - waited too long" error. (Bug
       #27779266)

     * InnoDB: With innodb_flush_log_at_trx_commit=2, the
       log_flusher thread could wait for an event with a timeout
       period equal to the innodb_flush_log_at_timeout setting,
       causing an initialization delay. (Bug #27762596)

     * InnoDB: An assertion was raised during an OPTIMIZE TABLE
       operation. (Bug #27753193)

     * InnoDB: Transaction rollback due to a deadlock caused an
       assertion failure in debug builds. Initiation of an
       attachable transaction for accessing the data dictionary
       was not expected during transaction rollback. (Bug
       #27729974)

     * InnoDB: With innodb_flush_log_at_trx_commit=0 and binary
       logging enabled, redo logs were not flushed as expected
       during the commit phase of DDL operations. (Bug
       #27691035)

     * InnoDB: With REDUNDANT or COMPRESSED row format and READ
       COMMITTED isolation level, only the LOB value prefix and
       possibly the external part of an old LOB value were
       returned, which could cause a JSON document to be viewed
       as corrupted. If there was no LOB value prefix, an old
       LOB value with new values for other fields could be
       returned, causing data inconsistency. (Bug #27624990)

     * InnoDB: A debug option that permits pausing periodic
       checkpoints became obsolete after periodic checkpoint
       ownership was moved from the master thread to a log
       checkpointer thread. The debug option was replaced by
       another method of pausing periodic checkpoints. (Bug
       #27588328)

     * InnoDB: A transaction on a table with a spatial index
       defined on a column with a spatial reference identifier
       (SRID) was able to insert into an area selected for
       update by another transaction. (Bug #27577612)

     * InnoDB: A foreign key constraint name was duplicated
       during a rename table operation, causing a failure during
       later query execution. (Bug #27545888)

     * InnoDB: A Serialized Dictionary Information (SDI)
       deletion failure raised an assertion. (Bug #27493634)

     * InnoDB: A server exit occurred after freeing large object
       (LOB) index entries during a LOB purge or rollback. (Bug
       #27419474)

     * InnoDB: In a function called before the execution of a
       statement in a stored procedure, a read and write
       operation on trx->lock.start_stmt was not protected by a
       mutex. (Bug #27325898)

     * InnoDB: The INFORMATION_SCHEMA.FILES and
       INFORMATION_SCHEMA.INNODB_TABLESPACES tables did not show
       the actual undo tablespaces that were present in the
       MySQL instance. Only the two default undo tablespaces
       were shown. (Bug #26820406)

     * InnoDB: An error occurred during a DDL operation due to a
       mismatch in a REDUNDANT row format calculation that
       determines the length of the online log. (Bug #26375771)

     * InnoDB: Enabling innodb_undo_log_truncate negatively
       affected transaction processing performance. Instead of
       performing two checkpoints during an undo tablespace
       truncate operation, pages that belong to the tablespace
       file are now flushed from disk. (Bug #26322656)

     * InnoDB: A helper class was introduced to improve
       performance associated with reading from secondary keys
       when there are multiple versions of the same row.
       Thanks to Domas Mituzas for the contribution. (Bug
       #25540277, Bug #84958)

     * InnoDB: The location of the Innodb Merge Temp File that
       reported by the wait/io/file/innodb/innodb_temp_file
       Performance Schema instrument was incorrect. (Bug
       #21339079, Bug #77519)

     * Partitioning: When a CREATE TABLE ... PARTITION BY ...
       statement failed due to an invalid partition definition,
       the server did not remove any partition files which might
       have been created prior to encountering the invalid
       PARTITION clause. (Bug #27798708)
       References: See also: Bug #88043, Bug #26945644.

     * Partitioning: It was possible to perform FLUSH TABLES FOR
       EXPORT on a partitioned table created with
       innodb_file_per_table=1 after discarding its tablespace.
       Attempting to do so now raises ER_TABLESPACE_DISCARDED.
       (Bug #95045, Bug #27903881)
       References: See also: Bug #80669, Bug #22899690.

     * Partitioning: An extraneous row lock was imposed by an
       update to a partitioned InnoDB table. (Bug #87253, Bug
       #26553164)

     * Replication: When a group member resumes after being
       suspended for some time and is not able to process all
       pending messages, it enters the ERROR state. However, the
       remaining members see it as UNREACHABLE, and wait until
       the member's suspicion expires to evict it from the
       group. The behavior has now been modified and a member
       stopping due to some error tries to connect to a known
       peer to request its removal from the group, before
       installing the leave view. (Bug #28252687)

     * Replication: When a replication slave is restarted by a
       START SLAVE statement, the columns in the Performance
       Schema table replication_applier_status_by_worker
       beginning APPLYING_TRANSACTION are now reset on a slave
       that is operating in single-threaded mode. These columns
       were always reset on a multi-threaded slave, because the
       existing worker threads were terminated by the statement
       and the information could not be retained. The behavior
       has now been standardized across the slave configurations
       by resetting the columns for a single-threaded slave as
       well. (Bug #28248026)

     * Replication: If Group Replication was started on server
       with an invalid group_replication_group_name, the server
       would stop unexpectedly. (Bug #28219136)

     * Replication: If a multi-threaded replication slave was
       stopped, changed to a single-threaded slave (by setting
       slave_parallel_workers > 0), and restarted, the
       Performance Schema table
       replication_applier_status_by_worker showed irrelevant
       timestamps because the old monitoring information had not
       been cleared. (Bug #28191382)

     * Replication: If the
       group_replication_recovery_retry_count variable was
       modified while the member was already making a
       reconnection attempt, the connection attempt could enter
       an infinite loop. (Bug #28092714)

     * Replication: When the binlog_group_commit_sync_delay
       system variable is set to a wait time to delay
       synchronization of transactions to disk, and the
       binlog_group_commit_sync_no_delay_count system variable
       is also set to a number of transactions, the MySQL server
       exits the wait procedure if the specified number of
       transactions is reached before the specified wait time is
       reached. The server manages this process by checking on
       the transaction count after a delta of one tenth of the
       time specified by binlog_group_commit_sync_delay has
       elapsed, then subtracting that interval from the
       remaining wait time.
       If rounding during calculation of the delta meant that
       the wait time was not a multiple of the delta, the final
       subtraction of the delta from the remaining wait time
       would cause the value to be negative, and therefore to
       wrap to the maximum wait time, making the commit hang.
       The data type for the remaining wait time has now been
       changed so that the value does not wrap in this
       situation, and the commit can proceed when the original
       wait time has elapsed. Thanks to Yan Huang for the
       contribution. (Bug #28091735, Bug #91055)

     * Replication: In debug builds, an assertion failed because
       more than 255 collations are now available in MySQL. (Bug
       #28015761)

     * Replication: An assertion was raised in debug builds
       because the MySQL server recorded a GTID consistency
       violation, but did not remove the record after the
       relevant statement failed to execute successfully. The
       handling of this situation has now been improved to
       ensure that the server checks at the end of a transaction
       whether a GTID consistency violation was produced by a
       failed statement, and if this is the case, restores the
       previous GTID consistency state. (Bug #27903831, Bug
       #90551)

     * Replication: The group_replication_exit_state_action
       variable enables you to specify what action is taken if a
       member involuntarily leaves the group, but when starting
       a server with group_replication_start_on_boot enabled the
       group_replication_exit_state_action variable was being
       ignored during the following scenarios:

          + valid number of group members was exceeded

          + incompatible configuration of the member system
            variables (various)

          + the joining member had more transactions than the
            group

          + the joining member's version was not compatible with
            the group
       (Bug #27881311)

     * Replication: With GTIDs in use for replication,
       transactions including statements that caused a parsing
       error (ER_PARSE_ERROR) could not be skipped manually by
       the recommended method of injecting an empty or
       replacement transaction with the same GTID. This action
       should result in the slave identifying the GTID as
       already used, and therefore skipping the unwanted
       transaction that shared its GTID. However, in the case of
       a parsing error, because the statement was parsed before
       the GTID was checked to see if it needed to be skipped,
       the replication applier thread stopped due to the parsing
       error, even though the intention was for the transaction
       to be skipped anyway.
       With this fix, the replication applier thread now ignores
       parsing errors if the transaction concerned needs to be
       skipped because the GTID was already used. Note that this
       behavior change does not apply in the case of workloads
       consisting of binary log output produced by mysqlbinlog.
       In that situation, there would be a risk that a
       transaction with a parsing error that immediately follows
       a skipped transaction would also be silently skipped,
       when it ought to raise an error. (Bug #27638268)

     * Replication: When a RESET SLAVE statement was issued on a
       replication slave with GTIDs in use, the existing relay
       log files were purged, but the replacement new relay log
       file was generated before the set of received GTIDs for
       the channel had been cleared. The former GTID set was
       therefore written to the new relay log file as the
       PREVIOUS_GTIDS event, causing a fatal error in
       replication stating that the slave had more GTIDs than
       the master, even though the gtid_executed set for both
       servers was empty. Now, when RESET SLAVE is issued, the
       set of received GTIDs is cleared before the new relay log
       file is generated, so that this situation does not occur.
       (Bug #27636289)

     * Replication: The master's receiver thread for
       semisynchronous replication held a mutex while reading
       acknowledgements from slaves, but the same mutex was
       required to add or remove a semisynchronous slave,
       causing those operations to be delayed by the
       acknowledgement activity. The issue has now been fixed by
       not acquiring the mutex to read the acknowledgements from
       slaves. (Bug #27610678, Bug #89370)

     * Replication: In code for replication slave reporting, a
       rare error situation raised an assertion in debug builds,
       but in release builds, returned leaving a mutex locked.
       The mutex is now unlocked before returning in this
       situation. Thanks to Zsolt Parragi for the patch. (Bug
       #27448019, Bug #89421)

     * Replication: Entries in the relay log info log (the
       slave_relay_log_info table) for the Group
       Replication-specific channels group_replication_applier
       and group_replication_recovery were not being cleared by
       a RESET SLAVE or RESET SLAVE ALL command. (Bug #27411175)

     * Replication: Automatic retrying of transactions on a
       replication slave, as specified by the
       slave_transaction_retries system variable, was taking
       place even if the transaction had a non-temporary error
       that would repeat on retrying or that indicated wider
       issues. Now, transactions are only automatically retried
       if there is either no error, or an error that is only
       temporary. (Bug #27373559, Bug #89143)

     * Replication: When FLUSH statements for specific log types
       (such as FLUSH SLOW LOGS) resulted in an error, the
       statements were still written to the binary log. This
       stopped replication because the error had occurred on the
       master, but did not occur on the slave. MySQL Server now
       checks on the outcome of these FLUSH statements, and if
       an error occurred, the statement is not written to the
       binary log. (Bug #24786290, Bug #83232)

     * Replication: The PASSWORD() function, which produces a
       hash of the password, was deprecated in MySQL 5.7 and
       removed in MySQL 8.0. When a SET PASSWORD statement that
       used this function was replicated from a MySQL 5.6 master
       to a MySQL 5.7 slave, or from a MySQL 5.7 master with the
       log_builtin_as_identified_by_password system variable set
       to ON to a MySQL 5.7 slave, the password hash was itself
       also hashed before being stored on the slave. The issue
       has now been fixed and the replicated password hash is
       stored as originally passed to the slave. (Bug #24687073)

     * Replication: If an ORDER BY clause was used in retrieving
       records from certain Performance Schema tables relating
       to replication, an empty set was returned. The issue has
       now been fixed. (Bug #22958077, Bug #80777)

     * Replication: When replication channels are used on a
       slave for multi-source replication, a START SLAVE
       statement that does not specify an individual channel (so
       without the FOR CHANNEL clause) should start the I/O
       thread and the SQL thread for all of the channels on the
       replication slave. However, if a RESET SLAVE statement
       was used on such a slave, a subsequent START SLAVE
       statement did not start the non-default channels. Now,
       replication channels that are deinitialized as a result
       of a RESET SLAVE statement, rather than as a result of an
       error in the initialization process, are identified and
       are restarted by a START SLAVE statement that applies to
       all channels. (Bug #22809607)

     * Replication: Issuing RESET SLAVE on a replication slave
       does not change any replication connection parameters
       such as master host, master port, master user, or master
       password, which are retained in memory. However, these
       connection parameters are reset if you issue RESET SLAVE
       ALL. Previously, if the slave mysqld was restarted
       immediately after issuing RESET SLAVE (including a server
       crash as well as a deliberate restart), the connection
       parameters were reset as if RESET SLAVE ALL had been
       used.
       Now, when master_info_repository=TABLE is set on the
       server (which is the default from MySQL 8.0), replication
       connection parameters are preserved in the crash-safe
       InnoDB table mysql.slave_master_info as part of the RESET
       SLAVE operation. They are also retained in memory. In the
       event of a server crash or deliberate restart after
       issuing RESET SLAVE but before issuing START SLAVE, the
       replication connection parameters are retrieved from the
       table and reused for the new connection.
       If master_info_repository=FILE is set on the server
       (which is the default in MySQL 5.7), replication
       connection parameters are only retained in memory, so the
       behavior remains the same as previously. If the slave
       mysqld is restarted due to a server crash or a deliberate
       restart immediately after issuing RESET SLAVE, the
       connection parameters are lost. In that case, you must
       issue a CHANGE MASTER TO statement after the server start
       to respecify the connection parameters before issuing
       START SLAVE.
       If you want to reset the connection parameters
       intentionally, you need to use RESET SLAVE ALL, which
       clears the connection parameters. In that case, you must
       issue a CHANGE MASTER TO statement after the server start
       to specify the new connection parameters. (Bug #20280946)

     * Replication: Compilation warnings related to unused
       functions in xdr_utils have been reduced. Thanks to Zsolt
       Parragi for the patch. (Bug #91071, Bug #28099963)

     * Replication: When group_replication_group_seeds contained
       a DNS based entry which resolved to its own local
       address, Group Replication could not start. (Bug #90483,
       Bug #27882096, Bug #28074929)

     * Replication: Issuing START GROUP_REPLICATION and then
       forcibly stopping the mysqld process, for example using
       control-C, could result in an unexpected halt of the
       server. (Bug #90457, Bug #27873419)

     * Microsoft Windows: An error now is written to the server
       log when the presence of the NO_AUTO_CREATE_USER value
       for the sql_mode option in the options file prevents a
       MySQL 8.0 server from starting. (Bug #28061945, Bug
       #90967)

     * Microsoft Windows: On Windows, uninstallation of the
       MySQL Server MSI package through MySQL Installer produced
       a spurious popup window. (Bug #27463864)

     * Microsoft Windows: On Windows, DBUG_ABORT did not print
       the custom stack trace and other information. (Bug
       #21383530)

     * JSON: The server did not reject creation of a table with
       a generated column in which the generated column used
       JSON_TABLE(), even though subqueries, parameters,
       variables, stored functions, and user-defined functions
       are not permitted in expressions for generated columns.
       The server now checks more aggressively to make sure any
       of the disallowed constructs (including JSON_TABLE()) are
       rejected for use in such expressions. (Bug #28518485)

     * JSON: SELECT ... FROM JSON_TABLE() sometimes failed with
       a permissions error for a user other than MySQL root.
       This issue could also occur when such a query was used as
       the basis for a view, and a SELECT from the view failed.
       (Bug #28255453, Bug #27923406)
       References: See also: Bug #27189940.

     * JSON: The JSON_TABLE() function subjected integer values
       greater than or equal to 2^31 to wraparound. For example,
       the query SELECT id FROM
       JSON_TABLE('[{"id":"2147483648"}]', '$[*]' COLUMNS (id
       BIGINT UNSIGNED PATH '$.id')) AS json returned
       -2147483648. (Bug #27856835)

     * JSON: In some contexts, the NULLIF() function returned
       its first argument as a boolean value rather than its
       actual type. This was noticed when the result of this
       function was used as an argument to JSON_ARRAYAGG() or
       JSON_OBJECTAGG(), but could have occurred in other cases
       in which NULLIF() was used in a similar fashion. (Bug
       #90833, Bug #28007237)

     * JSON: When a JSON document which contained binary data
       was converted to base-64 encoded text for display,
       newline characters in the encoded string were not
       properly escaped, so that the text representation could
       not be parsed as JSON, and was thus truncated, corrupted,
       or both. Now MySQL makes sure that any newline characters
       in the encoded string are escaped. (Bug #90503, Bug
       #27891359)

     * On the Fedora 29 platform, OpenSSL 1.0.x is used to build
       packages because 1.1.1 support is not ready. If you build
       MySQL from source, it is recommended that you build using
       the compat-openssl10-devel package. (Bug #28737143)

     * On the Fedora 29 platform, upgrading from MariaDB to
       MySQL 8.0.13 failed due to missing obsoletes. (Bug
       #28727698)

     * MySQL binary distributions for SLES 12 now are built
       using GCC 7. The lowest supported GCC version on this
       platform is now 5.3 (previously 4.8.5). (Bug #28542723)

     * Trying to add a functional index on a subquery should not
       be possible, and caused the server to hit an assertion
       when trying to resolve the indexed expression. Now in
       such cases, the expression is disallowed, and the servers
       returns an appropriate error message. (Bug #28526493)

     * Added a range check when performing calculations with
       exponents. (Bug #28505423)

     * CMAKE -DWITHOUT_SERVER=1 resulted in build errors. (Bug
       #28501563, Bug #92011)

     * When a prefix index was specified with a length of 8
       bytes, the Sub_part column in the output of SHOW INDEXES
       was NULL. (Bug #28499603)

     * Compilation failed for GCC 8 with MySQL configured to use
       some system libraries. (Bug #28471072, Bug #91914)

     * For debug builds, if the server bootstrapping phase
       failed, missing cleanup code caused an assertion to be
       raised. (Bug #28435378, Bug #91847)

     * Numeric ranges in MySQL builds could differ between the
       ARM and Intel x64 platforms. (Bug #28401869)

     * For mysqldump --tables output, file names now always
       include a .txt or .sql suffix, even for file names that
       already contain a dot. Thanks to Facebook for the
       contribution. (Bug #28380961, Bug #91745)

     * Concurrent INSERT and SELECT statements on a MERGE table
       could result in a server exit. (Bug #28379285)

     * On SLES 15, upgrading from MariaDB packages to MySQL
       packages failed due to incorrect obsoletes information.
       (Bug #28292138)

     * The data dictionary auto releaser now allocates maps for
       data dictionary object types dynamically. Also, maps were
       added for column statistics and resource groups used in
       size calculations and object removal, and an auto
       releaser was added for ANALYZE TABLE operations. (Bug
       #28245522, Bug #91420)

     * It was possible for a UNION query that mixed different
       character sets to fail with a spurious error. (Bug
       #28237675)
       References: This issue is a regression of: Bug #83895,
       Bug #25123839.

     * CHECK TABLE ... FOR UPGRADE on temporary tables could
       raise an assertion. (Bug #28220374)
       References: This issue is a regression of: Bug #24741307.

     * A divide-by-zero error could occur in the range
       optimizer. (Bug #28214186)

     * Due to a GCC 8 bug, recursion in foreign key checks could
       exhaust stack space. (Bug #28200774)

     * When sql_mode was set to the empty string, queries of the
       form SELECT CONCAT( FORMAT(LPAD(char,2,''), 1) ) were not
       handled properly; the same was also true for
       similarly-formed queries using RPAD() in place of LPAD().
       (Bug #28197977)

     * Non-privileged users could change their own account
       password history and reuse properties. (Bug #28191838)

     * The OpenSSL 1.1 OPENSSL_malloc_init() call did not work
       well on Windows. To address this, alternative allocation
       wrappers are used instead of the defaults from OpenSSL.
       Consequently, OpenSSL memory instrumentation is turned
       off. (Bug #28179051)

     * Allocation of certain object types during data dictionary
       lookups resulted in a stack buffer overflow. (Bug
       #28176453)

     * An internal server operation that attempted to perform a
       commit while fetching table statistics from the
       INFORMATION_SCHEMA could raise an assertion. (Bug
       #28165060)

     * Certain stored procedures could cause a server exit. (Bug
       #28156802)

     * Output for CREATE USER statements could differ in the
       general query log and audit log. (Bug #28147710)

     * For UPDATE and DELETE statements that produce an error
       due to sql_safe_updates being enabled, the error message
       was insufficiently informative. The message now includes
       the first diagnostic that was produced, to provide
       information about the reason for failure. For example,
       the message may indicate that the
       range_optimizer_max_mem_size value was exceeded or type
       conversion occurred, either of which can preclude use of
       an index.
       Additionally: (1) Using EXPLAIN for such statements does
       not produce an error, enabling users to see from EXPLAIN
       plus SHOW WARNINGS output why an index is not used. (2)
       For multiple-table deletes and updates, an error is
       produced with safe updates enabled only if any target
       table uses a table scan. (Bug #28145710, Bug #91080)

     * MySQL Server and test RPM packages were missing
       perl-Data-Dumper as a dependency. (Bug #28144933, Bug
       #72926)

     * Server startup could fail if a service needed by a
       component was not yet initialized. (Bug #28142250)

     * SHOW CREATE TABLE could omit foreign key RESTRICT
       options. This in turn could cause foreign key RESTRICT
       options to be lost from tables dumped with mysqldump and
       restored from the dump file. (Bug #28122781, Bug #91110)

     * The mysql client was slow to import large multiple-line
       statements in batch mode. Memory allocation is now more
       efficient for this situation. Thanks to Sinisa
       Milivojevic for the patch. (Bug #28116512, Bug #85155)

     * The SUM() and AVG() functions did not handle correctly a
       string argument used with a window function. (Bug
       #28105241)

     * Excessive nesting of geometry collections caused the
       server to exhaust stack space. The server now raises an
       error if there is a danger of stack overrun. (Bug
       #28100563)

     * For the mysql client, the -b short option was associated
       with two long options, --no-beep and --binary-as-hex. The
       -b option now is associated only with --no-beep. (Bug
       #28093271)

     * For a table with an auto-increment primary key,
       concurrent ALTER TABLE ... ADD ... VIRTUAL and INSERT
       statements could lead to duplicate-key errors. (Bug
       #28089240)

     * Handling of floating-point values by SUM() was improved.
       (Bug #28080199)

     * Some expressions using ST_Simplify() could cause a server
       exit. (Bug #28079969)

     * Testing on a UBSan-enabled build returned a "member call
       on null pointer of type 'struct Event_db_repository'"
       error. (Bug #28066155)

     * The WITH_GMOCK CMake option did not handle Windows path
       names properly. (Bug #28061409, Bug #90964)

     * INFORMATION_SCHEMA queries that attempted to cache table
       statistics could raise a debugging assertion. (Bug
       #28035207)

     * If roles were assigned to accounts, certain sql_mode
       settings could cause the server to be unable to start.
       (Bug #28030423)

     * Group lookups for LDAP authentication plugins could fail
       if the user had insufficient privileges. Now, group
       search operations bind again using root credentials if
       those are available. (Bug #28016008)

     * ANALYZE TABLE ... UPDATE HISTOGRAM statements produced by
       mysqldump contained a syntax error. (Bug #28014376, Bug
       #90846)

     * Generated columns having indexes and that used a string
       function were not always populated correctly. (Bug
       #27973409)

     * Fixed-length sort keys, such as those used by priority
       queues, that fit exactly were assumed to have failed.
       (Bug #27970481, Bug #92448, Bug #28654343)

     * For an empty result, REPLACE() sometimes returned a null
       string rather than an empty string. (Bug #27960921)

     * Dropping a table that was created with a user-defined
       collation no longer available could cause a server exit.
       (Bug #27952999)

     * Joining the INFORMATION_SCHEMA REFERENTIAL_CONSTRAINTS
       and TABLE_CONSTRAINTS tables on the CONSTRAINT_NAME
       failed because the column collations differed. (Bug
       #27945704, Bug #90690)

     * Some operations on DECIMAL values could cause a server
       exit. (Bug #27942277)

     * Stored program definitions in mysqldump dump files
       sometimes included the NO_AUTO_CREATE_USER SQL mode.
       Because that mode has been removed in MySQL 8.0, loading
       such a dump file into a MySQL 8.0 server failed.
       mysqldump now removes NO_AUTO_CREATE_USER from the
       definition of dumped stored programs. (Bug #27931181, Bug
       #90624)

     * Very long table keys were handled incorrectly on
       replication slaves. (Bug #27930505)

     * mysqld did not determine its installation directory
       correctly if that directory was the last one listed in
       $PATH. (Bug #27922896)

     * During server startup/shutdown, PID files could be
       mishandled. (Bug #27919254)

     * On rare occasions, setting a savepoint could raise an
       assertion. (Bug #27898591)

     * Runtime errors could occur for calls to copy_integer().
       myfunc_int(), mysql_sys_var_int(), or thd_killed(); for
       calls to MyISAM sorting functions; or for values outside
       the range of representable values of type unsigned long
       long. (Bug #27894901, Bug #90515, Bug #27871951, Bug
       #27918095, Bug #90609, Bug #27937522, Bug #90661, Bug
       #27978325, Bug #27962900)

     * mysql_install_plugin failed to report plugin-specific
       errors if the server was unable to store plugin metadata
       in the data dictionary. (Bug #27893406)

     * ssl_fips_mode cannot be set to ON unless the OpenSSL
       requirements are satisfied, but a failed attempt still
       resulted in the value being displayed as ON. (Bug
       #27891890)

     * The symbol for the mysql_result_metadata() C API function
       was not exported by the client library on Windows. (Bug
       #27868095)

     * For InnoDB tables, self-referencing foreign keys could be
       created, causing server misbehavior. (Bug #27864515)

     * A UNION query mixing different character sets produced
       invalid output when performed in a prepared statement or
       a stored procedure. (Bug #27849293)

     * Debian packages were missing a dependency for
       libcurl-dev. (Bug #27844465)

     * --help output for client programs did not include the
       current --ssl-fips-mode value. (Bug #27838966)

     * A runtime error could occur for calls to
       Derived_key_comp(). (Bug #27830679)

     * For MEMORY tables, memory overflow errors could occur.
       (Bug #27799513)

     * When converting from a BLOB (or TEXT) type to a smaller
       BLOB (or TEXT) type, no warning or error was reported
       informing about the truncation or data loss. Now an
       appropriate error is issued in strict SQL mode and a
       warning in nonstrict SQL mode. (Bug #27788685, Bug
       #90266)

     * For debug builds, my_strnxfrm_unicode_full_bin() could
       raise an assertion. (Bug #27752619)

     * In builds with Undefined Behavior Sanitizer enabled,
       signed integer overflow could occur in GIS calculations.
       (Bug #27751479, Bug #27744399, Bug #27811282)

     * It was possible in some cases for the internal function
       regexp::EvalExprToCharset() to bind a reference to a
       misaligned address. (Bug #27743722)

     * The severity of messages produced by the server about
       being unable to read key files has been escalated from
       INFORMATION to WARNING. (Bug #27737195)

     * No temporary table field was created for an expression
       using window functions combined with a rollup, causing
       queries containing these to fail. (Bug #27735167)

     * The expression FIND_IN_SET( JSON_UNQUOTE(
       JSON_SET('{}','$','') ), 1) was not evaluated properly.
       (Bug #27731699)

     * Failure to create a temporary table during a MyISAM query
       could cause a server exit. Thanks to Facebook for the
       patch. (Bug #27724519, Bug #90145)

     * parser_max_mem_size was ineffective when parsing stored
       program definitions. (Bug #27714748)

     * A BETWEEN clause comparing negative values could lead to
       erroneous results. (Bug #27691347)

     * These scripts are no longer included in RPM packages
       (they are unnecessary because they are compiled into the
       mysqld binary): fill_help_tables.sql,
       mysql_sys_schema.sql, mysql_system_tables.sql,
       mysql_system_tables_data.sql, mysql_system_users.sql.
       (Bug #27672991)

     * Unique::io_cache was not cleaned up properly when
       restarting an index merge operation, leading to an
       assertion in debug builds. (Bug #27599292)

     * Using a binary or hexadecimal literal value in a ENUM
       column resulted in a string type with bytes not permitted
       by the data dictionary character set. (Bug #27592803)

     * It was possible for CONVERT() to fail under the following
       conditions:
       The size of the result of the conversion was greater than
       max_allowed_packet
       sql_mode was '' (that is, empty).
       The character set of the result differed from
       character_set_connection (Bug #27592714)

     * Use of ENUM or SET fields with JSON_TABLE() could result
       in unexpected behavior. (Bug #27571251)

     * Host name resolution errors could cause the audit_log
       plugin to fail. (Bug #27567003)

     * Unsuccessful connection attempts were not being written
       to the error log when log_error_verbosity=3. (Bug
       #27539838)

     * Persisted system variables with a value of NULL were
       written to mysqld-auto.cnf incorrectly. (Bug #27512616)

     * An earlier code cleanup caused FEDERATED storage engine
       failures. (Bug #27493633, Bug #89537)
       References: This issue is a regression of: Bug #25943754.

     * Setting max_execution_time sometimes had no effect when
       used with full-text search. (Bug #27155294)

     * An attempted read of an uncommitted transaction raised an
       assertion. (Bug #26876608)

     * ALTER TABLE ... REORGANIZE PARTITION ... could result in
       incorrect behavior if any partition other than the last
       was missing the VALUES LESS THAN part of the syntax. (Bug
       #26791931)

     * In some cases when ER_DATA_TOO_LONG was the appropriate
       error, ER_TRUNCATED_WRONG_VALUE_FOR_FIELD was reported
       instead. (Bug #26475237, Bug #87100)

     * A last_checked_for_upgrade column that stores the current
       server version number was added to the mysql.tables data
       dictionary table to track successful CHECK TABLE ... FOR
       UPGRADE operations. This data was previously stored in
       .frm files to avoid rechecking tables unnecessarily. (Bug
       #24741307, Bug #83169)

     * A range check for the product of a signed and unsigned
       integer could be performed incorrectly. (Bug #17081376,
       Bug #69715)

     * Specifying the maximum possible value for a YEAR column
       failed when expressed as a real constant such as
       2155.0E00 or 2.15E3. (Bug #91226, Bug #28172538)

     * Prevented potential member access within a null pointer
       of type SELECT_LEX. (Bug #90689, Bug #27945614)

     * The base used for calculation of line numbers reported in
       warnings generated by SELECT statements has been changed
       from the number of input rows read to the actual row
       numbers seen by the user. For statements using GROUP BY,
       this number is now based on the number of aggregate
       groupings. (Bug #90667, Bug #27938507)

     * Estimates contained by histograms for the number of
       distinct values in each bucket, which can be employed to
       estimate the number of distinct values in a table, can
       now be used by the Optimizer's histograms::Histogram
       interface. (Bug #90465, Bug #27872281)

     * Selecting from the INFORMATION_SCHEMA.KEYWORDS table
       failed when no default database had been selected. (Bug
       #90160, Bug #27729859)

     * ANALYZE TABLE UPDATE HISTOGRAM failed to return an error
       condition to the client when lock_wait_timeout was
       exceeded during statement processing. (Bug #89738, Bug
       #27574375)

     * It was possible to create a table t having a generated
       column g and then to execute ALTER TABLE t ALTER COLUMN g
       SET DEFAULT ...; attempting to set the default for a
       generated column in this fashion now fails with Error
       1221 Incorrect usage of DEFAULT and generated column.
       This is the same behavior as for a similar CREATE TABLE
       statement. (Bug #88619, Bug #27164393)

Changes in MySQL Enterprise Backup 8.0.13 (2018-10-22)


     * Functionality Added or Changed

     * Bugs Fixed

Functionality Added or Changed


     * mysqlbackup now supports backup compression (the use of
       the --compress and --uncompress options) for incremental
       backups (except for incremental backups created with the
       --incremental-with-redo-log-only option).

     * mysqlbackup now supports transparent page compression for
       InnoDB tables. The support is enabled by setting the
       mysqlbackup option --compress-method=punch-hole; see
       description for the option for details.

Bugs Fixed


     * mysqlbackup hung when a backup operation failed due to a
       full disk. With this fix, mysqlbackup quits gracefully in
       the situation by throwing an error. (Bug #28399821)

     * A mysqlbackup operation on an image stored on an
       OpenStack cloud storage service sometimes failed with a
       segmentation fault or a bad URL error. It was because of
       a race condition caused by an uninitiated variable, which
       has been eliminated by this fix. (Bug #28189239, Bug
       #28183729)

     * Backups for databases with encrypted InnoDB tables failed
       when the --compress option was used. (Bug #28177466)

     * A mysqlbackup operation on an image stored on an
       OpenStack cloud storage service failed with a 401
       Unauthorized error when the operation took a long time
       and the authentication token for the cloud access
       expired. With this fix, a separate thread in mysqlbackup
       requests a new token from the OpenStack cloud service in
       that situation, so that the operation can continue. (Bug
       #27893174)

     * When an incremental backup was restored without using the
       --log-bin option, the binary log was not restored to its
       original location on the backed up server, but to the
       location specified by --log-bin earlier during the
       restore of the base backup. The same occurred for relay
       logs of incremental backups for slaves when the
       --relay-log option was not used. (Bug #27545745)

Changes in MySQL Router 8.0.13 (2018-10-22)


     * Functionality Added or Changed

     * Bugs Fixed

Functionality Added or Changed


     * To align package names with MySQL Server, the community
       package name prefix changed from "mysql-router-" to
       "mysql-router-community-". This change also allows
       upgrading from MySQL Router 2.1 to 8.0. Additionally, a
       "mysql-router" meta package was added that redirects
       "mysql-router" to "mysql-router-community".

Bugs Fixed


     * For SLES 12, MySQL binary distributions are now built
       using GCC 7. The lowest supported GCC version on this
       platform is now 5.3 (previously 4.8.5).
       Installing MySQL Router 8.0.13 or higher RPM packages on
       SLES 12 platforms requires that the GCC Devel repo is
       enabled, for example:
shell> cd /etc/zypp/repos.d/
shell> wget https://download.opensuse.org/repositories/devel:/gcc/SLE-12/devel:gcc.repo
...
shell> zypper install ./mysql-router-community-8.0.*rpm

       (Bug #28685857)
       References: See also: Bug #92147.

     * The log level was changed from INFO to DEBUG for the
       InnoDB cluster Metadata server and replicaset
       connections. Because MySQL Router's ttl configuration
       option defaults to 0.1, these each generate 10 log
       entries per second. (Bug #28424243)

     * Running MySQL Router against an invalid InnoDB cluster
       would report internal SQL errors, such as "Unknown
       database 'mysql_innodb_cluster_metadata'", rather than
       user-friendly information that the cluster is not set up
       as a metadata server. The generated error now clarifies
       the reason and points to related documentation. (Bug
       #28292073)

     * The --version output was aligned across all binaries to
       include license related text. (Bug #28262453)

     * On Windows, starting Router after uninstalling the Router
       service would cause Router to hang as it assumed the
       service was still enabled. (Bug #28261217)

     * Passing in --directory to an unwritable empty directory
       would yield a generic error. (Bug #28228800)

     * The error code ER_CON_COUNT_ERROR is now used instead of
       HY000 ("unknown") when the maximum number of allowed
       connections is exceeded. (Bug #28183810)

     * The metadata version
       (mysql_innodb_cluster_metadata.schema_version)
       compatibility check is now checked at runtime, when
       before it only happened during the bootstrap process.
       (Bug #28147601)

     * Bootstraping with --user set to the same user running the
       bootstrap operation would halt with a "setegid failed"
       error. (Bug #27698052)

     * An error related to running out of available threads was
       only logged once until Router was restarted. (Bug
       #27577694)

     * MySQL Router is now included in MySQL Server's source and
       monolithic binary packages. The MySQL Router standalone
       packages continue to exist, as before.

Dear MySQL users,

MySQL Shell 8.0.13 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.13.

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.13, see
the "Generally Available (GA) Releases" tab at http://dev.mysql.com/downloads/shell/

We welcome and appreciate your feedback and bug reports, see
http://bugs.mysql.com/

Enjoy!
==================================================
Changes in MySQL Shell 8.0.13    (2018-10-22)

Functionality Added or Changed

     * The upgrade checker utility provided by MySQL Shell,
       which is the checkForServerUpgrade() function of the util
       global object, has several enhancements:

          + You can now use the upgrade checker utility to check
            servers at earlier MySQL 8.0.x releases, as well as
            MySQL 5.7 servers, for compatibility errors and
            issues for upgrading.

          + You can now specify a target MySQL Server version to
            which you plan to upgrade. In MySQL Shell 8.0.13,
            you can specify release 8.0.11 (the MySQL Server 8.0
            GA release), 8.0.12, or 8.0.13. The upgrade checker
            utility carries out the checks that are relevant for
            the specified target release. If you specify the
            short form version number 8.0, or omit the
            targetVersion option, the utility checks for upgrade
            to the MySQL Server release number that matches the
            current MySQL Shell release number, currently
            8.0.13.

          + A check has been added for the removed syntax GROUP
            BY ASC/DESC, returning an error message if this
            syntax is found in a trigger, event, view, stored
            procedure, or function.

          + A check has been added for columns defined as ENUM
            or SET that contain elements longer than 255
            characters, returning an error message if any such
            columns are found.

          + The upgrade checker utility no longer returns a
            value, making its output easier to parse and process
            when automation is used.

       You can access the upgrade checker utility from within
       MySQL Shell or start it from the command line. For
       instructions and further information, see MySQL Shell
       Utilities
       (http://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-
        shell-utilities.html).

     * The behavior of Cluster.dissolve() has been updated to
       make it more consistent with other AdminAPI commands. Now
       you do not have to pass in the force option to start the
       command, and there is an interactive prompt available.
       When all instances belonging to the cluster are online,
       if MySQL Shell is running in interactive mode then you
       are prompted to confirm the operation of dissolving the
       cluster. If MySQL Shell is running in non-interactive
       mode, when all instances are reachable, or online, then
       the command removes the instances from the cluster. In
       the case that instances are not reachable an error is
       thrown. Pass in the force option to remove instances
       which are not reachable.
       References: See also: Bug #27833605, Bug #27837231.

     * MySQL Shell onscreen output can now be displayed using a
       pager such as less or more. You can configure the pager
       you want to use with the shell.options[pager] option, the
       \pager command, or the --pager command option. This
       improves how you work with longer text output in MySQL
       Shell, specifically the online help and the results of
       SQL operations. See Using a Pager
       (http://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-
        shell-using-pager.html).

     * The integration of MySQL Shell into command-line
       environments has been improved. Use the mysqlsh [options]
       -- shell_object object_method [method_arguments] syntax
       to pass operations directly to MySQL Shell global
       objects, bypassing the REPL interface. For example:
       mysqlsh -- util check-for-server-upgrade user@example
       --output-format=JSON

       which executes the equivalent
       util.checkForServerUpgrade(user@example, {"outputFormat":
       "JSON"}) with MySQL Shell and returns the output in JSON
       format. This makes it easy to integrate MySQL Shell into
       your automation scripts. To get help for this interface,
       use the MySQL Shell command \help cmdline. See mysqlsh
       Command Interface
       (http://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-
        command-interface.html).

     * A new optional parameter exitStateAction can be used with
       the dba.createCluster() and cluster.addInstance()
       commands, which enables you to configure the
       group_replication_exit_state_action variable of an InnoDB
       cluster member. The group_replication_exit_state_action
       variable enables you to specify what action is taken if a
       member involuntarily leaves the group. When
       group_replication_exit_state_action is set to
       ABORT_SERVER (the default value), the instance shuts
       itself down, and when group_replication_exit_state_action
       is set to READ_ONLY the instance switches itself to super
       read only mode instead and goes into the Group
       Replication ERROR state.

     * The new optional memberWeight option can be used with the
       dba.createCluster() and Cluster.addInstance() functions
       to enable you to set the group_replication_member_weight
       system variable of an InnoDB cluster server instances in
       a single-primary cluster. The default value is 50, in
       other words the system variable default. Set the
       memberWeight option to an integer between 0 and 100 to
       configure a member's weight in the failover election
       process. The value determines the chance of the instance
       being elected as the primary in the event of a failover.
       See Single-Primary Mode
       (http://dev.mysql.com/doc/refman/8.0/en/group-replication
        -single-primary-mode.html) for more information.

     * The connect-timeout connection path parameter
       (https://dev.mysql.com/doc/refman/en/connecting-using-pat
       h.html) has been added to the X DevAPI, which enables you
       to specify the number of seconds clients such as MySQL
       Shell wait until the client stops trying to connect to an
       unresponsive MySQL server. The value of connect-timeout
       must be a non-negative integer that defines a time frame
       in milliseconds. The timeout default value is 10000
       milliseconds, or 10 seconds. For example:
       // Decrease the timeout to 2 seconds.
       mysqlx.getSession('user@example.com?connect-timeout=2000');

       // Increase the timeout to 20 seconds
       mysqlx.getSession('user@example.com?connect-timeout=20000');

       To disable the timeout set the value to 0, meaning that
       the client waits until the underlying socket times out,
       which is platform dependent.

     * MySQL Shell has a new JSON import utility that enables
       you to import JSON documents from a file or standard
       input to a MySQL Server collection or relational table.
       The utility parses and validates the supplied JSON
       documents automatically and inserts them into the target
       database, removing the need to use multiple INSERT
       statements or write scripts to achieve this task. The
       utility can be started in a MySQL Shell session with the
       util.importJson() method in JavaScript or the
       util.import_json() method in Python. From the command
       line, you can use the -- util importJson syntax or the
       --import command to invoke the utility.

Bugs Fixed

     * The upgrade checker utility provided by MySQL Shell (the
       util.checkForServerUpgrade() operation) did not report
       removed functions if they were used in views or events.
       (Bug #28642534)

     * MySQL Shell incorrectly labeled warning messages as error
       messages in JSON output. (Bug #28546510)

     * When MySQL Shell server connection passwords are
       persisted using a Secret Store, if a classic MySQL
       protocol connection was made without specifying a port or
       socket, the saved password could not be retrieved for a
       subsequent connection. The password storage and retrieval
       process now ensures that the server URL used to store the
       password matches subsequent queries with user-provided
       connection options, even if defaults were used for the
       original connection. (Bug #28544628)

     * The dba.deploySandboxInstance() function in version
       8.0.12 deploys the sandbox and includes log_syslog=OFF in
       the instance's configuration file. This variable was
       deprecated in MySQL 8.0.12 and was removed in MySQL
       8.0.13. Now, the variable has been updated to include the
       loose_ prefix which makes the server ignore it for a
       MySQL 8.0.13 sandbox, while maintaining compatibility
       with earlier version sandboxes. (Bug #28543536)

     * A number of improvements have been made to the MySQL
       Shell prompt, including handling of overlength text,
       statement splitting, and support for multiple-line
       prompts. New sample prompt theme files are provided for
       double-line prompts that use one line for information
       display and a new line for the input prompt itself, so
       that additional information can be shown without
       detracting from the space available for text entry. (Bug
       #28515394, Bug #92048)

     * The --table command line option did not produce the
       appropriate output format in non-interactive mode. (Bug
       #28511408)

     * Extra spaces before or after the parameter used with the
       \help command are now trimmed. Previously, the presence
       of extra spaces made MySQL Shell unable to find the
       relevant help topic. (Bug #28508724, Bug #92030)

     * Some native MySQL Shell objects were not properly wrapped
       into JavaScript objects, causing memory leaks. The
       memory-handling mechanism has been corrected. (Bug
       #28473341)

     * If an empty string was provided as the argument for a
       MySQL Shell command-line option that expects a non-null
       argument and has no default defined, MySQL Shell did not
       return an appropriate error. The error handling for
       command-line arguments has now been improved so that a
       suitable error is issued in this situation and execution
       of the command terminates. (Bug #28378553)

     * If a session was explicitly closed by the user without
       closing MySQL Shell, the prompt continued to display the
       details of the closed session. (Bug #28314383)

     * User credentials stored by MySQL Shell could not be
       automatically retrieved for hosts identified by IPv6
       addresses. (Bug #28261301)

     * MySQL Shell now displays the build type (commercial or
       Community Edition) as part of the product version
       information displayed at startup and when the --help
       argument is used. (Bug #28242573)

     * If a MySQL Shell session was disconnected without closing
       MySQL Shell (for example, using the session.close()
       method), a subsequent query in SQL mode did not return a
       "Not connected" error. MySQL Shell now checks not only
       that the global session object exists, but also that it
       has a valid connection to the MySQL server instance. (Bug
       #28240437)

     * On the Windows platform, the background color was not
       reset in the MySQL Shell window when the terminal was
       cleared using Ctrl+L. (Bug #28235701, Bug #91102)

     * The commercial MySQL Shell package could not be installed
       on Debian or Ubuntu if the equivalent Community Edition
       package had already been installed. (Bug #28223781)

     * Occasionally, when adding an instance to an existing
       cluster the instance got stuck in the distributed
       recovery phase resulting in an immutable reported status
       of RECOVERING. This issue was related to the
       automatically generated password for the internal
       replication users created by InnoDB cluster. (Bug
       #28219398, Bug #91348)

     * MySQL Shell was using some deprecated functions and
       properties internally, which caused warning messages to
       appear in the MySQL Shell log file, although the
       functions were not executed by users. The deprecated
       functions and properties have now been removed from the
       internal code. (Bug #28216558)

     * If an invalid value was specified for the MySQL Shell
       option credentialStore.helper, the resulting error
       message at MySQL Shell startup was displayed incorrectly.
       (Bug #28216485)

     * The upgrade checker utility provided by MySQL Shell (the
       util.checkForServerUpgrade() operation) now correctly
       handles account names with spaces and other blank
       characters, and skips the permissions check when the
       server was started with the --skip-grants option. (Bug
       #28212899, Bug #91326)

     * In the default interactive mode, whenever using the
       function dba.rebootClusterFromCompleteOutage() without
       any parameter, the function failed with an error
       specifying the cluster name does not exist. Now the
       default cluster is assumed when the function is issued
       without a parameter. (Bug #28207565)

     * The handling of metadata server changes related to the
       Cluster.addInstance() has been improved, resulting in the
       following changes:

          + the correct session is now used for metadata and
            group operations

          + the Cluster.addInstance() operation aborts and
            recommends the use of Cluster.rescan() if the
            instance is in the group but not the InnoDB cluster
            metadata

          + the unnecessary parameter super_user_password has
            been removed
       (Bug #28200661)

     * The Windows scripts generated by
       dba.deploySandboxInstance() incorrectly displayed user
       output messages in quotes. Additionally, the scripts have
       been improved and they no longer display executed
       commands. (Bug #28199954)

     * When deleting history entries using the \history command
       in MySQL Shell, you can now specify a number of history
       entries to be deleted from the tail of the history, using
       the format \history delete -number. The handling of
       history entry numbers for deleted entries has been
       improved so that when the tail of the history is deleted,
       those history entry numbers are reused for new entries,
       and there is no gap. If a \history delete command empties
       the history, the numbering of history entries now resets
       as it does when the \history clear command is used. Also,
       the error message issued if you specify an invalid range
       of history entries to be deleted (using the format
       \history delete firstnumber-lastnumber ) has been
       improved. (Bug #28199513)

     * The dba.createCluster() AdminAPI operation always created
       replication users, even when the adoptFromGR option was
       used. However, when adopting an already existing Group
       Replication group no additional users need to be created.
       (Bug #28054500)

     * On the Windows platform, using the Ctrl+C key combination
       in MySQL Shell caused MySQL Shell to close, even if a
       command was in progress. (Bug #27894642)

     * Error messages issued by the AdminAPI relating to an
       invalid number of arguments for a function did not
       include the relevant object and method prior to the
       message text. These messages have now been standardized.
       (Bug #27832594)

     * The MySQL Shell code for identifying whether a given IP
       address is a loopback address did not account for
       additional IP addresses (besides the 127.0.0.0/8 address
       block) that had been added by the user to the loopback
       interface. All IP addresses assigned to the loopback
       interface are now checked. (Bug #27703779)

     * When running MySQL Shell in batch mode, tab separated
       format is the default for output. In some situations,
       table format was used for output instead. This issue has
       now been fixed. A command line option --tabbed has also
       been added to switch to the tab separated format for
       output when MySQL Shell is in interactive mode, where the
       default is table format. (Bug #27546082, Bug #89514)

     * Zone IDs in IPv6 addresses are now supported for MySQL
       Shell connections. A zone identifier is suffixed to the
       IPv6 address with a percent character (%) as a separator.
       For example: 2001:0db8:3c4d:0015::1a2f:1a2b%14
       If an IPv6 address with a zone ID is provided as a URI
       type string, URL encoding (percent-encoding) must be used
       for the percent character. For example:
       mysqlsh --uri=user@[2001:0db8:3c4d:0015::1a2f:1a2b%2514]
       :33060 shell.connect("user@[2001:0db8:3c4d:0015::1a2f:
       1a2b%2514]:33060")
       If an IPv6 address with a zone ID is provided using
       individual parameters or a data dictionary, URL encoding
       does not need to be used for the percent character, and
       the IPv6 address can be supplied as seen. For example:
       mysqlsh --user=user --host=2001:0db8:3c4d:0015::1a2f:
       1a2b%14 --port=33060
       See Connecting Using a Path
       (http://dev.mysql.com/doc/refman/8.0/en/connecting-
        using-path.html). (Bug #27539702)

     * When MySQL Shell log entries were output to stderr by
       prepending @ (at sign) to the value of the --log-level
       option, and the JSON output format was selected for MySQL
       Shell, some log entries were not being output in JSON
       format. The logger now checks and uses the current value
       of the MySQL Shell outputFormat configuration option as
       the output format when writing log entries to stderr.
       (Bug #27480887)

     * In SQL mode, MySQL Shell erroneously entered multi-line
       mode if an unknown command was executed, or if multiple
       consecutive SQL statement delimiters were used. Now, an
       appropriate error is returned in these situations. (Bug
       #27411526)

     * If you do not specify a protocol with the \connect
       command or when starting MySQL Shell, MySQL Shell
       automatically attempts to use X Protocol for the
       session's connection, and falls back to MySQL protocol if
       X Protocol is unavailable. The connection type option
       -ma, which specified that behavior explicitly, is now
       deprecated.
       The use of a single dash with the connection type options
       -mx and -mc, for an X Protocol and MySQL protocol
       connection respectively, is also deprecated. These
       options must now be specified with a double dash (that
       is, --mx and --mc) with the \connect command or when
       starting MySQL Shell. They are now defined as aliases of
       the long form --mysql (--mc) and --mysqlx (--mx)
       connection type options. (Bug #27363459)

     * When using dba.createCluster() or Cluster.addInstance(),
       the AdminAPI was setting the values of
       auto_increment_offset and auto_increment_increment
       incorrectly. Now the variables are set according to the
       following logic:

          + for a cluster running in single-primary mode:
               o auto_increment_offset=2
               o auto_increment_increment=1

          + for a cluster running in multi-primary mode:
               o auto_increment_offset=1 and server_id % 7
               o auto_increment_increment=7
       (Bug #27084767)

     * On the Windows platform, when a long command was accessed
       from the MySQL Shell command history and edited at the
       right edge of the console window, a cursor positioning
       error caused the command to move up one line and
       overwrite the output of previous commands. The issue has
       now been fixed. (Bug #27068352)

     * The mysqlsh command-line options --dbpassword[=password]
       and --dbuser=user_name are now deprecated. Use the
       options --password (-p) and --user (-u) instead. (Bug
       #26049681)

     * AdminAPI was using the incorrect terms for Group
       Replication. Now clusters are described as single-primary
       and multi-primary, the multiMaster option has been
       deprecated, and the multiPrimary option has been added.
       (Bug #25926603)

     * The result printer in MySQL Shell was refactored to
       improve handling of binary data based on the output
       format, handling of multi-byte characters, and alignment
       of table formatting when multi-line characters are
       present. (Bug #24912154, Bug #24967872)

     * The result of calling dba.get_cluster().status() when
       quorum was lost could not be converted to a JSON object,
       because the string representation of the resultant object
       contained escape sequences. This issue was not limited to
       the Cluster.status() method, but affected all arrays and
       dictionaries returned by the Shell API in Python mode.
       The internal representation of arrays and dictionaries
       has been fixed. (Bug #91304, Bug #28200499)

On Behalf of MySQL Release Engineering team,
-Sreedhar S 

Dear MySQL users,

MySQL Connector/Python 8.0.13 is the third GA release version of the
MySQL Connector Python 8.0 series. This series adds support for Python
3.7.  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.

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.13, see the "General Available
(GA) releases" tab at http://dev.mysql.com/downloads/connector/python/

Enjoy!

Changes in MySQL Connector/Python 8.0.13 (2018-10-22, General Availability)


Functionality Added or Changed


     * Added Python 3.7 support. (Bug #27081809, Bug #87818)

     * To go with the existing mysqlx.get_session(conn_str)
       method, a new mysqlx.get_client(conn_str, options) method was
       added that creates a connection pool handler that provides a
       get_session() method to create and retrieve connections from the
       pool. The collection pooling options are:

          + enabled: enables or disables connection pooling;
            boolean and defaults to true.

          + max_size: maximum number of connections available in
            the pool; positive integer and defaults to 25.

          + max_idle_time: maximum number of milliseconds a
            connection can be idle in the queue before being
            closed; integer >= 0 and defaults to 0 (infinite).

          + queue_timeout: maximum number of milliseconds a
            request will wait for a connection to become
            available; integer >= 0 and defaults to 0
            (infinite).
            This is different than connect_timeout that's used
            for non-pooling. In a pooling scenario there are
            already connections in the pool, so queue_timeout
            controls how long to wait for a connection in the
            pool.
       Example usage:
client = mysqlx.get_client(
    {
    'host': 'localhost',
    'port': 33060,
    'user': 'mike',
    'password': 'password'
    },
    { pooling: {
        enabled: true,
        max_idle_time: 5000,
        max_size: 25,
        queue_timeout: 20000
        }
    }
)

       Closing a session attached to the pool makes the
       connection available in the pool for subsequent
       get+session() calls, while closing (destroying) the pool
       effectively closes all server connections.

     * Added a connection-timeout connection timeout query
       parameter. This defines the length of time (milliseconds)
       the client waits for a MySQL server to become available
       in the given network addresses. It was added to both the
       mysqlx.get_session() (non-pooling sessions) and
       mysqlx.get_client() (pooling sessions) interfaces. This
       option defaults to 10000 (10 seconds). The value 0
       disables the timeout so the client will wait until the
       underlying socket (platform dependent) times out.
       Example usages:
mysqlx.get_session("root@localhost?connect-timeout=0");
mysqlx.get_session("root@[localhost:33060, 127.0.0.1:33060]?connect-ti
meout=5000");

       In a multi-host scenario, the connect-timeout value applies to
       each individual host.

Bugs Fixed


     * On Windows, the 32-bit MSI failed to install. The
       registry key path was updated to allow the CEXT prerequisite
       check to execute and pass. (Bug #28395599, Bug #28464866)

     * Subsequent collection.add() method calls would leak
       memory if the C extension was enabled. (Bug #28278352)

     * Missing bind() parameters could cause an unclear error
       message or unexpectedly halt. (Bug #28037275)

     * The username and password fields are now quoted to allow
       special characters when making X DevAPI connections.
       (Bug #27528819, Bug #89614)

Enjoy and thanks for the support!

On behalf of the MySQL Release Team,
Nawaz Nazeer Ahamed

Dear MySQL users,

Version 8.0.13 is the latest General Availability release of the 8.0
series of MySQL Connector/J. It is suitable for use with MySQL Server
versions 8.0, 5.7, 5.6, and 5.5. 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-13.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.13 GA, see the "Generally Available
(GA) Releases" tab at http://dev.mysql.com/downloads/connector/j/

Enjoy!

Changes in MySQL Connector/J 8.0.13 (2018-10-22, General
Availability)


Functionality Added or Changed


     * Important Change: Connector/J now requires Protocol
       Buffers 3.6.1 as an external library for using X DevAPI and for
       building Connector/J from source.  See Connector/J Installation
(http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-installing.html)
       on installation requirements for Connector/J.
       (Bug #28499094)

     * X DevAPI: X DevAPI now provides a connection pooling
       feature, which can reduce overhead for applications by allowing
       idle connections to be reused. Connection pools are managed by
       the new Client objects, from which sessions can be obtained. See
       Connecting to a Single MySQL Server Using Connection Pooling in
       the X DevAPI User Guide
       (http://dev.mysql.com/doc/x-devapi-userguide/en/) for details.

     * X DevAPI: A new connection property,
       xdevapi.connect-timeout, now defines the timeout (in
       milliseconds) for establishing an X-Protocol connection to the
       server. Default value is 10000 (10s), and a value of 0 disables
       timeout, which makes Connector/J wait for the underlying socket
       to time out instead. See Configuration Properties
(http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-configuration-properties.html)
       for details.
      
       Note that if xdevapi.connect-timeout is not set
       explicitly and connectTimeout is, xdevapi.connect-timeout takes
       up the value of connectTimeout.

     * The connection property useOldUTF8Behavior is no longer
       supported. The connection property never had any meaning for
       the MySQL Server versions supported by Connector/J 8.0, but
       actually corrupted the data when it was used with them.
       (Bug #28444461)

     * Connector/J now translates the legacy value of
       convertToNull for the connection property zeroDateTimeBehavior to
       CONVERT_TO_NULL. This allows applications or frameworks that use
       the legacy value (for example, NetBeans) to work with Connector/J
       8.0. (Bug #28246270, Bug #91421)

     * A new connection property, sslMode, has been introduced
       to replace the connection properties useSSL, requireSSL, and
       verifyServerCertificate, which are now deprecated.  Also, when
       not explicitly set, the connection properties xdevapi.ssl-mode,
       xdevapi.ssl-truststore, xdevapi.ssl-truststore-password, and
       xdevapi.ssl-truststore-type now take up the values of sslMode,
       trustCertificateKeyStoreUrl, trustCertificateKeyStorePassword,
       and trustCertificateKeyStoreType, respectively. See Connecting
       Securely Using SSL
(http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-using-ssl.html)
       and Configuration Properties
(http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-configuration-properties.html)
       for details.
      
       Note that for ALL server versions, the default setting
       of sslMode is PREFERRED, and it is equivalent to the legacy
       settings of useSSL=true, requireSSL=false, and
       verifyServerCertificate=false, which are different from their
       default settings for Connector/J 8.0.12 and earlier in some
       situations. Applications that continue to use the deprecated
       properties and rely on their old default settings should be
       reviewed.  (Bug #27102307)

     * The value UTF-8 for the connection property
       characterEncoding now maps to the utf8mb4 character set on the
       server and, for MySQL Server 5.5.2 and later,
       characterEncoding=UTF-8 can now be used to set the connection
       character set to utf8mb4 even if character_set_server has been
       set to something else on the server. (Before this change, the
       server must have character_set_server=utf8mb4 for Connector/J to
       use that character set.) Also, if the connection property
       connectionCollation is also set and is incompatible with the
       value of characterEncoding, characterEncoding will be overridden
       with the encoding corresponding to connectionCollation.  See
       Using Character Sets and Unicode
(http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-charsets.html)
       for details, including how to use the utf8mb3 character set now
       for connection. (Bug #23227334, Bug #81196)


Bugs Fixed


     * X DevAPI: Connector/J threw a WrongArgumentException when
       it encountered a JSON number with more than ten digits.  This was
       due to an error in the JSON parser, which has now been fixed.
       (Bug #28594434, Bug #92264)

     * X DevAPI: Session.getUri() returned a
       NullPointerException when the default value is null for any of
       the connection properties contained in the connection URL; and
       when Session.getUri() returned a URL, the URL contained a comma
       (",") before its first connection property. (Bug #23045604)

     * X DevAPI: When handling an invalid JSON document,
       Connector/J threw a NullPointerException. With this fix, a
       WrongArgumentException is thrown instead in the situation.
       (Bug #21914769)

     * Setting the connection property characterEncoding to an
       encoding that maps to the MySQL character set latin1 or utf8mb4
       did not result in the corresponding default connection collation
       (latin1_swedish_ci or utf8mb4_0900_ai_ci, respectively) to be
       used on the server. With this fix, the server default is used in
       the situation. (Bug #28207422)

     * Calling UpdatableResultSet.updateClob() resulted in an
       SQLFeatureNotSupportedException. It was because the
       implementation of the method was missing from Connector/J, and it
       has been added with this fix. (Bug #28207088)

     * When a connection property's value contained an equal
       sign ("=") in itself, an exception ("WrongArgumentException:
       Malformed database URL") was thrown. This was due to an error in
       the parser for the connection URL, which has been corrected by
       this fix.  (Bug #28150662)

     * Connector/J threw a SQLSyntaxErrorException when the
       parameter tableName for
       DatabaseMetaDataUsingInfoSchema.getTables() had a null argument.
       (Bug #28034570, Bug #90887)

     * Setting rewriteBatchedStatements=true and
       useLocalTransactionState=true caused transactions to be
       uncommitted for batched UPDATE and DELETE statements. It was due
       to the intermediate queries for enabling multiquery support on
       the server resetting the local transaction state as a side
       effect. With this fix, the local transaction state is preserved
       when the intermediate queries are executed.
       (Bug #27658489, Bug #89948)

     * Rewriting prepared INSERT statements in a multiquery
       batch failed with a BatchUpdateException when the statements did
       not contain place holders. This was due a faulty mechanism for
       query rewriting, which has been corrected by this fix.
       (Bug #25501750, Bug #84813)      

     * When using batched prepared statements with multiple
       queries per statement, queries rewriting was incorrect, resulting
       in the wrong queries being sent to the server. 
       (Bug #23098159, Bug #81063)

     * Record updates failed for a scrollable and updatable
       PreparedStatement when the WHERE clause for the updater or
       refresher contained fractional timestamp values and the
       connection property sendFractionalSeconds was set to false. It
       was because in the situation, Connector/J did not perform the
       proper adjustments of the fractional parts in the WHERE clause
       values according to the length of the field's fractional part as
       defined in the database. This fix makes Connector/J perform the
       proper adjustment to the fractional part, so that the WHERE
       clause value can be properly compared to the value fetched from
       the database. (Bug #22305979)

     * Some tests in the testsuite failed as they could not
       recognize system time zone values like CEST or WEST, even with
       the connection property serverTimezone set. This was because the
       value of serverTimezone in the testsuite URLs, after being
       processed by the testsuite, was not actually propagated as a
       connection property to Connector/J. This fix makes sure the
       property is in the actual URLs passed to Connector/J.
       (Bug #21774249)

     * When a Java Date value was bound to a PreparedStatement
       parameter, attempts to format the value by a proleptic
       GregorianCalendar failed to make the dates proleptic, so that
       dates before the Julian-Gregorian cutover (October 15, 1582) were
       stored wrongly. With this fix, a proleptic calendar is properly
       used if supplied to the setDate() method.  Note that when trying
       to set or retrieve dates before the Julian-Gregorian cutover with
       PreparedSatement methods, a proleptic GregorianCalendar should
       always be explicitly supplied to the setDate() and getDate()
       method. For details, see Known Issues and Limitations
(http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-usagenotes-known-issues-limitations.html).
       (Bug #18749544, Bug #72609)


Enjoy and thanks for the support!

On behalf of the MySQL Release Team,
Nawaz Nazeer Ahamed

Dear MySQL users,

MySQL Server 5.7.24, a new version of the popular Open Source
Database Management System, has been released. MySQL 5.7.24 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.24 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.24 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.24 is also available from our repository for Linux
platforms, go here for details:

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

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.24 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.23. It may also be viewed
online at

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

Enjoy!

Changes in MySQL 5.7.24 (2018-10-22, General Availability)

Deprecation and Removal Notes


     * InnoDB; Partitioning: Support for placing table
       partitions in shared tablespaces is deprecated and will
       be removed in a future version of MySQL. Shared
       tablespaces include the system tablespace and general
       tablespaces. For information about identifying partitions
       in shared tablespaces and moving them to file-per-table
       tablespaces, see Preparing Your Installation for Upgrade
http://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html

     * InnoDB: Support for TABLESPACE = innodb_file_per_table
       and TABLESPACE = innodb_temporary clauses with CREATE
       TEMPORARY TABLE is deprecated and will be removed in a
       future MySQL version.

Packaging Notes


     * Binary packages that include curl rather than linking to
       the system curl library now use curl 7.60.0 rather than
       7.45.0. (Bug #28043702)

Security Notes


     * Microsoft Windows: On Windows, MySQL Enterprise Edition
       distributions now bundle the Cyrus SASL library files
       libsasl.dll and saslSCRAM.dll so that the LDAP
       authentication plugins can use the SCRAM-SHA-1
       authentication method.

     * MySQL Enterprise Edition now provides data masking and
       de-identification capabilities, implemented as a plugin
       library containing a plugin and a set of user-defined
       functions. Data masking hides sensitive information by
       replacing real values with substitutes. MySQL Enterprise
       Data Masking and De-Identification functions enable
       masking existing data using several methods such as
       obfuscation (removing identifying characteristics),
       generation of formatted random data, and data replacement
       or substitution. For example:
mysql> SET @ssn = gen_rnd_ssn();
mysql> SET @masked_ssn1 = mask_ssn(@ssn);
mysql> SET @masked_ssn2 = mask_outer(mask_inner (@ssn,4,5,'A'), 3,0,'B');
mysql> SELECT @ssn, @masked_ssn1, @masked_ssn2;
+-------------+--------------+--------------+
| @ssn        | @masked_ssn1 | @masked_ssn2 |
+-------------+--------------+--------------+
| 980-31-2838 | XXX-XX-2838  | BBB-AA-2838  |
+-------------+--------------+--------------+

       For more information, see MySQL Enterprise Data Masking
       and De-Identification
http://dev.mysql.com/doc/refman/8.0/en/data-masking.html

Functionality Added or Changed


     * Previously, file I/O performed in the I/O cache in the
       mysys library was not instrumented, affecting in
       particular file I/O statistics reported by the
       Performance Schema about the binary log index file. Now,
       this I/O is instrumented and Performance Schema
       statistics are accurate. Thanks to Yura Sorokin for the
       contribution. (Bug #27788907, Bug #90264)

     * The zlib library version bundled with MySQL was raised
       from version 1.2.3 to version 1.2.11. MySQL implements
       compression with the help of the zlib library.
       The zlib compressBound() function in zlib 1.2.11 returns
       a slightly higher estimate of the buffer size required to
       compress a given length of bytes than it did in zlib
       version 1.2.3. The compressBound() function is called by
       InnoDB functions that determine the maximum row size
       permitted when creating compressed InnoDB tables or
       inserting rows into compressed InnoDB tables. As a
       result, CREATE TABLE ... ROW_FORMAT=COMPRESSED or INSERT
       operations with row sizes very close to the maximum row
       size that were successful in earlier releases could now
       fail.

Bugs Fixed


     * InnoDB: An ALTER TABLE operation that added a primary key
       produced a segmentation fault. (Bug #28395278)
       References: This issue is a regression of: Bug #27753193.

     * InnoDB: A query that scanned the primary key of a table
       did not return the expected result. (Bug #28104394, Bug
       #91032)

     * InnoDB: A query interruption during a lock wait caused an
       error. (Bug #28068293)

     * InnoDB: An index record was not found when updating a
       secondary index defined on a generated column. (Bug
       #27968952)

     * InnoDB: The update log applied as part of an online ALTER
       TABLE operation did not take into account the computed
       value of the generated column in the old row while
       updating the secondary index. (Bug #27921932)

     * InnoDB: An unsupported DDL operation involving a foreign
       key constraint raised an assertion. (Bug #27912873)

     * InnoDB: An attempted foreign key check on a discarded
       table caused a segmentation fault. (Bug #27804668)

     * InnoDB: An assertion was raised during an OPTIMIZE TABLE
       operation. (Bug #27753193)

     * InnoDB: A foreign key constraint name was duplicated
       during a rename table operation, causing a failure during
       later query execution. (Bug #27545888)

     * InnoDB: In a function called before the execution of a
       statement in a stored procedure, a read and write
       operation on trx->lock.start_stmt was not protected by a
       mutex. (Bug #27325898)

     * InnoDB: An error occurred during a DDL operation due to a
       mismatch in a REDUNDANT row format calculation that
       determines the length of the online log. (Bug #26375771)

     * InnoDB: The location of the Innodb Merge Temp File that
       reported by the wait/io/file/innodb/innodb_temp_file
       Performance Schema instrument was incorrect. (Bug
       #21339079, Bug #77519)

     * Partitioning: When a CREATE TABLE ... PARTITION BY ...
       statement failed due to an invalid partition definition,
       the server did not remove any partition files which might
       have been created prior to encountering the invalid
       PARTITION clause. (Bug #27798708)
       References: See also: Bug #88043, Bug #26945644.

     * Partitioning: It was possible to perform FLUSH TABLES FOR
       EXPORT on a partitioned table created with
       innodb_file_per_table=1 after discarding its tablespace.
       Attempting to do so now raises ER_TABLESPACE_DISCARDED.
       (Bug #95045, Bug #27903881)
       References: See also: Bug #80669, Bug #22899690.

     * Replication: If the
       group_replication_recovery_retry_count variable was
       modified while the member was already making a
       reconnection attempt, the connection attempt could enter
       an infinite loop. (Bug #28092714)

     * Replication: When the binlog_group_commit_sync_delay
       system variable is set to a wait time to delay
       synchronization of transactions to disk, and the
       binlog_group_commit_sync_no_delay_count system variable
       is also set to a number of transactions, the MySQL server
       exits the wait procedure if the specified number of
       transactions is reached before the specified wait time is
       reached. The server manages this process by checking on
       the transaction count after a delta of one tenth of the
       time specified by binlog_group_commit_sync_delay has
       elapsed, then subtracting that interval from the
       remaining wait time.
       If rounding during calculation of the delta meant that
       the wait time was not a multiple of the delta, the final
       subtraction of the delta from the remaining wait time
       would cause the value to be negative, and therefore to
       wrap to the maximum wait time, making the commit hang.
       The data type for the remaining wait time has now been
       changed so that the value does not wrap in this
       situation, and the commit can proceed when the original
       wait time has elapsed. Thanks to Yan Huang for the
       contribution. (Bug #28091735, Bug #91055)

     * Replication: An assertion was raised in debug builds
       because the MySQL server recorded a GTID consistency
       violation, but did not remove the record after the
       relevant statement failed to execute successfully. The
       handling of this situation has now been improved to
       ensure that the server checks at the end of a transaction
       whether a GTID consistency violation was produced by a
       failed statement, and if this is the case, restores the
       previous GTID consistency state. (Bug #27903831, Bug
       #90551)

     * Replication: With GTIDs in use for replication,
       transactions including statements that caused a parsing
       error (ER_PARSE_ERROR) could not be skipped manually by
       the recommended method of injecting an empty or
       replacement transaction with the same GTID. This action
       should result in the slave identifying the GTID as
       already used, and therefore skipping the unwanted
       transaction that shared its GTID. However, in the case of
       a parsing error, because the statement was parsed before
       the GTID was checked to see if it needed to be skipped,
       the replication applier thread stopped due to the parsing
       error, even though the intention was for the transaction
       to be skipped anyway.
       With this fix, the replication applier thread now ignores
       parsing errors if the transaction concerned needs to be
       skipped because the GTID was already used. Note that this
       behavior change does not apply in the case of workloads
       consisting of binary log output produced by mysqlbinlog.
       In that situation, there would be a risk that a
       transaction with a parsing error that immediately follows
       a skipped transaction would also be silently skipped,
       when it ought to raise an error. (Bug #27638268)

     * Replication: When a RESET SLAVE statement was issued on a
       replication slave with GTIDs in use, the existing relay
       log files were purged, but the replacement new relay log
       file was generated before the set of received GTIDs for
       the channel had been cleared. The former GTID set was
       therefore written to the new relay log file as the
       PREVIOUS_GTIDS event, causing a fatal error in
       replication stating that the slave had more GTIDs than
       the master, even though the gtid_executed set for both
       servers was empty. Now, when RESET SLAVE is issued, the
       set of received GTIDs is cleared before the new relay log
       file is generated, so that this situation does not occur.
       (Bug #27636289)

     * Replication: The master's receiver thread for
       semisynchronous replication held a mutex while reading
       acknowledgements from slaves, but the same mutex was
       required to add or remove a semisynchronous slave,
       causing those operations to be delayed by the
       acknowledgement activity. The issue has now been fixed by
       not acquiring the mutex to read the acknowledgements from
       slaves. (Bug #27610678, Bug #89370)

     * Replication: Entries in the relay log info log (the
       slave_relay_log_info table) for the Group
       Replication-specific channels group_replication_applier
       and group_replication_recovery were not being cleared by
       a RESET SLAVE or RESET SLAVE ALL command. (Bug #27411175)

     * Replication: Automatic retrying of transactions on a
       replication slave, as specified by the
       slave_transaction_retries system variable, was taking
       place even if the transaction had a non-temporary error
       that would repeat on retrying or that indicated wider
       issues. Now, transactions are only automatically retried
       if there is either no error, or an error that is only
       temporary. (Bug #27373559, Bug #89143)

     * Replication: Attempting to uninstall the plugin while
       START GROUP_REPLICATION executed could result in
       unexpected behavior. (Bug #25423650, Bug #91042, Bug
       #28088177)

     * Replication: When FLUSH statements for specific log types
       (such as FLUSH SLOW LOGS) resulted in an error, the
       statements were still written to the binary log. This
       stopped replication because the error had occurred on the
       master, but did not occur on the slave. MySQL Server now
       checks on the outcome of these FLUSH statements, and if
       an error occurred, the statement is not written to the
       binary log. (Bug #24786290, Bug #83232)

     * Replication: The PASSWORD() function, which produces a
       hash of the password, was deprecated in MySQL 5.7 and
       removed in MySQL 8.0. When a SET PASSWORD statement that
       used this function was replicated from a MySQL 5.6 master
       to a MySQL 5.7 slave, or from a MySQL 5.7 master with the
       log_builtin_as_identified_by_password system variable set
       to ON to a MySQL 5.7 slave, the password hash was itself
       also hashed before being stored on the slave. The issue
       has now been fixed and the replicated password hash is
       stored as originally passed to the slave. (Bug #24687073)

     * Replication: If an ORDER BY clause was used in retrieving
       records from certain Performance Schema tables relating
       to replication, an empty set was returned. The issue has
       now been fixed. (Bug #22958077, Bug #80777)

     * Replication: When replication channels are used on a
       slave for multi-source replication, a START SLAVE
       statement that does not specify an individual channel (so
       without the FOR CHANNEL clause) should start the I/O
       thread and the SQL thread for all of the channels on the
       replication slave. However, if a RESET SLAVE statement
       was used on such a slave, a subsequent START SLAVE
       statement did not start the non-default channels. Now,
       replication channels that are deinitialized as a result
       of a RESET SLAVE statement, rather than as a result of an
       error in the initialization process, are identified and
       are restarted by a START SLAVE statement that applies to
       all channels. (Bug #22809607)

     * Replication: Issuing RESET SLAVE on a replication slave
       does not change any replication connection parameters
       such as master host, master port, master user, or master
       password, which are retained in memory. However, these
       connection parameters are reset if you issue RESET SLAVE
       ALL. Previously, if the slave mysqld was restarted
       immediately after issuing RESET SLAVE (including a server
       crash as well as a deliberate restart), the connection
       parameters were reset as if RESET SLAVE ALL had been
       used.
       Now, when master_info_repository=TABLE is set on the
       server (which is the default from MySQL 8.0), replication
       connection parameters are preserved in the crash-safe
       InnoDB table mysql.slave_master_info as part of the RESET
       SLAVE operation. They are also retained in memory. In the
       event of a server crash or deliberate restart after
       issuing RESET SLAVE but before issuing START SLAVE, the
       replication connection parameters are retrieved from the
       table and reused for the new connection.
       If master_info_repository=FILE is set on the server
       (which is the default in MySQL 5.7), replication
       connection parameters are only retained in memory, so the
       behavior remains the same as previously. If the slave
       mysqld is restarted due to a server crash or a deliberate
       restart immediately after issuing RESET SLAVE, the
       connection parameters are lost. In that case, you must
       issue a CHANGE MASTER TO statement after the server start
       to respecify the connection parameters before issuing
       START SLAVE.
       If you want to reset the connection parameters
       intentionally, you need to use RESET SLAVE ALL, which
       clears the connection parameters. In that case, you must
       issue a CHANGE MASTER TO statement after the server start
       to specify the new connection parameters. (Bug #20280946)

     * Replication: Compilation warnings related to unused
       functions in xdr_utils have been reduced. Thanks to Zsolt
       Parragi for the patch. (Bug #91071, Bug #28099963)

     * Replication: When group_replication_group_seeds contained
       a DNS based entry which resolved to its own local
       address, Group Replication could not start. (Bug #90483,
       Bug #27882096, Bug #28074929)

     * Microsoft Windows: On Windows, uninstallation of the
       MySQL Server MSI package through MySQL Installer produced
       a spurious popup window. (Bug #27463864)

     * On the Fedora 29 platform, OpenSSL 1.0.x is used to build
       packages because 1.1.1 support is not ready. If you build
       MySQL from source, it is recommended that you build using
       the compat-openssl10-devel package. (Bug #28737143)

     * On the Fedora 29 platform, upgrading from MariaDB to
       MySQL 8.0.13 failed due to missing obsoletes. (Bug
       #28727698)

     * Address Sanitizer revealed SSL/Zlib link problems related
       to the audit_log plugin; these were corrected. (Bug
       #28525431, Bug #92082)

     * Compilation failed for GCC 8 with MySQL configured to use
       some system libraries. (Bug #28471072, Bug #91914)

     * Concurrent INSERT and SELECT statements on a MERGE table
       could result in a server exit. (Bug #28379285)

     * For UPDATE and DELETE statements that produce an error
       due to sql_safe_updates being enabled, the error message
       was insufficiently informative. The message now includes
       the first diagnostic that was produced, to provide
       information about the reason for failure. For example,
       the message may indicate that the
       range_optimizer_max_mem_size value was exceeded or type
       conversion occurred, either of which can preclude use of
       an index.
       Additionally: (1) Using EXPLAIN for such statements does
       not produce an error, enabling users to see from EXPLAIN
       plus SHOW WARNINGS output why an index is not used. (2)
       For multiple-table deletes and updates, an error is
       produced with safe updates enabled only if any target
       table uses a table scan. (Bug #28145710, Bug #91080)

     * MySQL Server and test RPM packages were missing
       perl-Data-Dumper as a dependency. (Bug #28144933, Bug
       #72926)

     * For the mysql client, the -b short option was associated
       with two long options, --no-beep and --binary-as-hex. The
       -b option now is associated only with --no-beep. (Bug
       #28093271)

     * The WITH_GMOCK CMake option did not handle Windows path
       names properly. (Bug #28061409, Bug #90964)

     * Group lookups for LDAP authentication plugins could fail
       if the user had insufficient privileges. Now, group
       search operations bind again using root credentials if
       those are available. (Bug #28016008)

     * Generated columns having indexes and that used a string
       function were not always populated correctly. (Bug
       #27973409)

     * Stored program definitions in mysqldump dump files
       sometimes included the NO_AUTO_CREATE_USER SQL mode.
       Because that mode has been removed in MySQL 8.0, loading
       such a dump file into a MySQL 8.0 server failed.
       mysqldump now removes NO_AUTO_CREATE_USER from the
       definition of dumped stored programs. (Bug #27931181, Bug
       #90624)

     * Very long table keys were handled incorrectly on
       replication slaves. (Bug #27930505)

     * During server startup/shutdown, PID files could be
       mishandled. (Bug #27919254)

     * If flushing the error log failed due to a file permission
       error, the flush operation did not complete. (Bug
       #27891472, Bug #90505)
       References: This issue is a regression of: Bug #26447825.

     * For MEMORY tables, memory overflow errors could occur.
       (Bug #27799513)

     * When converting from a BLOB (or TEXT) type to a smaller
       BLOB (or TEXT) type, no warning or error was reported
       informing about the truncation or data loss. Now an
       appropriate error is issued in strict SQL mode and a
       warning in nonstrict SQL mode. (Bug #27788685, Bug
       #90266)

     * The severity of messages produced by the server about
       being unable to read key files has been escalated from
       INFORMATION to WARNING. (Bug #27737195)

     * Failure to create a temporary table during a MyISAM query
       could cause a server exit. Thanks to Facebook for the
       patch. (Bug #27724519, Bug #90145)

     * parser_max_mem_size was ineffective when parsing stored
       program definitions. (Bug #27714748)

     * Host name resolution errors could cause the audit_log
       plugin to fail. (Bug #27567003)

     * Unsuccessful connection attempts were not being written
       to the error log when log_error_verbosity=3. (Bug
       #27539838)

     * An earlier code cleanup caused FEDERATED storage engine
       failures. (Bug #27493633, Bug #89537)
       References: This issue is a regression of: Bug #25943754.

     * An attempted read of an uncommitted transaction raised an
       assertion. (Bug #26876608)

     * ALTER TABLE ... REORGANIZE PARTITION ... could result in
       incorrect behavior if any partition other than the last
       was missing the VALUES LESS THAN part of the syntax. (Bug
       #26791931)

     * The audit_log plugin could deadlock the server. (Bug
       #24353553)

     * Debug symbol packages are now included for all apt
       platforms (previously, they were only available on 
       Debian9). (Bug #24008883, Bug #27990381)

     * Specifying the maximum possible value for a YEAR column
       failed when expressed as a real constant such as
       2155.0E00 or 2.15E3. (Bug #91226, Bug #28172538)

     * It was possible for a subquery that used a unique key on
       a column allowing NULL to return multiple rows. (Bug
       #88670, Bug #27182010)

On Behalf of MySQL/ORACLE RE Team
Gipson Pulla

   Functionality Added or Changed

     * Added dynamic libmysql linking support via the
       -DMYSQLCLIENT_STATIC_LINKING:BOOL=TRUE|FALSE option;
       defaults to FALSE to enable dynamic linking.

   Bugs Fixed

     * Fixed column metadata handling with Microsoft Access.
       (Bug #28670725, Bug #91856)

     * The following obsolete options were removed: NO_SCHEMA
       (use NO_CATALOG instead), DISABLE_SSL_DEFAULT (use
       SSLMODE instead), and SSL_ENFORCE (use SSLMODE instead).
       (Bug #28407520)

     * The ODBC Driver returned 0 for the
       SQL_MAX_SCHEMA_NAME_LEN attribute, and now returns 64 as
       the maximum length for a MySQL schema name.
       (Bug #28385722)

     * Because the MySQL ODBC driver ignored the SQL_RD_OFF
       value for the SQL_ATTR_RETRIEVE_DATA attribute, it
       incorrectly kept writing into the data buffers. This led
       to write access violation errors when data was written
       into the buffer when the user application explicitly
       requested not to write there. (Bug #28098219, Bug #91060)

Dear MySQL users,

MySQL Connector/Node.js is a new Node.js driver for use with the X
DevAPI. This release, v8.0.13, 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.13 (2018-10-22, General availability)

Functionality Added or Changed

     * To go with the existing asynchronous
       mysqlx.getSession(conn_str) method, a new synchronous
       mysqlx.getClient(conn_str, options) method was added that
       creates a connection pool handler that provides an
       asynchronous getSession() method to create and retrieve
       connections from the pool. The collection pooling options
       are:

          + enabled: enables or disables connection pooling;
            boolean and defaults to true.

          + maxSize: maximum number of connections available in
            the pool; positive integer and defaults to 25.

          + maxIdleTime: maximum number of milliseconds a
            connection can be idle in the queue before being
            closed; integer >= 0 and defaults to 0 (infinite).

          + queueTimeout: maximum number of milliseconds a
            request will wait for a connection to become
            available; integer >= 0 and defaults to 0
            (infinite).
            This is different than connectTimeout that's used
            for non-pooling. In a pooling scenario, there might
            already be connections in the pool and queueTimeout
            controls how long to wait for a connection in the
            pool.
       Example usage:
       var mysqlx = require('@mysql/xdevapi')
       var client = mysqlx.getClient(
         { user: 'root', host: 'localhost', port: 33060 },
         { pooling: { enabled: true, maxIdleTime: 5000, maxSize: 25, queueTimeout: 20000 } }
       );

       client.getSession()
         .then(session => {
           console.log(session.inspect())
           return session.close() // the connection becomes idle in the client pool
         })
         .then(() => {
           return client.getSession()
         })
         .then(session => {
           console.log(session.inspect())
           return client.close() // closes all connections and destroys the pool
         })

       Closing a session attached to the pool makes the
       connection available in the pool for subsequent
       getSession() calls, while closing (destroying) the pool
       effectively closes all server connections.

     * Added a connection timeout query parameter. This defines
       the length of time (milliseconds) the client waits for a
       MySQL server to become available in the given network
       addresses. It was added to both the mysqlx.getSession()
       (non-pooling sessions) and mysqlx.getClient() (pooling
       sessions) interfaces. This option defaults to 10000 (10
       seconds). The value 0 disables the timeout so the client
       will wait until the underlying socket (platform
       dependent) times out.
       Similar to other option formatting rules, this option
       defined as connection-timeout (kebab-case) for URI
       definitions and connectionTimeout (camelCase) for plain
       JavaScript configuration objects.
       Example usage:
       const mysqlx = require('@mysql/xdevapi');
       var client = mysqlx.getClient('root@localhost?connect-timeout=5000')
       client.getSession()
           .catch(err => {
               console.log(err.message) // "Connection attempt to the server was aborted. Timeout of 5000 ms was exceeded."
           })

       // Or

       const mysqlx = require('@mysql/xdevapi');
       var client = mysqlx.getClient('mysqlx://root:passwd@[localhost:33060, 127.0.0.1:33060]?connect-timeout=5000')
       client.getSession()
           .catch(err => {
               // connection could not be established after 10 seconds (5 seconds for each server)
               console.log(err.message); // All server connection attempts we re aborted. Timeout of 5000 ms was exceeded for each selected server.
           });

       In a multi-host scenario, the connect-timeout value
       applies to each individual host.


Bugs Fixed

     * Improved the handling of X Protocol global notices by
       properly logging and then ignoring non-fatal errors, and
       making the connection unusable for subsequent operations
       in the case of a fatal error. (Bug #28653781)

     * Calling getCollationName() on non-textual fields, such as
       INT, threw the following error "TypeError: Cannot read
       property 'collation' of undefined". (Bug #28608923)

     * The fields() method did not function with valid
       expressions generated by the expr() method. (Bug
       #28409639)

     * The returned Session.inspect() object now includes the
       'user' property in addition to the 'dbUser' property but
       containing the same value. (Bug #28362115) 

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

Dear MySQL users,

MySQL Server 5.5.62 is a new version of the 5.5 production release of
the world's most popular open source database. MySQL 5.5.62 is
recommended for use on production systems.

MySQL 5.5 includes several high-impact enhancements to improve the
performance and scalability of the MySQL Database, taking advantage of
the latest multi-CPU and multi-core hardware and operating systems. In
addition, with release 5.5, InnoDB is now the default storage engine for
the MySQL Database, delivering ACID transactions, referential integrity
and crash recovery by default.

MySQL 5.5 also provides a number of additional enhancements including:

  - Significantly improved performance on Windows, with various Windows
    specific features and improvements
  - Higher availability, with new semi-synchronous replication and
    Replication Heartbeat
  - Improved usability, with Improved index and table partitioning,
    SIGNAL/RESIGNAL support and enhanced diagnostics, including a new
    Performance Schema monitoring capability.

For a more complete look at what's new in MySQL 5.5, please see the
following resources:

Documentation:

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

If you are running a MySQL production level system, we would like to
direct your attention to MySQL Enterprise Edition, which includes the
most comprehensive set of MySQL production, backup, monitoring,
modeling, development, and administration tools so businesses can
achieve the highest levels of MySQL performance, security and uptime.

  http://mysql.com/products/enterprise/

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

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

For upgrading from previous MySQL releases, please see the important
upgrade considerations at:

  http://dev.mysql.com/doc/refman/5.5/en/upgrading.html

MySQL Database 5.5.62 is available in source and binary form for a
number of platforms from our download pages at:

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

The following link lists the changes in the MySQL source code since the
previous released version of MySQL 5.5. It may also be viewed online at:

  http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-62.html

This is the last update to be published for MySQL Server 5.5. To
continue receiving updates for this product, you will need to upgrade to
at least version 5.6.

Enjoy!

Changes in MySQL 5.5.62 (2018-10-22, General availability)

Functionality Added or Changed

     * Previously, file I/O performed in the I/O cache in the
       mysys library was not instrumented, affecting in
       particular file I/O statistics reported by the
       Performance Schema about the binary log index file. Now,
       this I/O is instrumented and Performance Schema
       statistics are accurate. Thanks to Yura Sorokin for the
       contribution. (Bug #27788907, Bug #90264)

     * The zlib library version bundled with MySQL was raised
       from version 1.2.3 to version 1.2.11. MySQL implements
       compression with the help of the zlib library.
       The zlib compressBound() function in zlib 1.2.11 returns
       a slightly higher estimate of the buffer size required to
       compress a given length of bytes than it did in zlib
       version 1.2.3. The compressBound() function is called by
       InnoDB functions that determine the maximum row size
       permitted when creating compressed InnoDB tables or
       inserting rows into compressed InnoDB tables. As a
       result, CREATE TABLE ... ROW_FORMAT=COMPRESSED or INSERT
       operations with row sizes very close to the maximum row
       size that were successful in earlier releases could now
       fail.


Bugs Fixed

     * MySQL Server and test RPM packages were missing
       perl-Data-Dumper as a dependency. (Bug #28144933, Bug
       #72926)

     * For the mysql client, the -b short option was associated
       with two long options, --no-beep and --binary-as-hex. The
       -b option now is associated only with --no-beep. (Bug
       #28093271)

     * During server startup/shutdown, PID files could be
       mishandled. (Bug #27919254)

     * For MEMORY tables, memory overflow errors could occur.
       (Bug #27799513)

     * When converting from a BLOB (or TEXT) type to a smaller
       BLOB (or TEXT) type, no warning or error was reported
       informing about the truncation or data loss. Now an
       appropriate error is issued in strict SQL mode and a
       warning in nonstrict SQL mode. (Bug #27788685, Bug
       #90266)

     * ALTER TABLE ... REORGANIZE PARTITION ... could result in
       incorrect behavior if any partition other than the last
       was missing the VALUES LESS THAN part of the syntax. (Bug
       #26791931) 

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

Dear MySQL users,

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

   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.5 through MySQL 5.5.62
   (see Changes in MySQL 5.5.62 (2018-10-22, General availability)
   (http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-62.html)).
   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.42 on new servers or upgrading
to MySQL 5.6.42 from previous MySQL releases, please see

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

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

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

Not all mirror sites may be up to date at this point in time, so if you
can't find this version on some mirror, please try again later or choose
another download site.

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

https://wikis.oracle.com/display/mysql/Contributing

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

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

Enjoy!

Changes in MySQL 5.6.42 (2018-10-22, General Availability)


     * Functionality Added or Changed

     * Bugs Fixed

Functionality Added or Changed


     * Previously, file I/O performed in the I/O cache in the
       mysys library was not instrumented, affecting in particular file
       I/O statistics reported by the Performance Schema about the
       binary log index file. Now, this I/O is instrumented and
       Performance Schema statistics are accurate. Thanks to Yura
       Sorokin for the contribution. (Bug #27788907, Bug #90264)

     * The zlib library version bundled with MySQL was raised
       from version 1.2.3 to version 1.2.11. MySQL implements
       compression with the help of the zlib library.  The zlib
       compressBound() function in zlib 1.2.11 returns a slightly higher
       estimate of the buffer size required to compress a given length
       of bytes than it did in zlib version 1.2.3. The compressBound()
       function is called by InnoDB functions that determine the maximum
       row size permitted when creating compressed InnoDB tables or
       inserting rows into compressed InnoDB tables. As a result, CREATE
       TABLE ... ROW_FORMAT=COMPRESSED or INSERT operations with row
       sizes very close to the maximum row size that were successful in
       earlier releases could now fail.  If you have compressed InnoDB
       tables with large rows, it is recommended that you test
       compressed table CREATE TABLE statements on a MySQL 8.0.3 test
       instance prior to upgrading.

Bugs Fixed


     * InnoDB: An ALTER TABLE operation that added a primary key
       produced a segmentation fault. (Bug #28395278) References: This
       issue is a regression of: Bug #27753193.

     * InnoDB: An assertion was raised during an OPTIMIZE TABLE
       operation. (Bug #27753193)

     * InnoDB: A foreign key constraint name was duplicated
       during a rename table operation, causing a failure during later
       query execution. (Bug #27545888)

     * InnoDB: The location of the Innodb Merge Temp File that
       reported by the wait/io/file/innodb/innodb_temp_file Performance
       Schema instrument was incorrect. (Bug #21339079, Bug #77519)

     * Replication: When FLUSH statements for specific log types
       (such as FLUSH SLOW LOGS) resulted in an error, the statements
       were still written to the binary log. This stopped replication
       because the error had occurred on the master, but did not occur
       on the slave. MySQL Server now checks on the outcome of these
       FLUSH statements, and if an error occurred, the statement is not
       written to the binary log. (Bug #24786290, Bug #83232)

     * Microsoft Windows: On Windows, uninstallation of the
       MySQL Server MSI package through MySQL Installer produced a
       spurious popup window. (Bug #27463864)

     * Concurrent INSERT and SELECT statements on a MERGE table
       could result in a server exit. (Bug #28379285)

     * MySQL Server and test RPM packages were missing
       perl-Data-Dumper as a dependency. (Bug #28144933, Bug #72926)

     * For the mysql client, the -b short option was associated
       with two long options, --no-beep and --binary-as-hex. The -b
       option now is associated only with --no-beep. (Bug #28093271)

     * Very long table keys were handled incorrectly on
       replication slaves. (Bug #27930505)

     * During server startup/shutdown, PID files could be
       mishandled. (Bug #27919254)

     * For MEMORY tables, memory overflow errors could occur.
       (Bug #27799513)

     * When converting from a BLOB (or TEXT) type to a smaller
       BLOB (or TEXT) type, no warning or error was reported informing
       about the truncation or data loss. Now an appropriate error is
       issued in strict SQL mode and a warning in nonstrict SQL mode.
       (Bug #27788685, Bug #90266)

     * Failure to create a temporary table during a MyISAM query
       could cause a server exit. Thanks to Facebook for the patch. (Bug
       #27724519, Bug #90145)

     * An attempted read of an uncommitted transaction raised an
       assertion. (Bug #26876608)

     * ALTER TABLE ... REORGANIZE PARTITION ... could result in
       incorrect behavior if any partition other than the last was
       missing the VALUES LESS THAN part of the syntax. (Bug #26791931)

     * yum update did not properly update from RHEL5 RPM
       packages to current packages. (Bug #20560761)

     * It was possible for a subquery that used a unique key on
       a column allowing NULL to return multiple rows. (Bug #88670, Bug
       #27182010)

On Behalf of MySQL Release Engineering Team,
Surabhi Bhat

Dear MySQL users,
 
MySQL Connector/NET 8.0.13 is the first version to support
Entity Framework Core 2.1 and the third general availability release
of MySQL Connector/NET to add support for the new X DevAPI,which
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/index.html. For more
information about how the X DevAPI is implemented in Connector/NET, see
http://dev.mysql.com/doc/dev/connector-net.

NuGet packages provide functionality at a project level. To get the
full set of features available in Connector/NET such as availability
in the GAC, integration with Visual Studio's Entity Framework Designer
and integration with MySQL for Visual Studio, installation through
the MySQL Installer or the stand-alone MSI is required.
 
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/NET 8.0.13, see
http://dev.mysql.com/downloads/connector/net/
 
Installation instructions can be found at
https://dev.mysql.com/doc/connector-net/en/connector-net-installation.html

Changes in MySQL Connector/NET 8.0.13 (2018-10-22, General Availability) 

     * Important Changes

     * Functionality Added or Changed

     * Bugs Fixed

Important Changes


     * The default value for the SslMode connection option now
       differs based on the protocol used to make the
       connection. The Preferred mode has been reintroduced in
       this release (see Options for Both Classic MySQL Protocol
       and X Protocol
       http://dev.mysql.com/doc/connector-net/en/connector-net-8-0-connection-options.html#connector-net-8-0-connection-options-classic-xprotocol .
       To summarize the default  Sslmode values in the Connector/NET 8.0 (and 7.0) release series:

       Connector/NET 8.0.13: Preferred mode is the default for
       classic MySQL protocol connections only. Required mode is
       the default for X Protocol connections only (Preferred
       mode is not available for use with X Protocol).

       Connector/NET 8.0.8 to 8.0.12: Preferred mode is not
       supported for any connections. Required mode is the
       default for both classic MySQL protocol and X Protocol
       connections.

       Connector/NET 7.0.0 to 7.0.7: Preferred mode is the
       default for both classic MySQL protocol and X Protocol
       connections. (Bug #28687769)


Functionality Added or Changed

     * Document Store: An incremental improvement was made to
       the performance of session creation with a connection
       string. (Bug #28343655)

     * Support for EF Core 2.1 was added to Connector/NET 8.0.13
       and support for EF Core 2.0 was discontinued in the same
       connector version. Other versions of Connector/NET
       continue to support EF Core 2.0 (see Entity Framework
       Core Support
       http://dev.mysql.com/doc/connector-net/en/connector-net-entityframework-core.html .

     * The ConnectionTimeout connection option and property were
       reimplemented as the Connect-Timeout option (and the
       ConnectTimeout property) for X Protocol operations. Some
       aspects of the timeout behavior were changed (see Options
       for X Protocol Only
       http://dev.mysql.com/doc/connector-net/en/connector-net-8-0-connection-options.html#connector-net-8-0-connection-options-xprotocol .
       The new ConnectTimeout property was added to the
       MySqlX.XDevAPI.MySqlXConnectionStringBuilder class and
       the existing ConnectionTimeout property was removed.

       No modifications were made to the existing implementation
       of the ConnectionTimeout option (or property) for classic
       MySQL operations.

     * Connector/NET now provides connection pooling for
       applications using the X Protocol. The implementation
       includes the new static MySQLX.GetClient method that
       takes two parameters: connectionData (connection string
       or URI) and connectionOptions (JSON-formatted string or
       anonymous object containing the pooling options).
      

       Method overloading enables the following type combinations:
        MySQLX.GetClient(Object, Object)
        MySQLX.GetClient(Object, String)
        MySQLX.GetClient(String, Object)
        MySQLX.GetClient(String, String)

       GetClient returns the new Client object, which retrieves
       an existing and currently unused network connection from
       the pool, resets it, and uses it. Closing a session marks
       the underlying connection as unused and returns it to the
       pool.

       Connection options are configured as follows:
       // Connection options of type String
        Client client = MySQLX.GetClient(ConnectionData, "{ \"pooling\": { \"maxSize\":  5, \"queueTimeout\": 5000 } }");

      // Connection options of type Object (anonymous object)
       Client client = MySQLX.GetClient(ConnectionData, new { pooling = new {maxSize = 5, queueTimeout = 5000 } });

       The new keyword must be used twice when the connection
       options are configured using an anonymous object.
       Connection options are: enabled, maxSize, maxIdleTime,
       and queueTimeout. For more information, see Connection
       and Session Concepts
       http://dev.mysql.com/doc/x-devapi-userguide/en/devapi-connection-concepts.html .

Bugs Fixed

     * Document Store: Connector-side validation performed when
       the Collection.CreateIndex method was called duplicated
       some of the checks already made by the server. The
       connector now only validates that the indexDefinition
       value passed to the method is a valid JSON document with
       the correct structure. (Bug #28343828)

     * EF Core: An invalid syntax error was generated when a new
       property (defined as numeric, has a default value, and is
       not a primary key) was added to an entity that already
       contained a primary-key column with the AUTO_INCREMENT
       attribute. This fix validates that the entity property
       (column) is a primary key first before adding the
       attribute. (Bug #28293927)

     * Document Store: A mixed alphanumeric value such as
       "1address" when used with the Set and Unset methods
       caused the operations to throw an exception. This fix
       resolves the way mixed values are converted into tokens
       to generate only one token as an identifier. (Bug
       #28094094)

     * EF Core: The implementation of some methods required to
       scaffold an existing database were incomplete. (Bug
       #27898343, Bug #90368)

     * Attempts to create a new foreign key from within an
       application resulted in an exception when the key was
       generated by a server in the MySQL 8.0 release series.
       (Bug #27715069)

     * A variable of type POINT when used properly within an
       application targeting MySQL 8.0 generated an SQL syntax
       error. (Bug #27715007)

     * The case-sensitive lookup of field ordinals was
       initialized using case-insensitive comparison logic. This
       fix removes the original case-sensitive lookup. (Bug
       #27285641, Bug #88950)

     * The MySql.Data.Types.MySqlGeometry constructor called
       with an array of bytes representing an empty geometry
       collection generated an ArgumentOutOfRangeException
       exception, rather than creating the type as expected.
       Thanks to Peet Whittaker for the patch. (Bug #26421346,
       Bug #86974)

     * Slow connections made to MySQL were improved by reducing
       the frequency and scope of operating system details
       required by the server to establish and maintain a
       connection. (Bug #22580399, Bug #80030)


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 7.5.12, 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.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.12 (5.7.24-ndb-7.5.12) (2018-10-23,
General Availability)

   MySQL NDB Cluster 7.5.12 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
   ( http://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
   ( http://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.24 (see Changes in MySQL 5.7.24 (2018-10-22,
   General Availability)
   ( http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-24.html )).

Bugs Fixed


     * Packaging: Expected NDB header files were in the devel
       RPM package instead of libndbclient-devel. (Bug #84580,
       Bug #26448330)

     * MySQL NDB ClusterJ: When a table containing a BLOB
       ( http://dev.mysql.com/doc/refman/5.7/en/blob.html ) or a
       TEXT ( http://dev.mysql.com/doc/refman/5.7/en/blob.html )
       field was being queried with ClusterJ for a record that
       did not exist, an exception ("The method is not valid in
       current blob state") was thrown. (Bug #28536926)

     * MySQL NDB ClusterJ: A NullPointerException was thrown
       when a full table scan was performed with ClusterJ on
       tables containing either a BLOB or a TEXT field. It was
       because the proper object initializations were omitted,
       and they have now been added by this fix. (Bug #28199372,
       Bug #91242)

     * When the SUMA kernel block receives a SUB_STOP_REQ
       signal, it executes the signal then replies with
       SUB_STOP_CONF. (After this response is relayed back to
       the API, the API is open to send more SUB_STOP_REQ
       signals.) After sending the SUB_STOP_CONF, SUMA drops the
       subscription if no subscribers are present, which
       involves sending multiple DROP_TRIG_IMPL_REQ messages to
       DBTUP. LocalProxy can handle up to 21 of these requests
       in parallel; any more than this are queued in the Short
       Time Queue. When execution of a DROP_TRIG_IMPL_REQ was
       delayed, there was a chance for the queue to become
       overloaded, leading to a data node shutdown with Error in
       short time queue.
       This issue is fixed by delaying the execution of the
       SUB_STOP_REQ signal if DBTUP is already handling
       DROP_TRIG_IMPL_REQ signals at full capacity, rather than
       queueing up the DROP_TRIG_IMPL_REQ signals.
       (Bug#26574003)

     * Having a large number of deferred triggers could
       sometimes lead to job buffer exhaustion. This could occur
       due to the fact that a single trigger can execute many
       operations---for example, a foreign key parent trigger
       may perform operations on multiple matching child table
       rows---and that a row operation on a base table can
       execute multiple triggers. In such cases, row operations
       are executed in batches. When execution of many triggers
       was deferred---meaning that all deferred triggers are
       executed at pre-commit---the resulting concurrent
       execution of a great many trigger operations could cause
       the data node job buffer or send buffer to be exhausted,
       leading to failure of the node.
       This issue is fixed by limiting the number of concurrent
       trigger operations as well as the number of trigger fire
       requests outstanding per transaction.
       For immediate triggers, limiting of concurrent trigger
       operations may increase the number of triggers waiting to
       be executed, exhausting the trigger record pool and
       resulting in the error Too many concurrently fired
       triggers (increase MaxNoOfFiredTriggers. This can be
       avoided by increasing MaxNoOfFiredTriggers
       ( http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-ndbd-definition.html#ndbparam-ndbd-maxnooffiredtriggers ),
       reducing the user transaction batch size, or both.
       (Bug#22529864)
       References: See also: Bug #18229003, Bug #27310330.

     * When moving an OperationRec from the serial to the
       parallel queue, Dbacc::startNext() failed to update the
       Operationrec::OP_ACC_LOCK_MODE flag which is required to
       reflect the accumulated OP_LOCK_MODE of all previous
       operations in the parallel queue. This inconsistency in
       the ACC lock queues caused the scan lock takeover
       mechanism to fail, as it incorrectly concluded that a
       lock to take over was not held. The same failure caused
       an assert when aborting an operation that was a member of
       such an inconsistent parallel lock queue. (Bug #92100,
       Bug #28530928)

     * DBTUP sent the error Tuple corruption detected when a
       read operation attempted to read the value of a tuple
       inserted within the same transaction. (Bug #92009,
       Bug#28500861)

     * False constraint violation errors could occur when
       executing updates on self-referential foreign keys.
       (Bug#91965, Bug #28486390)
       References: See also: Bug #90644, Bug #27930382.

     * An NDB internal trigger definition could be dropped while
       pending instances of the trigger remained to be executed,
       by attempting to look up the definition for a trigger
       which had already been released. This caused
       unpredictable and thus unsafe behavior possibly leading
       to data node failure. The root cause of the issue lay in
       an invalid assumption in the code relating to determining
       whether a given trigger had been released; the issue is
       fixed by ensuring that the behavior of NDB, when a
       trigger definition is determined to have been released,
       is consistent, and that it meets expectations.
       (Bug#91894, Bug #28451957)

     * In certain cases, a cascade update trigger was fired
       repeatedly on the same record, which eventually consumed
       all available concurrent operations, leading to Error 233
       Out of operation records in transaction coordinator
       (increase MaxNoOfConcurrentOperations). If
       MaxNoOfConcurrentOperations
       ( http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-ndbd-definition.html#ndbparam-ndbd-maxnoofconcurrentoperations )
       was set to a value sufficiently high to avoid this,
       the issue manifested as data nodes consuming very large
       amounts of CPU, very likely eventually leading to a
       timeout. (Bug #91472, Bug #28262259)

     * Inserting a row into an NDB
       ( http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster.html )
       table having a self-referencing foreign key that
       referenced a unique index on the table other than the
       primary key failed with ER_NO_REFERENCED_ROW_2
       ( http://dev.mysql.com/doc/refman/5.7/en/error-messages-server.html#error_er_no_referenced_row_2 ).
       This was due tothe fact that NDB checked foreign key constraints 
       before the unique index was updated, so that the constraint
       check was unable to use the index for locating the row.
       Now, in such cases, NDB waits until all unique index
       values have been updated before checking foreign key
       constraints on the inserted row. (Bug #90644,
       Bug#27930382)
       References: See also: Bug #91965, Bug #28486390.

On Behalf of Oracle/MySQL Release Engineering Team
Prashant Tekriwal

Dear MySQL Users,

MySQL Cluster is the distributed database combining massive
scalability and high availability. It provides in-memory
real-time access with transactional consistency across
partitioned and distributed datasets. It is designed for
mission critical applications.

MySQL Cluster has replication between clusters across multiple
geographical sites built-in. A shared nothing architecture with
data locality awareness make it the perfect choice for running
on commodity hardware and in globally distributed cloud
infrastructure.


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
  - Transactional consistency across partitioned and distributed datasets
  - Parallel cross partition queries such as joins

  - 99.9999% 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.13-dmr, 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/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.13 (2018-10-23, Development Milestone)

   MySQL NDB Cluster 8.0.13 is a new development 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 8.0

(http://dev.mysql.com/doc/refman/8.0/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.13 (see Changes in MySQL 8.0.13 (2018-10-22)
(http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html)).

     * Functionality Added or Changed

     * Bugs Fixed

Functionality Added or Changed


     * Important Change; NDB Disk Data: The following changes
       are made in the display of information about Disk Data
       files in the INFORMATION_SCHEMA.FILES table:

          + Tablespaces and log file groups are no longer
            represented in the FILES table. (These constructs
            are not actually files.)

          + Each data file is now represented by a single row in
            the FILES table. Each undo log file is also now
            represented in this table by one row only.
            (Previously, a row was displayed for each copy of
            each of these files on each data node.)

          + For rows corresponding to data files or undo log
            files, node ID and undo log buffer information is no
            longer displayed in the EXTRA column of the FILES
            table.

     * Important Change; NDB Client Programs: Removed the
       deprecated --ndb option for perror. Use ndb_perror to
       obtain error message information from NDB error codes
       instead. (Bug #81705, Bug #23523957)
       References: See also: Bug #81704, Bug #23523926.

     * Important Change: Beginning with this release, MySQL NDB
       Cluster is being developed in parallel with the standard
       MySQL 8.0 server under a new unified release model with
       the following features:

          + NDB 8.0 is developed in, built from, and released
            with the MySQL 8.0 source code tree.

          + The numbering scheme for NDB Cluster 8.0 releases
            follows the scheme for MySQL 8.0, starting with the
            current MySQL release (8.0.13).

          + Building the source with NDB support appends
            -cluster to the version string returned by mysql -V,
            as shown here:
            shell≫ mysql -V
            mysql  Ver 8.0.13-cluster for Linux on x86_64 (Source distribution)

            NDB binaries continue to display both the MySQL
            Server version and the NDB engine version, like
            this:
            shell> ndb_mgm -V
            MySQL distrib mysql-8.0.13 ndb-8.0.13-dmr, for Linux (x86_64)

            In MySQL Cluster NDB 8.0, these two version numbers
            are always the same.
       To build the MySQL 8.0.13 (or later) source with NDB
       Cluster support, use the CMake option -DWITH_NDBCLUSTER.

     * INFORMATION_SCHEMA tables now are populated with
       tablespace statistics for MySQL Cluster tables. (Bug
       #27167728)

     * It is now possible to specify a set of cores to be used
       for I/O threads performing offline multithreaded builds
       of ordered indexes, as opposed to normal I/O duties such
       as file I/O， compression， or decompression. "Offline" in
       this context refers to building of ordered indexes
       performed when the parent table is not being written to;
       such building takes place when an NDB cluster performs a
       node or system restart, or as part of restoring a cluster
       from backup using ndb_restore --rebuild-indexes.
       In addition, the default behaviour for offline index
       build work is modified to use all cores available to
       ndbmtd, rather limiting itself to the core reserved for
       the I/O thread. Doing so can improve restart and restore
       times and performance, availability, and the user
       experience.
       This enhancement is implemented as follows:

         1. The default value for BuildIndexThreads is changed
            from 0 to 128. This means that offline ordered index
            builds are now multithreaded by default.

         2. The default value for TwoPassInitialNodeRestartCopy
            is changed from false to true. This means that an
            initial node restart first copies all data from a
            "live" node to one that is starting---without
            creating any indexes---builds ordered indexes
            offline, and then again synchronizes its data with
            the live node, that is, synchronizing twice and
            building indexes offline between the two
            synchonizations. This causes an initial node restart
            to behave more like the normal restart of a node,
            and reduces the time required for building indexes.

         3. A new thread type (idxbld) is defined for the
            ThreadConfig configuration parameter, to allow
            locking of offline index build threads to specific
            CPUs.
       In addition, NDB now distinguishes the thread types that
       are accessible to "ThreadConfig" by the following two
       criteria:

         1. Whether the thread is an execution thread. Threads
            of types main, ldm, recv, rep, tc, and send are
            execution threads; thread types io, watchdog, and
            idxbld are not.

         2. Whether the allocation of the thread to a given task
            is permanent or temporary. Currently all thread
            types except idxbld are permanent.
       For additonal information, see the descriptions of the
       parameters in the Manual. (Bug #25835748, Bug #26928111)

     * When performing an NDB backup, the ndbinfo.logbuffers
       table now displays information regarding buffer usage by
       the backup process on each data node. This is implemented
       as rows reflecting two new log types in addition to REDO
       and DD-UNDO. One of these rows has the log type
       BACKUP-DATA, which shows the amount of data buffer used
       during backup to copy fragments to backup files. The
       other row has the log type BACKUP-LOG, which displays the
       amount of log buffer used during the backup to record
       changes made after the backup has started. One each of
       these log_type rows is shown in the logbuffers table for
       each data node in the cluster. Rows having these two log
       types are present in the table only while an NDB backup
       is currently in progress. (Bug #25822988)

     * Added the ODirectSyncFlag configuration parameter for
       data nodes. When enabled, the data node treats all
       completed filesystem writes to the redo log as though
       they had been performed using fsync.
       Note
       This parameter has no effect if at least one of the
       following conditions is true:

          + ODirect is not enabled.

          + InitFragmentLogFiles is set to SPARSE.
       (Bug #25428560)

     * Added the --logbuffer-size option for ndbd and ndbmtd,
       for use in debugging with a large number of log messages.
       This controls the size of the data node log buffer; the
       default (32K) is intended for normal operations. (Bug
       #89679, Bug #27550943)

     * Prior to NDB 8.0, all string hashing was based on first
       transforming the string into a normalized form, then
       MD5-hashing the resulting binary image. This could give
       rise to some performance problems, for the following
       reasons:

          + The normalized string is always space padded to its
            full length. For a VARCHAR, this often involved
            adding more spaces than there were characters in the
            original string.

          + The string libraries were not optimized for this
            space padding, and added considerable overhead in
            some use cases.

          + The padding semantics varied between character sets,
            some of which were not padded to their full length.

          + The transformed string could become quite large,
            even without space padding; some Unicode 9.0
            collations can transform a single code point into
            100 bytes of character data or more.

          + Subsequent MD5 hashing consisted mainly of padding
            with spaces, and was not particularly efficient,
            possibly causing additional performance penalties by
            flush significant portions of the L1 cache.
       Collations provide their own hash functions, which hash
       the string directly without first creating a normalized
       string. In addition, for Unicode 9.0 collations, the
       hashes are computed without padding. NDB now takes
       advantage of this built-in function whenever hashing a
       string identified as using a Unicode 9.0 collation.
       Since, for other collations there are existing databases
       which are hash partitioned on the transformed string, NDB
       continues to employ the previous method for hashing
       strings that use these, to maintain compatibility. (Bug
       #89609, Bug #27523758)
       References: See also: Bug #89590, Bug #27515000, Bug
       #89604, Bug #27522732.

     * A table created in NDB 7.6 and earlier contains metadata
       in the form of a compressed .frm file, which is no longer
       supported in MySQL 8.0. To facilitate online upgrades to
       NDB 8.0, NDB performs on-the-fly translation of this
       metadata and writes it into the MySQL Server's data
       dictionary, which enables the mysqld in NDB Cluster 8.0
       to work with the table without preventing subsequent use
       of the table by a previous version of the NDB software.
       Important
       Once a table's structure has been modified in NDB 8.0,
       its metadata is stored using the Data Dictionary, and it
       can no longer be accessed by NDB 7.6 and earlier.
       This enhancement also makes it possible to restore an NDB
       backup made using an earlier version to a cluster running
       NDB 8.0 (or later).


Bugs Fixed


     * Important Change; NDB Disk Data: It was possible to issue
       a CREATE TABLE statement that referred to a nonexistent
       tablespace. Now such a statement fails with an error.
       (Bug #85859, Bug #25860404)

     * Important Change; NDB Replication: Because the MySQL
       Server now executes RESET MASTER with a global read lock,
       the behavior of this statement when used with NDB Cluster
       has changed in the following two respects:

          + It is no longer guaranteed to be synchronous; that
            is, it is now possible that a read coming
            immediately before RESET MASTER is issued may not be
            logged until after the binary log has been rotated.

          + It now behaves identically, regardless of whether
            the statement is issued on the same SQL node that is
            writing the binary log, or on a different SQL node
            in the same cluster.
       Note
       SHOW BINLOG EVENTS, FLUSH LOGS, and most data definition
       statements continue, as they did in previous NDB
       versions, to operate in a synchronous fashion.
       (Bug #89976, Bug #27665565)

     * Important Change: NDB supports any of the following three
       values for the CREATE TABLE statement's ROW_FORMAT
       option: DEFAULT, FIXED, and DYNAMIC. Formerly, any values
       other than these were accepted but resulted in DYNAMIC
       being used. Now a CREATE TABLE statement that attempts to
       create an NDB table fails with an error if ROW_FORMAT is
       used, and does not have one of the three values listed.
       (Bug #88803, Bug #27230898)

     * Microsoft Windows; ndbinfo Information Database: The
       process ID of the monitor process used on Windows
       platforms by RESTART to spawn and restart a mysqld is now
       shown in the ndbinfo.processes table as an angel_pid.
       (Bug #90235, Bug #27767237)

     * NDB Cluster APIs: The example NDB API programs
       ndbapi_array_simple and ndbapi_array_using_adapter did
       not perform cleanup following execution; in addition, the
       example program ndbapi_simple_dual did not check to see
       whether the table used by this example already existed.
       Due to these issues, none of these examples could be run
       more than once in succession.
       The issues just described have been corrected in the
       example sources, and the relevant code listings in the
       NDB API documentation have been updated to match. (Bug
       #27009386)

     * NDB Cluster APIs: A previous fix for an issue, in which
       the failure of multiple data nodes during a partial
       restart could cause API nodes to fail, did not properly
       check the validity of the associated NdbReceiver object
       before proceeding. Now in such cases an invalid object
       triggers handling for invalid signals, rather than a node
       failure. (Bug #25902137)
       References: This issue is a regression of: Bug #25092498.

     * NDB Cluster APIs: Incorrect results, usually an empty
       result set, were returned when setBound() was used to
       specify a NULL bound. This issue appears to have been
       caused by a problem in gcc, limited to cases using the
       old version of this method (which does not employ
       NdbRecord), and is fixed by rewriting the problematic
       internal logic in the old implementation. (Bug #89468,
       Bug #27461752)

     * NDB Cluster APIs: Released NDB API objects are kept in
       one or more Ndb_free_list structures for later reuse.
       Each list also keeps track of all objects seized from it,
       and makes sure that these are eventually released back to
       it. In the event that the internal function
       NdbScanOperation::init() failed, it was possible for an
       NdbApiSignal already allocated by the NdbOperation to be
       leaked. Now in such cases, NdbScanOperation::release() is
       called to release any objects allocated by the failed
       NdbScanOperation before it is returned to the free list.
       This fix also handles a similar issue with
       NdbOperation::init(), where a failed call could also leak
       a signal. (Bug #89249, Bug #27389894)

     * NDB Cluster APIs: Removed the unused TFSentinel
       implementation class, which raised compiler warnings on
       32-bit systems. (Bug #89005, Bug #27302881)

     * NDB Cluster APIs: The success of thread creation by API
       calls was not always checked, which could lead to
       timeouts in some cases. (Bug #88784, Bug #27225714)

     * ndbinfo Information Database: Counts of committed rows
       and committed operations per fragment used by some tables
       in ndbinfo were taken from the DBACC block, but due to
       the fact that commit signals can arrive out of order,
       transient counter values could be negative. This could
       happen if, for example, a transaction contained several
       interleaved insert and delete operations on the same row;
       in such cases, commit signals for delete operations could
       arrive before those for the corresponding insert
       operations, leading to a failure in DBACC.
       This issue is fixed by using the counts of committed rows
       which are kept in DBTUP, which do not have this problem.
       (Bug #88087, Bug #26968613)

     * NDB Client Programs: When passed an invalid connection
       string, the ndb_mgm client did not always free up all
       memory used before exiting. (Bug #90179, Bug #27737906)

     * NDB Client Programs: ndb_show_tables did not always free
       up all memory which it used. (Bug #90152, Bug #27727544)

     * NDB Client Programs: On Unix platforms, the
       Auto-Installer failed to stop the cluster when ndb_mgmd
       was installed in a directory other than the default. (Bug
       #89624, Bug #27531186)

     * NDB Client Programs: The Auto-Installer did not provide a
       mechanism for setting the ServerPort parameter. (Bug
       #89623, Bug #27539823)

     * MySQL NDB ClusterJ: When a table containing a BLOB or a
       TEXT field was being queried with ClusterJ for a record
       that did not exist, an exception ("The method is not
       valid in current blob state") was thrown. (Bug #28536926)

     * MySQL NDB ClusterJ: ClusterJ quit unexpectedly as there
       was no error handling in the scanIndex() function of the
       ClusterTransactionImpl class for a null returned to it
       internally by the scanIndex() method of the
       ndbTransaction class. (Bug #27297681, Bug #88989)

     * Local checkpoints did not always handle DROP TABLE
       operations correctly. (Bug #27926532)
       References: This issue is a regression of: Bug #26908347,
       Bug #26968613.

     * In some circumstances, when a transaction was aborted in
       the DBTC block, there remained links to trigger records
       from operation records which were not yet
       reference-counted, but when such an operation record was
       released the trigger reference count was still
       decremented. (Bug #27629680)

     * NDB attempted to drop subscriptions which had already
       been dropped, leading to a data node shutdown with Error
       2341. (Bug #27622643)

     * An NDB online backup consists of data, which is fuzzy,
       and a redo and undo log. To restore to a consistent state
       it is necessary to ensure that the log contains all of
       the changes spanning the capture of the fuzzy data
       portion and beyond to a consistent snapshot point. This
       is achieved by waiting for a GCI boundary to be passed
       after the capture of data is complete, but before
       stopping change logging and recording the stop GCI in the
       backup's metadata.
       At restore time, the log is replayed up to the stop GCI,
       restoring the system to the state it had at the
       consistent stop GCI. A problem arose when, under load, it
       was possible to select a GCI boundary which occurred too
       early and did not span all the data captured. This could
       lead to inconsistencies when restoring the backup; these
       could be be noticed as broken constraints or corrupted
       BLOB entries.
       Now the stop GCI is chosen is so that it spans the entire
       duration of the fuzzy data capture process, so that the
       backup log always contains all data within a given stop
       GCI. (Bug #27497461)
       References: See also: Bug #27566346.

     * For NDB tables, when a foreign key was added or dropped
       as a part of a DDL statement, the foreign key metatdata
       for all parent tables referenced should be reloaded in
       the handler on all SQL nodes connected to the cluster,
       but this was done only on the mysqld on which the
       statement was executed. Due to this, any subsequent
       queries relying on foreign key metadata from the
       corresponding parent tables could return inconsistent
       results. (Bug #27439587)
       References: See also: Bug #82989, Bug #24666177.

     * ANALYZE TABLE used excessive amounts of CPU on large,
       low-cardinality tables. (Bug #27438963)

     * Queries using very large lists with IN were not handled
       correctly, which could lead to data node failures. (Bug
       #27397802)

     * A data node overload could in some situations lead to an
       unplanned shutdown of the data node, which led to all
       data nodes disconnecting from the management and nodes.
       This was due to a situation in which API_FAILREQ was not
       the last received signal prior to the node failure.
       As part of this fix, the transaction coordinator's
       handling of SCAN_TABREQ signals for an ApiConnectRecord
       in an incorrect state was also improved. (Bug #27381901)
       References: See also: Bug #47039, Bug #11755287.

     * In a two-node cluster, when the node having the lowest ID
       was started using --nostart, API clients could not
       connect, failing with Could not alloc node id at HOST
       port PORT_NO: No free node id found for mysqld(API). (Bug
       #27225212)

     * Changing MaxNoOfExecutionThreads without an initial
       system restart led to an unplanned data node shutdown.
       (Bug #27169282)
       References: This issue is a regression of: Bug #26908347,
       Bug #26968613.

     * In most cases, and especially in error conditions, NDB
       command-line programs failed on exit to free memory used
       by option handling, and failed to call ndb_end(). This is
       fixed by removing the internal methods
       ndb_load_defaults() and ndb_free_defaults() from
       storage/ndb/include/util/ndb_opts.h, and replacing these
       with an Ndb_opts class that automatically frees such
       resources as part of its destructor. (Bug #26930148)
       References: See also: Bug #87396, Bug #26617328.

     * A query against the INFORMATION_SCHEMA.FILES table
       returned no results when it included an ORDER BY clause.
       (Bug #26877788)

     * ClusterJ failed to connect to a MySQL node that used
       utf8mb4_800_ci_ai as its default character set for
       connection. Also, ClusterJ quit unexpectedly when
       handling a table with a character set number of 255 or
       larger. This fix corrected both issues. (Bug #26027722)

     * During a restart, DBLQH loads redo log part metadata for
       each redo log part it manages, from one or more redo log
       files. Since each file has a limited capacity for
       metadata, the number of files which must be consulted
       depends on the size of the redo log part. These files are
       opened, read, and closed sequentially, but the closing of
       one file occurs concurrently with the opening of the
       next.
       In cases where closing of the file was slow, it was
       possible for more than 4 files per redo log part to be
       open concurrently; since these files were opened using
       the OM_WRITE_BUFFER option, more than 4 chunks of write
       buffer were allocated per part in such cases. The write
       buffer pool is not unlimited; if all redo log parts were
       in a similar state, the pool was exhausted, causing the
       data node to shut down.
       This issue is resolved by avoiding the use of
       OM_WRITE_BUFFER during metadata reload, so that any
       transient opening of more than 4 redo log files per log
       file part no longer leads to failure of the data node.
       (Bug #25965370)

     * Under certain conditions, data nodes restarted
       unnecessarily during execution of ALTER TABLE...
       REORGANIZE PARTITION. (Bug #25679639)

     * Race conditions sometimes occurred during asynchronous
       disconnection and reconnection of the transporter while
       other threads concurrently inserted signal data into the
       send buffers, leading to an unplanned shutdown of the
       cluster.
       As part of the work fixing this issue, the internal
       templating function used by the Transporter Registry when
       it prepares a send is refactored to use
       likely-or-unlikely logic to speed up execution, and to
       remove a number of duplicate checks for NULL. (Bug
       #24444908, Bug #25128512)
       References: See also: Bug #20112700.

     * ndb_restore sometimes logged data file and log file
       progress values much greater than 100%. (Bug #20989106)

     * Removed unneeded debug printouts from the internal
       function ha_ndbcluster::copy_fk_for_offline_alter(). (Bug
       #90991, Bug #28069711)

     * The internal function BitmaskImpl::setRange() set one bit
       fewer than specified. (Bug #90648, Bug #27931995)

     * Inserting a row into an NDB table having a
       self-referencing foreign key that referenced a unique
       index on the table other than the primary key failed with
       ER_NO_REFERENCED_ROW_2. This was due to the fact that NDB
       checked foreign key constraints before the unique index
       was updated, so that the constraint check was unable to
       use the index for locating the row. Now, in such cases,
       NDB waits until all unique index values have been updated
       before checking foreign key constraints on the inserted
       row. (Bug #90644, Bug #27930382)
       References: See also: Bug #91965, Bug #28486390.

     * Removed all references to the C++ register storage class
       in the NDB Cluster sources; use of this specifier, which
       was deprecated in C++11 and removed in C++17, raised
       warnings when building with recent compilers. (Bug
       #90110, Bug #27705985)

     * It was not possible to create an NDB table using
       PARTITION_BALANCE set to FOR_RA_BY_LDM_X_2,
       FOR_RA_BY_LDM_X_3, or FOR_RA_BY_LDM_X_4. (Bug #89811, Bug
       #27602352)
       References: This issue is a regression of: Bug #81759,
       Bug #23544301.

     * Adding a [tcp] or [shm] section to the global
       configuration file for a cluster with multiple data nodes
       caused default TCP connections to be lost to the node
       using the single section. (Bug #89627, Bug #27532407)

     * Removed a memory leak in the configuration file parser.
       (Bug #89392, Bug #27440614)

     * Fixed a number of implicit-fallthrough warnings, warnings
       raised by uninitialized values, and other warnings
       encountered when compiling NDB with GCC 7.2.0. (Bug
       #89254, Bug #89255, Bug #89258, Bug #89259, Bug #89270,
       Bug #27390714, Bug #27390745, Bug #27390684, Bug
       #27390816, Bug #27396662)
       References: See also: Bug #88136, Bug #26990244.

     * Node connection states were not always reported correctly
       by ClusterMgr immediately after reporting a
       disconnection. (Bug #89121, Bug #27349285)

     * As a result of the reuse of code intended for send
       threads when performing an assist send, all of the local
       release send buffers were released to the global pool,
       which caused the intended level of the local send buffer
       pool to be ignored. Now send threads and assisting worker
       threads follow their own policies for maintaining their
       local buffer pools. (Bug #89119, Bug #27349118)

     * When the PGMAN block seized a new Page_request record
       using seizeLast, its return value was not checked, which
       could cause access to invalid memory. (Bug #89009, Bug
       #27303191)

     * TCROLLBACKREP signals were not handled correctly by the
       DBTC kernel block. (Bug #89004, Bug #27302734)

     * When sending priority A signals, we now ensure that the
       number of pending signals is explicitly initialized. (Bug
       #88986, Bug #27294856)

     * The internal function ha_ndbcluster::unpack_record() did
       not perform proper error handling. (Bug #88587, Bug
       #27150980)

     * CHECKSUM is not supported for NDB tables, but this was
       not not reflected in the CHECKSUM column of the
       INFORMATION_SCHEMA.TABLES table, which could potentially
       assume a random value in such cases. Now the value of
       this column is always set to NULL for NDB tables, just as
       it is for InnoDB tables. (Bug #88552, Bug #27143813)

     * Removed a memory leak detected when running ndb_mgm -e
       "CLUSTERLOG ...". (Bug #88517, Bug #27128846)

     * When terminating, ndb_config did not release all memory
       which it had used. (Bug #88515, Bug #27128398)

     * ndb_restore did not free memory properly before exiting.
       (Bug #88514, Bug #27128361)

     * In certain circumstances where multiple Ndb objects were
       being used in parallel from an API node, the block number
       extracted from a block reference in DBLQH was the same as
       that of a SUMA block even though the request was coming
       from an API node. Due to this ambiguity, DBLQH mistook
       the request from the API node for a request from a SUMA
       block and failed. This is fixed by checking node IDs
       before checking block numbers. (Bug #88441, Bug
       #27130570)

     * A join entirely within the materialized part of a
       semi-join was not pushed even if it could have been. In
       addition, EXPLAIN provided no information about why the
       join was not pushed. (Bug #88224, Bug #27022925)
       References: See also: Bug #27067538.

     * All known compiler warnings raised by -Werror when
       building the NDB source code have been fixed. (Bug
       #88136, Bug #26990244)

     * When the duplicate weedout algorithm was used for
       evaluating a semi-join, the result had missing rows. (Bug
       #88117, Bug #26984919)
       References: See also: Bug #87992, Bug #26926666.

     * NDB did not compile with GCC 7. (Bug #88011, Bug
       #26933472)

     * A table used in a loose scan could be used as a child in
       a pushed join query, leading to possibly incorrect
       results. (Bug #87992, Bug #26926666)

     * When representing a materialized semi-join in the query
       plan, the MySQL Optimizer inserted extra QEP_TAB and
       JOIN_TAB objects to represent access to the materialized
       subquery result. The join pushdown analyzer did not
       properly set up its internal data structures for these,
       leaving them uninitialized instead. This meant that later
       usage of any item objects referencing the materialized
       semi-join accessed an initialized tableno column when
       accessing a 64-bit tableno bitmask, possibly referring to
       a point beyond its end, leading to an unplanned shutdown
       of the SQL node. (Bug #87971, Bug #26919289)

     * In some cases, a SCAN_FRAGCONF signal was received after
       a SCAN_FRAGREQ with a close flag had already been sent,
       clearing the timer. When this occurred, the next
       SCAN_FRAGREF to arrive caused time tracking to fail. Now
       in such cases, a check for a cleared timer is performed
       prior to processing the SCAN_FRAGREF message. (Bug
       #87942, Bug #26908347)

     * While deleting an element in Dbacc, or moving it during
       hash table expansion or reduction, the method used
       (getLastAndRemove()) could return a reference to a
       removed element on a released page, which could later be
       referenced from the functions calling it. This was due to
       a change brought about by the implementation of dynamic
       index memory in NDB 7.6.2; previously, the page had
       always belonged to a single Dbacc instance, so accessing
       it was safe. This was no longer the case following the
       change; a page released in Dbacc could be placed directly
       into the global page pool where any other thread could
       then allocate it.
       Now we make sure that newly released pages in Dbacc are
       kept within the current Dbacc instance and not given over
       directly to the global page pool. In addition, the
       reference to a released page has been removed; the
       affected internal method now returns the last element by
       value, rather than by reference. (Bug #87932, Bug
       #26906640)
       References: See also: Bug #87987, Bug #26925595.

     * When creating a table with a nonexistent conflict
       detection function, NDB returned an improper error
       message. (Bug #87628, Bug #26730019)

     * ndb_top failed to build with the error "HAVE_NCURSESW_H"
       is not defined. (Bug #87035, Bug #26429281)

     * In a MySQL Cluster with one MySQL Server configured to
       write a binary log failure occurred when creating and
       using an NDB table with non-stored generated columns. The
       problem arose only when the product was built with
       debugging support. (Bug #86084, Bug #25957586)

     * It was possible to create or alter a STORAGE MEMORY table
       using a nonexistent tablespace without any error
       resulting. Such an operation now fails with Error 3510
       ER_TABLESPACE_MISSING_WITH_NAME, as intended. (Bug
       #82116, Bug #23744378)

     * ndb_restore --print_data --hex did not print trailing 0s
       of LONGVARBINARY values. (Bug #65560, Bug #14198580)

     * When the internal function
       ha_ndbcluster::copy_fk_for_offline_alter() checked
       dependent objects on a table from which it was supposed
       to drop a foreign key, it did not perform any filtering
       for foreign keys, making it possible for it to attempt
       retrieval of an index or trigger instead, leading to a
       spurious Error 723 (No such table).

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

Dear MySQL Users,

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

  - In-Memory storage - Real-time performance
  - 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.4 makes significant advances in performance;
operational efficiency (such as enhanced reporting and faster restarts
and upgrades) and conflict detection and resolution for active-active
replication between MySQL Clusters.

MySQL Cluster 7.4.22, 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.4/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.4.22 (5.6.42-ndb-7.4.22) (2018-10-23, General Availability)

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

   Obtaining MySQL NDB Cluster 7.4.  MySQL NDB Cluster 7.4
   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.4, see
   What is New in NDB Cluster 7.4
   (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-what-is-new-7-4.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.42 (see Changes in MySQL 5.6.42 (Not yet
   released, General Availability)
   (http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-42.html)).

Bugs Fixed

     * MySQL NDB ClusterJ: When a table containing a BLOB or a
       TEXT field was being queried with ClusterJ for a record
       that did not exist, an exception ("The method is not
       valid in current blob state") was thrown. (Bug #28536926)

     * MySQL NDB ClusterJ: A NullPointerException was thrown
       when a full table scan was performed with ClusterJ on
       tables containing either a BLOB or a TEXT field. It was
       because the proper object initializations were omitted,
       and they have now been added by this fix. (Bug #28199372,
       Bug #91242)

     * When the SUMA kernel block receives a SUB_STOP_REQ
       signal, it executes the signal then replies with
       SUB_STOP_CONF. (After this response is relayed back to
       the API, the API is open to send more SUB_STOP_REQ
       signals.) After sending the SUB_STOP_CONF, SUMA drops the
       subscription if no subscribers are present, which
       involves sending multiple DROP_TRIG_IMPL_REQ messages to
       DBTUP. LocalProxy can handle up to 21 of these requests
       in parallel; any more than this are queued in the Short
       Time Queue. When execution of a DROP_TRIG_IMPL_REQ was
       delayed, there was a chance for the queue to become
       overloaded, leading to a data node shutdown with Error in
       short time queue.
       This issue is fixed by delaying the execution of the
       SUB_STOP_REQ signal if DBTUP is already handling
       DROP_TRIG_IMPL_REQ signals at full capacity, rather than
       queueing up the DROP_TRIG_IMPL_REQ signals. (Bug
       #26574003)

     * Having a large number of deferred triggers could
       sometimes lead to job buffer exhaustion. This could occur
       due to the fact that a single trigger can execute many
       operations---for example, a foreign key parent trigger
       may perform operations on multiple matching child table
       rows---and that a row operation on a base table can
       execute multiple triggers. In such cases, row operations
       are executed in batches. When execution of many triggers
       was deferred---meaning that all deferred triggers are
       executed at pre-commit---the resulting concurrent
       execution of a great many trigger operations could cause
       the data node job buffer or send buffer to be exhausted,
       leading to failure of the node.
       This issue is fixed by limiting the number of concurrent
       trigger operations as well as the number of trigger fire
       requests outstanding per transaction.
       For immediate triggers, limiting of concurrent trigger
       operations may increase the number of triggers waiting to
       be executed, exhausting the trigger record pool and
       resulting in the error Too many concurrently fired
       triggers (increase MaxNoOfFiredTriggers. This can be
       avoided by increasing MaxNoOfFiredTriggers, reducing the
       user transaction batch size, or both. (Bug #22529864)
       References: See also: Bug #18229003, Bug #27310330.

On Behalf of MySQL Release Engineering team,
-Sreedhar S 

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.6.8, 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.6 is also available from our repository for Linux
platforms, go here for details:

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

The release notes are available from

  http://dev.mysql.com/doc/relnotes/mysql-cluster/7.6/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.6.8 (5.7.24-ndb-7.6.8) (2018-10-23, General Availability)

   MySQL NDB Cluster 7.6.8 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
   (http://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.24 (see Changes in MySQL 5.7.24 (2018-10-22, General Availability)
   (http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-24.html)).


Functionality Added or Changed


     * Performance: This release introduces a number of
       significant improvements in the performance of scans;
       these are listed here:

          + Row checksums help detect hardware issues, but do so
            at the expense of performance. NDB now offers the
            possibility of disabling these by setting the new
            ndb_row_checksum server system variable to 0; doing
            this means that row checksums are not used for new
            or altered tables. This can have a significant
            impact (5 to 10 percent, in some cases) on
            performance for all types of queries. This variable
            is set to 1 by default, to provide compatibility
            with the previous behavior.

          + A query consisting of a scan can execute for a
            longer time in the LDM threads when the queue is not
            busy.

          + Previously, columns were read before checking a
            pushed condition; now checking of a pushed condition
            is done before reading any columns.

          + Performance of pushed joins should see significant
            improvement when using range scans as part of join
            execution.

Bugs Fixed


     * Packaging: Expected NDB header files were in the devel
       RPM package instead of libndbclient-devel. (Bug #84580,
       Bug #26448330)

     * NDB Disk Data: While restoring a local checkpoint, it is
       possible to insert a row that already exists in the
       database; this is expected behavior which is handled by
       deleting the existing row first, then inserting the new
       copy of that row. In some cases involving data on disk,
       NDB failed to delete the existing row. (Bug #91627, Bug
       #28341843)

     * NDB Client Programs: Removed a memory leak in
       NdbImportUtil::RangeList that was revealed in ASAN
       builds. (Bug #91479, Bug #28264144)

     * MySQL NDB ClusterJ: When a table containing a BLOB or a
       TEXT field was being queried with ClusterJ for a record
       that did not exist, an exception ("The method is not
       valid in current blob state") was thrown. (Bug #28536926)

     * MySQL NDB ClusterJ: A NullPointerException was thrown
       when a full table scan was performed with ClusterJ on
       tables containing either a BLOB or a TEXT field. It was
       because the proper object initializations were omitted,
       and they have now been added by this fix. (Bug #28199372,
       Bug #91242)

     * When copying deleted rows from a live node to a node just
       starting, it is possible for one or more of these rows to
       have a global checkpoint index equal to zero. If this
       happened at the same time that a full local checkpoint
       was started due to the undo log getting full, the
       LCP_SKIP bit was set for a row having GCI = 0, leading to
       an unplanned shutdown of the data node. (Bug #28372628)

     * ndbmtd sometimes experienced a hang when exiting due to
       log thread shutdown. (Bug #28027150)

     * When the SUMA kernel block receives a SUB_STOP_REQ
       signal, it executes the signal then replies with
       SUB_STOP_CONF. (After this response is relayed back to
       the API, the API is open to send more SUB_STOP_REQ
       signals.) After sending the SUB_STOP_CONF, SUMA drops the
       subscription if no subscribers are present, which
       involves sending multiple DROP_TRIG_IMPL_REQ messages to
       DBTUP. LocalProxy can handle up to 21 of these requests
       in parallel; any more than this are queued in the Short
       Time Queue. When execution of a DROP_TRIG_IMPL_REQ was
       delayed, there was a chance for the queue to become
       overloaded, leading to a data node shutdown with Error in
       short time queue.
       This issue is fixed by delaying the execution of the
       SUB_STOP_REQ signal if DBTUP is already handling
       DROP_TRIG_IMPL_REQ signals at full capacity, rather than
       queueing up the DROP_TRIG_IMPL_REQ signals. (Bug
       #26574003)

     * Having a large number of deferred triggers could
       sometimes lead to job buffer exhaustion. This could occur
       due to the fact that a single trigger can execute many
       operations---for example, a foreign key parent trigger
       may perform operations on multiple matching child table
       rows---and that a row operation on a base table can
       execute multiple triggers. In such cases, row operations
       are executed in batches. When execution of many triggers
       was deferred---meaning that all deferred triggers are
       executed at pre-commit---the resulting concurrent
       execution of a great many trigger operations could cause
       the data node job buffer or send buffer to be exhausted,
       leading to failure of the node.
       This issue is fixed by limiting the number of concurrent
       trigger operations as well as the number of trigger fire
       requests outstanding per transaction.
       For immediate triggers, limiting of concurrent trigger
       operations may increase the number of triggers waiting to
       be executed, exhausting the trigger record pool and
       resulting in the error Too many concurrently fired
       triggers (increase MaxNoOfFiredTriggers. This can be
       avoided by increasing MaxNoOfFiredTriggers, reducing the
       user transaction batch size, or both. (Bug #22529864)
       References: See also: Bug #18229003, Bug #27310330.

     * ndbout and ndberr became invalid after exiting from
       mgmd_run(), and redirecting to them before the next call
       to mgmd_run() caused a segmentation fault, during an mgmd
       service restart. This fix ensures that ndbout and ndberr
       remain valid at all times. (Bug #17732772, Bug #28536919)

     * Running out of undo log buffer memory was reported using
       error 921 Out of transaction memory ... (increase
       SharedGlobalMemory).
       This problem is fixed by introducing a new error code 923
       Out of undo buffer memory (increase UNDO_BUFFER_SIZE).
       (Bug #92125, Bug #28537319)

     * When moving an OperationRec from the serial to the
       parallel queue, Dbacc::startNext() failed to update the
       Operationrec::OP_ACC_LOCK_MODE flag which is required to
       reflect the accumulated OP_LOCK_MODE of all previous
       operations in the parallel queue. This inconsistency in
       the ACC lock queues caused the scan lock takeover
       mechanism to fail, as it incorrectly concluded that a
       lock to take over was not held. The same failure caused
       an assert when aborting an operation that was a member of
       such an inconsistent parallel lock queue. (Bug #92100,
       Bug #28530928)

     * A data node failed during startup due to the arrival of a
       SCAN_FRAGREQ signal during the restore phase. This signal
       originated from a scan begun before the node had
       previously failed and which should have been aborted due
       to the involvement of the failed node in it. (Bug #92059,
       Bug #28518448)

     * DBTUP sent the error Tuple corruption detected when a
       read operation attempted to read the value of a tuple
       inserted within the same transaction. (Bug #92009, Bug
       #28500861)

     * False constraint violation errors could occur when
       executing updates on self-referential foreign keys. (Bug
       #91965, Bug #28486390)
       References: See also: Bug #90644, Bug #27930382.

     * An NDB internal trigger definition could be dropped while
       pending instances of the trigger remained to be executed,
       by attempting to look up the definition for a trigger
       which had already been released. This caused
       unpredictable and thus unsafe behavior possibly leading
       to data node failure. The root cause of the issue lay in
       an invalid assumption in the code relating to determining
       whether a given trigger had been released; the issue is
       fixed by ensuring that the behavior of NDB, when a
       trigger definition is determined to have been released,
       is consistent, and that it meets expectations. (Bug
       #91894, Bug #28451957)

     * In some cases, a workload that included a high number of
       concurrent inserts caused data node failures when using
       debug builds. (Bug #91764, Bug #28384750)

     * During an initial node restart with disk data tables
       present and TwoPassInitialNodeRestartCopy enabled, DBTUP
       used an unsafe scan in disk order. Such scans are no
       longer employed in this case. (Bug #91724, Bug #28378227)

     * Checking for old LCP files tested the table version, but
       this was not always dependable. Now, instead of relying
       on the table version, the check reagrds as invalid any
       LCP file having a maxGCI smaller than its createGci. (Bug
       #91637, Bug #28346565)

     * In certain cases, a cascade update trigger was fired
       repeatedly on the same record, which eventually consumed
       all available concurrent operations, leading to Error 233
       Out of operation records in transaction coordinator
       (increase MaxNoOfConcurrentOperations). If
       MaxNoOfConcurrentOperations was set to a value
       sufficiently high to avoid this, the issue manifested as
       data nodes consuming very large amounts of CPU, very
       likely eventually leading to a timeout. (Bug #91472, Bug
       #28262259)

     * Inserting a row into an NDB table having a
       self-referencing foreign key that referenced a unique
       index on the table other than the primary key failed with
       ER_NO_REFERENCED_ROW_2. This was due to the fact that NDB
       checked foreign key constraints before the unique index
       was updated, so that the constraint check was unable to
       use the index for locating the row. Now, in such cases,
       NDB waits until all unique index values have been updated
       before checking foreign key constraints on the inserted
       row. (Bug #90644, Bug #27930382)
       References: See also: Bug #91965, Bug #28486390.

     * A connection string beginning with a slash (/) character
       is now rejected by ndb_mgmd.
       Our thanks to Daniël van Eeden for contributing this fix.
       (Bug #90582, Bug #27912892)

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.23, 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.23 (5.6.42-ndb-7.3.23) (2018-10-23, General Availability)

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

   Obtaining MySQL NDB Cluster 7.3.  MySQL NDB Cluster 7.3
   source code and binaries can be obtained from
   http://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
(http://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.42 (see Changes in MySQL 5.6.42 (Not yet
   released, General Availability)
(http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-42.html)).

Bugs Fixed


     * Having a large number of deferred triggers could
       sometimes lead to job buffer exhaustion. This could occur
       due to the fact that a single trigger can execute many
       operations---for example, a foreign key parent trigger
       may perform operations on multiple matching child table
       rows---and that a row operation on a base table can
       execute multiple triggers. In such cases, row operations
       are executed in batches. When execution of many triggers
       was deferred---meaning that all deferred triggers are
       executed at pre-commit---the resulting concurrent
       execution of a great many trigger operations could cause
       the data node job buffer or send buffer to be exhausted,
       leading to failure of the node.
       This issue is fixed by limiting the number of concurrent
       trigger operations as well as the number of trigger fire
       requests outstanding per transaction.
       For immediate triggers, limiting of concurrent trigger
       operations may increase the number of triggers waiting to
       be executed, exhausting the trigger record pool and
       resulting in the error Too many concurrently fired
       triggers (increase MaxNoOfFiredTriggers. This can be
       avoided by increasing MaxNoOfFiredTriggers, reducing the
       user transaction batch size, or both. (Bug #22529864)
       References: See also: Bug #18229003, Bug #27310330.

On Behalf of Oracle/MySQL Release Engineering Team
Piotr Obrzut

Dear MySQL Users,

MySQL Cluster Manager 1.4.7 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.7 is listed below:

Changes in MySQL Cluster Manager 1.4.7  (2018-12-14)

 * Functionality Added or Changed

 * Bugs Fixed

Functionality Added or Changed


     * Agent: Performance has been improved for the add package
       command by removing unnecessary queries from its
       execution process. (Bug #28950231)

     * Agent: The initialization script for mcmd now cleans up
       the temporary files it creates under the tmp directory while
       starting new mcmd processes. (Bug #28924059)

     * Agent: The list hosts command now returns, in addition to
       Available and Unavailable, two more possible statuses for
       the agent of a host:

          + Recovery: The agent is in the process of recovering
            itself

          + Unresponsive: The agent rejected an attempt to
            connect
       (Bug #28438155)

     * Agent: The option --core-file
       http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-program-options-common.html#option_ndb_common_core-file,
       when used at the command line to start a node in a wild
       cluster, now causes the import cluster and update process
       commands to give a warning (that the option "may be
       removed on next restart of the process"), instead of
       causing the commands to fail. See Creating and
       Configuring the Target Cluster
       http://dev.mysql.com/doc/mysql-cluster-manager/1.4/en/mcm-using-import-cluster-create-configure.html 
       for details. (Bug #28177366)

     * Agent: The import cluster and update process commands now
       support a new --remove-angel option, which kills any
       angel processes for the data nodes to be imported or
       updated and also updates the data nodes' PID files. See
       descriptions for the two commands for details. (Bug
       #28116279)

     * Agent: The backup cluster command finishes faster now, as
       some unnecessary wait time has been eliminated from the
       backup process. (Bug #27986443)

     * Agent: A new option for mcmd, --initial, allows an agent
       that has fallen into an inconsistent state to recover its
       configuration from other agents. See the description for
       --initial for details. (Bug #20892397)

     * Agent: The set, get, and reset commands now support the
       following command-line-only attributes, which can only be
       configured at the command line when outside MySQL Cluster
       Manager:

          + For ndb_mgmd: --core-file, --log-name, --verbose

          + For ndbd and ndbmtd: --core-file, -- --verbose

     * Agent: The internal mechanism for agent recovery
       http://dev.mysql.com/doc/mysql-cluster-manager/1.4/en/mcm-using-restore-agent.html
       has been improved, making it more robust and less error-prone.

     * Client: To reduce the size of the mcmd log, node events
       are no longer dumped into the log during a cluster
       restart. (Bug #28843656)

     * Client: The message for ERROR 5200 ("Restore cannot be
       performed ...") has been expanded to include the reason
       for the restore's failure. (Bug #25075284)

     * Client: The message for ERROR 5017 has been expanded to
       include the reason for an action being invalid for a
       process or cluster. (Bug #22777846)

Bugs Fixed


     * Agent: During a rolling restart for a cluster (which
       takes place, for example, after a cluster
       reconfiguration), the node group IDs for some data nodes
       might become some invalid numbers transiently, and that
       might cause mcmd to throw an internal error (Error 1003).
       With this fix, such transient changes of node group IDs
       are ignored by mcmd, and no error is thrown. (Bug
       #28949173)

     * Agent: An update process command on a mysqld node failed
       with a timeout if the node was in the status of stopping.
       It was because mcmd did not retry stopping the node, and
       this fix makes it do so in the situation. (Bug #28913525)

     * Agent: After a cluster reconfiguration failed, the
       restart of an mcmd agent that had lost contact with other
       agents might fail with a checksum error. That was because
       in the process, the original configuration for the
       cluster was removed from the agent's repository by
       mistake. With this fix, the original cluster
       configuration was preserved and the agent restarts as
       expected. (Bug #28904775)

     * Agent: When trying to shutdown a mysqld node, if mcmd
       failed to get the MySQL Server's version number through a
       query, the shutdown failed because mcmd could not decide
       on the proper shutdown method. With this fix, mcmd falls
       back on the shutdown method for the MySQL Server version
       bundled with the mcmd version in the MySQL Cluster CGE
       distribution. (Bug #28830884)

     * Agent: Commands to reconfigure or stop a cluster hung
       when a mysqld node did not respond to queries. With this
       fix, under the situation, a query to a mysqld node times
       out after a certain period of time, after which the
       command for reconfiguring or stopping the cluster is
       aborted and an error is returned. (Bug #28813012)

     * Agent: mcmd hung when it failed to stop a data node that
       was in an unknown status. With this fix, the stop process
       command fails with an error in the situation. (Bug
       #28780427)

     * Agent: Attempts to restore an mcmd agent with data from
       other agents
       http://dev.mysql.com/doc/mysql-cluster-manager/1.4/en/mcm-using-restore-agent.html
       failed with the agent remaining in the state of recovering indefinitely,
       when any of the cluster log files was very long. With this
       fix, the agent only scans the most recent segments of the
       logs instead of the full logs for error information,
       which speeds up the restore process and allows it to be
       completed. (Bug #28671584)

     * Agent: In an environment that used only IP addresses, if
       a site was defined using host names, an mcmd agent hung
       at startup or restart when it attempted reverse DNS
       lookups. (Bug #28437469)

     * Agent: The collect logs command sometimes reported
       success before the operation was actually finished if the
       cluster had many hosts and a lot of log data to be
       collected. (Bug #28282932)

     * Agent: mcmd failed to start when its init.d script found
       the previous PID for mcmd was in use by another process,
       which was taken to mean mcmd was already running. With
       this fix, the process name for the PID is also checked,
       so that mcmd is started again if the PID is no longer
       used by mcmd. (Bug #28278727)

     * Agent: The collect log command failed with an ERROR 1003
       Internal error when no data was received on the TCP
       connection established for collecting data from another
       host. With this fix, the connection is closed gracefully
       if no data is received, allowing other hosts to connect
       to the TCP port and send data. (Bug #28278410)

     * Agent: The restore cluster command failed when the
       cluster to be restored contained databases with special
       characters in their names. (Bug #28220549)

     * Agent: Memory leaks occurred when an mcmd process on a
       management node read large cluster logs during its
       operations. This fix makes sure mcmd regularly truncates
       the buffer for log reading, so the buffer size does not
       keep growing in an uncontrolled manner. (Bug #28076545)

     * Agent: On Windows platforms, the collect logs command
       failed with an ERROR 1003 Internal error when the path
       name of a log file to be transferred was exactly 260
       characters. It was because, while 260 is the maximum
       number of characters allowed, the internal test forgot to
       count the trailing zero for the path name in the internal
       buffer, so it failed to catch the error. With this fix,
       mcmd throws an ERROR 106 Path max length exceeded for
       file instead in the situation. (Bug #28062069)

     * Agent: If mcmd was started on Windows platforms with the
       option --log-syslog being true but without specifying the
       --log-file option, running the show settings command
       would cause mcmd to quit with an Error 2013 (Lost
       connection to MySQL server during query). (Bug #27981362)

     * Agent: When, due to some reasons (for example, time jumps
       on virtual machines), an mcmd agent ended up receiving
       incomplete event records from an ndb_mgmd node, the agent
       quit unexpectedly. With this fix, mcmd can now parse and
       handle incomplete records properly. (Bug #25746295)

     * Agent: Agent recovery (for example, after upgrading the
       agents) sometimes failed when the agent received recovery
       configurations both locally and from a remote host, and
       the recovering process was then frustrated, With the new
       recovery mechanism now in place, the recovery
       configuration is only received once. (Bug #25517245)

     * Agent: The create site command failed with a timeout when
       the site to be created had a large number of hosts (more
       than 45), and the hosts were not uniform in their machine
       configurations. (Bug #25075284)

     * Client: In a number of instances where an ndb_mgmd
       command or a mysqld query failed, the wrong error (Error
       1006 or Error 7006) was thrown. With this fix, the 
       appropriate Error 7030 is thrown instead. (Bug #28829732)
 

On Behalf of MySQL Release Engineering team,
Surabhi Bhat

Dear MySQL Users,

MySQL Cluster is the distributed database combining massive
scalability and high availability. It provides in-memory
real-time access with transactional consistency across
partitioned and distributed datasets. It is designed for
mission critical applications.

MySQL Cluster has replication between clusters across multiple
geographical sites built-in. A shared nothing architecture with
data locality awareness make it the perfect choice for running
on commodity hardware and in globally distributed cloud
infrastructure.


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
  - Transactional consistency across partitioned and distributed datasets
  - Parallel cross partition queries such as joins

  - 99.9999% 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.13-dmr, 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/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.14 (2019-01-21, Development Milestone)

   MySQL NDB Cluster 8.0.14 is a new development 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
(http://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.14 (see Changes in MySQL 8.0.14 (Not yet
   released, General Availability)
(http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-14.html)).

     * Functionality Added or Changed

     * Bugs Fixed

Functionality Added or Changed


     * Performance: This release introduces a number of
       significant improvements in the performance of scans;
       these are listed here:

          + Row checksums help detect hardware issues, but do so
            at the expense of performance. NDB now offers the
            possibility of disabling these by setting the new
            ndb_row_checksum server system variable to 0; doing
            this means that row checksums are not used for new
            or altered tables. This can have a significant
            impact (5 to 10 percent, in some cases) on
            performance for all types of queries. This variable
            is set to 1 by default, to provide compatibility
            with the previous behavior.

          + A query consisting of a scan can execute for a
            longer time in the LDM threads when the queue is not
            busy.

          + Previously, columns were read before checking a
            pushed condition; now checking of a pushed condition
            is done before reading any columns.

          + Performance of pushed joins should see significant
            improvement when using range scans as part of join
            execution.

     * NDB Disk Data: MySQL NDB Cluster now implements schema
       synchronization of disk data objects including
       tablespaces and log file groups, just as it does for NDB
       databases and in-memory tables. This eliminates a
       possible mismatch between the MySQL data dictionary and
       the NDB dictionary following a native backup and restore
       that could arise when disk data tablespaces and undo log
       file groups were restored to the NDB dictionary, but not
       to the MySQL Server's data dictionary.

     * NDB Disk Data: NDB now makes use of the MySQL data
       dictionary to ensure correct distribution of tablespaces
       and log file groups across all cluster SQL nodes.

     * The extra metadata property for NDB tables is now used to
       store information from the MySQL data dictionary. Because
       this information is significantly larger than the binary
       representation previously stored here (a .frm file, no
       longer used), the hard-coded size limit for this extra
       metadata has been increased.
       This change can have an impact on downgrades: Trying to
       read NDB tables created in NDB 8.0.14 and later may cause
       data nodes running NDB 8.0.13 or earlier to fail on
       startup with NDB error code 2355 Failure to restore
       schema: Permanent error, external action needed: Resource
       configuration error. This can happen if the table's
       metadata exceeds 6K in size, which was the old limit.
       Tables created in NDB 8.0.13 and earlier can be read by
       later versions without any issues.
       For more information, see NDB table extra metadata
       changes
(http://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-what-is-new.html#mysql-cluster-what-is-new-8-0-extra-metadata),
       and See also MySQL Data Dictionary
(http://dev.mysql.com/doc/refman/8.0/en/data-dictionary.html).

Bugs Fixed

     * Packaging: Expected NDB header files were in the devel
       RPM package instead of libndbclient-devel. (Bug #84580,
       Bug #26448330)

     * MySQL NDB ClusterJ: The ndb.clusterj test for NDB 8.0.13
       failed when being run more than once. This was deal to a
       new, stricter rule with NDB 8.0.13 that did not allow
       temporary files being left behind in the variable folder
       of mysql-test-run (mtr). With this fix, the temporary
       files are deleted before the test is executed. (Bug
       #28279038)

     * MySQL NDB ClusterJ: A NullPointerException was thrown
       when a full table scan was performed with ClusterJ on
       tables containing either a BLOB or a TEXT field. It was
       because the proper object initializations were omitted,
       and they have now been added by this fix. (Bug #28199372,
       Bug #91242)

     * Trying to build from source using -DWITH_NDBCLUSTER and
       -Werror failed with GCC 8. (Bug #28707282)

     * When copying deleted rows from a live node to a node just
       starting, it is possible for one or more of these rows to
       have a global checkpoint index equal to zero. If this
       happened at the same time that a full local checkpoint
       was started due to the undo log getting full, the
       LCP_SKIP bit was set for a row having GCI = 0, leading to
       an unplanned shutdown of the data node. (Bug #28372628)

     * ndbmtd sometimes experienced a hang when exiting due to
       log thread shutdown. (Bug #28027150)

     * NDB has an upper limit of 128 characters for a fully
       qualified table name. Due to the fact that mysqld names
       NDB tables using the format
       database_name/catalog_name/table_name, where catalog_name
       is always def, it is possible for statements such as
       CREATE TABLE to fail in spite of the fact that neither
       the table name nor the database name exceeds the
       63-character limit imposed by NDB. The error raised in
       such cases was misleading and has been replaced. (Bug
       #27769521)
       References: See also: Bug #27769801.

     * When the SUMA kernel block receives a SUB_STOP_REQ
       signal, it executes the signal then replies with
       SUB_STOP_CONF. (After this response is relayed back to
       the API, the API is open to send more SUB_STOP_REQ
       signals.) After sending the SUB_STOP_CONF, SUMA drops the
       subscription if no subscribers are present, which
       involves sending multiple DROP_TRIG_IMPL_REQ messages to
       DBTUP. LocalProxy can handle up to 21 of these requests
       in parallel; any more than this are queued in the Short
       Time Queue. When execution of a DROP_TRIG_IMPL_REQ was
       delayed, there was a chance for the queue to become
       overloaded, leading to a data node shutdown with Error in
       short time queue.
       This issue is fixed by delaying the execution of the
       SUB_STOP_REQ signal if DBTUP is already handling
       DROP_TRIG_IMPL_REQ signals at full capacity, rather than
       queueing up the DROP_TRIG_IMPL_REQ signals. (Bug
       #26574003)

     * When starting, a data node copies metadata, while a local
       checkpoint updates metadata. To avoid any conflict, any
       ongoing LCP activity is paused while metadata is being
       copied. An issue arose when a local checkpoint was paused
       on a given node, and another node that was also
       restarting checked for a complete LCP on this node; the
       check actually caused the LCP to be completed before
       copying of metadata was complete and so ended the pause
       prematurely. Now in such cases, the LCP completion check
       waits to complete a paused LCP until copying of metadata
       is finished and the pause ends as expected, within the
       LCP in which it began. (Bug #24827685)

     * ndbout and ndberr became invalid after exiting from
       mgmd_run(), and redirecting to them before the next call
       to mgmd_run() caused a segmentation fault, during an
       ndb_mgmd service restart. This fix ensures that ndbout
       and ndberr remain valid at all times. (Bug #17732772, Bug
       #28536919)

     * NdbScanFilter did not always handle NULL according to the
       SQL standard, which could result in sending
       non-qualifying rows to be filtered (otherwise not
       necessary) by the MySQL server. (Bug #92407, Bug
       #28643463)

     * The internal function ndb_my_error() was used in
       ndbcluster_get_tablespace_statistics() and
       prepare_inplace_alter_table() to report errors when the
       function failed to interact with NDB. The function was
       expected to push the NDB error as warning on the stack
       and then set an error by translating the NDB error to a
       MySQL error and then finally call my_error() with the
       translated error. When calling my_error(), the function
       extracts a format string that may contain placeholders
       and use the format string in a function similar to
       sprintf(), which in this case could read arbitrary memory
       leading to a segmentation fault, due to the fact that
       my_error() was called without any arguments.
       The fix is always to push the NDB error as a warning and
       then set an error with a provided message. A new helper
       function has been added to Thd_ndb to be used in place of
       ndb_my_error(). (Bug #92244, Bug #28575934)

     * Running out of undo log buffer memory was reported using
       error 921 Out of transaction memory ... (increase
       SharedGlobalMemory).
       This problem is fixed by introducing a new error code 923
       Out of undo buffer memory (increase UNDO_BUFFER_SIZE).
       (Bug #92125, Bug #28537319)

     * When moving an OperationRec from the serial to the
       parallel queue, Dbacc::startNext() failed to update the
       Operationrec::OP_ACC_LOCK_MODE flag which is required to
       reflect the accumulated OP_LOCK_MODE of all previous
       operations in the parallel queue. This inconsistency in
       the ACC lock queues caused the scan lock takeover
       mechanism to fail, as it incorrectly concluded that a
       lock to take over was not held. The same failure caused
       an assert when aborting an operation that was a member of
       such an inconsistent parallel lock queue. (Bug #92100,
       Bug #28530928)

     * ndb_restore did not free all memory used after being
       called to restore a table that already existed. (Bug
       #92085, Bug #28525898)

     * A data node failed during startup due to the arrival of a
       SCAN_FRAGREQ signal during the restore phase. This signal
       originated from a scan begun before the node had
       previously failed and which should have been aborted due
       to the involvement of the failed node in it. (Bug #92059,
       Bug #28518448)

     * DBTUP sent the error Tuple corruption detected when a
       read operation attempted to read the value of a tuple
       inserted within the same transaction. (Bug #92009, Bug
       #28500861)

     * False constraint violation errors could occur when
       executing updates on self-referential foreign keys. (Bug
       #91965, Bug #28486390)
       References: See also: Bug #90644, Bug #27930382.

     * An NDB internal trigger definition could be dropped while
       pending instances of the trigger remained to be executed,
       by attempting to look up the definition for a trigger
       which had already been released. This caused
       unpredictable and thus unsafe behavior possibly leading
       to data node failure. The root cause of the issue lay in
       an invalid assumption in the code relating to determining
       whether a given trigger had been released; the issue is
       fixed by ensuring that the behavior of NDB, when a
       trigger definition is determined to have been released,
       is consistent, and that it meets expectations. (Bug
       #91894, Bug #28451957)

     * During an initial node restart with disk data tables
       present and TwoPassInitialNodeRestartCopy enabled, DBTUP
       used an unsafe scan in disk order. Such scans are no
       longer employed in this case. (Bug #91724, Bug #28378227)

     * Checking for old LCP files tested the table version, but
       this was not always dependable. Now, instead of relying
       on the table version, the check regards as invalid any
       LCP file having a maxGCI smaller than its createGci. (Bug
       #91637, Bug #28346565)

     * In certain cases, a cascade update trigger was fired
       repeatedly on the same record, which eventually consumed
       all available concurrent operations, leading to Error 233
       Out of operation records in transaction coordinator
       (increase MaxNoOfConcurrentOperations). If
       MaxNoOfConcurrentOperations was set to a value
       sufficiently high to avoid this, the issue manifested as
       data nodes consuming very large amounts of CPU, very
       likely eventually leading to a timeout. (Bug #91472, Bug
       #28262259)

Dear MySQL users,

MySQL Server 5.6.43, a new version of the popular Open Source
Database Management System, has been released. MySQL 5.6.43 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.43 on new servers or upgrading
to MySQL 5.6.43 from previous MySQL releases, please see

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

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

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


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.42. It may also be viewed
online at

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

Enjoy!

Changes in MySQL 5.6.43 (2019-01-21, General Availability)


Security Notes


     * The linked OpenSSL library for the MySQL Commercial
       Server has been updated to version 1.0.2q. Issues fixed
       in the new OpenSSL version are described at
       http://www.openssl.org/news/vulnerabilities.html.
       This change does not affect the Oracle-produced MySQL
       Community build of MySQL Server, which uses the yaSSL
       library instead. (Bug #28988091)

Functionality Added or Changed


     * Microsoft Windows: The access control granted to clients
       on the named pipe created by the MySQL server now is set
       to the minimum necessary for successful communication on
       Windows. Newer MySQL client software can open named pipe
       connections without any additional configuration. If
       older client software cannot be upgraded immediately, the
       new named_pipe_full_access_group server system variable
       can be used to give a Windows group the necessary
       permissions to open a named pipe connection. Membership
       in the full-access group should be restricted and
       temporary.

Bugs Fixed


     * Replication: A patch to correct the handling of quotes
       for identifiers in ROLLBACK TO SAVEPOINT statements in
       the binary log was not correctly applied to subsequent
       MySQL versions. (Bug #28569645)

     * Replication: In some circumstances, the CHANGE MASTER TO
       statement could not be used on a replication slave if the
       master info log had been changed from a table
       (master_info_repository=TABLE) into a file
       (master_info_repository=FILE). (Bug #28529558)

     * Replication: The value returned by a SHOW SLAVE STATUS
       statement for the total combined size of all existing
       relay log files (Relay_Log_Space) could become much
       larger than the actual disk space used by the relay log
       files. The I/O thread did not lock the variable while it
       updated the value, so the SQL thread could automatically
       delete a relay log file and write a reduced value before
       the I/O thread finished updating the value. The I/O
       thread then wrote its original size calculation, ignoring
       the SQL thread's update and so adding back the space for
       the deleted file. The Relay_Log_Space value is now locked
       during updates to prevent concurrent updates and ensure
       an accurate calculation. (Bug #26997096, Bug #87832)

     * Replication: If the relay log index file was temporarily
       locked for viewing by a backup process for a replication
       slave, and MySQL Server also attempted to access the file
       at that time for rename or delete operations, the backup
       completed with warnings, but MySQL Server experienced an
       unexpected halt. MySQL Server now retries the file access
       operation a number of times in case this or a similar
       scenario is the explanation and the file becomes
       available again before long. (Bug #25839610)

     * The server permitted creation of databases with the same
       name as redo log files, which could result in unexpected
       server behavior. Such names are no longer permitted as
       database names. (Bug #28867993)

     * Comparing log file names as strings using the memcmp()
       function resulted in uninitialized memory read errors.
       The comparison now uses the strncmp() function. Thanks to
       Zsolt Parragi and Laurynas Biveinis for their
       contributions. (Bug #28178776, Bug #90238)

     * The transformation of IN subquery predicates into
       semijoins was not handled correctly for a very large
       number of tables. (Bug #28004674)

     * Executing a prepared statement to do a multiple-row
       insert with large number of placeholders consumed
       excessive memory and could execute slowly. (Bug
       #27703912)

     * The parser accepted invalid SET statement syntax in
       trigger definitions that could result in a server exit.
       (Bug #27595603)

     * MyISAM index corruption could occur for bulk-insert and
       table-repair operations that involve the
       repair-by-sorting algorithm and many (more than 450
       million) rows. (Bug #26929724, Bug #88003, Bug #28483283)

     * When a subquery contained a UNION, the count of the
       number of subquery columns was calculated incorrectly.
       (Bug #24899924)

     * A query employing a dynamic range and an index merge
       could use more memory than expected. (Bug #89953, Bug
       #27659490)

On Behalf of MySQL/ORACLE RE Team
Gipson Pulla