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.
replication):
Incremental patch to enable idempotency support for update events again.
The final handling of errors will be done in BUG#31609, and until then
the handling of errors should be consistent between the different types
of changes.
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.
If a temporary error occured inside a group on an event that was not the first
event of the group, the slave could get stuck because the retry counter is reset
whenever an event was executed successfully.
This patch only reset the retry counter when an entire group has been successfully
executed, or failed with a non-transient error.
When replicating an update pair (before image, after image) under row-based
replication, and the before image is not found on the slave, the after image
was not discared, and was hence read as a before image for the next row.
Eventually, this lead to an after image being read outside the block of rows
in the event, causing an assertion to fire.
This patch fixes this by reading the after image in the event that the row
was not found on the slave, adds some extra debug assertion to catch future
errors earlier, and also adds a few non-debug checks to prevent reading
outside the block of the event.
is possible):
When skipping the beginning of a transaction starting with BEGIN, the OPTION_BEGIN
flag was not set correctly, which caused the slave to not recognize that it was
inside a group. This patch sets the OPTION_BEGIN flag for BEGIN, COMMIT, ROLLBACK,
and XID events. It also adds checks if inside a group before decreasing the
slave skip counter to zero.
Begin_query_log_event was not marked that it could not end a group, which is now
corrected.
Refactoring code to add parameter to pack() and unpack() functions with
purpose of indicating if data should be packed in little-endian or
native order. Using new functions to always pack data for binary log
in little-endian order. The purpose of this refactoring is to allow
proper implementation of endian-agnostic pack() and unpack() functions.
Eliminating several versions of virtual pack() and unpack() functions
in favor for one single virtual function which is overridden in
subclasses.
Implementing pack() and unpack() functions for some field types that
packed data in native format regardless of the value of the
st_table_share::db_low_byte_first flag.
The field types that were packed in native format regardless are:
Field_real, Field_decimal, Field_tiny, Field_short, Field_medium,
Field_long, Field_longlong, and Field_blob.
Before the patch, row-based logging wrote the rows incorrectly on
big-endian machines where the storage engine defined its own
low_byte_first() to be FALSE on big-endian machines (the default
is TRUE), while little-endian machines wrote the fields in correct
order. The only known storage engine that does this is NDB. In effect,
this means that row-based replication from or to a big-endian
machine where the table was using NDB as storage engine failed if the
other engine was either non-NDB or on a little-endian machine.
With this patch, row-based logging is now always done in little-endian
order, while ORDER BY uses the native order if the storage engine
defines low_byte_first() to return FALSE for big-endian machines.
In addition, the max_data_length() function available in Field_blob
was generalized to the entire Field hierarchy to give the maximum
number of bytes that Field::pack() will write.
"Rows not deleted from innodb partitioned tables if --innodb_autoinc_lock_mode=0"
Due to a previous bugfix which initializes a previously uninitialized
variable, ha_partition::get_auto_increment() may fail to operate
correctly when the storage engine reports that it is only reserving
one value and one or more partitions have a different 'next-value'.
Currently, only affects Innodb's new-style auto-increment code which
reserves larger blocks of values and has less inter-thread contention.
"Regression: "--innodb_autoinc_lock_mode=0" (off) not same as older releases"
Bug#28430
"Failure in replication of innodb partitioned tables on row/mixed format"
Bug#30888
"Innodb table + stored procedure + row deletion = server crash"
Apply Oracle patch from Sunny
Include tests cases by Omer
Ensure that innobase_read_and_init_auto performs table autoinc lock when lock_mode = 0
No need for "if" guard around row_unlock_table_autoinc_for_mysql() because
it already performs same check.
Make autoinc_lock_mode variable read-only for duration of running mysqld process.
of statement breaks binlog.
There were two problems discovered by this bug:
1. Default (current) database is not fixed at the creation time.
That leads to wrong output of DATABASE() function.
2. Database attributes (@@collation_database) are not fixed at
the creation time. That leads to wrong resultset.
Binlog breakage and Query Cache wrong output happened because of
the first problem.
The fix is to remember the current database at the PREPARE-time and
set it each time at EXECUTE.
