2005-12-22 06:39:02 +01:00
# Requires statement logging
2006-08-30 10:22:43 +03:00
-- source include/have_binlog_format_mixed_or_statement.inc
2005-12-22 06:39:02 +01:00
# See if replication of a "LOAD DATA in an autoincrement column"
# Honours autoincrement values
# i.e. if the master and slave have the same sequence
#
# check replication of load data for temporary tables with additional
# parameters
#
# check if duplicate entries trigger an error (they should unless IGNORE or
# REPLACE was used on the master) (bug 571).
#
# check if START SLAVE, RESET SLAVE, CHANGE MASTER reset Last_slave_error and
# Last_slave_errno in SHOW SLAVE STATUS (1st and 3rd commands did not: bug 986)
-- source include/master-slave.inc
connection slave;
reset master;
connection master;
WL#3146 "less locking in auto_increment":
this is a cleanup patch for our current auto_increment handling:
new names for auto_increment variables in THD, new methods to manipulate them
(see sql_class.h), some move into handler::, causing less backup/restore
work when executing substatements.
This makes the logic hopefully clearer, less work is is needed in
mysql_insert().
By cleaning up, using different variables for different purposes (instead
of one for 3 things...), we fix those bugs, which someone may want to fix
in 5.0 too:
BUG#20339 "stored procedure using LAST_INSERT_ID() does not replicate
statement-based"
BUG#20341 "stored function inserting into one auto_increment puts bad
data in slave"
BUG#19243 "wrong LAST_INSERT_ID() after ON DUPLICATE KEY UPDATE"
(now if a row is updated, LAST_INSERT_ID() will return its id)
and re-fixes:
BUG#6880 "LAST_INSERT_ID() value changes during multi-row INSERT"
(already fixed differently by Ramil in 4.1)
Test of documented behaviour of mysql_insert_id() (there was no test).
The behaviour changes introduced are:
- LAST_INSERT_ID() now returns "the first autogenerated auto_increment value
successfully inserted", instead of "the first autogenerated auto_increment
value if any row was successfully inserted", see auto_increment.test.
Same for mysql_insert_id(), see mysql_client_test.c.
- LAST_INSERT_ID() returns the id of the updated row if ON DUPLICATE KEY
UPDATE, see auto_increment.test. Same for mysql_insert_id(), see
mysql_client_test.c.
- LAST_INSERT_ID() does not change if no autogenerated value was successfully
inserted (it used to then be 0), see auto_increment.test.
- if in INSERT SELECT no autogenerated value was successfully inserted,
mysql_insert_id() now returns the id of the last inserted row (it already
did this for INSERT VALUES), see mysql_client_test.c.
- if INSERT SELECT uses LAST_INSERT_ID(X), mysql_insert_id() now returns X
(it already did this for INSERT VALUES), see mysql_client_test.c.
- NDB now behaves like other engines wrt SET INSERT_ID: with INSERT IGNORE,
the id passed in SET INSERT_ID is re-used until a row succeeds; SET INSERT_ID
influences not only the first row now.
Additionally, when unlocking a table we check that the thread is not keeping
a next_insert_id (as the table is unlocked that id is potentially out-of-date);
forgetting about this next_insert_id is done in a new
handler::ha_release_auto_increment().
Finally we prepare for engines capable of reserving finite-length intervals
of auto_increment values: we store such intervals in THD. The next step
(to be done by the replication team in 5.1) is to read those intervals from
THD and actually store them in the statement-based binary log. NDB
will be a good engine to test that.
2006-07-09 17:52:19 +02:00
select last_insert_id();
2005-12-22 06:39:02 +01:00
create table t1(a int not null auto_increment, b int, primary key(a) );
2006-01-26 12:35:36 +01:00
load data infile '../std_data_ln/rpl_loaddata.dat' into table t1;
WL#3146 "less locking in auto_increment":
this is a cleanup patch for our current auto_increment handling:
new names for auto_increment variables in THD, new methods to manipulate them
(see sql_class.h), some move into handler::, causing less backup/restore
work when executing substatements.
This makes the logic hopefully clearer, less work is is needed in
mysql_insert().
By cleaning up, using different variables for different purposes (instead
of one for 3 things...), we fix those bugs, which someone may want to fix
in 5.0 too:
BUG#20339 "stored procedure using LAST_INSERT_ID() does not replicate
statement-based"
BUG#20341 "stored function inserting into one auto_increment puts bad
data in slave"
BUG#19243 "wrong LAST_INSERT_ID() after ON DUPLICATE KEY UPDATE"
(now if a row is updated, LAST_INSERT_ID() will return its id)
and re-fixes:
BUG#6880 "LAST_INSERT_ID() value changes during multi-row INSERT"
(already fixed differently by Ramil in 4.1)
Test of documented behaviour of mysql_insert_id() (there was no test).
The behaviour changes introduced are:
- LAST_INSERT_ID() now returns "the first autogenerated auto_increment value
successfully inserted", instead of "the first autogenerated auto_increment
value if any row was successfully inserted", see auto_increment.test.
Same for mysql_insert_id(), see mysql_client_test.c.
- LAST_INSERT_ID() returns the id of the updated row if ON DUPLICATE KEY
UPDATE, see auto_increment.test. Same for mysql_insert_id(), see
mysql_client_test.c.
- LAST_INSERT_ID() does not change if no autogenerated value was successfully
inserted (it used to then be 0), see auto_increment.test.
- if in INSERT SELECT no autogenerated value was successfully inserted,
mysql_insert_id() now returns the id of the last inserted row (it already
did this for INSERT VALUES), see mysql_client_test.c.
- if INSERT SELECT uses LAST_INSERT_ID(X), mysql_insert_id() now returns X
(it already did this for INSERT VALUES), see mysql_client_test.c.
- NDB now behaves like other engines wrt SET INSERT_ID: with INSERT IGNORE,
the id passed in SET INSERT_ID is re-used until a row succeeds; SET INSERT_ID
influences not only the first row now.
Additionally, when unlocking a table we check that the thread is not keeping
a next_insert_id (as the table is unlocked that id is potentially out-of-date);
forgetting about this next_insert_id is done in a new
handler::ha_release_auto_increment().
Finally we prepare for engines capable of reserving finite-length intervals
of auto_increment values: we store such intervals in THD. The next step
(to be done by the replication team in 5.1) is to read those intervals from
THD and actually store them in the statement-based binary log. NDB
will be a good engine to test that.
2006-07-09 17:52:19 +02:00
# verify that LAST_INSERT_ID() is set by LOAD DATA INFILE
select last_insert_id();
2005-12-22 06:39:02 +01:00
create temporary table t2 (day date,id int(9),category enum('a','b','c'),name varchar(60));
2006-01-26 12:35:36 +01:00
load data infile '../std_data_ln/rpl_loaddata2.dat' into table t2 fields terminated by ',' optionally enclosed by '%' escaped by '@' lines terminated by '\n##\n' starting by '>' ignore 1 lines;
2005-12-22 06:39:02 +01:00
create table t3 (day date,id int(9),category enum('a','b','c'),name varchar(60));
insert into t3 select * from t2;
save_master_pos;
connection slave;
sync_with_master;
select * from t1;
select * from t3;
# We want to be sure that LOAD DATA is in the slave's binlog.
# But we can't simply read this binlog, because as the slave has not been
# restarted for this test, the file_id is uncertain (would cause test
# failures). So instead, we test if the binlog looks long enough to
# contain LOAD DATA. Since 5.0.3 we assume that binlog of 1292 is ok.
# If LOAD DATA was not logged, the binlog would be shorter.
show master status;
connection master;
drop table t1;
drop table t2;
drop table t3;
create table t1(a int, b int, unique(b));
save_master_pos;
connection slave;
sync_with_master;
# See if slave stops when there's a duplicate entry for key error in LOAD DATA
insert into t1 values(1,10);
connection master;
2006-01-26 12:35:36 +01:00
load data infile '../std_data_ln/rpl_loaddata.dat' into table t1;
2005-12-22 06:39:02 +01:00
save_master_pos;
connection slave;
# The SQL slave thread should be stopped now.
wait_for_slave_to_stop;
# Skip the bad event and see if error is cleared in SHOW SLAVE STATUS by START
# SLAVE, even though we are not executing any event (as sql_slave_skip_counter
# takes us directly to the end of the relay log).
set global sql_slave_skip_counter=1;
start slave;
sync_with_master;
--replace_result $MASTER_MYPORT MASTER_PORT
--replace_column 1 # 8 # 9 # 16 # 23 # 33 #
show slave status;
# Trigger error again to test CHANGE MASTER
connection master;
set sql_log_bin=0;
delete from t1;
set sql_log_bin=1;
2006-01-26 12:35:36 +01:00
load data infile '../std_data_ln/rpl_loaddata.dat' into table t1;
2005-12-22 06:39:02 +01:00
save_master_pos;
connection slave;
# The SQL slave thread should be stopped now.
# Exec_Master_Log_Pos should point to the start of Execute event
# for last load data.
wait_for_slave_to_stop;
# CHANGE MASTER and see if error is cleared in SHOW SLAVE STATUS.
stop slave;
change master to master_user='test';
change master to master_user='root';
--replace_result $MASTER_MYPORT MASTER_PORT
--replace_column 1 # 8 # 9 # 16 # 23 # 33 #
show slave status;
# Trigger error again to test RESET SLAVE
set global sql_slave_skip_counter=1;
start slave;
sync_with_master;
connection master;
set sql_log_bin=0;
delete from t1;
set sql_log_bin=1;
2006-01-26 12:35:36 +01:00
load data infile '../std_data_ln/rpl_loaddata.dat' into table t1;
2005-12-22 06:39:02 +01:00
save_master_pos;
connection slave;
# The SQL slave thread should be stopped now.
wait_for_slave_to_stop;
# RESET SLAVE and see if error is cleared in SHOW SLAVE STATUS.
stop slave;
reset slave;
--replace_result $MASTER_MYPORT MASTER_PORT
--replace_column 1 # 8 # 9 # 16 # 23 # 33 #
show slave status;
# Finally, see if logging is done ok on master for a failing LOAD DATA INFILE
connection master;
reset master;
eval create table t2 (day date,id int(9),category enum('a','b','c'),name varchar(60),
unique(day)) engine=$engine_type; # no transactions
2007-01-22 18:42:52 +02:00
--error ER_DUP_ENTRY_WITH_KEY_NAME
2006-01-26 12:35:36 +01:00
load data infile '../std_data_ln/rpl_loaddata2.dat' into table t2 fields
2005-12-22 06:39:02 +01:00
terminated by ',' optionally enclosed by '%' escaped by '@' lines terminated by
'\n##\n' starting by '>' ignore 1 lines;
select * from t2;
save_master_pos;
connection slave;
start slave;
sync_with_master;
select * from t2;
# verify that if no error on slave, this is an error
alter table t2 drop key day;
connection master;
delete from t2;
2007-01-22 18:42:52 +02:00
--error ER_DUP_ENTRY_WITH_KEY_NAME
2006-01-26 12:35:36 +01:00
load data infile '../std_data_ln/rpl_loaddata2.dat' into table t2 fields
2005-12-22 06:39:02 +01:00
terminated by ',' optionally enclosed by '%' escaped by '@' lines terminated by
'\n##\n' starting by '>' ignore 1 lines;
connection slave;
wait_for_slave_to_stop;
drop table t2;
connection master;
drop table t2;
2006-05-31 23:34:28 +02:00
drop table t1;
2005-12-22 06:39:02 +01:00
# End of 4.1 tests