MySQL Bugs: #22109: Slave breaks charset in replicating 'LOAD DATA' statement

Bug #22109	Slave breaks charset in replicating 'LOAD DATA' statement
Submitted:	8 Sep 2006 10:54	Modified:	23 Oct 2006 13:39
Reporter:	Hu Hailin
Status:	Duplicate
Category:	Server: Replication	Severity:	S2 (Serious)
Version:	5.0.24a	OS:	Linux (CentOS release 4.2 (Final))
Assigned to:		Target Version:
Tags:	LOAD DATA, charset, replication

Description:
When master server did a LOAD DATA job including some charset setting, the slave failed
to replicate the job with proper charset. So the data on slave would be messed up.

How to repeat:
All operations below are on the master server:

1. INITIALIZE
CREATE DATABASE `ja` CHARACTER SET ujis;
CREATE TABLE `ja`.`ujis` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `name` varchar(255) default NULL,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB;

2. JOB (ujis.sql)
USE ja;
TRUNCATE TABLE ujis;
LOAD DATA LOCAL INFILE 'ujis.csv' INTO TABLE ujis
  FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' ESCAPED BY ''
  LINES TERMINATED BY '\r\n'
  ( name );

3. DATA (ujis.csv)
---quote--
あいうえお
かきくけこ
さしすせそ
たちつてと
なにぬねの
---quote--
line feed is CR+LF, charset is EUC-JP

4. EXECUTE
/usr/local/mysql-master/bin/mysql --local-infile -S /tmp/mysql-master.sock -u root <
ujis.sql

5. RESULT
The data on the master server is right as usual. But the data on the slave server is
messed up, just like the character_set_database system variable is still latin1.

Thank you for a problem report. Please, send my.cnf from your master and slave, for
completeness.

my.cnf of master and slave

Attachment: my.cnf.tar.gz (application/x-gzip, text), 2.34 KiB.

my.cnf uploaded.
I'm sorry to miss the note that I should add comment to update the bug status.

Duplicate of bug #15126, almost surely.