Important Change; Replication: The SHOW BINARY LOGS statement (and its equivalent SHOW MASTER LOGS) may now be executed by a user with the REPLICATION CLIENT privilege. (Formerly, the SUPER privilege was necessary to use either form of this statement.)

InnoDB: If a row was deleted from an InnoDB table, then another row was re-inserted with the same primary key value, an attempt by a concurrent transaction to lock the row could succeed when it should have waited. This issue occurred if the locking select used a WHERE clause that performed an index scan using a secondary index. (Bug #14100254, Bug #65389)

InnoDB: In a transaction using the REPEATABLE READ isolation level, an UPDATE or DELETE statement for an InnoDB table could sometimes overlook rows recently committed by other transactions. As explained in Consistent Nonlocking Reads, DML statements within a REPEATABLE READ transaction apply to rows committed by other transactions, even if a query could not see those rows. (Bug #14007649, Bug #65111)

InnoDB: Performing an ALTER TABLE operation on an InnoDB could cause the server to halt with an error, if the tablespace for that table was already removed by an ALTER TABLE ... DISCARD TABLESPACE statement. (Bug #13943231)

InnoDB: Using the KILL statement to terminate a query could cause an unnecessary message in the error log:

[ERROR] Got error -1 when reading table table_name

(Bug #13933132)

InnoDB: For an InnoDB table with a trigger, under the setting innodb_autoinc_lock_mode=1, sometimes auto-increment values could be interleaved when inserting into the table from two sessions concurrently. The sequence of auto-increment values could vary depending on timing, leading to data inconsistency in systems using replication. (Bug #12752572, Bug #61579)

InnoDB: The CHECK TABLE statement could fail for a large InnoDB table due to a timeout value of 2 hours. For typical storage devices, the issue could occur for tables that exceeded approximately 200 or 350 GB, depending on I/O speed. The fix relaxes the locking performed on the table being checked, which makes the timeout less likely. It also makes InnoDB recognize the syntax CHECK TABLE QUICK, which avoids the possibility of the timeout entirely. (Bug #11758510, Bug #50723)

Replication: It was theoretically possible for concurrent execution of more than one instance of SHOW BINLOG EVENTS to crash the MySQL Server. (Bug #13979418)

Replication: An event whose length exceeded the size of the master dump thread's max_allowed_packet caused replication to fail. This could occur when updating many large rows and using row-based replication.

As part of this fix, a new server option --slave-max-allowed-packet is added, which permits max_allowed_packet to be exceeded by the slave SQL and I/O threads. Now the size of a packet transmitted from the master to the slave is checked only against this value (available as the value of the slave_max_allowed_packet server system variable), and not against the value of max_allowed_packet. (Bug #12400221, Bug #60926)

Replication: Statements using AUTO_INCREMENT, LAST_INSERT_ID(), RAND(), or user variables could be applied in the wrong context on the slave when using statement-based replication and replication filtering server options (see How Servers Evaluate Replication Filtering Rules). (Bug #11761686, Bug #54201)

References: See also Bug #11754117, Bug #45670, Bug #11746146, Bug #23894.

Replication: An INSERT into a table that has a composite primary key that includes an AUTO_INCREMENT column that is not the first column of this composite key is not safe for statement-based binary logging or replication. Such statements are now marked as unsafe and fail with an error when using the STATEMENT binary logging format. For more information, see Determination of Safe and Unsafe Statements in Binary Logging, as well as Replication and AUTO_INCREMENT.

(Bug #11754117, Bug #45670)

References: See also Bug #11761686, Bug #54201, Bug #11746146, Bug #23894.

Replication: After upgrading a replication slave to MySQL 5.5.60 or later, enabling the query cache eventually caused the slave to fail. (Bug #64624, Bug #14005409)

When the index enforcing a foreign key constraint was dropped while foreign_key_checks=0, further operations involving the foreign key column could cause a serious error after the foreign_key_checks option was re-enabled. (Bug #14025221)

Incorrect stored program caching could cause statements within a stored program that included a GROUP BY clause to return different results across multiple program invocations. (Bug #13805127)

For queries with ORDER BY COUNT(*) and LIMIT, the optimizer could choose an execution plan that produced incorrect results. (Bug #12713907)

SHOW TABLES was very slow unless the required information was already in the disk cache. (Bug #60961, Bug #12427262)

mysqlbinlog exited with no error code if file write errors occurred. (Bug #55289, Bug #11762667)

yaSSL rejected valid SSL certificates that OpenSSL accepts. (Bug #54348, Bug #11761822)

Sessions could end up deadlocked when executing a combination of SELECT, DROP TABLE, KILL, and SHOW ENGINE INNODB STATUS. (Bug #60682, Bug #12636001)

When dumping the mysql database, mysqldump did not include the general_log and slow_query_log tables because they cannot be locked. This caused a problem after reloading the dump file if that file contained a DROP DATABASE statement for the mysql database: The database no longer contained the log tables and attempts to log to them failed. Now mysqldump includes statements to re-create the general_log and slow_query_log tables so that they exist after loading the dump file. Log table contents still are not dumped. (Bug #45740, Bug #11754178)