mirror of
https://github.com/MariaDB/server.git
synced 2025-01-17 20:42:30 +01:00
930e542f44
The following is an excerption from the WL.
1. Change so that MIXED is default format
1.1 to change the default for command line --binlog-format
1.2 to alter global_system_variables.binlog_format calculation
basing on command line --binlog-format parameter and
its default.
2. Change test suite so that more testing is done by MIXED format.
2.1 to check if there are test cases requiring --binlog-foramt=statement via
`source include/have_binlog_format_statement.inc' and affected by
altering the latter to be "mixed".
2.2 to check the content of such vulnerable cases to find if
extending to the mixed does not modify results. In that case simply
substitute source arguments as explained.
2.3 if a test in mixed mode deals with features triggering
row-binlogging then if necessary we can switch explicitly
to statement mode or create another test to run with
non-recommended STATEMENT mode
Particullarily, extracting INSERT DELAYED
binlogging subtest for statement mode is performed, and
the snippet is moved into a separate test file.
Note that since now all three modes verify this use case
through 3 different tests.
No changes in item 3 of HLD appeared to be needed.
mysql-test/extra/binlog_tests/binlog.test:
Moving INSERT DELAYED verification section into separate file. The latter is sourced
from two different files: the current one and a newly created for STATEMENT
mode check.
mysql-test/extra/rpl_tests/rpl_loaddata.test:
require mixed_or_statement
mysql-test/extra/rpl_tests/rpl_stm_000001.test:
require mixed_or_statement
mysql-test/extra/rpl_tests/rpl_stm_charset.test:
require mixed_or_statement
mysql-test/r/binlog_stm_binlog.result:
new result to correspond to MIXED mode.
mysql-test/r/rpl_rbr_to_sbr.result:
result changed
mysql-test/t/archive.test:
require mixed_or_statement
mysql-test/t/binlog_stm_binlog.test:
require exclusive mixed format because of INSERT DELAYED.
mysql-test/t/binlog_stm_blackhole.test:
require mixed_or_statement
mysql-test/t/binlog_stm_ctype_cp932.test:
require mixed_or_statement
mysql-test/t/binlog_stm_ctype_ucs.test:
require mixed_or_statement
mysql-test/t/binlog_stm_drop_tmp_tbl.test:
require mixed_or_statement
mysql-test/t/binlog_stm_innodb_stat.test:
require mixed_or_statement
mysql-test/t/binlog_stm_insert_select.test:
require mixed_or_statement
mysql-test/t/binlog_stm_mix_innodb_myisam.test:
require mixed_or_statement
mysql-test/t/create_select_tmp.test:
require mixed_or_statement
mysql-test/t/ctype_cp932_binlog_stm.test:
require mixed_or_statement
mysql-test/t/date_formats.test:
MIXED case appended to the replace instruction
mysql-test/t/mysqlbinlog.test:
require mixed_or_statement
mysql-test/t/mysqlbinlog2.test:
require mixed_or_statement
mysql-test/t/ndb_multi.test:
require mixed_or_statement
mysql-test/t/rpl000013.test:
require mixed_or_statement
mysql-test/t/rpl_heap.test:
require mixed_or_statement
mysql-test/t/rpl_loaddata_s.test:
require mixed_or_statement
mysql-test/t/rpl_mixed_ddl_dml.test:
require mixed_or_statement
mysql-test/t/rpl_rbr_to_sbr.test:
Rather meaningless line is discarded.
The test does not loose anything without it and without considering the WL.
mysql-test/t/rpl_rewrt_db.test:
require mixed_or_statement
mysql-test/t/rpl_rotate_logs.test:
require mixed_or_statement
mysql-test/t/rpl_stm_EE_err2.test:
require mixed_or_statement
mysql-test/t/rpl_stm_flsh_tbls.test:
require mixed_or_statement
mysql-test/t/rpl_stm_log.test:
require mixed_or_statement
mysql-test/t/rpl_stm_max_relay_size.test:
require mixed_or_statement
mysql-test/t/rpl_stm_multi_query.test:
require mixed_or_statement
mysql-test/t/rpl_stm_mystery22.test:
require mixed_or_statement
mysql-test/t/rpl_stm_no_op.test:
require mixed_or_statement
mysql-test/t/rpl_stm_reset_slave.test:
require mixed_or_statement
mysql-test/t/rpl_stm_until.test:
require mixed_or_statement
mysql-test/t/rpl_temp_table.test:
require mixed_or_statement
mysql-test/t/rpl_trigger.test:
require mixed_or_statement
mysql-test/t/rpl_trunc_temp.test:
require mixed_or_statement
mysql-test/t/user_var-binlog.test:
require mixed_or_statement
sql/mysqld.cc:
Implementation of making BINLOG_FORMAT_MIXED to be the default of
global_system_variables.binlog_format. Not in the case of embedded.
mysql-test/extra/binlog_tests/binlog_insert_delayed.test:
Snippend sourced from two tests to verify INSERT DELAYED in all three binlog formats.
mysql-test/include/have_binlog_format_mixed.inc:
Part of exclusive MIXED format requirement
mysql-test/include/have_binlog_format_mixed_or_statement.inc:
requirement to have mixed or statement. Most of the tests with STATEMENT format indeed
are tolerant to MIXED format to yield the same result files. There are few exception
because of features triggering RBR events when MIXED format.
mysql-test/r/binlog_statement_insert_delayed.result:
BitKeeper file /home/elkin/MySQL/TEAM/FIXES/5.1/wl3368_mixed_default/mysql-test/r/binlog_statement_insert_delayed.result
mysql-test/r/have_binlog_format_mixed.require:
Exclusive MIXED format
mysql-test/t/binlog_statement_insert_delayed.test:
BitKeeper file /home/elkin/MySQL/TEAM/FIXES/5.1/wl3368_mixed_default/mysql-test/t/binlog_statement_insert_delayed.test
66 lines
2.1 KiB
Text
66 lines
2.1 KiB
Text
################################
|
|
# Change Author: JBM
|
|
# Change Date: 2006-01-12
|
|
# Change: Added back have stm binlog
|
|
# and added requirments comments
|
|
################################
|
|
# test case to make slave thread get ahead by 22 bytes
|
|
################################
|
|
#REQUIREMENT: If there is a faked slave duplicate key insert
|
|
#error and the slave is restarted, the replication should
|
|
#proceed in a correct way.
|
|
################################
|
|
#REQUIREMENT: If there is a faked slave non-existing record
|
|
#delete error and the slave is restarted, then the replication
|
|
#should proceed in a correct way.
|
|
#################################
|
|
|
|
-- source include/have_binlog_format_mixed_or_statement.inc
|
|
-- source include/master-slave.inc
|
|
|
|
# first, cause a duplicate key problem on the slave
|
|
create table t1(n int auto_increment primary key, s char(10));
|
|
sync_slave_with_master;
|
|
insert into t1 values (2,'old');
|
|
connection master;
|
|
insert into t1 values(NULL,'new');
|
|
insert into t1 values(NULL,'new');
|
|
save_master_pos;
|
|
connection slave;
|
|
# wait until the slave tries to run the query, fails and aborts slave thread
|
|
wait_for_slave_to_stop;
|
|
select * from t1 order by n;
|
|
delete from t1 where n = 2;
|
|
--disable_warnings
|
|
start slave;
|
|
--enable_warnings
|
|
sync_with_master;
|
|
#now the buggy slave would be confused on the offset but it can replicate
|
|
#in order to make it break, we need to stop/start the slave one more time
|
|
stop slave;
|
|
connection master;
|
|
# to be able to really confuse the slave, we need some non-auto-increment
|
|
# events in the log
|
|
create table t2(n int);
|
|
drop table t2;
|
|
insert into t1 values(NULL,'new');
|
|
# what happens when we delete a row which does not exist on slave?
|
|
set sql_log_bin=0;
|
|
insert into t1 values(NULL,'new');
|
|
set sql_log_bin=1;
|
|
delete from t1 where n=4;
|
|
save_master_pos;
|
|
connection slave;
|
|
--disable_warnings
|
|
start slave;
|
|
--enable_warnings
|
|
#now the truth comes out - if the slave is buggy, it will never sync because
|
|
#the slave thread is not able to read events
|
|
sync_with_master;
|
|
select * from t1 order by n;
|
|
#clean up
|
|
connection master;
|
|
drop table t1;
|
|
sync_slave_with_master;
|
|
|
|
# End of 4.1 tests
|