MySQL 5.7 Release Notes - Download - MySQL

MySQL 5.7 Release Notesplayed again on the promoted master's slaves, leading quickly to inconsistencies on those slaves.(Bug #17813449)References: See also Bug #17827018.• Replication: When the master and the slave both had gtid_mode=ON set initially, and the slaveSQL thread was stopped while there remained GTID transactions in the relay log, if the slavewas then restarted with gtid_mode=OFF, then the slave SQL thread executed any anonymoustransaction it encountered without writing its GTID to the binary log, with the result that the GTID waslost. This could cause problems when the slave was later promoted to a master, as the transactionwould be played again on the promoted master's slaves, leading quickly to inconsistencies on thoseslaves. (Bug #17827018)References: See also Bug #17813449.• Replication: When the binary log I/O cache grew to exactly 32768 bytes and the current transactionwas preceded by a transaction whose size was greater than 32768 bytes, events could be corruptedwhen written into the binary log. (Bug #17842137)• Replication: Creating and dropping large numbers of temporary tables could lead to increasedmemory consumption. (Bug #17806014)• Replication: SHOW SLAVE STATUS used incorrect values when reporting MASTER_SSL_CRL andMASTER_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 themaster, even when sync_binlog was set to 1. This could lead to either of those of the followingtwo 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 donot 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 shouldnot happen when sync_binlog is 1. To fix this issue, a lock (LOCK_log) is now held duringsynchronization, and is released only after the binary events are actually written to disk. (Bug#17632285, Bug #70669)• Replication: mysqlbinlog --verbose failed when it encountered a corrupt row event in thebinary log. Such a row event could also cause the slave to fail. (Bug #17632978)References: See also Bug #16960133.• Replication: When log_warnings is greater than 1, the master prints binary log dump threadinformation—containing the slave server ID, binary log file name, and binary log position—inmysqld.1.err. A slave server ID greater than 2 billion was printed with a negative value in suchcases. (Bug #17641586, Bug #70685)• 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 instances of the warning SlaveSQL: Could not execute Query event. Detailed error: ;, Error_code: 0. (Bug#17581990, Bug #68429)References: See also Bug #17986385.• Replication: When semi-synchronous replication was configured on an independent server withno slaves and rpl_semi_sync_master_wait_no_slave was set to OFF, the master still waitedfor an ACK from the slave. When rpl_semi_sync_master_wait_no_slave is set to OFF,the master should revert to normal replication when the number of slaves reaches zero during29