"doc" did not exist on "mysql-5.7.13"
-
Alfranio Correia authored
BUG#11763471 BUG#56184 Rolled back transaction without non-transactional table updated was binlogged BUG#11763126 BUG#55798 Slave SQL retry on transaction inserts extra data into non-transaction table BUG#56184 --------- The transaction modified non-transactional table will be binlogged with ROLLBACK if it rolls back on master. It includes the case that all statements which modified non-transactional table are binlogged outside the transaction. Example: BEGIN INSERT INTO trans-table; INSERT INTO non-trans-table; ROLLBACK This will be binlogged as: BEGIN INSERT INTO non-trans-table; COMMIT BEGIN INSERT INTO trans-table; ROLLBACK; All statements in the second binlogged transaction modify only transactional tables and are rolled back safely on master. So the second transaction should not be binlogged. After 5.5, there are two caches for binary logs, a transactional cache and a statement cache. When executing a transaction, statements that modified only transactional tables are always put in transactional cache. Statements that modified non-transactional tables can be put in either transactional or non-transactional cache depending on different situations. In this patch, a flag is added to mark if there is any statement that modified non-transactional table in transactional cache. When rolling back a transaction on master, transactional cache should not be flushed to binary log, if there is no statement in it that modified a non-transactional table. Otherwise, it should be flushed into binary log followed by 'ROLLBACK' statement. BUG#55798 --------- When a temporary error(eg. Lock timeout) happens, Slave SQL thread will rollback the transaction and retry it again. But it is possible that the transaction cannot be rolled back safely. For example a non-transactional table has been modified by the transaction. It will make master and slave diverge. After this patch, SQL thread will not retry to execute a transaction which cannot be rolled back safely if temporary error is encountered. ADDITIONAL CHANGES ------------------ Some refactoring related to THD_TRANS::modified_non_trans_table and binlog_cache_data was also done.
Alfranio Correia authoredBUG#11763471 BUG#56184 Rolled back transaction without non-transactional table updated was binlogged BUG#11763126 BUG#55798 Slave SQL retry on transaction inserts extra data into non-transaction table BUG#56184 --------- The transaction modified non-transactional table will be binlogged with ROLLBACK if it rolls back on master. It includes the case that all statements which modified non-transactional table are binlogged outside the transaction. Example: BEGIN INSERT INTO trans-table; INSERT INTO non-trans-table; ROLLBACK This will be binlogged as: BEGIN INSERT INTO non-trans-table; COMMIT BEGIN INSERT INTO trans-table; ROLLBACK; All statements in the second binlogged transaction modify only transactional tables and are rolled back safely on master. So the second transaction should not be binlogged. After 5.5, there are two caches for binary logs, a transactional cache and a statement cache. When executing a transaction, statements that modified only transactional tables are always put in transactional cache. Statements that modified non-transactional tables can be put in either transactional or non-transactional cache depending on different situations. In this patch, a flag is added to mark if there is any statement that modified non-transactional table in transactional cache. When rolling back a transaction on master, transactional cache should not be flushed to binary log, if there is no statement in it that modified a non-transactional table. Otherwise, it should be flushed into binary log followed by 'ROLLBACK' statement. BUG#55798 --------- When a temporary error(eg. Lock timeout) happens, Slave SQL thread will rollback the transaction and retry it again. But it is possible that the transaction cannot be rolled back safely. For example a non-transactional table has been modified by the transaction. It will make master and slave diverge. After this patch, SQL thread will not retry to execute a transaction which cannot be rolled back safely if temporary error is encountered. ADDITIONAL CHANGES ------------------ Some refactoring related to THD_TRANS::modified_non_trans_table and binlog_cache_data was also done.
Loading