There is an inconsistency with DROP DATABASE IF EXISTS, DROP
TABLE IF EXISTS and DROP VIEW IF EXISTS: those are binlogged even
if the DB or TABLE does not exist, whereas DROP PROCEDURE IF
EXISTS does not. It would be nice or at least consistent if DROP
PROCEDURE/STATEMENT worked the same too.
Fixed DROP PROCEDURE|FUNCTION IF EXISTS by adding a call to
write_bin_log in mysql_execute_command. Checked also if all
documented "DROP (...) IF EXISTS" get binlogged. Left out DROP
SERVER IF EXISTS because it seems that it only gets binlogged when
using row event (see BUG#25705).
TRUNCATE TABLE fails to replicate when stmt-based binlogging is not supported.
There were two separate problems with the code, both of which are fixed with
this patch:
1. An error was printed by InnoDB for TRUNCATE TABLE in statement mode when
the in isolation levels READ COMMITTED and READ UNCOMMITTED since InnoDB
does permit statement-based replication for DML statements. However,
the TRUNCATE TABLE is not transactional, but is a DDL, and should therefore
be allowed to be replicated as a statement.
2. The statement was not logged in mixed mode because of the error above, but
the error was not reported to the client.
This patch fixes the problem by treating TRUNCATE TABLE a DDL, that is, it is
always logged as a statement and not reporting an error from InnoDB for TRUNCATE
TABLE.
Documented behaviour was broken by the patch for bug 33699
that actually is not a bug.
This fix reverts patch for bug 33699 and reverts the
UPDATE of NOT NULL field with NULL query to old
behavior.
Remove size of binlog file from SHOW BINARY LOGS.
Changing size of binlog file is an affect of adding or removing events to/from
binlog and it can be checked in next command of test: SHOW BINLOG EVENTS.
For SHOW BINARY LOGS statement enough to show the list of file names.
Fixing pb failures caused by mtr invokes the test with --tmpdir to which
there are sensitive operations in the test
and setup_fake_relay_log.inc also needed --secure-file-priv for its own separate
directory.
Fixed with removing SELECT INTO OUTFILE and deploying --exec echo instead in the marco.
The test's opt file should contain --secure-file-priv=$MYSQL_TEST_DIR as the test
operations deal with files located in $MYSQL_TEST_DIR.
The test fails with timeout when applying diff on two tables.
In this test case, there can be a situation when the slave is not yet synced
with the master, thence the changes may not be on the slave at diff time.
This patch addresses this issue by synchronizing master and slave before the
diff takes place.
Overriding a default value of --secure-file-priv on pb.mtr to be $MYSQLTEST_VARDIR which
makes pb's mtr happy to execute the regression test for the bug.
conflicts:
Text conflict in client/mysqltest.cc
Text conflict in mysql-test/include/wait_until_connected_again.inc
Text conflict in mysql-test/lib/mtr_report.pm
Text conflict in mysql-test/mysql-test-run.pl
Text conflict in mysql-test/r/events_bugs.result
Text conflict in mysql-test/r/log_state.result
Text conflict in mysql-test/r/myisam_data_pointer_size_func.result
Text conflict in mysql-test/r/mysqlcheck.result
Text conflict in mysql-test/r/query_cache.result
Text conflict in mysql-test/r/status.result
Text conflict in mysql-test/suite/binlog/r/binlog_index.result
Text conflict in mysql-test/suite/binlog/r/binlog_innodb.result
Text conflict in mysql-test/suite/rpl/r/rpl_packet.result
Text conflict in mysql-test/suite/rpl/t/rpl_packet.test
Text conflict in mysql-test/t/disabled.def
Text conflict in mysql-test/t/events_bugs.test
Text conflict in mysql-test/t/log_state.test
Text conflict in mysql-test/t/myisam_data_pointer_size_func.test
Text conflict in mysql-test/t/mysqlcheck.test
Text conflict in mysql-test/t/query_cache.test
Text conflict in mysql-test/t/rpl_init_slave_func.test
Text conflict in mysql-test/t/status.test
It's a regression issue.
The reason of the bug appeared to be an error introduced into 5.1 source code.
A piece of code in Create_file_log_event::do_apply_event() did not have test
coverage which made make test and pb unaware.
Fixed with inverting the old value of the return value from
Create_file_log_event::do_apply_event().
The rpl test suite is extended with `rpl_cross_version' the file to hold
regression cases similar to the current.
clause server fires immediately after creating event and time between create and delete
event sometimes is enough for firing. So adding STARTS clause moves first execution in
future after drop of event
1. Added STARTS clause for CREATE EVENT.
2. Updated result file.
The next number (AUTO_INCREMENT) field of the table for write
rows events are not initialized, and cause some engines (innodb)
not correctly update the tables's auto_increment value.
This patch fixed this problem by honor next number fields if present.
Problem 1: The test waits for an error in the slave sql thread,
then resolves the error and issues 'start slave'. However, there
is a gap between when the error is reported and the slave sql
thread stops. If this gap was long, the slave would still be
running when 'start slave' happened, so 'start slave' would fail
and cause a test failure.
Fix 1: Made wait_for_slave_sql_error wait for the slave to stop
instead of wait for error in the IO thread. After stopping, the
error code is verified. If the error code is wrong, debug info
is printed. To print debug info, the debug printing code in
wait_for_slave_param.inc was moved out to a new file,
show_rpl_debug_info.inc.
Problem 2: rpl_stm_mystery22 is a horrible name, the comments in
the file didn't explain anything useful, the test was generally
hard to follow, and the test was essentially duplicated between
rpl_stm_mystery22 and rpl_row_mystery22.
Fix 2: The test is about conflicts in the slave SQL thread,
hence I renamed the tests to rpl_{stm,row}_conflicts. Refactored
the test so that the work is done in
extra/rpl_tests/rpl_conflicts.inc, and
rpl.rpl_{row,stm}_conflicts merely sets some variables and then
sourced extra/rpl_tests/rpl_conflicts.inc.
The tests have been rewritten and comments added.
Problem 3: When calling wait_for_slave_sql_error.inc, you always
want to verify that the sql thread stops because of the expected
error and not because of some other error. Currently,
wait_for_slave_sql_error.inc allows the caller to omit the error
code, in which case all error codes are accepted.
Fix 3: Made wait_for_slave_sql_error.inc fail if no error code
is given. Updated rpl_filter_tables_not_exist accordingly.
Problem 4: rpl_filter_tables_not_exist had a typo, the dollar
sign was missing in a 'let' statement.
Fix 4: Added dollar sign.
Problem 5: When replicating from other servers than the one named
'master', the wait_for_slave_* macros were unable to print debug
info on the master.
Fix 5: Replace parameter $slave_keep_connection by
$master_connection.
Problem: When an Incident_log_event contains a bad incident number on disk,
the server crashes with an assertion.
Fix: Don't validate input with assertions. Use errors.
Bug#38540 rpl_server_id2 uses show slave status unnecessarily
Slave did not perform any event recorded into the relay log from some
different master when it was started with --replicate-same-server-id.
The reason appeared to be a consequence of BUG#38734 which stopped the
sql thread at its startup time.
The real fixes for the current bug are in the patch for BUG#38734.
This changeset carries only a regression test for the bugs. Bug#38540
gets fixed too by means of eliminating an extra show slave status.
exact number of error. The patch does following:
1) Add new parameter $slave_sql_errno for wait_for_slave_sql_error.inc
2) Add waiting error 1062 (Duplicate PK) for slave SQL thread in test case.
where timeout can happen:
1. Added waiting start/stop slave to make sure that slave works properly.
2. Added cleanup for slave.
3. Updated related result files.
after rollback on master
When starting a transaction with a statement containing changes
to both transactional tables and non-transactional tables, the
statement is considered as non-transactional and is therefore
written directly to the binary log. This behaviour was present
in 5.0, and has propagated to 5.1.
If a trigger containing a change of a non-transactional table is
added to a transactional table, any changes to the transactional
table is "tainted" as non-transactional.
This patch solves the problem by removing the existing "hack" that
allows non-transactional statements appearing first in a transaction
to be written directly to the binary log. Instead, anything inside
a transaction is treaded as part of the transaction and not written
to the binary log until the transaction is committed.
If before running test rpl_mulit_engin, the mysqltest1 database exists
on master but not exists on slave, then the following statement:
create database if not exists mysqltest1;
would not be logged to binary log, and so the database would not be
created on slave. This would cause the test to fail and reporting
mysqltest1 database not existed on slave.
This patch fixed this problem by not using a different database for
the whole test, just use the default test database, there is no reason
why a seperate database is used for this test.
Problem: Many test cases don't clean up after themselves (fail
to drop tables or fail to reset variables). This implies that:
(1) check-testcase in the new mtr that currently lives in
5.1-rpl failed. (2) it may cause unexpected results in
subsequent tests.
Fix: make all tests clean up.
Also: cleaned away unnecessary output in rpl_packet.result
Also: fixed bug where rpl_log called RESET MASTER with a running
slave. This is not supposed to work.
Also: removed unnecessary code from rpl_stm_EE_err2 and made it
verify that an error occurred.
Also: removed unnecessary code from rpl_ndb_ctype_ucs2_def.
Problem 1: BUG#36625: rpl_redirect doesn't do anything useful. It tests an
obsolete feature that was never fully implemented.
Fix 1: Remove rpl_redirect.
Problem 2: rpl_innodb_bug28430 and rpl_flushlog_loop are disabled despite the
bugs for which they were disabled have been fixed.
Fix 2: Re-enable rpl_innodb_bug28430 and rpl_flushlog_loop.
The partitioning clause is only a very long single line, which is very
hard to interpret for a human. This patch breaks the partitioning
syntax into one line for the partitioning type, and one line per
partition/subpartition.
