Bug #76879 | Carriage Return Issue | ||
---|---|---|---|
Submitted: | 29 Apr 2015 8:44 | Modified: | 4 May 2015 8:32 |
Reporter: | Infosys DBS Team | Email Updates: | |
Status: | Can't repeat | Impact on me: | |
Category: | MySQL Server | Severity: | S2 (Serious) |
Version: | 5.0.95 | OS: | Linux (x86-64) |
Assigned to: | MySQL Verification Team | CPU Architecture: | Any |
[29 Apr 2015 8:44]
Infosys DBS Team
[29 Apr 2015 14:24]
MySQL Verification Team
Hi, Thanks for the bug report. I need some more details from you - How did you perform a backup? - How did you perform restore? - Tables in question - what storage engine they use? - Were both server you backed from and restored to same version? all best Bogdan Kecman
[30 Apr 2015 2:01]
Infosys DBS Team
Hello Bodgan, Below is the information: - How did you perform a backup? We use below command to take the backup: mysqldump -u root -p --all-databases > /opt/data/dump/full_dump_31072014.sql - How did you perform restore? mysql -u root -p < /tmp/full_dump_31072014.sql - Tables in question - what storage engine they use? Engine used is InnoDB. - Were both server you backed from and restored to same version? Yes Thanks for looking into this and let us know if any other details required from our end. Regards, Shakti
[30 Apr 2015 8:59]
MySQL Verification Team
Hi, Nothing like this I could reproduce in any of the mysql versions including 5.0.95. What type are the columns you found extra CR's in, varchar or text or? What type are the columns you found binary corruption? Blob's or? The common problem (not a bug) with dump/restore is wrt character set's but not even that can introduce new CR's into field values. Did you maybe move that dump via FTP between servers? FTP is known to affect content of the file especially transfering between windows and unix systems. all best Bogdan Kecman
[4 May 2015 8:32]
Infosys DBS Team
Hello Bodgan, We found CRs in columns defined as varchar(255). Backup, restore was done on the same server so no files were moved using ftp between servers. One thing which I feel was incorrect in the last update was we restored only a single table from the backup taken of the complete database. So the command we used to backup was as we had shared but then we extracted a single table from the dump and inserted it in the db. Below were the steps we did: # grep -n 'Table structure' db_backup_file_name # cat db_backup_file_name | sed -n -e '/Table structure for table .tab1./,/Table structure for table .tab2./p' > /tmp/tab1_export.sql # mysql -u root -p mysql> connect db_name mysql> source /tmp/tab1_export.sql; Regards, Shakti
[6 May 2015 7:42]
MySQL Verification Team
Hi, if you load the original dump, do you get extra CR's then? When you open the SQL file you are sourcing, do you see those extra CR's in the SQL file? If you open original SQL, are the CR's there? all best Bogdan Kecman