MySQL 歷史舊版本 Page40

更新時間：2014-08-01
更新細節：

What's new in this version:

Security Notes:
- Security Fix: The linked OpenSSL library for the MySQL 5.6 Commercial Server has been updated from version 1.0.1g to version 1.0.1h. Versions of OpenSSL prior to and including 1.0.1g are reported to be vulnerable to CVE-2014-0224.
- This change does not affect the Oracle-produced MySQL Community build of MySQL Server 5.6, which uses the yaSSL library instead. (CVE-2014-0224)

InnoDB Notes:
- Important Change: Redo log writes for large, externally stored BLOB fields could overwrite the most recent checkpoint. The 5.6.20 patch limits the size of redo log BLOB writes to 10% of the redo log file size. The 5.7.5 patch addresses the bug without imposing a limitation. For MySQL 5.5, the bug remains a known limitation.
- As a result of the redo log BLOB write limit introduced for MySQL 5.6, innodb_log_file_size should be set to a value greater than 10 times the largest BLOB data size found in the rows of your tables plus the length of other variable length fields (VARCHAR, VARBINARY, and TEXT type fields). Failing to do so could result in “Row size too large” errors. No action is required if your innodb_log_file_size setting is already sufficiently large or your tables contain no BLOB data.
- Functionality Added or Changed:
- Replication: The new system variable binlog_impossible_mode controls what happens if the server cannot write to the binary log, for example, due to a file error. For backward compatibility, the default for binlog_impossible_mode is IGNORE_ERROR, meaning the server logs the error, halts logging, and continues updates to the database. Setting this variable to ABORT_SERVER makes the server halt logging and shut down if it cannot write to the binary log.
- CMake support was updated to handle CMake version 3.
- New Debian7, Ubuntu12.04, and Ubuntu14.04 distribution support that was introduced with 5.6.17 now comes with the platform-specific packaging source placed under the packaging directory, in the deb-precise, deb-wheezy, and deb-trusty directories.
- Support for LinuxThreads has been removed from the source code. LinuxThreads was superseded by NPTL in Linux 2.6.
- By default, mysql_install_db creates a my.cnf file in the installation base directory using a template. This may be undesireable for some deployments. To enable this behavior to be suppressed, mysql_install_db now supports a --keep-my-cnf option to preserve any existing my.cnf file and not create a new my.cnf file.
- The mysqlhotcopy utility is now deprecated and will be removed in a future version of MySQL. Among the reasons for this: It works only for the MyISAM and ARCHIVE storage engines; it works on Unix but not Windows. Alternatives include mysqldump and MySQL Enterprise Backup.
- The timed_mutexes system variable has no effect and is deprecated.

Bugs Fixed:
- Important Change; Replication: A DROP TABLE statement may be divided into multiple statements before it is sent to the binary log if it contains regular (not temporary) tables and temporary tables, or if it contains temporary tables using both transactional and non-transactional storage engines. Now, when using GTIDs, DROP TABLE statements affecting these combinations of tables are no longer allowed unless the value of the gtid_next system variable is AUTOMATIC. This is because, with GTIDs enabled on the server, issuing a DROP TABLE in the cases just described while having only one GTID associated with each statement (the SQL thread does this following SET gtid_next='uuid:number') causes problems when there are not enough GTIDs for assignment to all the resulting statements following the division of the original DROP TABLE.
- A DROP TABLE statement might be split due to the behavior of the statement with respect to the current transaction varying, depending on table characteristics, as follows:
- DROP TABLE of a regular (not temporary) table is committed immediately
- DROP TABLE of a temporary table using a transactional storage engine is committed with the current transaction (following COMMIT)
- DROP TABLE of a temporary table that uses a nontransactional storage engine is committed immediately
- Naming all three of these types of tables in a single DROP TABLE statement causes the MySQL server to divide the original statement into three separate DROP TABLE statements in the binary log. If GTIDs are enabled but the value of gtid_next is not AUTOMATIC, issuing a DROP TABLE statement that mixes any of the table types described previously causes the server to have an insufficient number of GTIDs to write with all of the resulting statements into the binary log. In addition, DROP TABLE IF EXISTS is always written in the binary log for all tables specified in the statement, even if some or all of the tables do not exist.
- Because temporary tables are handled differently by DROP TABLE depending on whether they use a transactional or nontransactional storage engine, any tables named by a DROP TEMPORARY TABLE statement that do not exist are assumed to be transactional. This means that, if a DROP TEMPORARY TABLE with two nontransactional temporary tables is issued on the master, it would writes only one DROP TABLE statement naming both tables. If one of the temporary tables no longer exists on the slave, then, when the SQL thread executes the statement, it tries to divide it into multiple statements due to it affecting a nontransactional (but existing) temporary table and a nonexistent transactional temporary table; this leads to problems because the SQL thread has only one GTID for the original DROP TABLE statement but must write two DROP TABLE statements in the binary log.
- In addition, when the slave dropped temporary tables after detecting that the master had restarted, it logged one DROP TABLE statement per pseudo-thread and per database, but combined temporary tables using transactional and nontransactional storage engines in a single DROP TABLE statement.
- Now, we throw an error in the client session if gtid_next is set to a uuid:number value and a DROP TABLE statement is issued mixing any of the table types described previously.
- In addition, we now group the nonexistent temporary tables and assume them to be transactional only if at least one transactional temporary table is dropped by the statement. If no transactional temporary tables are dropped, any nonexistent temporary tables are assumed to be nontransactional temporary tables.
- The slave now also handles dropping of temporary tables correctly in the event of the restart by the master.
- InnoDB: Opening a parent table that has thousands of child tables could result in a long semaphore wait condition.
- InnoDB: For single item full-text searches, deleted documents were included in inverse document frequency (IDF) calculations.
- InnoDB: On mysqld start, specifying multiple data files using the innodb_data_file_path option would return a Space id in fsp header error after data is written to the second file.
- InnoDB: A DELETE operation on a table with full-text search indexes raised an assertion.
- InnoDB: When calling the memcached flush_all command, InnoDB attempts to initialize a connection and a transaction. If the transaction is in TRX_STATE_NOT_STARTED state, InnoDB would fail to set CONN_DATA->CRSR_TRX to NULL, resulting in a serious error.
- InnoDB: When InnoDB is built as a shared library, attempting to load the InnoDB full-text search (FTS) INFORMATION_SCHEMA plugin would fail with a Can't open shared library 'ha_innodb.so' error.
- InnoDB: A regression introduced in MySQL 5.6.5 would cause full-text search index tables to be created in the system tablespace (space 0) even though innodb_file_per_table was enabled.
- InnoDB: The InnoDB memcached plugin would call plugin_del without acquiring the lock_plugin mutex. This bug fix also addresses a race condition in ib_cursor_delete_row.
- InnoDB: The fix for Bug#16418661 added superfluous buf_flush_list() logic to InnoDB startup code.
- InnoDB: A race condition in fts_get_next_doc_id resulted in Duplicate FTS_DOC_ID and Cannot find index FTS_DOC_ID_INDEX in InnoDB index translation table errors.
- InnoDB: Due to differences in memory ordering on different processor types, some mutex and read-write lock flags were not read consistently.
- Partitioning: Selecting from a table having multiple columns in its primary key and partitioned by LIST COLUMNS(R), where R was the last (rightmost) column listed in the primary key definition, returned an incorrect result.
- Replication: mysqlbinlog --raw did not check for errors caused by failed writes, which could result in silent corruption of binary logs. Now in such cases it stops with an error.
- Replication: When a slave worker thread tried to execute a statement that was too large, the resulting error caused a crash. Now in such cases, the error is truncated to fit the size of the buffer.
- Replication: When using row-based replication, updating or deleting a row on the master that did not exist on the slave led to failure of the slave when it tried to process the change. This problem occurred with InnoDB tables lacking a primary key.
- Replication: Quotation marks were not always handled correctly by LOAD DATA INFILE when written into the binary log.
- Replication: Beginning in MySQL 5.6.20, when a user specified AUTO_INCREMENT value falls outside of the range between the current AUTO_INCREMENT value and the sum of the current and number of rows affected values it is replicated correctly. In previous versions, an error was generated by the slave even if the user specified AUTO_INCREMENT value fell outside of the range.
- Replication: A group of threads involved in acquiring locks could deadlock when the following events occurred:
- Dump thread reconnects from slave; on master, a new dump thread tries to kill zombie dump threads; having acquired the thread's LOCK_thd_data, it is about to acquire LOCK_log.
- Application thread executing show binary logs, having acquired LOCK_log and about to acquire LOCK_index.
- Application thread executing PURGE BINARY LOGS; having acquired LOCK_index, it is about to acquire LOCK_thread_count.
- Application thread executing SHOW PROCESSLIST (or SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST), having acquired LOCK_thread_count and about to acquire the zombie dump thread's LOCK_thd_data.
- This leads to the 4 threads deadlocking in the same order which the threads have been listed here.
- This problem arises because there are ordering rules for LOCK_log and LOCK_index, as well as rules for ordering LOCK_thread_count and LOCK_thd_data, but there are no rules for ordering across these two sets of locks. This was because the internal mysqld_list_processes() function invoked by SHOW PROCESSLIST acquired LOCK_thread_count for the complete lifetime of the function as well as acquiring and releasing each thread's LOCK_thd_data. Now this function takes a copy of the threads from the global thread list and performs its traversal on these, and only after releasing LOCK_thread_count. During this traversal, removal from the global thread list is blocked using LOCK_thd_remove such that the copies that would otherwise be destroyed by the removal remain valid during traversal. The locking order following this fix is shown here:
- LOCK_thd_remove -> LOCK_thd_data -> LOCK_log -> LOCK_index -> LOCK_thread_count
- Replication: On Windows, mysqldump failed if the error log file was deleted (missing) from the active MySQL server.
- Replication: Client applications should be able to set the BINLOG_DUMP_NON_BLOCK flag in the initial handshake packet (COM_BINLOG_DUMP). Clients connecting to a server issuing a COM_BINLOG_DUMP with the flag unset do not get an EOF when the server has sent the last event in the binary log, which causes the connection to block. This flag, which was removed in error in MySQL 5.6.5, is now restored in the current release.
- As part of this fix, a new --connection-server-id option is added to mysqlbinlog. This option can be used by the client to test a MySQL server for the presence of this issue.
- When a SELECT included a derived table in a join in its FROM list and the SELECT list included COUNT(DISTINCT), the COUNT() returned 1 even if the underlying result set was empty.
- Enabling optimizer trace could cause a server exit for queries with a subquery in a HAVING clause.
- SHA and MD5 functions failed for operations using the internal filename character set and could cause a server exit.
- Large arguments passed to mysqldump could lead to buffer overflow and program exit.
- Compiler flags were not passed to DTrace, causing problems for 32-bit builds cross-compiled on 64-bit platforms.
- ALTER TABLE on a partitioned table could result in the wrong storage engine being written into the table's .frm file and displayed in SHOW CREATE TABLE.
- With the max_heap_table_size system variable set to a large value (20GB), creation of a temporary table or a table using the MEMORY storage engine caused a server exit.
- For debug builds, a 0x00 character in a full-text query string that used the ujis_japanese_ci, utf8mb4_turkish_ci, or eucjpms_bin collation could raise an assertion.
- mysqladmin password masked the old password given on the command line, but not the new password.
- yaSSL code had an off-by-one error in certificate decoding that could cause buffer overflow.
- yaSSL code had an opendir() without a corresponding closedir().
- For full-text queries on InnoDB tables, attempts to access deleted document IDs could lead to a server exit.
- MyISAM temporary files could be used to mount a code-execution attack.
- For queries that selected from the Performance Schema events_statements_current table, adding an ORDER BY clause could produce incorrect results.
- If a query had both MIN()/MAX() and aggregate_function(DISTINCT) (for example, SUM(DISTINCT)) and was executed using Loose Index Scan, the result values of MIN()/MAX() were set improperly.
- For UNION statements, the rows-examined value was calculated incorrectly. This was manifest as too-large values for the ROWS_EXAMINED column of Performance Schema statement tables (such as events_statements_current).
- Clients could determine based on connection error message content whether an account existed.
- An assertion could be raised when creating a index on a prefix of a TINYBLOB or GEOMETRY column in an InnoDB column.
- Use of a nonmultibyte algorithm for skipping leading spaces in multibyte strings could cause a server exit. (Bug #12368495, Bug #18315770)
- For a view defined on a UNION, the server could create an invalid view definition.
- Configuring with cmake -DWITHOUT_SERVER to build clients without the server failed for builds outside of the source tree.
- With big_tables enabled, queries that used COUNT(DISTINCT) on a simple join with a constant equality condition on a non-duplicate key returned incorrect results.
- Deadlock could occur if three threads simultaneously performed INSTALL PLUGIN, SHOW VARIABLES, and mysql_change_user().
- mysql_config_editor exited when given an empty argument to the --login-path option.
- MySQL did not compile with Bison 3. A workaround is to downgrade to Bison 2.
- Uninstalling and reinstalling semisynchronous replication plugins while semisynchronous replication was active caused replication failures. The plugins now check whether they can be uninstalled and produce an error if semisynchronous replication is active. To uninstall the master-side plugin, there must be no semisynchronous slaves. To uninstall the slave-side plugin, there must be no semisynchronous I/O threads running.
- If there was a predicate on a column referenced by MIN() or MAX() and that predicate was not present in all the disjunctions on key parts earlier in the compound index, Loose Index Scan returned an incorrect result.
- Client auto-reconnect did not work for clients linked against libmysqlclient, even with MYSQL_OPT_RECONNECT enabled.
- Upgrades using RPM packages could change the ownership of an installation directory.
- Proxy users were unable to execute statements if the proxied user password had expired.
- A new CMake option, SUNPRO_CXX_LIBRARY, enables linking against libCstd instead of stlport4 on Solaris 10 or later. This works only for client code because the server depends on C++98. Example usage:
- cmake -DWITHOUT_SERVER=1 -DSUNPRO_CXX_LIBRARY=Cstd
- File permissions and line endings of several test and configuration files were made more consistent to avoid warnings from package checkers. (Bug #68521, Bug #16415173, Bug #16395459, Bug #68517, Bug #16415032, Bug #71112, Bug #17919313, Bug #71113, Bug #17919422)

更新時間：2014-07-31
更新細節：

What's new in this version:

Functionality Added or Changed:
- CMake support was updated to handle CMake version 3.
- The timed_mutexes system variable has no effect and is deprecated. Bugs Fixed:
- InnoDB: Opening a parent table that has thousands of child tables could result in a long semaphore wait condition.
- Partitioning: Selecting from a table having multiple columns in its primary key and partitioned by LIST COLUMNS(R), where R was the last (rightmost) column listed in the primary key definition, returned an incorrect result.
- Replication: When using row-based replication, updating or deleting a row on the master that did not exist on the slave led to failure of the slave when it tried to process the change. This problem occurred with InnoDB tables lacking a primary key.
- Replication: Quotation marks were not always handled correctly by LOAD DATA INFILE when written into the binary log.
- Replication: A group of threads involved in acquiring locks could deadlock when the following events occurred:
> Dump thread reconnects from slave; on master, a new dump thread tries to kill zombie dump threads; having acquired the thread's LOCK_thd_data, it is about to acquire LOCK_log.
> Application thread executing show binary logs, having acquired LOCK_log and about to acquire LOCK_index.
> Application thread executing PURGE BINARY LOGS; having acquired LOCK_index, it is about to acquire LOCK_thread_count.
> Application thread executing SHOW PROCESSLIST (or SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST), having acquired LOCK_thread_count and about to acquire the zombie dump thread's LOCK_thd_data.
- SHA and MD5 functions failed for operations using the internal filename character set and could cause a server exit.
- Large arguments passed to mysqldump could lead to buffer overflow and program exit.
- Compiler flags were not passed to DTrace, causing problems for 32-bit builds cross-compiled on 64-bit platforms.
- ALTER TABLE on a partitioned table could result in the wrong storage engine being written into the table's .frm file and displayed in SHOW CREATE TABLE.
- With the max_heap_table_size system variable set to a large value (20GB), creation of a temporary table or a table using the MEMORY storage engine caused a server exit.
- mysqladmin password masked the old password given on the command line, but not the new password.
- yaSSL code had an off-by-one error in certificate decoding that could cause buffer overflow.
- yaSSL code had an opendir() without a corresponding closedir().
- MyISAM temporary files could be used to mount a code-execution attack.
- If a query had both MIN()/MAX() and aggregate_function(DISTINCT) (for example, SUM(DISTINCT)) and was executed using Loose Index Scan, the result values of MIN()/MAX() were set improperly.
- For UNION statements, the rows-examined value was calculated incorrectly. This was manifest as too-large values for the ROWS_EXAMINED column of Performance Schema statement tables (such as events_statements_current).
- Clients could determine based on connection error message content whether an account existed.
- An assertion could be raised when creating a index on a prefix of a TINYBLOB or GEOMETRY column in an InnoDB column.
- Use of a nonmultibyte algorithm for skipping leading spaces in multibyte strings could cause a server exit.
- For a view defined on a UNION, the server could create an invalid view definition.
- Deadlock could occur if three threads simultaneously performed INSTALL PLUGIN, SHOW VARIABLES, and mysql_change_user().
- MySQL did not compile with Bison 3. A workaround is to downgrade to Bison 2.
- Uninstalling and reinstalling semisynchronous replication plugins while semisynchronous replication was active caused replication failures. The plugins now check whether they can be uninstalled and produce an error if semisynchronous replication is active. To uninstall the master-side plugin, there must be no semisynchronous slaves. To uninstall the slave-side plugin, there must be no semisynchronous I/O threads running.
- If there was a predicate on a column referenced by MIN() or MAX() and that predicate was not present in all the disjunctions on key parts earlier in the compound index, Loose Index Scan returned an incorrect result.
- File permissions and line endings of several test and configuration files were made more consistent to avoid warnings from package checkers.

更新時間：2014-07-31
更新細節：

What's new in this version:

Functionality Added or Changed:
- CMake support was updated to handle CMake version 3.
- The timed_mutexes system variable has no effect and is deprecated. Bugs Fixed:
- InnoDB: Opening a parent table that has thousands of child tables could result in a long semaphore wait condition.
- Partitioning: Selecting from a table having multiple columns in its primary key and partitioned by LIST COLUMNS(R), where R was the last (rightmost) column listed in the primary key definition, returned an incorrect result.
- Replication: When using row-based replication, updating or deleting a row on the master that did not exist on the slave led to failure of the slave when it tried to process the change. This problem occurred with InnoDB tables lacking a primary key.
- Replication: Quotation marks were not always handled correctly by LOAD DATA INFILE when written into the binary log.
- Replication: A group of threads involved in acquiring locks could deadlock when the following events occurred:
> Dump thread reconnects from slave; on master, a new dump thread tries to kill zombie dump threads; having acquired the thread's LOCK_thd_data, it is about to acquire LOCK_log.
> Application thread executing show binary logs, having acquired LOCK_log and about to acquire LOCK_index.
> Application thread executing PURGE BINARY LOGS; having acquired LOCK_index, it is about to acquire LOCK_thread_count.
> Application thread executing SHOW PROCESSLIST (or SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST), having acquired LOCK_thread_count and about to acquire the zombie dump thread's LOCK_thd_data.
- SHA and MD5 functions failed for operations using the internal filename character set and could cause a server exit.
- Large arguments passed to mysqldump could lead to buffer overflow and program exit.
- Compiler flags were not passed to DTrace, causing problems for 32-bit builds cross-compiled on 64-bit platforms.
- ALTER TABLE on a partitioned table could result in the wrong storage engine being written into the table's .frm file and displayed in SHOW CREATE TABLE.
- With the max_heap_table_size system variable set to a large value (20GB), creation of a temporary table or a table using the MEMORY storage engine caused a server exit.
- mysqladmin password masked the old password given on the command line, but not the new password.
- yaSSL code had an off-by-one error in certificate decoding that could cause buffer overflow.
- yaSSL code had an opendir() without a corresponding closedir().
- MyISAM temporary files could be used to mount a code-execution attack.
- If a query had both MIN()/MAX() and aggregate_function(DISTINCT) (for example, SUM(DISTINCT)) and was executed using Loose Index Scan, the result values of MIN()/MAX() were set improperly.
- For UNION statements, the rows-examined value was calculated incorrectly. This was manifest as too-large values for the ROWS_EXAMINED column of Performance Schema statement tables (such as events_statements_current).
- Clients could determine based on connection error message content whether an account existed.
- An assertion could be raised when creating a index on a prefix of a TINYBLOB or GEOMETRY column in an InnoDB column.
- Use of a nonmultibyte algorithm for skipping leading spaces in multibyte strings could cause a server exit.
- For a view defined on a UNION, the server could create an invalid view definition.
- Deadlock could occur if three threads simultaneously performed INSTALL PLUGIN, SHOW VARIABLES, and mysql_change_user().
- MySQL did not compile with Bison 3. A workaround is to downgrade to Bison 2.
- Uninstalling and reinstalling semisynchronous replication plugins while semisynchronous replication was active caused replication failures. The plugins now check whether they can be uninstalled and produce an error if semisynchronous replication is active. To uninstall the master-side plugin, there must be no semisynchronous slaves. To uninstall the slave-side plugin, there must be no semisynchronous I/O threads running.
- If there was a predicate on a column referenced by MIN() or MAX() and that predicate was not present in all the disjunctions on key parts earlier in the compound index, Loose Index Scan returned an incorrect result.
- File permissions and line endings of several test and configuration files were made more consistent to avoid warnings from package checkers.

更新時間：2014-06-02
更新細節：

What's new in this version:

Bugs Fixed:
- InnoDB: For each insert, memset would be called three times to allocate memory for system fields. To reduce CPU usage, the three memset calls are now combined into a single call.
- Replication: When used on a table employing a transactional storage engine, a failed TRUNCATE TABLE was still written to the binary log and thus replayed on the slave. This could lead to inconsistency when the master retained data that was removed on the slave. Now in such cases TRUNCATE TABLE is logged only when it executes successfully.
- Certain INFORMATION_SCHEMA queries could cause a server exit.
- For indexes on prefixes or character string columns, index corruption could occur for assignment of binary data to the column due to improper character counting.
- Solaris-specific scripts were included in and installed by non-Solaris packages.
- EXPLAIN on a query with an EXISTS subquery containing a UNION could cause a server exit. Multiple executions of a prepared EXPLAIN on a UNION of subqueries could cause a server exit.
- Executing a correlated subquery on an ARCHIVE table which has an AUTO_INCREMENT column caused the server to hang.
- The client library could cause clients to exit due to incorrectly mapping the client error number to the corresponding message, if reallocation of packet buffer memory occurred.
- Calling mysql_get_server_version() with an invalid connection handler argument caused the client to exit. Now it returns 0 and reports a CR_COMMANDS_OUT_OF_SYNC error.
- On Windows, calling mysql_thread_init() call without mysql_init() caused the client to exit. windows. Now it returns a nonzero result because it is an error to call mysql_thread_init() before the client library is initialized with mysql_library_init().
- CMake produced not-useful warnings about INTERFACE_LINK_LIBRARIES policy.
- LOAD DATA LOCAL INFILE could use all CPU if import errors occurred when there were no line delimiters.
- A statement of the following form broke row-based replication because it created a table having a field of data type BIGINT with a display width of 3000, which is beyond the maximum acceptable value of 255: CREATE TABLE t1 AS SELECT REPEAT('A',1000) DIV 1 AS a;

更新時間：2014-06-02
更新細節：

What's new in this version:

Functionality Added or Changed:
- The obsolete and unmaintained charset2html utility has been removed from MySQL distributions. (Bug #71897, Bug #18352347)
- The mysqlbug, mysql_waitpid, and mysql_zap utilities have been deprecated and will be removed in MySQL 5.7. Bugs Fixed:
- InnoDB: After upgrading from 5.6.10 to MySQL versions up to and including MySQL 5.6.18, InnoDB would attempt to rename obsolete full-text search auxiliary tables on server startup, resulting in an assertion failure. (Bug #18634201, Bug #72079)
- InnoDB: For each insert, memset would be called three times to allocate memory for system fields. To reduce CPU usage, the three memset calls are now combined into a single call. (Bug #17858679, Bug #71014)
- InnoDB: Enabling the InnoDB Table Monitor would result in a ib_table->stat_initialized assertion failure. (Bug #17039528, Bug #69641)
- InnoDB: Setting innodb_max_dirty_pages_pct=0 would leave 1% of dirty pages unflushed. Buffer pool flushing is initiated when the percentage of dirty pages is greater innodb_max_dirty_pages_pct. The internal variables that store the innodb_max_dirty_pages_pct value and the percentage of dirty pages (buf_get_modified_ratio_pct and srv_max_buf_pool_modified_pct) were defined as unsigned integer data types, which meant that a innodb_max_dirty_pages_pct value of 0 required a dirty pages percentage of 1 or greater to initiate buffer pool flushing.
- To address this problem, the buf_get_modified_ratio_pct and srv_max_buf_pool_modified_pct internal variables are redefined as double data types, which changes the range value for innodb_max_dirty_pages_pct and innodb_max_dirty_pages_pct_lwm from 0 .. 99 to 0 .. 99.99. Additionally, buffer pool flushing is now initiated when the percentage of dirty pages is “greater than or equal to” innodb_max_dirty_pages_pct. (Bug #13029450, Bug #62534)
- Replication: Log rotation events could cause group_relay_log_pos to be moved forward incorrectly within a group. This meant that, when the transaction was retried, or if the SQL thread was stopped in the middle of a transaction following one or more log rotations (such that the transaction or group spanned multiple relay log files), part or all of the group was silently skipped.
- This issue has been addressed by correcting a problem in the logic used to avoid touching the coordinates of the SQL thread when updating the log position as part of a relay log rotation whereby it was possible to update the SQL thread's coordinates when not using a multi-threaded slave, even in the middle of a group. (Bug #18482854)
- Replication: When running the server with --gtid-mode=ON, STOP SLAVE followed by START SLAVE resulted in a mismatch between the information provided by INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO and the Slave_open_temp_tables status variable: the INNODB_TEMP_TABLE_INFO table showed that no temporary tables existed, but Slave_open_temp_tables had a nonzero value. (Bug #18364070)
- References: See also Bug #18236612.
- Replication: In certain cases, the server mishandled triggers and stored procedures that tried to modify other tables when called by CREATE TABLE ... SELECT. This is now handled correctly as an error. (Bug #18137535)
- Replication: When used on a table employing a transactional storage engine, a failed TRUNCATE TABLE was still written to the binary log and thus replayed on the slave. This could lead to inconsistency when the master retained data that was removed on the slave.
- Now in such cases TRUNCATE TABLE is logged only when it executes successfully. (Bug #17942050, Bug #71070)
- Replication: The server did not always handle the auto.cnf file correctly in cases where this file's permissions were incorrect. (Bug #17786581, Bug #70891)
- Replication: When the binary log was rotated due to receipt of a SIGHUP signal, the new binary log did not contain the Previous_gtid_event required for subsequent processing of that binary log's GTID events. Now when SIGHUP is received, steps are taken to insure that the server writes the necessary Previous_gtid_event to the new log before writing any GTID events to the new log. (Bug #17026898) Replication: When gtid_mode=ON, and a transaction is filtered out on the slave, the GTID of the transaction is still logged on the slave as an “empty” transaction (consisting of a GTID followed immediately by BEGIN and then COMMIT). This is necessary to prevent the transaction from being retransmitted the next time the slave reconnects or is involved in a failover. The current fix addresses two issues relating to such “empty” transactions:
- No empty transaction was generated for CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE statements.
- If the slave used a database filter (--replicate-do-db or --replicate-ignore-db option), no empty transaction was generated.
- (Bug #71326, Bug #18095502, Bug #18145032)
- The server could fail to properly reprepare triggers that referred to another table after that table was truncated. (Bug #18596756)
- Certain INFORMATION_SCHEMA queries could cause a server exit. (Bug #18319790)
- For indexes on prefixes or character string columns, index corruption could occur for assignment of binary data to the column due to improper character counting. (Bug #18359924)
- Solaris-specific scripts were included in and installed by non-Solaris packages. (Bug #18305641)
- Concurrent execution of a FLUSH TABLE operation and a stored program that used a cursor could cause a server exit. (Bug #18158639)
- The client library could cause clients to exit due to incorrectly mapping the client error number to the corresponding message, if reallocation of packet buffer memory occurred. (Bug #18080920)
- Calling mysql_get_server_version() with an invalid connection handler argument caused the client to exit. Now it returns 0 and reports a CR_COMMANDS_OUT_OF_SYNC error. (Bug #18053212)
- mysqldump could create table definitions in the dump file that resulted in Too many columns errors when reloading the dump file. (Bug #17477959)
- On Windows, calling mysql_thread_init() call without mysql_init() caused the client to exit. windows. Now it returns a nonzero result because it is an error to call mysql_thread_init() before the client library is initialized with mysql_library_init(). (Bug #17514920)
- The optimizer trace could cause a server exit in cases where a subquery was transformed away. (Bug #17458054)
- The Debug Sync facility could lose a signal, leading to a spurious ER_DEBUG_SYNC_TIMEOUT error. (Bug #14765080, Bug #18221750)
- Compilation problems were fixed for errors reported by Clang and gcc when compiling in C++11 mode. (Bug #66803, Bug #14631159)
- CMake produced not-useful warnings about INTERFACE_LINK_LIBRARIES policy. (Bug #71089, Bug #17905155, Bug #17894997)
- LOAD DATA LOCAL INFILE could use all CPU if import errors occurred when there were no line delimiters. (Bug #51840, Bug #11759519)
On Windows, REPAIR TABLE and OPTIMIZE TABLE failed for MyISAM tables with .MYD files larger than 4GB. (Bug #69683, Bug #17235179)
- A statement of the following form broke row-based replication because it created a table having a field of data type BIGINT with a display width of 3000, which is beyond the maximum acceptable value of 255: CREATE TABLE t1 AS SELECT REPEAT('A',1000) DIV 1 AS a; (Bug #71179, Bug #17994219)
- Updates could fail to update all applicable rows in cases where multiple key values were identical except for trailing spaces. (Bug #69684, Bug #17156940)

更新時間：2014-06-02
更新細節：

What's new in this version:

Bugs Fixed:
- InnoDB: For each insert, memset would be called three times to allocate memory for system fields. To reduce CPU usage, the three memset calls are now combined into a single call.
- Replication: When used on a table employing a transactional storage engine, a failed TRUNCATE TABLE was still written to the binary log and thus replayed on the slave. This could lead to inconsistency when the master retained data that was removed on the slave. Now in such cases TRUNCATE TABLE is logged only when it executes successfully.
- Certain INFORMATION_SCHEMA queries could cause a server exit.
- For indexes on prefixes or character string columns, index corruption could occur for assignment of binary data to the column due to improper character counting.
- Solaris-specific scripts were included in and installed by non-Solaris packages.
- EXPLAIN on a query with an EXISTS subquery containing a UNION could cause a server exit. Multiple executions of a prepared EXPLAIN on a UNION of subqueries could cause a server exit.
- Executing a correlated subquery on an ARCHIVE table which has an AUTO_INCREMENT column caused the server to hang.
- The client library could cause clients to exit due to incorrectly mapping the client error number to the corresponding message, if reallocation of packet buffer memory occurred.
- Calling mysql_get_server_version() with an invalid connection handler argument caused the client to exit. Now it returns 0 and reports a CR_COMMANDS_OUT_OF_SYNC error.
- On Windows, calling mysql_thread_init() call without mysql_init() caused the client to exit. windows. Now it returns a nonzero result because it is an error to call mysql_thread_init() before the client library is initialized with mysql_library_init().
- CMake produced not-useful warnings about INTERFACE_LINK_LIBRARIES policy.
- LOAD DATA LOCAL INFILE could use all CPU if import errors occurred when there were no line delimiters.
- A statement of the following form broke row-based replication because it created a table having a field of data type BIGINT with a display width of 3000, which is beyond the maximum acceptable value of 255: CREATE TABLE t1 AS SELECT REPEAT('A',1000) DIV 1 AS a;

更新時間：2014-06-02
更新細節：

What's new in this version:

Functionality Added or Changed:
- The obsolete and unmaintained charset2html utility has been removed from MySQL distributions. (Bug #71897, Bug #18352347)
- The mysqlbug, mysql_waitpid, and mysql_zap utilities have been deprecated and will be removed in MySQL 5.7. Bugs Fixed:
- InnoDB: After upgrading from 5.6.10 to MySQL versions up to and including MySQL 5.6.18, InnoDB would attempt to rename obsolete full-text search auxiliary tables on server startup, resulting in an assertion failure. (Bug #18634201, Bug #72079)
- InnoDB: For each insert, memset would be called three times to allocate memory for system fields. To reduce CPU usage, the three memset calls are now combined into a single call. (Bug #17858679, Bug #71014)
- InnoDB: Enabling the InnoDB Table Monitor would result in a ib_table->stat_initialized assertion failure. (Bug #17039528, Bug #69641)
- InnoDB: Setting innodb_max_dirty_pages_pct=0 would leave 1% of dirty pages unflushed. Buffer pool flushing is initiated when the percentage of dirty pages is greater innodb_max_dirty_pages_pct. The internal variables that store the innodb_max_dirty_pages_pct value and the percentage of dirty pages (buf_get_modified_ratio_pct and srv_max_buf_pool_modified_pct) were defined as unsigned integer data types, which meant that a innodb_max_dirty_pages_pct value of 0 required a dirty pages percentage of 1 or greater to initiate buffer pool flushing.
- To address this problem, the buf_get_modified_ratio_pct and srv_max_buf_pool_modified_pct internal variables are redefined as double data types, which changes the range value for innodb_max_dirty_pages_pct and innodb_max_dirty_pages_pct_lwm from 0 .. 99 to 0 .. 99.99. Additionally, buffer pool flushing is now initiated when the percentage of dirty pages is “greater than or equal to” innodb_max_dirty_pages_pct. (Bug #13029450, Bug #62534)
- Replication: Log rotation events could cause group_relay_log_pos to be moved forward incorrectly within a group. This meant that, when the transaction was retried, or if the SQL thread was stopped in the middle of a transaction following one or more log rotations (such that the transaction or group spanned multiple relay log files), part or all of the group was silently skipped.
- This issue has been addressed by correcting a problem in the logic used to avoid touching the coordinates of the SQL thread when updating the log position as part of a relay log rotation whereby it was possible to update the SQL thread's coordinates when not using a multi-threaded slave, even in the middle of a group. (Bug #18482854)
- Replication: When running the server with --gtid-mode=ON, STOP SLAVE followed by START SLAVE resulted in a mismatch between the information provided by INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO and the Slave_open_temp_tables status variable: the INNODB_TEMP_TABLE_INFO table showed that no temporary tables existed, but Slave_open_temp_tables had a nonzero value. (Bug #18364070)
- References: See also Bug #18236612.
- Replication: In certain cases, the server mishandled triggers and stored procedures that tried to modify other tables when called by CREATE TABLE ... SELECT. This is now handled correctly as an error. (Bug #18137535)
- Replication: When used on a table employing a transactional storage engine, a failed TRUNCATE TABLE was still written to the binary log and thus replayed on the slave. This could lead to inconsistency when the master retained data that was removed on the slave.
- Now in such cases TRUNCATE TABLE is logged only when it executes successfully. (Bug #17942050, Bug #71070)
- Replication: The server did not always handle the auto.cnf file correctly in cases where this file's permissions were incorrect. (Bug #17786581, Bug #70891)
- Replication: When the binary log was rotated due to receipt of a SIGHUP signal, the new binary log did not contain the Previous_gtid_event required for subsequent processing of that binary log's GTID events. Now when SIGHUP is received, steps are taken to insure that the server writes the necessary Previous_gtid_event to the new log before writing any GTID events to the new log. (Bug #17026898) Replication: When gtid_mode=ON, and a transaction is filtered out on the slave, the GTID of the transaction is still logged on the slave as an “empty” transaction (consisting of a GTID followed immediately by BEGIN and then COMMIT). This is necessary to prevent the transaction from being retransmitted the next time the slave reconnects or is involved in a failover. The current fix addresses two issues relating to such “empty” transactions:
- No empty transaction was generated for CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE statements.
- If the slave used a database filter (--replicate-do-db or --replicate-ignore-db option), no empty transaction was generated.
- (Bug #71326, Bug #18095502, Bug #18145032)
- The server could fail to properly reprepare triggers that referred to another table after that table was truncated. (Bug #18596756)
- Certain INFORMATION_SCHEMA queries could cause a server exit. (Bug #18319790)
- For indexes on prefixes or character string columns, index corruption could occur for assignment of binary data to the column due to improper character counting. (Bug #18359924)
- Solaris-specific scripts were included in and installed by non-Solaris packages. (Bug #18305641)
- Concurrent execution of a FLUSH TABLE operation and a stored program that used a cursor could cause a server exit. (Bug #18158639)
- The client library could cause clients to exit due to incorrectly mapping the client error number to the corresponding message, if reallocation of packet buffer memory occurred. (Bug #18080920)
- Calling mysql_get_server_version() with an invalid connection handler argument caused the client to exit. Now it returns 0 and reports a CR_COMMANDS_OUT_OF_SYNC error. (Bug #18053212)
- mysqldump could create table definitions in the dump file that resulted in Too many columns errors when reloading the dump file. (Bug #17477959)
- On Windows, calling mysql_thread_init() call without mysql_init() caused the client to exit. windows. Now it returns a nonzero result because it is an error to call mysql_thread_init() before the client library is initialized with mysql_library_init(). (Bug #17514920)
- The optimizer trace could cause a server exit in cases where a subquery was transformed away. (Bug #17458054)
- The Debug Sync facility could lose a signal, leading to a spurious ER_DEBUG_SYNC_TIMEOUT error. (Bug #14765080, Bug #18221750)
- Compilation problems were fixed for errors reported by Clang and gcc when compiling in C++11 mode. (Bug #66803, Bug #14631159)
- CMake produced not-useful warnings about INTERFACE_LINK_LIBRARIES policy. (Bug #71089, Bug #17905155, Bug #17894997)
- LOAD DATA LOCAL INFILE could use all CPU if import errors occurred when there were no line delimiters. (Bug #51840, Bug #11759519)
On Windows, REPAIR TABLE and OPTIMIZE TABLE failed for MyISAM tables with .MYD files larger than 4GB. (Bug #69683, Bug #17235179)
- A statement of the following form broke row-based replication because it created a table having a field of data type BIGINT with a display width of 3000, which is beyond the maximum acceptable value of 255: CREATE TABLE t1 AS SELECT REPEAT('A',1000) DIV 1 AS a; (Bug #71179, Bug #17994219)
- Updates could fail to update all applicable rows in cases where multiple key values were identical except for trailing spaces. (Bug #69684, Bug #17156940)

更新時間：2014-03-28
更新細節：

What's new in this version:

Functionality Added or Changed:
- Incompatible Change - The AES_ENCRYPT() and AES_DECRYPT() functions now permit control of the block encryption mode and take an optional initialization vector argument.
- The new block_encryption_mode system variable controls the mode for block-based encryption algorithms. Its default value is aes-128-ecb, which signifies encryption using a key length of 128 bits and ECB mode.
- An optional init_vector argument provides an initialization vector for encryption modes that require it.
- AES_ENCRYPT(str,key_str[,init_vector])
- AES_DECRYPT(crypt_str,key_str[,init_vector])
- A random string of bytes to use for the initialization vector can be produced by calling the new RANDOM_BYTES() function.
- For more information, see Encryption and Compression Functions.
- These changes make statements that use AES_ENCRYPT() or AES_DECRYPT() unsafe for statement-based replication and they cannot be stored in the query cache. Queries that use RANDOM_BYTES() are unsafe for statement-based replication and cannot be stored in the query cache.
- Incompatible Change - The deprecated ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE SQL modes now do nothing. Instead, their previous effects are included in the effects of strict SQL mode (STRICT_ALL_TABLES or STRICT_TRANS_TABLES). In other words, strict mode now means the same thing as the previous meaning of strict mode plus the ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE modes. This change reduces the number of SQL modes with an effect dependent on strict mode and makes them part of strict mode itself.
- To prepare for the SQL mode changes in this version of MySQL, it is advisable before upgrading to read SQL Mode Changes in MySQL 5.7. That discussion provides guidelines to assess whether your applications will be affected by these changes.
- The deprecated ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE SQL modes are still recognized so that statements that name them do not produce an error, but will be removed in a future version of MySQL. To make advance preparation for versions of MySQL in which these modes do not exist, applications should be modified to not refer to those mode names. InnoDB - MySQL now supports rebuilding regular and partitioned InnoDB tables using online DDL (ALGORITHM=INPLACE) for the following operations:
- OPTIMIZE TABLE
- ALTER TABLE ... FORCE
- ALTER TABLE ... ENGINE=INNODB (when run on an InnoDB table)
- Online DDL support reduces table rebuild time and permits concurrent DML, which helps reduce user application downtime. For additional information, see Overview of Online DDL. (Bug #13975225)
- On Solaris, mysql_config --libs now includes -R/path/to/library so that libraries can be found at runtime. (Bug #18235669)
- mysql_install_db provides a more informative diagnostic message when required Perl modules are missing. (Bug #69844, Bug #18187451)
- The IGNORE clause for ALTER TABLE is now deprecated and will be removed in a future version of MySQL. ALTER IGNORE TABLE causes problems for replication, prevents online ALTER TABLE for unique index creation, and causes problems with foreign keys (rows removed in the parent table). Bugs Fixed:
- Incompatible Change: Old clients (older than MySQL 5.5.7) failed to parse authentication data correctly if the server was started with the --default-authentication-plugin=sha256_password option.
- Note - As a result of this bug fix, MySQL 5.6.16 clients cannot connect to a 5.6.17 server using an account that authenticates with the sha256_password plugin. Similarly, MySQL 5.7.3 clients cannot connect to a 5.7.4 server using an account that authenticates with the sha256_password plugin. (Bug #17495562)
- Important Change; InnoDB; Partitioning: The FLUSH TABLES statement's FOR EXPORT option is now supported for partitioned InnoDB tables. (Bug #16943907)
- InnoDB: Running a SELECT on a partitioned table caused a memory access violation in memcpy(). (Bug #18383840)
- InnoDB: An invalid memmove in fts_query_fetch_document would cause a serious error. (Bug #18229433)
- InnoDB: For full-text queries, a failure to check that num_token is less than max_proximity_item could result in an assertion. (Bug #18233051)
- InnoDB: innodb_ft_result_cache_limit now has a hardcoded maximum value of 4294967295 bytes or (2**32 -1). The maximum value was previously defined as the maximum value of ulong. (Bug #18180057, Bug #71554)
- InnoDB: InnoDB would fail to restore a corrupt first page of a system tablespace data file from the doublewrite buffer, resulting in a startup failure. (Bug #18144349, Bug #18058884)
- InnoDB: An UPDATE resulted in a memory access error in lock_rec_other_trx_holds_expl. The transaction list (trx_sys->rw_trx_list) was traversed without acquiring the transaction subsystem mutex (trx_sys->mutex). (Bug #18161853)
- InnoDB: A regression introduced by Bug #14329288 would result in a performance degradation when a compressed table does not fit into memory. (Bug #18124788, Bug #71436)
- InnoDB: The maximum value for innodb_thread_sleep_delay is now 1000000 microseconds. The previous maximum value (4294967295 microseconds on 32-bit and 18446744073709551615 microseconds on 64-bit) was unnecessarily large. Because the maximum value of innodb_thread_sleep_delay is limited by the value set for innodb_adaptive_max_sleep_delay (when set to a non-zero value), the maximum value for innodb_thread_sleep_delay is now the same as the maximum value for innodb_adaptive_max_sleep_delay. (Bug #18117322)
- InnoDB: A full-text tokenizer thread would terminate with an incorrect error message. (Bug #18021306)
- InnoDB: Attempting to uninstall the InnoDB memcached plugin while the InnoDB memcached plugin is still initializing would kill the InnoDB memcached daemon thread. Uninstall should wait until initialization is complete. (Bug #18038948)
- InnoDB: In debug builds, creating a unique index on a binary column, with input data containing duplicate keys, would cause an assertion. (Bug #18010711)
- InnoDB: The srv_monitor_thread would crash in the lock_print_info_summary() function due to a race condition between the srv_monitor_thread and purge coordinator thread. (Bug #17980590, Bug #70430)
- InnoDB: Attempting to add an invalid foreign key when foreign key checking is disabled (foreign_key_checks=0) would cause a serious error. (Bug #17666774)
- InnoDB: For debug builds, the table rebuilding variant of online ALTER TABLE, when run on tables with BLOB columns, would cause an assertion in the row_log_table_apply_update function. For normal builds, a DB_PRODUCTION error would be returned. (Bug #17661919)
- InnoDB: When creating a table there are a minimum of three separate inserts on the mysql.innodb_index_stats table. To improve CREATE TABLE performance, there is now a single COMMIT operation instead of one for each insert. (Bug #17323202, Bug #70063)
- InnoDB: The server would halt with an assertion in lock_rec_has_to_wait_in_queue(lock) due to a locking-related issue and a transaction being prematurely removed from trx_sys->rw_trx_set. (Bug #17320977)
- InnoDB: Server shutdown would result in a hang with the following message written to the error log: “[NOTE] InnoDB: Waiting for purge thread to be suspended.” (Bug #16495065)
- InnoDB: InnoDB would fail to start when innodb_data_file_path specified the data file size in kilobytes by appending K to the size value. (Bug #16287752)
- InnoDB: An insert buffer merge would cause an assertion error due to incorrectly handled ownership information for externally stored BLOBs.
- InnoDB: Assertion failure in thread thread_num in file ibuf0ibuf.cc line 4080
- InnoDB: Failing assertion: rec_get_deleted_flag(rec, page_is_comp(page)) Bug #14668683)
- InnoDB: Decreasing the auto_increment_increment value would have no affect on the next auto-increment value. (Bug #14049391, Bug #65225)
- Partitioning: When the index_merge_intersection flag (enabled by default) or the index_merge_union flag was enabled by the setting of the optimizer_switch system variable, queries returned incorrect results when executed against partitoned tables that used the MyISAM storage engine, as well as partitioned InnoDB tables that lacked a primary key. (Bug #18167648)
- References: See also Bug #16862316, Bug #17588348, Bug #17648468.
- Replication: The MASTER_SSL_CRL and MASTER_SSL_CRLPATH options are not available when using yaSSL; MySQL Replication now sets these to NULL automatically whenever yaSSL is enabled. (Bug #18165937)
- Replication: Setting --slave-parallel-workers to 1 or greater and starting the slave caused the slave SQL thread to use but not release memory until the slave was restarted with STOP SLAVE and START SLAVE. (Bug #18001777, Bug #71197)
- Replication: When a slave was configured with replication filters and --log-warnings=2, every statement which was filtered caused an entry to be written in the error log. For busy servers which generated many statements to be filtered, the result was that the error log could quickly grow to many gigabytes in size. Now a throttle is used for such errors, so that an error message is printed only once in a given interval, saying that this particular error occurred a specific number of times during that interval. (Bug #17986385)
- Replication: SHOW SLAVE STATUS used incorrect values when reporting MASTER_SSL_CRL and MASTER_SSL_CRLPATH. (Bug #17772911, Bug #70866)
- References: This bug was introduced by Bug #11747191.
- Replication - Binary log events could be sent to slaves before they were flushed to disk on the master, even when sync_binlog was set to 1. This could lead to either of those of the following two issues when the master was restarted following a crash of the operating system.
- Replication cannot continue because one or more slaves are requesting replicate events that do not exist on the master.
- Data exists on one or more slaves, but not on the master.
- Such problems are expected on less durable settings (sync_binlog not equal to 1), but it should not happen when sync_binlog is 1. To fix this issue, a lock (LOCK_log) is now held during synchronization, and is released only after the binary events are actually written to disk. (Bug #17632285, Bug #70669)
- Replication: When running the slave with --slave-parallel-workers at 1 or greater, setting --slave-skip-errors=all caused the error log to be filled with with instances of the warning Slave SQL: Could not execute Query event. Detailed error: ;, Error_code: 0. (Bug #17581990, Bug #68429)
- References: See also Bug #17986385.
- Replication: A number of possible state messages used as values for the PROCESSLIST_STATE column of the Performance Schema threads table were longer than the width of the column (64 characters).
- The long state messages are now silently truncated in order to avoid errors. This fix applies in MySQL 5.6 only; a permanent fix for the issue is made in MySQL 5.7 and later. (Bug #17319380)
- Replication: The server did not handle correctly the insertion of a row larger than 4 GB when using row-based replication. (Bug #17081415)
- Replication: When using row-based replication, an additional auto-increment column on the slave version of a table was not updated correctly; a zero was inserted instead. (Bug #17066269, Bug #69680)
- 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, or DELETE) or flush (TRUNCATE TABLE) performance schema tables on a single server without affecting others. However, when replicating from a MySQL 5.5 master to a MySQL 5.5 or later slave, warnings about unsafe statements updating Performance Schema tables were elevated to errors. For MySQL 5.6 and later slaves, this prevented the simultaneous use of performance_schema and GTIDs (see Replication with Global Transaction Identifiers).
- This fix causes all updates on tables in the performance_schema database to be filtered on the master and not replicated, regardless of the type of logging that is in effect. Prior to this fix, statements using 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_SCHEMA database is not changed by this fix.
- For more information, see MySQL Performance Schema. (Bug #16814264)
- References: See also Bug #14741537, Bug #18259193.
- Replication: Modifying large amounts of data within a transaction can cause the creation of temporary files. Such files are created when the size of the data modified exceeds the size of the binary log cache (max_binlog_cache_size). Previously, such files persisted until the client connection was closed, which could allow them to grow until they exhausted all available disk space in tmpdir. To prevent this from occurring, the size of a temporary file created in this way in a given transaction is now reset to 0 when the transaction is committed or rolled back. (Bug #15909788, Bug #18021493, Bug #66237)
- Replication: The server checks to determine whether semisynchronous replication has been enabled without a lock, and if this is the case, it takes the lock and checks again. If semisynchronous replication was disabled after the first but prior to the second one, this could cause the server to fail. (Bug #14511533, Bug #66411)
- References: See also Bug #17920923.
- Replication: Semisynchronous replication became very slow if there were many dump threads (such as from mysqlbinlog or slave I/O connections) working at the same time. It was also found that semisynchronous master plugin functions were called even when the dump connections did not support semisynchronous replication, which led to locking of the plugin lock as well as wasting time on necessary code.
- After this fix, non-semisynchronous dump threads no longer call semisynchronous master functions to observe binary events. (Bug #70218, Bug #17434690)
- mysql_install_db could hang while reading /dev/random to generate a random root password. (Bug #18395378)
- Compilation failed if MySQL was configured with CFLAGS set to include a -Werror option with an argument. (Bug #18173037)
- A shared libmysqld embedded server library was not built on Linux. (Bug #18123048, Bug #16430656, Bug #68559)
- While printing the server version, the mysql client did not check for buffer overflow in a string variable. (Bug #18186103)
- Building MySQL from source on Windows using Visual Studio 2008 would fail with an identifier not found error due to a regression introduced by the patch for Bug#16249481. (Bug #18057449)
- On Microsoft Windows, the rw-lock backup implementation for the my_atomic_* functions was always used. Now, the native Microsoft Windows implementation is used, where available. (Bug #18054042)
- When tables are reopened from the table cache and the current thread is not instrumented for the Performance Schema, a table handle was unnecessarily instrumented. (Bug #18047865)
- The audit log plugin could cause a server exit during log file rotation operations when there were many operations happening for multiple connections. (Bug #17930339)
- The SUM_SORT_MERGE_PASSES column value in the Performance Schema events_statements_summary_by_digest table was calculated incorrectly. (Bug #17938255)
- If the Performance Schema events_statements_summary_by_digest table was full when a statement with a new digest was found, the Performance_schema_digest_lost status variable was not incremented. (Bug #17935314)
- The optimizer could push down a condition when the index did not have the key part present in the condition. (Bug #17814492)
- Contraction information in a collation could be mishandled, resulting in incorrect decisions about whether a character is part of a contraction, and miscalculation of contraction weights. (Bug #17760379)
- DROP TRIGGER succeeded even with the read_only system variable enabled. (Bug #17503460)
- If used to process a prepared CALL statement for a stored procedure with OUT or INOUT parameters, mysql_stmt_store_result() did not properly set the flags required to retrieve all the result sets. (Bug #14492429, Bug #17849978)
- When run by root, mysqld --help --verbose exited with a nonzero error code after displaying the help message. (Bug #70058, Bug #17324415)
- MySQL client programs from a Community Edition distribution could not connect using SSL to a MySQL server from an Enterprise Edition. This was due to a difference in certificate handling by yaSSL and OpenSSL (used for Community and Enterprise, respectively). OpenSSL expected a blank certificate to be sent when not all of the --ssl-ca, --ssl-cert, and --ssl-key options were specified, and yaSSL did not do so. To resolve this, yaSSL has been modified to send a blank certificate when an option is missing. (Bug #68788, Bug #16715064)
- The mysqladmin, mysqlbinlog, mysqlcheck, mysqldump, mysqlimport, mysqlslap, and mysqlshow programs now support a --secure-auth option that prevents sending passwords to the server in old (pre-4.1) format. This option is enabled by default; use --skip-secure-auth to disable it. (Bug #69051, Bug #16723046)
- A deadlock error occurring during subquery execution could cause an assertion to be raised. (Bug #69969, Bug #17307201)
- The Performance Schema stage/sql/Waiting to get readlock instrument is no longer used and has been removed. (Bug #71298, Bug #18035404)
- A query that creates a temporary table to find distinct values and has a constant value in the projected list could produce incorrect results. (Bug #70657, Bug #17634335)
- Messages written by the server to the error log for LDML collation definition problems were missing the collation name. (Bug #68144, Bug #16204175)
- mysqlcheck did not correctly handle table names containing dots. (Bug #68015, Bug #16064833)
- Aggregating the results of a subquery in the FROM clause could produce incorrect results. (Bug #71244, Bug #18014565)
- For system variables that take a string value, SET statements permitted an unquoted value, but values that contained dots were parsed incorrectly and only part of the value was assigned. For example, SET GLOBAL slow_query_log_file = my_slow.log assigned the value my_slow. Now such values must be quoted or an error occurs. (Bug #69703, Bug #17075846)
- A temporal literal string without delimiters and more than 14 digits was validated as a TIMESTAMP/DATETIME value with a two-digit precision fractional seconds part. But fractional seconds should always be separated from other parts of a time by a decimal point. (Bug #69714, Bug #17080703)
- The msql2mysql, mysql_convert_table_format, mysql_find_rows, mysql_fix_extensions, mysql_setpermission, and mysqlaccess utilities are now deprecated and will be removed in MySQL 5.7. (Bug #27482, Bug #69012, Bug #69014, Bug #69015, Bug #69016, Bug #69017, Bug #11746603, Bug #16699248, Bug #16699279, Bug #16699284, Bug #16699317, Bug #18179576)

更新時間：2014-03-28
更新細節：

What's new in this version:

Functionality Added or Changed:
- Incompatible Change - The AES_ENCRYPT() and AES_DECRYPT() functions now permit control of the block encryption mode and take an optional initialization vector argument.
- The new block_encryption_mode system variable controls the mode for block-based encryption algorithms. Its default value is aes-128-ecb, which signifies encryption using a key length of 128 bits and ECB mode.
- An optional init_vector argument provides an initialization vector for encryption modes that require it.
- AES_ENCRYPT(str,key_str[,init_vector])
- AES_DECRYPT(crypt_str,key_str[,init_vector])
- A random string of bytes to use for the initialization vector can be produced by calling the new RANDOM_BYTES() function.
- For more information, see Encryption and Compression Functions.
- These changes make statements that use AES_ENCRYPT() or AES_DECRYPT() unsafe for statement-based replication and they cannot be stored in the query cache. Queries that use RANDOM_BYTES() are unsafe for statement-based replication and cannot be stored in the query cache.
- Incompatible Change - The deprecated ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE SQL modes now do nothing. Instead, their previous effects are included in the effects of strict SQL mode (STRICT_ALL_TABLES or STRICT_TRANS_TABLES). In other words, strict mode now means the same thing as the previous meaning of strict mode plus the ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE modes. This change reduces the number of SQL modes with an effect dependent on strict mode and makes them part of strict mode itself.
- To prepare for the SQL mode changes in this version of MySQL, it is advisable before upgrading to read SQL Mode Changes in MySQL 5.7. That discussion provides guidelines to assess whether your applications will be affected by these changes.
- The deprecated ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE SQL modes are still recognized so that statements that name them do not produce an error, but will be removed in a future version of MySQL. To make advance preparation for versions of MySQL in which these modes do not exist, applications should be modified to not refer to those mode names. InnoDB - MySQL now supports rebuilding regular and partitioned InnoDB tables using online DDL (ALGORITHM=INPLACE) for the following operations:
- OPTIMIZE TABLE
- ALTER TABLE ... FORCE
- ALTER TABLE ... ENGINE=INNODB (when run on an InnoDB table)
- Online DDL support reduces table rebuild time and permits concurrent DML, which helps reduce user application downtime. For additional information, see Overview of Online DDL. (Bug #13975225)
- On Solaris, mysql_config --libs now includes -R/path/to/library so that libraries can be found at runtime. (Bug #18235669)
- mysql_install_db provides a more informative diagnostic message when required Perl modules are missing. (Bug #69844, Bug #18187451)
- The IGNORE clause for ALTER TABLE is now deprecated and will be removed in a future version of MySQL. ALTER IGNORE TABLE causes problems for replication, prevents online ALTER TABLE for unique index creation, and causes problems with foreign keys (rows removed in the parent table). Bugs Fixed:
- Incompatible Change: Old clients (older than MySQL 5.5.7) failed to parse authentication data correctly if the server was started with the --default-authentication-plugin=sha256_password option.
- Note - As a result of this bug fix, MySQL 5.6.16 clients cannot connect to a 5.6.17 server using an account that authenticates with the sha256_password plugin. Similarly, MySQL 5.7.3 clients cannot connect to a 5.7.4 server using an account that authenticates with the sha256_password plugin. (Bug #17495562)
- Important Change; InnoDB; Partitioning: The FLUSH TABLES statement's FOR EXPORT option is now supported for partitioned InnoDB tables. (Bug #16943907)
- InnoDB: Running a SELECT on a partitioned table caused a memory access violation in memcpy(). (Bug #18383840)
- InnoDB: An invalid memmove in fts_query_fetch_document would cause a serious error. (Bug #18229433)
- InnoDB: For full-text queries, a failure to check that num_token is less than max_proximity_item could result in an assertion. (Bug #18233051)
- InnoDB: innodb_ft_result_cache_limit now has a hardcoded maximum value of 4294967295 bytes or (2**32 -1). The maximum value was previously defined as the maximum value of ulong. (Bug #18180057, Bug #71554)
- InnoDB: InnoDB would fail to restore a corrupt first page of a system tablespace data file from the doublewrite buffer, resulting in a startup failure. (Bug #18144349, Bug #18058884)
- InnoDB: An UPDATE resulted in a memory access error in lock_rec_other_trx_holds_expl. The transaction list (trx_sys->rw_trx_list) was traversed without acquiring the transaction subsystem mutex (trx_sys->mutex). (Bug #18161853)
- InnoDB: A regression introduced by Bug #14329288 would result in a performance degradation when a compressed table does not fit into memory. (Bug #18124788, Bug #71436)
- InnoDB: The maximum value for innodb_thread_sleep_delay is now 1000000 microseconds. The previous maximum value (4294967295 microseconds on 32-bit and 18446744073709551615 microseconds on 64-bit) was unnecessarily large. Because the maximum value of innodb_thread_sleep_delay is limited by the value set for innodb_adaptive_max_sleep_delay (when set to a non-zero value), the maximum value for innodb_thread_sleep_delay is now the same as the maximum value for innodb_adaptive_max_sleep_delay. (Bug #18117322)
- InnoDB: A full-text tokenizer thread would terminate with an incorrect error message. (Bug #18021306)
- InnoDB: Attempting to uninstall the InnoDB memcached plugin while the InnoDB memcached plugin is still initializing would kill the InnoDB memcached daemon thread. Uninstall should wait until initialization is complete. (Bug #18038948)
- InnoDB: In debug builds, creating a unique index on a binary column, with input data containing duplicate keys, would cause an assertion. (Bug #18010711)
- InnoDB: The srv_monitor_thread would crash in the lock_print_info_summary() function due to a race condition between the srv_monitor_thread and purge coordinator thread. (Bug #17980590, Bug #70430)
- InnoDB: Attempting to add an invalid foreign key when foreign key checking is disabled (foreign_key_checks=0) would cause a serious error. (Bug #17666774)
- InnoDB: For debug builds, the table rebuilding variant of online ALTER TABLE, when run on tables with BLOB columns, would cause an assertion in the row_log_table_apply_update function. For normal builds, a DB_PRODUCTION error would be returned. (Bug #17661919)
- InnoDB: When creating a table there are a minimum of three separate inserts on the mysql.innodb_index_stats table. To improve CREATE TABLE performance, there is now a single COMMIT operation instead of one for each insert. (Bug #17323202, Bug #70063)
- InnoDB: The server would halt with an assertion in lock_rec_has_to_wait_in_queue(lock) due to a locking-related issue and a transaction being prematurely removed from trx_sys->rw_trx_set. (Bug #17320977)
- InnoDB: Server shutdown would result in a hang with the following message written to the error log: “[NOTE] InnoDB: Waiting for purge thread to be suspended.” (Bug #16495065)
- InnoDB: InnoDB would fail to start when innodb_data_file_path specified the data file size in kilobytes by appending K to the size value. (Bug #16287752)
- InnoDB: An insert buffer merge would cause an assertion error due to incorrectly handled ownership information for externally stored BLOBs.
- InnoDB: Assertion failure in thread thread_num in file ibuf0ibuf.cc line 4080
- InnoDB: Failing assertion: rec_get_deleted_flag(rec, page_is_comp(page)) Bug #14668683)
- InnoDB: Decreasing the auto_increment_increment value would have no affect on the next auto-increment value. (Bug #14049391, Bug #65225)
- Partitioning: When the index_merge_intersection flag (enabled by default) or the index_merge_union flag was enabled by the setting of the optimizer_switch system variable, queries returned incorrect results when executed against partitoned tables that used the MyISAM storage engine, as well as partitioned InnoDB tables that lacked a primary key. (Bug #18167648)
- References: See also Bug #16862316, Bug #17588348, Bug #17648468.
- Replication: The MASTER_SSL_CRL and MASTER_SSL_CRLPATH options are not available when using yaSSL; MySQL Replication now sets these to NULL automatically whenever yaSSL is enabled. (Bug #18165937)
- Replication: Setting --slave-parallel-workers to 1 or greater and starting the slave caused the slave SQL thread to use but not release memory until the slave was restarted with STOP SLAVE and START SLAVE. (Bug #18001777, Bug #71197)
- Replication: When a slave was configured with replication filters and --log-warnings=2, every statement which was filtered caused an entry to be written in the error log. For busy servers which generated many statements to be filtered, the result was that the error log could quickly grow to many gigabytes in size. Now a throttle is used for such errors, so that an error message is printed only once in a given interval, saying that this particular error occurred a specific number of times during that interval. (Bug #17986385)
- Replication: SHOW SLAVE STATUS used incorrect values when reporting MASTER_SSL_CRL and MASTER_SSL_CRLPATH. (Bug #17772911, Bug #70866)
- References: This bug was introduced by Bug #11747191.
- Replication - Binary log events could be sent to slaves before they were flushed to disk on the master, even when sync_binlog was set to 1. This could lead to either of those of the following two issues when the master was restarted following a crash of the operating system.
- Replication cannot continue because one or more slaves are requesting replicate events that do not exist on the master.
- Data exists on one or more slaves, but not on the master.
- Such problems are expected on less durable settings (sync_binlog not equal to 1), but it should not happen when sync_binlog is 1. To fix this issue, a lock (LOCK_log) is now held during synchronization, and is released only after the binary events are actually written to disk. (Bug #17632285, Bug #70669)
- Replication: When running the slave with --slave-parallel-workers at 1 or greater, setting --slave-skip-errors=all caused the error log to be filled with with instances of the warning Slave SQL: Could not execute Query event. Detailed error: ;, Error_code: 0. (Bug #17581990, Bug #68429)
- References: See also Bug #17986385.
- Replication: A number of possible state messages used as values for the PROCESSLIST_STATE column of the Performance Schema threads table were longer than the width of the column (64 characters).
- The long state messages are now silently truncated in order to avoid errors. This fix applies in MySQL 5.6 only; a permanent fix for the issue is made in MySQL 5.7 and later. (Bug #17319380)
- Replication: The server did not handle correctly the insertion of a row larger than 4 GB when using row-based replication. (Bug #17081415)
- Replication: When using row-based replication, an additional auto-increment column on the slave version of a table was not updated correctly; a zero was inserted instead. (Bug #17066269, Bug #69680)
- 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, or DELETE) or flush (TRUNCATE TABLE) performance schema tables on a single server without affecting others. However, when replicating from a MySQL 5.5 master to a MySQL 5.5 or later slave, warnings about unsafe statements updating Performance Schema tables were elevated to errors. For MySQL 5.6 and later slaves, this prevented the simultaneous use of performance_schema and GTIDs (see Replication with Global Transaction Identifiers).
- This fix causes all updates on tables in the performance_schema database to be filtered on the master and not replicated, regardless of the type of logging that is in effect. Prior to this fix, statements using 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_SCHEMA database is not changed by this fix.
- For more information, see MySQL Performance Schema. (Bug #16814264)
- References: See also Bug #14741537, Bug #18259193.
- Replication: Modifying large amounts of data within a transaction can cause the creation of temporary files. Such files are created when the size of the data modified exceeds the size of the binary log cache (max_binlog_cache_size). Previously, such files persisted until the client connection was closed, which could allow them to grow until they exhausted all available disk space in tmpdir. To prevent this from occurring, the size of a temporary file created in this way in a given transaction is now reset to 0 when the transaction is committed or rolled back. (Bug #15909788, Bug #18021493, Bug #66237)
- Replication: The server checks to determine whether semisynchronous replication has been enabled without a lock, and if this is the case, it takes the lock and checks again. If semisynchronous replication was disabled after the first but prior to the second one, this could cause the server to fail. (Bug #14511533, Bug #66411)
- References: See also Bug #17920923.
- Replication: Semisynchronous replication became very slow if there were many dump threads (such as from mysqlbinlog or slave I/O connections) working at the same time. It was also found that semisynchronous master plugin functions were called even when the dump connections did not support semisynchronous replication, which led to locking of the plugin lock as well as wasting time on necessary code.
- After this fix, non-semisynchronous dump threads no longer call semisynchronous master functions to observe binary events. (Bug #70218, Bug #17434690)
- mysql_install_db could hang while reading /dev/random to generate a random root password. (Bug #18395378)
- Compilation failed if MySQL was configured with CFLAGS set to include a -Werror option with an argument. (Bug #18173037)
- A shared libmysqld embedded server library was not built on Linux. (Bug #18123048, Bug #16430656, Bug #68559)
- While printing the server version, the mysql client did not check for buffer overflow in a string variable. (Bug #18186103)
- Building MySQL from source on Windows using Visual Studio 2008 would fail with an identifier not found error due to a regression introduced by the patch for Bug#16249481. (Bug #18057449)
- On Microsoft Windows, the rw-lock backup implementation for the my_atomic_* functions was always used. Now, the native Microsoft Windows implementation is used, where available. (Bug #18054042)
- When tables are reopened from the table cache and the current thread is not instrumented for the Performance Schema, a table handle was unnecessarily instrumented. (Bug #18047865)
- The audit log plugin could cause a server exit during log file rotation operations when there were many operations happening for multiple connections. (Bug #17930339)
- The SUM_SORT_MERGE_PASSES column value in the Performance Schema events_statements_summary_by_digest table was calculated incorrectly. (Bug #17938255)
- If the Performance Schema events_statements_summary_by_digest table was full when a statement with a new digest was found, the Performance_schema_digest_lost status variable was not incremented. (Bug #17935314)
- The optimizer could push down a condition when the index did not have the key part present in the condition. (Bug #17814492)
- Contraction information in a collation could be mishandled, resulting in incorrect decisions about whether a character is part of a contraction, and miscalculation of contraction weights. (Bug #17760379)
- DROP TRIGGER succeeded even with the read_only system variable enabled. (Bug #17503460)
- If used to process a prepared CALL statement for a stored procedure with OUT or INOUT parameters, mysql_stmt_store_result() did not properly set the flags required to retrieve all the result sets. (Bug #14492429, Bug #17849978)
- When run by root, mysqld --help --verbose exited with a nonzero error code after displaying the help message. (Bug #70058, Bug #17324415)
- MySQL client programs from a Community Edition distribution could not connect using SSL to a MySQL server from an Enterprise Edition. This was due to a difference in certificate handling by yaSSL and OpenSSL (used for Community and Enterprise, respectively). OpenSSL expected a blank certificate to be sent when not all of the --ssl-ca, --ssl-cert, and --ssl-key options were specified, and yaSSL did not do so. To resolve this, yaSSL has been modified to send a blank certificate when an option is missing. (Bug #68788, Bug #16715064)
- The mysqladmin, mysqlbinlog, mysqlcheck, mysqldump, mysqlimport, mysqlslap, and mysqlshow programs now support a --secure-auth option that prevents sending passwords to the server in old (pre-4.1) format. This option is enabled by default; use --skip-secure-auth to disable it. (Bug #69051, Bug #16723046)
- A deadlock error occurring during subquery execution could cause an assertion to be raised. (Bug #69969, Bug #17307201)
- The Performance Schema stage/sql/Waiting to get readlock instrument is no longer used and has been removed. (Bug #71298, Bug #18035404)
- A query that creates a temporary table to find distinct values and has a constant value in the projected list could produce incorrect results. (Bug #70657, Bug #17634335)
- Messages written by the server to the error log for LDML collation definition problems were missing the collation name. (Bug #68144, Bug #16204175)
- mysqlcheck did not correctly handle table names containing dots. (Bug #68015, Bug #16064833)
- Aggregating the results of a subquery in the FROM clause could produce incorrect results. (Bug #71244, Bug #18014565)
- For system variables that take a string value, SET statements permitted an unquoted value, but values that contained dots were parsed incorrectly and only part of the value was assigned. For example, SET GLOBAL slow_query_log_file = my_slow.log assigned the value my_slow. Now such values must be quoted or an error occurs. (Bug #69703, Bug #17075846)
- A temporal literal string without delimiters and more than 14 digits was validated as a TIMESTAMP/DATETIME value with a two-digit precision fractional seconds part. But fractional seconds should always be separated from other parts of a time by a decimal point. (Bug #69714, Bug #17080703)
- The msql2mysql, mysql_convert_table_format, mysql_find_rows, mysql_fix_extensions, mysql_setpermission, and mysqlaccess utilities are now deprecated and will be removed in MySQL 5.7. (Bug #27482, Bug #69012, Bug #69014, Bug #69015, Bug #69016, Bug #69017, Bug #11746603, Bug #16699248, Bug #16699279, Bug #16699284, Bug #16699317, Bug #18179576)

更新時間：2014-03-28
更新細節：

What's new in this version:

Functionality Added or Changed:
- On Solaris, mysql_config --libs now includes -R/path/to/library so that libraries can be found at runtime. Bugs Fixed:
- InnoDB: A regression introduced by Bug #14329288 would result in a performance degradation when a compressed table does not fit into memory.
- InnoDB: The maximum value for innodb_thread_sleep_delay is now 1000000 microseconds. The previous maximum value (4294967295 microseconds on 32-bit and 18446744073709551615 microseconds on 64-bit) was unnecessarily large. Because the maximum value of innodb_thread_sleep_delay is limited by the value set for innodb_adaptive_max_sleep_delay (when set to a non-zero value), the maximum value for innodb_thread_sleep_delay is now the same as the maximum value for innodb_adaptive_max_sleep_delay.
- InnoDB: In debug builds, creating a unique index on a binary column, with input data containing duplicate keys, would cause an assertion.
- InnoDB: InnoDB would fail to start when innodb_data_file_path specified the data file size in kilobytes by appending K to the size value.
- InnoDB: An insert buffer merge would cause an assertion error due to incorrectly handled ownership information for externally stored BLOBs.
- InnoDB: Assertion failure in thread thread_num in file ibuf0ibuf.cc line 4080
- InnoDB: Failing assertion: rec_get_deleted_flag(rec, page_is_comp(page))
- InnoDB: Decreasing the auto_increment_increment value would have no affect on the next auto-increment value.
- Replication: The server did not handle correctly the insertion of a row larger than 4 GB when using row-based replication.
- Replication: When using row-based replication, an additional auto-increment column on the slave version of a table was not updated correctly; a zero was inserted instead.
- 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, or DELETE) or flush (TRUNCATE TABLE) performance schema tables on a single server without affecting others. However, when replicating from a MySQL 5.5 master to a MySQL 5.5 or later slave, warnings about unsafe statements updating Performance Schema tables were elevated to errors. For MySQL 5.6 and later slaves, this prevented the simultaneous use of performance_schema and GTIDs (see Replication with Global Transaction Identifiers, in the MySQL 5.6 Manual).
- Compilation failed if MySQL was configured with CFLAGS set to include a -Werror option with an argument.
- A shared libmysqld embedded server library was not built on Linux.
- While printing the server version, the mysql client did not check for buffer overflow in a string variable.
- Contraction information in a collation could be mishandled, resulting in incorrect decisions about whether a character is part of a contraction, and miscalculation of contraction weights.
- DROP TRIGGER succeeded even with the read_only system variable enabled.
- Updating the Performance Schema setup_instruments table on a replication master caused a slave to exit.
- Due to a race condition, it was possible for two threads to end up with the same query ID for different queries.
- When run by root, mysqld --help --verbose exited with a nonzero error code after displaying the help message.
- MySQL client programs from a Community Edition distribution could not connect using SSL to a MySQL server from an Enterprise Edition. This was due to a difference in certificate handling by yaSSL and OpenSSL (used for Community and Enterprise, respectively). OpenSSL expected a blank certificate to be sent when not all of the --ssl-ca, --ssl-cert, and --ssl-key options were specified, and yaSSL did not do so. To resolve this, yaSSL has been modified to send a blank certificate when an option is missing.
- A deadlock error occurring during subquery execution could cause an assertion to be raised.
- The Performance Schema stage/sql/Waiting to get readlock instrument is no longer used and has been removed.
- For system variables that take a string value, SET statements permitted an unquoted value, but values that contained dots were parsed incorrectly and only part of the value was assigned. For example, SET GLOBAL slow_query_log_file = my_slow.log assigned the value my_slow. Now such values must be quoted or an error occurs.