Yes, still exhibits this problem -- although at a different line in the file. 
(Seems random.) I should also mention, the backup is running across a local 
network. The machine the starts automysqlbackup (and internally, mysqldump) 
connects over TCP/IP to the database server. I am going to try running 
mysqldump on the database server itself, but it's not something I can do during 
normal hours -- plus at 10GB, it's a time-consuming thing to test. (Would it 
matter? I guess I need to find out.)

In any case, it seems clear that during the dump, mysqldump is periodically 
adding a character to the dump file.

On 2009-11-20, at 12:41 PM, Gavin Towey wrote:

> Have you tried dumping that table manually using mysqldump on the command 
> line to confirm it's not an issue with automysqlbackup?
> 
> Regards,
> Gavin Towey
> 
> -----Original Message-----
> From: René Fournier [mailto:m...@renefournier.com]
> Sent: Friday, November 20, 2009 8:31 AM
> To: mysql
> Subject: Strange problem with mysqldump / automysqlbackup (ERROR 1300)
> 
> I've been using automysqlbackup 2.5 for years on a particular database, and 
> it's always performed great. Recently, however, I've become encountering 
> problems when trying to re-import one of its dumped sql files. (Not sure if 
> it matters, but the database file in question is large and growing -- about 
> 10GB. The other databases automysqlbackup backs up are fine.)
> 
> Basically on the import, MySQL fails and returns an error indicating a 
> problem with the dump file:
> 
> mysql -u root -p < dump_file.sql  (~10GB)
> Enter password:
> ERROR 1300 (HY000) at line 426: Invalid utf8 character string: '?03422'
> 
> Sure enough, I look at the line in dump_file.sql, which should contain two 
> unsigned ints, and two unsigned small ints:
> 
>        [...],(32562206,1228?03422,1641,135),[...]
> 
> And yup, there's a question mark in the middle of the second unsigned int, 
> for some strange reason. Not in any of the other rows in that statement. When 
> I look at the existing database from which the dump file was made, that row 
> is fine:
> 
> mysql> SELECT * FROM bandwidth WHERE id = 32562206;
> +----------+------------+-----------+-------+
> | id       | time_sec   | device_id | bytes |
> +----------+------------+-----------+-------+
> | 32562206 | 1228803422 |      1641 |   135 |
> +----------+------------+-----------+-------+
> 1 row in set (0.00 sec)
> 
> 
> So... It appears either mysqldump and/or automysqlbackup is having a problem 
> dumping a true copy of the database.
> 
> Anyone else run into this sort of thing? Any suggestions? Thanks.
> 
> ...Rene
> 
> The information contained in this transmission may contain privileged and 
> confidential information. It is intended only for the use of the person(s) 
> named above. If you are not the intended recipient, you are hereby notified 
> that any review, dissemination, distribution or duplication of this 
> communication is strictly prohibited. If you are not the intended recipient, 
> please contact the sender by reply email and destroy all copies of the 
> original message.


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/mysql?unsub=arch...@jab.org

Reply via email to