This is a milestone release, for use at your own risk. Upgrades between milestone releases (or from a milestone release to a GA release) are not supported. Significant development changes take place in milestone releases and you may encounter compatibility issues, such as data format changes that require attention in addition to the usual procedure of running mysql_upgrade. For example, you may find it necessary to dump your data with mysqldump before the upgrade and reload it afterward. (Making a backup before the upgrade is a prudent precaution in any case.)
-
Microsoft Windows: Windows Vista, Windows Server 2008, and newer support native symbolic linking using the mklink command. This makes the MySQL Server implementation of database symbolic links using
.symfiles redundant, so that mechanism is now removed. This change has the following implications:Existing
.symfiles are now ignored. Database symbolic links should be recreated using mklink. See Using Symbolic Links for Databases on Windows.The
--symbolic-linksand--skip-symbolic-linksoptions and thehave_symlinksystem variable now are meaningful only for Unix systems, and not for Windows.
(WL #6561)
MySQL now supports stacked diagnostics areas. When a push to the diagnostics area stack occurs, the first (current) diagnostics area becomes the second (stacked) diagnostics area and a new current diagnostics area is created as a copy of it. Within a condition handler, executed statements modify the new current diagnostics area, but
GET STACKED DIAGNOSTICScan be used to inspect the stacked diagnostics area to obtain information about the condition that caused the handler to activate, independent of current conditions within the handler itself. (Previously, there was a single diagnostics area. To inspect handler-activating conditions within a handler, it was necessary to check this diagnostics area before executing any statements that could change it.) See GET DIAGNOSTICS Statement, and The MySQL Diagnostics Area. (WL #6406)
Important Change; Replication:
SHOW SLAVE STATUSwhen run concurrently withSTOP SLAVEcan take a long time to execute if the slave SQL thread was in the midst of applying a large update. To fix this problem, a newNONBLOCKINGoption has been added to theSHOW SLAVE STATUSstatement. When this option is used,SHOW SLAVE STATUSdoes not wait on the SQL or I/O threads but returns immediately. This means that the reported states of these threads may not be completely up to date when the option is used.NONBLOCKINGis intended primarily for use by monitoring tools in which obtaining an immediate response is more important than having the most timely data. (Bug #15993588, Bug #67879, WL #6402)Important Change; Replication: Added the
--idempotentoption for mysqlbinlog, which causes the MySQL Server to employ idempotent mode. This causes suppression of all duplicate-key and key-not-found errors when processing updates from the binary log. The mode is in effect for the current mysqlbinlog client and client session only. (WL #6403)-
Important Change:
INSERT DELAYEDis no longer supported. The server recognizes but ignores theDELAYEDkeyword, handles the insert as a nondelayed insert, and generates anER_WARN_LEGACY_SYNTAX_CONVERTEDwarning. (“INSERT DELAYED is no longer supported. The statement was converted to INSERT.”). Similarly,REPLACE DELAYEDis handled as a nondelayed replace. TheDELAYEDkeyword will be removed in a future release.In addition, several
DELAYED-related options or features were removed:The
--delayed-insertoption for mysqldump.-
The
COUNT_WRITE_DELAYED,SUM_TIMER_WRITE_DELAYED,MIN_TIMER_WRITE_DELAYED,AVG_TIMER_WRITE_DELAYED, andMAX_TIMER_WRITE_DELAYEDcolumns of thetable_lock_waits_summary_by_tablePerformance Schema table.If you upgrade to this MySQL release from an earlier version, you must run mysql_upgrade (and restart the server) to incorporate these changes into the
performance_schemadatabase. mysqlbinlog no longer writes comments mentioning
INSERT DELAYED.
(WL #6073)
Previously, Control+C in mysql interrupted the current statement if there was one, or exited mysql if not. Now Control+C interrupts the current statement if there was one, or cancels any partial input line otherwise, but does not exit. (Bug #66583, Bug #14554568)
The server now issues a warning if an index is created that duplicates an existing index, or an error in strict SQL mode. (Bug #37520, Bug #11748842)
-
The
mysql_clear_passwordcleartext client-side authentication plugin is intended for authentication schemes that require the server to receive the password as entered on the client side, without hashing. Because the password is sent in the clear, this plugin should be used within the context of an encrypted connection, such as an SSL connection, to avoid exposing the password over the network. To make inadvertent use of this plugin less likely, it is now required that clients explicitly enable it. This can be done several ways:Set the
LIBMYSQL_ENABLE_CLEARTEXT_PLUGINenvironment variable to a value that begins with1,Y, ory. This enables the plugin for all client connections.The mysql, mysqladmin, and mysqlslap client programs support an
--enable-cleartext-pluginoption that enables the plugin on a per-invocation basis.The
mysql_options()C API function supports aMYSQL_ENABLE_CLEARTEXT_PLUGINoption that enables the plugin on a per-connection basis. Also, any program that useslibmysqlclientand reads option files can enable the plugin by including anenable-cleartext-pluginoption in an option group read by the client library.
-
Important Change; Replication: Statements involving the Performance Schema tables should not be written to the binary log, because the content of these tables is applicable only to a given MySQL Server instance, and may differ greatly between different servers in a replication topology. The database administrator should be able to configure (
INSERT,UPDATE, orDELETE) or flush (TRUNCATE TABLE) performance schema tables on a single server without affecting others. However, when using replication with GTIDs enabled (see Replication with Global Transaction Identifiers), warnings about unsafe statements updating Performance Schema tables were elevated to errors, preventing the use ofperformance_schemaand GTIDs together.Similar problems were encountered with replication and system logging tables when GTIDs were enabled.
This fix introduces the concept of a nonreplicated or local table. Now when MySQL replication encounters a table that is marked as local, updates to this table are ignored.
This fix defines as local the following tables, which are no longer replicated:
All tables in the
performance_schemadatabasemysql.general_logmysql.slow_logmysql.slave_relay_log_infomysql.slave_master_infomysql.slave_worker_info
Before this fix, statements using the
performance_schemaand other tables just listed were handled by being marked as unsafe for replication, which caused warnings during execution; the statements were nonetheless written to the binary log, regardless of the logging format in effect.Existing replication behavior for tables in the
INFORMATION_SCHEMAdatabase is not changed by this fix.For more information, see MySQL Performance Schema. See also MySQL Server Logs, and Replication Metadata Repositories. For information about general and slow query log tables, see Selecting General Query Log and Slow Query Log Output Destinations. (Bug #14741537)
Important Change: Formerly, the
ExtractValue()andUpdateXML()functions supported a maximum length of 127 characters for XPath expressions supplied to them as arguments. This limitation has now been removed. (Bug #13007062, Bug #62429)InnoDB: Creating and altering tables repeatedly would result in a memory leak that was due to a duplicate key error. The duplicate key error occurred because the
row_merge_build_indexesfunction did not callrow_fts_psort_info_destroyoften enough. As full-text search indexes were created with a unique index, the unique index failed due to the duplicate key error, and full-text search build resource would not be released. (Bug #14759111)InnoDB: During an online DDL operation, a duplicate key error could be incorrectly issued if a record was inserted and subsequently updated while the table was being rebuilt. (Bug #14723456)
InnoDB: InnoDB IO threads within Performance Schema were exposed with the following name: “
io_handler_thread”. This fix implements specific keys such asio_read_handler_thread,io_write_handler_thread,io_ibuf_handler_threadto differentiate InnoDB IO threads within Performance Schema. (Bug #14670810)InnoDB: If the server crashed at a precise moment during an
ALTER TABLEoperation that rebuilt the clustered index for anInnoDBtable, the original table could be inaccessible afterward. An example of such an operation isALTER TABLE ... ADD PRIMARY KEYThe fix preserves the original table if the server halts during this operation. You might still need to rename the.ibdfile manually to restore the original table contents: in MySQL 5.6 and higher, rename from#sql-ib$tonew_table_id.ibdwithin the database directory; prior to MySQL 5.6, the temporary file to rename istable_name.ibdortable_name#1#2. (Bug #14669848)InnoDB: Inserting data of varying record lengths into an
InnoDBtable that used compression could cause the server to halt with an error. (Bug #14554000, Bug #13523839, Bug #63815, Bug #12845774, Bug #61456, Bug #12595091, Bug #61208)InnoDB: This fix addresses an assert condition that would occur when inserting large BLOBs into tablespaces with a 4KB physical page size or into some compressed tables. Extents would not be allocated soon enough for tablespaces with smaller physical page sizes. (Bug #14520559)
InnoDB: If a table was defined with an index key length very close to the upper length limit of 3072, a query against that table could cause a serious error. (Bug #14500557, Bug #14537695)
InnoDB: In debug builds, a mismatch in the
InnoDBPAGE_FREElist would cause an assertion. (Bug #12701488)-
InnoDB: On Linux systems, certain I/O requests that read or wrote fewer than the requested number of bytes could cause the server to crash. This issue could happen more frequently with asynchronous I/O requests. The messages did not clearly identify what type of error occurred:
InnoDB: Operating system error number 0 in a file operation. InnoDB: Error number 0 means 'Success'.With this fix, MySQL retries the operation several times before giving up. (The number of retries is defined by the constant
NUM_RETRIES_ON_PARTIAL_IOin the source code, default value 10.) (Bug #11761646, Bug #54160) Partitioning: When the server is started with
--skip-partition, it should reject DDL or DML statements on partitioned tables. However, forDROP TABLE, the server dropped the.frmfile, and forRENAME TABLE, the server renamed the.frmfile. (Bug #11763795)-
Replication: mysqlbinlog did not properly decode
DECIMALvalues in a row-based binary log. This could cause invalid values to be printed out forDECIMALcolumns. (Bug #14309019)References: See also: Bug #17544169.
Replication: mysqlbinlog
-v-vprints in verbose mode, with comments on data column types, from a binary log file. When mysqlbinlog-v -vencountered a column data value which wasNULL, the column's data type was not updated; as a result, the data type of the previous column was printed instead, or—in the case where this was the table's first column—the type was shown as<an integer>. Now in such cases, the data type is shown correctly. (Bug #14171756)Replication: When using mysqlbinlog with the
--verboseoption to read a binary log written by a MySQL server using row-based or mixed-format logging, invalid SQL could be produced when comments appeared insideBINLOGstatements. One way in which this could happen was when a function that updated data was used within anINSERT ... SELECTstatement. (Bug #12889121)Replication: mysql_upgrade on the master broke replication when the slave was run with
--log-outputequal toFILEorNONE. (Bug #11763447)Replication: Issuing
STOP SLAVEcaused a spurious Error reading packet from server: Lost connection to MySQL server during query message to be written to the error log. (Bug #11761457, Bug #12977988, Bug #53955)Replication: When an error occurs in the slave SQL thread, this causes the
Slave_SQL_ErrorandSlave_SQL_Errnocolumns fromSHOW SLAVE STATUSto display the reason for the error. The error number should be one of the usual constants ER_* defined insql/share/errmsg.txt, and the error message should be the corresponding string. However, in some cases,Slave_SQL_Errnowas set to something other than anER_*number, andSlave_SQL_Errorto a hard-coded error message rather than a translatable string fromsql/share/errmsg.txt. Now all errors shown bySHOW SLAVE STATUSoriginate insql/share/errmsg.txt, as expected. (Bug #11760365, Bug #52768)Microsoft Windows: On Microsoft Windows, CMake entries for POSIX API's not found on Microsoft Windows were added to the CMake cache. This decreases the number of expected "Not found" errors while compiling MySQL. (Bug #14790333)
Microsoft Windows: On Microsoft Windows, queries referring to a table with invalid characters would search the system for invalid file names. The generated system error code (
ERROR_INVALID_NAME) was not recognized by MySQL, so this unknown error would be reported to the server log as "ERRNO: 22 - INVALID ARGUMENT". MySQL now recognizes these errors and reports them as the table does not existing, and it no longer logs them to the server error log. (Bug #14642248)Microsoft Windows: On Windows, starting the server with
--log-errorand--consolecaused the server to write to the log file but not the console. Before MySQL 5.5.3, this occurred only if--log-errorwas specified after--console. Now,--consoleoverrides--log-errorno matter the option order so that--consoleproduces console output in all cases. (Bug #14207773, Bug #65592)Microsoft Windows: It was possible to specify a Named Pipe that was already in use. This is no longer allowed, as an error is now emitted and the process is aborted. After
mysqld.exewas started in Named Pipe mode with a pipe name that was already used by a different instance, neither instance was able to shut down properly when a shutdown command was received from aTCPsocket in any of the processes. Therefore,mysqld.exewas not terminated. (Bug #13891058, Bug #61885)Microsoft Windows: On Microsoft Windows, a failed API or function call in
mysqld.execould sometimes report the error code 22, instead of the proper error code. (Bug #11763004)-
NDB Replication: Transactions originating on a replication master are applied on slaves as if using
AO_AbortError, but transactions replayed from a binary log were not. Now transactions being replayed from a log are handled in the same way as those coming from a “live” replication master.See NdbOperation::AbortOption, for more information. (Bug #14615095)
Joins of exactly 32 tables and containing a
HAVINGclause returned an empty result. (Bug #15972635)The parser rejected some legal
UNIONstatements. (Bug #14730856)Setting
thread_cache_sizeto a negative value at server startup resulted in a value of 16384 rather than 0. (Bug #14683107)XA RECOVERdisplayed nonprintable characters in the XID data. Now such characters are hex encoded. (Bug #14670465)There was no warning at startup if the server was started with an invalid
query_cache_sizevalue. (Bug #14576423)The return value from
IS_USED_LOCK()was reported using the wrong data type. (Bug #14575699)When resolving outer fields,
Item_field::fix_outer_fields()creates newItem_refs for each execution of a prepared statement, so these must be allocated in the runtime memroot. The memroot switching before resolvingJOIN::havingcaused these to be allocated in the statement root, leaking memory for each prepared statement execution. (Bug #14409015)Activation of a stored program handler did not preserve the current diagnostics stack. (Bug #14342913, WL #6406)
In debug builds, killing a
HELPstatement caused an assertion to be raised. (Bug #14221840)If an error occurred during evaluation of the
BEFOREexpression of aPURGE BINARY LOGS BEFOREstatement, the statement did not abort as it should have and later raised an assertion. (Bug #14215847)For the index merge access method, the optimizer could make a suboptimal choice of indexes to use. (Bug #14095506)
An assertion could be raised if the attempt to open the
.frmfile for a temporary table failed. (Bug #13359247)If the state of the Event Scheduler was changed during server shutdown, the server could crash. (Bug #13002460)
-
When storing the definition for a view that used the
UPPER()orLOWER()function, the function call was replaced byUCASE()orLCASE(), respectively (as shown in the output ofSHOW CREATE VIEW). This was in spite of the fact thatUPPER()andLOWER()are standard, withUCASE()andLCASE()being MySQL synonyms for these. This made it more difficult to move databases between MySQL and other database systems.With this fix, calls to
UPPER()andLOWER()within views are no longer rewritten when storing their definitions; instead,UCASE()is now rewritten asUPPER()in stored view definitions, andLCASE()asLOWER(), which increases the portability of the views. (Bug #12844279) For queries that accessed an
INFORMATION_SCHEMAtable in a subquery, an attempt to lock a mutex that had already been locked could cause a server crash. (Bug #11765744)A view using INTERVAL() could be created, but it was not possible to select from the view, nor could it be shown with SHOW CREATE VIEW. (Bug #11753832)
The
Range checked for each recordoptimization is now used for conditions with outer query references. (Bug #11750963)For an
ALTER TABLEstatement that renamed or changed the default value of aBINARYcolumn, the alteration was done using a table copy and not in place. (Bug #67141, Bug #14735373, Bug #69580, Bug #17024290)For queries using
refaccess on string data types, therefaccess condition could be evaluated again as part of the query condition or pushed down as an index condition to the storage engine. (Bug #66983, Bug #14682735)Concurrent execution of
DROP DATABASEand any ofCREATE FUNCTION,CREATE PROCEDURE, orCREATE EVENTcould be written to the binary log in the wrong order, causing replication failure. (Bug #65428, Bug #14127220)For a view defined on a
UNION, the server could create an invalid view definition. (Bug #65388, Bug #14117018, Bug #72018, Bug #18405221)If
read_onlyis enabled, it is still permitted to createTEMPORARYtables. But in this case, a non-TEMPORARYtable with the same name could also be created, which should not be permitted. (Bug #64992, Bug #13969578)Enabling the session value of
low_priority_updateshad no effect forINSERTstatements. (Bug #64892, Bug #13939940)References to a stored function without a database name qualifier while there was no default database resulted in an
ER_SP_DOES_NOT_EXISTerror rather thanER_NO_DB_ERROR. (Bug #64692, Bug #13864485)The server refused client connections while executing
FLUSH PRIVILEGES. (Bug #63178, Bug #13418619)A view was created with an incorrect definition if the
WHEREclause contained string literals andcharacter_set_clientandcharacter_set_connectionwere set to different character sets. (Bug #63094, Bug #13520710)SHOW CREATE VIEWfailed if the tables underlying the view were changed. (Bug #61718, Bug #12762393)Concurrent inserts were blocked by selects if the inserts were generated from within a stored procedure. (Bug #58689, Bug #11765698)
An
INSERT INTO ... SELECTstatement that inserted no rows unnecessarily invalidated statements in the query cache that used the target table. (Bug #50065, Bug #11757947)Using
ALTER TABLEto rename a table to.resulted in a table with no name. (Bug #49636, Bug #11757569)SHOW GLOBAL STATUScaused performance problems on busy servers due to lock contention. (Bug #42930, Bug #11751904)INSERT INTO ... SELECT ... ON DUPLICATE KEY UPDATEandLOAD DATA CONCURRENT REPLACEtook too weak a lock, leading to the possibility of concurrentSELECTstatements returning inconsistent results. (Bug #38046, Bug #11749055)An event was not dropped from the
mysql.eventtable under these circumstances: The event was created while the event scheduler was enabled; the scheduler was disabled and re-enabled; the event expiration time was reached. (Bug #34804, Bug #11748012)