Problem: in mixed and statement mode, a query that refers to a
system variable will use the slave's value when replayed on
slave. So if the value of a system variable is inserted into a
table, the slave will differ from the master.
Fix: mark statements that refer to a system variable as "unsafe",
meaning they will be replicated by row in mixed mode and produce a warning
in statement mode. There are some exceptions: some variables are actually
replicated. Those should *not* be marked as unsafe.
BUG#34732: mysqlbinlog does not print default values for auto_increment variables
Problem: mysqlbinlog does not print default values for some variables,
including auto_increment_increment and others. So if a client executing
the output of mysqlbinlog has different default values, replication will
be wrong.
Fix: Always print default values for all variables that are replicated.
I need to fix the two bugs at the same time, because the test cases would
fail if I only fixed one of them.
Non-determinism in the tests was due to results of SBR are different from those gained
with row binlog format.
Because tests effectively verify skipping only ER_DUP_ENTRY it is explicitly required
to run the test on in mixed and stmt binlog format.
ER_DUP_ENTRY is automatically ignored when happened in RBR because of implicit rule
favoring reentrant reading from binlog rule
which means that a Write_rows_log_event overwrites a slave's row
if the one has the same primary key.
If future we might have skipping error due to applying of row-based events.
The comments added saying a new file would be needed for that: rpl_row_skip_error or smth.
