| Bug #1633 | replicated load data command fail to recognise field delimeter | ||
|---|---|---|---|
| Submitted: | 23 Oct 2003 2:03 | Modified: | 23 Oct 2003 5:00 |
| Reporter: | [ name withheld ] | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S1 (Critical) |
| Version: | 4.0.12 | OS: | Linux (Red Hat linux 7.3) |
| Assigned to: | CPU Architecture: | Any | |
[23 Oct 2003 5:00]
Guilhem Bichot
Thank you for your bug report. This issue has already been fixed in the latest released version of that product, which you can download at http://www.mysql.com/downloads/
[23 Oct 2003 5:03]
Guilhem Bichot
Hi! Thank you for your bug report. This is fixed since 4.0.13: from the changelog (http://www.mysql.com/doc/en/News-4.0.13.html) "Fixed bugs in replication of LOAD DATA INFILE for custom parameters (ENCLOSED, TERMINATED and so on) and temporary tables. (Bug #183, Bug #222)". Generally speaking, when you are not using the last version, browsing the changelog to see if this bug was already fixed, saves time. Regards, Guilhem
Description: I am using Ver 4.0.12 for pc-linux on i686. The following command executed successfully on the master and the command got replicated to the slave, load data infile './b.t' replace into table `JobHist` fields terminated by "\n" lines terminated by "\n%%\n" ; with file b.t containg 2003 Oct 23 daily 5 161480704 39% 11:11:11 11:11:11 15:33:16 15:33:50 15:33:53 %% However, the replicated command ran and treated each line to be a 'line' instead of a 'field' as directed by the load command. I have run the same command on the slave through a normal session with same file input. It works normally. I suspect the slave replicating thread executed the command and read the file through communication and losts all the '/n's. How to repeat: Follow the description described above.