mariadb/mysql-test/t/rpl_charset.test
guilhem@mysql.com 86e8ecc965 Implementation of WL#1824 "Add replication of character set variables in 4.1",
by binlogging some SET ONE_SHOT CHARACTER_SETetc,
which will be enough until we have it more compact and more complete in 5.0. With the present patch,
replication will work ok between 4.1.3 master and slaves, as long as:
- master and slave have the same GLOBAL.COLLATION_SERVER
- COLLATION_DATABASE and CHARACTER_SET_DATABASE are not used
- application does not use the fact that table is created with charset of the USEd db (BUG#2326).
all of which are not too hard to fulfill. 
ONE_SHOT is reserved for internal use of mysqlbinlog|mysql and works only for charsets,
so we give error if used for non-charset vars.
Fix for BUG#3875 "mysqlbinlog produces wrong ouput  if query uses
 variables containing quotes" and BUG#3943 "Queries with non-ASCII literals are not replicated
 properly after SET NAMES".
Detecting that master and slave have different global charsets or server ids.
2004-06-03 23:17:18 +02:00

153 lines
4.6 KiB
Text
Raw Blame History

# Replication of character sets.
# This test will fail if the server/client does not support enough charsets.
# Remember that there currently exists
# Bug #2326: Charset of table is determined by charset of db only if "USE db;"
source include/master-slave.inc;
--disable_warnings
drop database if exists test2;
drop database if exists test3;
--enable_warnings
create database test2 character set latin2;
set @@character_set_server=latin5;
create database test3;
--disable_query_log
select "--- --master--" as "";
--enable_query_log
show create database test2;
show create database test3;
sync_slave_with_master;
--disable_query_log
select "--- --slave--" as "";
--enable_query_log
show create database test2;
show create database test3;
connection master;
set @@collation_server=armscii_bin;
drop database test3;
create database test3;
--disable_query_log
select "--- --master--" as "";
--enable_query_log
show create database test3;
sync_slave_with_master;
--disable_query_log
select "--- --slave--" as "";
--enable_query_log
show create database test3;
connection master;
use test2;
create table t1 (a int auto_increment primary key, b varchar(100));
set character_set_client=cp850, collation_connection=latin2_croatian_ci;
insert into t1 (b) values(@@character_set_server);
insert into t1 (b) values(@@collation_server);
# character_set_database and collation_database are not tested as they
# are not replicated (Bar said that this variable may be removed shortly).
insert into t1 (b) values(@@character_set_client);
# collation_client does not exist
insert into t1 (b) values(@@character_set_connection);
insert into t1 (b) values(@@collation_connection);
--disable_query_log
select "--- --master--" as "";
--enable_query_log
select * from t1 order by a;
sync_slave_with_master;
--disable_query_log
select "--- --slave--" as "";
--enable_query_log
select * from test2.t1 order by a;
connection master;
set character_set_client=latin1, collation_connection=latin1_german1_ci;
truncate table t1;
insert into t1 (b) values(@@collation_connection);
insert into t1 (b) values(LEAST("M<>ller","Muffler"));
set collation_connection=latin1_german2_ci;
insert into t1 (b) values(@@collation_connection);
insert into t1 (b) values(LEAST("M<>ller","Muffler"));
--disable_query_log
select "--- --master--" as "";
--enable_query_log
select * from t1 order by a;
sync_slave_with_master;
--disable_query_log
select "--- --slave--" as "";
--enable_query_log
select * from test2.t1 order by a;
# See if SET ONE_SHOT gets into binlog when LOAD DATA
connection master;
load data infile '../../std_data/words.dat' into table t1 (b);
# See if user var is prefixed with collation in binlog and replicated well.
# Note: replication of user variables is broken as far as derivation is
# concerned. That's because when we store a user variable in the binlog,
# we lose its derivation. So later on the slave, it's impossible to
# know if the collation was explicit or not, so we use DERIVATION_NONE,
# which provokes error messages (like 'Illegal mix of collation') when
# we replay the master's INSERT/etc statements.
set @a= _cp850 'M<>ller' collate cp850_general_ci;
truncate table t1;
insert into t1 (b) values(collation(@a));
--disable_query_log
select "--- --master--" as "";
--enable_query_log
select * from t1 order by a;
sync_slave_with_master;
--disable_query_log
select "--- --slave--" as "";
--enable_query_log
select * from test2.t1 order by a;
connection master;
drop database test2;
drop database test3;
show binlog events from 79;
sync_slave_with_master;
# Check that we can't change global.collation_server
error 1105;
set global character_set_server=latin2;
connection master;
error 1105;
set global character_set_server=latin2;
# Check that SET ONE_SHOT is really one shot
set one_shot @@character_set_server=latin5;
set @@max_join_size=1000;
select @@character_set_server;
select @@character_set_server;
set @@character_set_server=latin5;
select @@character_set_server;
select @@character_set_server;
# ONE_SHOT on not charset/collation stuff is not allowed
error 1105;
set one_shot max_join_size=10;
# Test of wrong character set numbers;
error 1115;
set character_set_client=9999999;
error 1273;
set collation_server=9999998;
# This one was contributed by Sergey Petrunia (BUG#3943)
use test;
CREATE TABLE t1 (c1 VARBINARY(255), c2 VARBINARY(255));
SET CHARACTER_SET_CLIENT=koi8r,
CHARACTER_SET_CONNECTION=cp1251,
CHARACTER_SET_RESULTS=koi8r;
INSERT INTO t1 (c1, c2) VALUES ('<27><>, <20><> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>','<27><>, <20><> <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>');
select hex(c1), hex(c2) from t1;
sync_slave_with_master;
select hex(c1), hex(c2) from t1;
connection master;
drop table t1;
sync_slave_with_master;