Bug #40221 Replication failure on RBR + UPDATE the primary key
A transaction could result in having an extra event after a query that errored e.g because of a dup key. Such a query is rolled back in innodb, as specified, but has not been in binlog. It appeares that the binlog engine did not always register for a query (statement) because the previous query had not reset at its statement commit time. Because of that fact there was no roll-back to the trx_data->before_stmt_pos position and a the pending event of the errorred query could become flushed to the binlog file. Fixed with deploying the reset of trx_data->before_stmt_pos at the end of the query processing. mysql-test/suite/binlog/r/binlog_innodb_row.result: a new test file to contain tests dealing with binlogging innodb with the row-based format. mysql-test/suite/binlog/t/binlog_innodb_row.test: a new test file to contain tests dealing with binlogging innodb with the row-based format. sql/log.cc: Flushing the pending row event at binlog_end_trans() is moved down to the commit branch. Resetting of trx_data->before_stmt_pos to the uninitialized value at the end of the statement is implemented in binlog_commit() and binlog_rollback(). Asserting emptiness the transaction cache after reset() and the uninitilized value for the statement's savepoint binlog position.
Showing
Please register or sign in to comment