Fix for BUG#20649 "mixed replication mode does not work with INSERT DELAYED".
The bug was that if the server was running in mixed binlogging mode, and an INSERT DELAYED used some needing-row-based components like UUID(), the server didn't binlog this row-based but statement-based, which thus failed to insert correct data on the slave. This changeset implements that when a delayed_insert thread is created, if the server's global binlog mode is "mixed", that thread will use row-based. This also fixes BUG#20633 "INSERT DELAYED RAND() or @user_var does not replicate statement-based": we don't fix it in statement-based mode (would require bookeeping of rand seeds and user variables used by each row), but at least it will now work in mixed mode (as row-based will be used). We re-enable rpl_switch_stm_row_mixed.test (so BUG#18590 which was about re-enabling this test, will be closed) to test the fixes. Between when it was disabled and now, some good changes to row-based binlogging (no generation of table map events for non-changed tables) induce changes in the test's result file. mysql-test/r/rpl_switch_stm_row_mixed.result: result update. Note that some pieces of binlog are gone, not due to my test but to changes to the row-based binlogging code (non-changed tables don't generate table map binlog events now) done while the test was disabled. mysql-test/t/disabled.def: this test works now mysql-test/t/rpl_switch_stm_row_mixed.test: testing fix to make INSERT DELAYED work in mixed mode sql/sql_insert.cc: In mixed binlogging mode, the delayed_insert system thread now always uses row-based binlogging. This makes replication of INSERT DELAYED VALUES(RAND()) or VALUES(@A) work in mixed mode (it does not in statement-based).
Showing
Please register or sign in to comment