diff options
author | Sergei Golubchik <serg@mariadb.org> | 2015-08-30 18:48:37 +0200 |
---|---|---|
committer | Sergei Golubchik <serg@mariadb.org> | 2015-08-31 17:54:26 +0200 |
commit | 059dfc187e3b51e06d941dc1ba539128c1b3de8c (patch) | |
tree | 28b14fa874c491906a0060b71a0427d83c51f99c /mysql-test/suite/rpl/t/rpl_timezone.test | |
parent | 6176b3477a0a7a20d09047e379c4c8b87c5e87b6 (diff) | |
download | mariadb-git-wip-binlog-encryption.tar.gz |
tests (temp)wip-binlog-encryption
Diffstat (limited to 'mysql-test/suite/rpl/t/rpl_timezone.test')
-rw-r--r-- | mysql-test/suite/rpl/t/rpl_timezone.test | 209 |
1 files changed, 0 insertions, 209 deletions
diff --git a/mysql-test/suite/rpl/t/rpl_timezone.test b/mysql-test/suite/rpl/t/rpl_timezone.test deleted file mode 100644 index 1f0220421ab..00000000000 --- a/mysql-test/suite/rpl/t/rpl_timezone.test +++ /dev/null @@ -1,209 +0,0 @@ -####################################### -# Change Author: JBM -# Change Date: 2006-01-17 -# Change: Added order by -####################################### -# Test of replication of time zones. -###################################### -# There is currently some bug possibly in prepared statements (this -# test fails with --ps-protocol): sys_var_thd_time_zone::value_ptr() -# is called only at prepare time, not at execution time. So, -# thd->time_zone_used is not equal to 1 (it is back to 0, because of -# reset_thd_for_next_command called at execution time), so the -# timezone used in CONVERT_TZ is not binlogged. To debug (by Guilhem -# and possibly Konstantin). - -source include/master-slave.inc; - ---disable_query_log -CALL mtr.add_suppression("Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT"); ---enable_query_log - ---disable_ps_protocol - -# Save original timezone -set @my_time_zone= @@global.time_zone; - -# Some preparations -let $VERSION=`select version()`; -set timestamp=100000000; # for fixed output of mysqlbinlog -create table t1 (t timestamp, n int not null auto_increment, PRIMARY KEY(n)); -create table t2 (t char(32), n int not null auto_increment, PRIMARY KEY(n)); - -connection slave; -select @@time_zone; -#set time_zone='UTC'; -#select @@time_zone; -# -# Let us check how well replication works when we are saving datetime -# value in TIMESTAMP field. -# -connection master; -select @@time_zone; -#set time_zone='UTC'; -#select @@time_zone; -insert into t1 values ('20050101000000', NULL), ('20050611093902',NULL); -insert into t1 values ('20040101000000',NULL), ('20040611093902',NULL); -SELECT * FROM t1 ORDER BY n; -sync_slave_with_master; -#set time_zone='UTC'; -SELECT * FROM t1 ORDER BY n; - -# Let us check also that setting of time_zone back to default also works -# well -connection master; -delete from t1; -set time_zone='Europe/Moscow'; -insert into t1 values ('20040101000000',NULL), ('20040611093902',NULL); -SELECT * FROM t1 ORDER BY n; -sync_slave_with_master; -set time_zone='Europe/Moscow'; -SELECT * FROM t1 ORDER BY n; -connection master; -# Change Author: JBM -# Change Date: 2005-12-22 -# Change: Comment out the exec of the binlog so test works for both SBR and RBR -#--replace_result $MYSQLTEST_VARDIR MYSQLTEST_VARDIR -#--exec $MYSQL_BINLOG --short-form $MYSQLTEST_VARDIR/log/master-bin.000001 - -# Let us check with LOAD DATA INFILE -# (we do it after mysqlbinlog because the temp files names are not constant) -connection master; -delete from t1; -set time_zone='UTC'; -load data infile '../../std_data/rpl_timezone2.dat' into table t1; -SELECT * FROM t1 ORDER BY n; -sync_slave_with_master; -set time_zone='UTC'; -SELECT * FROM t1 ORDER BY n; -set time_zone='Europe/Moscow'; - -# Put back values of before the LOAD -connection master; -set time_zone='Europe/Moscow'; -delete from t1; -insert into t1 values ('20040101000000',NULL), ('20040611093902',NULL); - -# -# Now let us check how well we replicate statments reading TIMESTAMP fields -# (We should see the same data on master and on slave but it should differ -# from originally inserted) -# -set time_zone='MET'; ---disable_warnings ONCE -insert into t2 (select * from t1); -SELECT * FROM t1 ORDER BY n; -sync_slave_with_master; -SELECT * FROM t2 ORDER BY n; - -# -# Now let us check how well we replicate various CURRENT_* functions -# -connection master; -delete from t2; -set timestamp=1000072000; -insert into t2 values (current_timestamp,NULL), (current_date,NULL), (current_time,NULL); -sync_slave_with_master; -SELECT * FROM t2 ORDER BY n; - -# -# At last let us check replication of FROM_UNIXTIME/UNIX_TIMESTAMP functions. -# -connection master; -delete from t2; -insert into t2 values (from_unixtime(1000000000),NULL), - (unix_timestamp('2001-09-09 03:46:40'),NULL); -SELECT * FROM t2 ORDER BY n; -sync_slave_with_master; -# We should get same result on slave as on master -SELECT * FROM t2 ORDER BY n; - -# -# Let us check that we are allowing to set global time_zone with -# replication -# -connection master; -set global time_zone='MET'; - -# -# Let us see if CONVERT_TZ(@@time_zone) replicates -# -delete from t2; -set time_zone='UTC'; -insert into t2 values(convert_tz('2004-01-01 00:00:00','MET',@@time_zone),NULL); -insert into t2 values(convert_tz('2005-01-01 00:00:00','MET','Japan'),NULL); -SELECT * FROM t2 ORDER BY n; -sync_slave_with_master; -SELECT * FROM t2 ORDER BY n; - -# Clean up -connection master; -drop table t1, t2; -sync_slave_with_master; - - -# Restore original timezone -connection master; -set global time_zone= @my_time_zone; - ---echo End of 4.1 tests - -# -# Bug #29536: timestamp inconsistent in replication around 1970 -# -connection master; - -CREATE TABLE t1 (a INT, b TIMESTAMP); -INSERT INTO t1 VALUES (1, NOW()); - -SET @@session.time_zone='Japan'; -UPDATE t1 SET b= '1970-01-01 08:59:59' WHERE a= 1; -SELECT * FROM t1 ORDER BY a; - -sync_slave_with_master; -SET @@session.time_zone='Japan'; -# must procdure the same result as the SELECT on the master -SELECT * FROM t1 ORDER BY a; - -SET @@session.time_zone = default; -connection master; -DROP TABLE t1; -SET @@session.time_zone = default; ---sync_slave_with_master ---source include/stop_slave.inc - -# Bug#41719 delayed INSERT into timestamp col needs set time_zone for concurrent binlogging -# To test that time_zone is correctly binloging for 'insert delayed' statement -# Insert 2 values into timestamp col with different time_zone. Check result. - ---connection master -reset master; -CREATE TABLE t1 (date timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, a int(11) default NULL); - -SET @@session.time_zone='+01:00'; -insert into t1 values('2008-12-23 19:39:39',1); - ---connection master1 -SET @@session.time_zone='+02:00'; -insert delayed into t1 values ('2008-12-23 19:39:39',2); - -# wait for the delayed insert to be executed -let $wait_condition= SELECT date FROM t1 WHERE a=2; ---source include/wait_condition.inc - -flush table t1; -flush logs; -select * from t1; -DROP TABLE t1; - -let $MYSQLD_DATADIR= `select @@datadir;`; ---exec $MYSQL_BINLOG $MYSQLD_DATADIR/master-bin.000001 | $MYSQL ---connection master1 -select * from t1 order by a; -DROP TABLE t1; -SET @@session.time_zone = default; - ---let $rpl_only_running_threads= 1 ---source include/rpl_end.inc - ---echo End of 5.0 tests |