Now, every transaction (including autocommit transactions) starts with
a BEGIN and ends with a COMMIT/ROLLBACK in the binlog.
Added a test case, and updated lots of test case result files.
without PK
Bug#31609 Not all RBR slave errors reported as errors
bug#32468 delete rows event on a table with foreign key constraint fails
The first two bugs comprise idempotency issues.
First, there was no error code reported under conditions of the bug
description although the slave sql thread halted.
Second, executions were different with and without presence of prim key in
the table.
Third, there was no way to instruct the slave whether to ignore an error
and skip to the following event or to halt.
Fourth, there are handler errors which might happen due to idempotent
applying of binlog but those were not listed among the "idempotent" error
list.
All the named issues are addressed.
Wrt to the 3rd, there is the new global system variable, changeble at run
time, which controls the slave sql thread behaviour.
The new variable allows further extensions to mimic the sql_mode
session/global variable.
To address the 4th, the new bug#32468 had to be fixed as it was staying
in the way.
When executing drop view statement on the master, the statement is not written into bin-log if any error occurs, this could cause master slave inconsistence if any view has been dropped.
If some error occured and no view has been dropped, don't bin-log the statement, if at least one view has been dropped the query is bin-logged possible with an error.
- Reorganize collect a little to make it easier to apply optimizations
and settings to collected test cases.
- Add suite/rpl/combination file
- Rename include/set_binlog_format_x.inc to .sql since thay are run by "mysql"
Non-deterministic parameters of SHOW SLAVE STATUS are masked out
by means of using the standard include-macro.
The masked-out parameters are not needed by the logics of the original
tests. What is need to demonstre that replication is not stopped remains.
In BUG#30244 added FOUND_ROWS() as an unsafe function, but that
works only in mixed mode under 5.1. There is a workaround that
can be used in statement-based mode either under 5.0 or 5.1
where the result of FOUND_ROWS() is stored into a user vari-
able and used that way instead. This will replicate correctly
even under statement-based replication, since it will write
a User_var entry to the binary log. For some other cases, the
value has to be passed explicitly.
This patch adds tests to demonstrate that the workarounds docu-
mented for statement-based replication works as advertised, and
does more extensive tests for cases that does not work under sta-
tement-based replication actually work under mixed mode by switch-
ing to row-based replication.
Actually, the failure happened with 3innodb as well. Most probably
the reason is in failing to delete a binlog file on __NT__ so that
that master increments the index of the binlog file.
The test results hide valueable warning that windows could generate
about that.
The scope of this fix is to make sure we have such warning and
to lessen chances for binlog file being held at time of closing.
The dump thread is getting a good chance to leave and
release the file for its successful deletion.
We shall watch over the two tests as regression is not excluded.
In that case we would have an extra info possibly explaining why
__NT__ env can not close/delete the file.
However, regardless of that reason, there is alwasy workaround to mask out
non-deterministic binlog index number.
Marking statements containing USER() or CURRENT_USER() as unsafe, causing
them to switch to using row-based logging in MIXED mode and generate a
warning in STATEMENT mode.
The rpl_trigger test case indicated a problem with idempotency support when run
under row-based replication, which this patch fixes.
However, despite this, the test is not designed for execution under row-based
replication and hence rpl_trigger.test is not executed under row-based
replication.
The problem is that the test expects triggers to be executed when the slave
updates rows on the slave, and this is (deliberately) not done with row-based
replication.
