1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
# 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).
--disable_ps_protocol
source include/master-slave.inc;
# Some preparations
let $VERSION=`select version()`;
set timestamp=100000000; # for fixed output of mysqlbinlog
create table t1 (t timestamp);
create table t2 (t char(32));
connection slave;
select @@time_zone;
#
# Let us check how well replication works when we are saving datetime
# value in TIMESTAMP field.
#
connection master;
select @@time_zone;
insert into t1 values ('20050101000000'), ('20050611093902');
set time_zone='UTC';
insert into t1 values ('20040101000000'), ('20040611093902');
select * from t1;
sync_slave_with_master;
set time_zone='UTC';
select * from t1;
# 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'), ('20040611093902');
select * from t1;
sync_slave_with_master;
set time_zone='Europe/Moscow';
select * from t1;
connection master;
--replace_result $MYSQL_TEST_DIR MYSQL_TEST_DIR
--exec $MYSQL_BINLOG --short-form $MYSQL_TEST_DIR/var/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_timezone.dat' into table t1;
select * from t1;
sync_slave_with_master;
set time_zone='UTC';
select * from t1;
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'), ('20040611093902');
#
# 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';
insert into t2 (select t from t1);
select * from t1;
sync_slave_with_master;
select * from t2;
#
# 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), (current_date), (current_time);
sync_slave_with_master;
select * from t2;
#
# At last let us check replication of FROM_UNIXTIME/UNIX_TIMESTAMP functions.
#
connection master;
delete from t2;
insert into t2 values (from_unixtime(1000000000)),
(unix_timestamp('2001-09-09 03:46:40'));
select * from t2;
sync_slave_with_master;
# We should get same result on slave as on master
select * from t2;
#
# 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));
insert into t2 values(convert_tz('2005-01-01 00:00:00','MET','Japan'));
select * from t2;
sync_slave_with_master;
select * from t2;
# Clean up
connection master;
drop table t1, t2;
sync_slave_with_master;
|
