mariadb/mysql-test/suite/rpl/r/rpl_view_multi.result
Konstantin Osipov 8a54198cba Backport of:
----------------------------------------------------------------
2630.4.9 Dmitry Lenev	2008-05-26
         WL#3726 "DDL locking for all metadata objects".
        
         After review fixes in progress. Adjusted test case
         according to review.


mysql-test/suite/rpl/r/rpl_view_multi.result:
  Changed test case to check that statements are replicated
  properly instead of directly inspecting binary log. Also
  made result file more readable by adding echo there it
  was appropriate. Moved test case to "rpl" suite.
mysql-test/suite/rpl/t/rpl_view_multi.test:
  Changed test case to check that statements are replicated
  properly instead of directly inspecting binary log. Also
  made result file more readable by adding echo there it
  was appropriate. Moved test case to "rpl" suite.
2009-11-30 19:21:40 +03:00

90 lines
2.6 KiB
Text

stop slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
reset master;
reset slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
start slave;
#
# Bug #25144 "replication / binlog with view breaks".
# Statements that used views didn't ensure that view were not modified
# during their execution. Indeed this led to incorrect binary log with
# statement based logging and as result to broken replication.
#
drop tables if exists t1, t2;
drop view if exists v1;
# Syncing slave with master and switching to connection 'slave'
# Switching to connection 'master'
create table t1 (i int);
create table t2 (i int);
create view v1 as select * from t1;
# First we try to concurrently execute statement that uses view
# and statement that drops it. We use "user" locks as means to
# suspend execution of first statement once it opens our view.
select get_lock("lock_bg25144", 1);
get_lock("lock_bg25144", 1)
1
# Switching to connection 'master1'
insert into v1 values (get_lock("lock_bg25144", 100));
# Switching to connection 'master2'
drop view v1;
# Switching to connection 'master'
select release_lock("lock_bg25144");
release_lock("lock_bg25144")
1
# Switching to connection 'master1'
select release_lock("lock_bg25144");
release_lock("lock_bg25144")
1
# Switching to connection 'master2'
# Switching to connection 'master'
# Check that insertion through view did happen.
select * from t1;
i
1
# Syncing slave with master and switching to connection 'slave'
# Check that slave was able to replicate this sequence
# which means that we got correct binlog order.
select * from t1;
i
1
# Switching to connection 'master'
# Now we will repeat the test by trying concurrently execute
# statement that uses a view and statement that alters it.
create view v1 as select * from t1;
select get_lock("lock_bg25144", 1);
get_lock("lock_bg25144", 1)
1
# Switching to connection 'master1'
insert into v1 values (get_lock("lock_bg25144", 100));
# Switching to connection 'master2'
alter view v1 as select * from t2;
# Switching to connection 'master'
select release_lock("lock_bg25144");
release_lock("lock_bg25144")
1
# Switching to connection 'master1'
select release_lock("lock_bg25144");
release_lock("lock_bg25144")
1
# Switching to connection 'master2'
# Switching to connection 'master'
# Second insertion should go to t1 as well.
select * from t1;
i
1
1
select * from t2;
i
# Syncing slave with master and switching to connection 'slave'
# Now let us check that statements were logged in proper order
# So we have same result on slave.
select * from t1;
i
1
1
select * from t2;
i
# Switching to connection 'master'
drop table t1, t2;
drop view v1;
# Syncing slave with master and switching to connection 'slave'