Test for bug 578. And a comment in slave.cc.
This commit is contained in:
parent
e6cdc81613
commit
0058593c2d
8
mysql-test/r/lock_tables_lost_commit.result
Normal file
8
mysql-test/r/lock_tables_lost_commit.result
Normal file
@ -0,0 +1,8 @@
|
||||
drop table if exists t1;
|
||||
create table t1(a int) type=innodb;
|
||||
lock tables t1 write;
|
||||
insert into t1 values(10);
|
||||
select * from t1;
|
||||
a
|
||||
10
|
||||
drop table t1;
|
1
mysql-test/t/lock_tables_lost_commit-master.opt
Normal file
1
mysql-test/t/lock_tables_lost_commit-master.opt
Normal file
@ -0,0 +1 @@
|
||||
--binlog-ignore-db=test innodb
|
18
mysql-test/t/lock_tables_lost_commit.test
Normal file
18
mysql-test/t/lock_tables_lost_commit.test
Normal file
@ -0,0 +1,18 @@
|
||||
# This is a test for bug 578
|
||||
|
||||
connect (con1,localhost,root,,);
|
||||
connect (con2,localhost,root,,);
|
||||
|
||||
connection con1;
|
||||
drop table if exists t1;
|
||||
create table t1(a int) type=innodb;
|
||||
lock tables t1 write;
|
||||
insert into t1 values(10);
|
||||
disconnect con1;
|
||||
|
||||
connection con2;
|
||||
# The bug was that, because of the LOCK TABLES, the handler "forgot" to commit,
|
||||
# and the other commit when we write to the binlog was not done because of
|
||||
# binlog-ignore-db
|
||||
select * from t1;
|
||||
drop table t1;
|
20
sql/slave.cc
20
sql/slave.cc
@ -1186,6 +1186,26 @@ int init_relay_log_info(RELAY_LOG_INFO* rli, const char* info_fname)
|
||||
strmov(strcend(tmp,'.'),"-relay-bin");
|
||||
opt_relay_logname=my_strdup(tmp,MYF(MY_WME));
|
||||
}
|
||||
|
||||
/*
|
||||
The relay log will now be opened, as a SEQ_READ_APPEND IO_CACHE. It is
|
||||
notable that the last kilobytes of it (8 kB for example) may live in memory,
|
||||
not on disk (depending on what the thread using it does). While this is
|
||||
efficient, it has a side-effect one must know:
|
||||
the size of the relay log on disk (displayed by 'ls -l' on Unix) can be a
|
||||
few kilobytes less than one would expect by doing SHOW SLAVE STATUS; this
|
||||
happens when only the IO thread is started (not the SQL thread). The
|
||||
"missing" kilobytes are in memory, are preserved during 'STOP SLAVE; START
|
||||
SLAVE IO_THREAD', and are flushed to disk when the slave's mysqld stops. So
|
||||
this does not cause any bug. Example of how disk size grows by leaps:
|
||||
|
||||
Read_Master_Log_Pos: 7811 -rw-rw---- 1 guilhem qq 4 Jun 5 16:19 gbichot2-relay-bin.002
|
||||
...later...
|
||||
Read_Master_Log_Pos: 9744 -rw-rw---- 1 guilhem qq 8192 Jun 5 16:27 gbichot2-relay-bin.002
|
||||
|
||||
See how 4 is less than 7811 and 8192 is less than 9744.
|
||||
*/
|
||||
|
||||
if (open_log(&rli->relay_log, glob_hostname, opt_relay_logname,
|
||||
"-relay-bin", opt_relaylog_index_name,
|
||||
LOG_BIN, 1 /* read_append cache */,
|
||||
|
Loading…
x
Reference in New Issue
Block a user