Bug #6433 | Administrator stops analysing backup file without any stated reason | ||
---|---|---|---|
Submitted: | 4 Nov 2004 14:27 | Modified: | 6 Oct 2005 14:06 |
Reporter: | Patrick Questembert | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Administrator | Severity: | S3 (Non-critical) |
Version: | 1.0.13 | OS: | Windows (Windows XP) |
Assigned to: | Mike Lischke | CPU Architecture: | Any |
[4 Nov 2004 14:27]
Patrick Questembert
[10 Jan 2005 18:02]
Jorge del Conde
I was able to verify this (WinXP / SP2) using a db w/230 tables and a total of 3 GB in size. All tables where InnoDB.
[5 Mar 2005 19:52]
David Ziegelheim
Same problem, 26 tables. InnoDB. 100MB. Is there a workaround. This is a MAJOR problem...S2 at least...for me.
[25 Apr 2005 19:02]
James Evans
Same problem - just backed up 4 gig of data from work, transfered it to home and analyze backup file stops at 0 with "analyze completed successfully", nothing shown in the list of tables. Really big problem as I wanted to setup a dev environment. Any other options? Thanks, James
[3 Jun 2005 20:35]
Chris Wiegand
Can just use command line client in batch mode to get around this for now (as we did here with out small database, no data, just structure). I suspect this is a SQL-parsing bug as we have no data (yet) in our mysql server.
[15 Jun 2005 8:14]
Peter Tellram
Just had the same problem here. 310 mb, 50 tables (all MyISAM). Tried using MySQL Administrator 1.0.19 trhu 1.0.21 - same result. This must for sure be a critical bug, since I can't restore any backup of the database.
[21 Jun 2005 11:53]
Jim Cartlidge
I get this problem all the time. Opening up the backup with a text editor, you see that strange characters are being inserted into the text (CR?), removing these cause the restore to work. However, on a 128mb file, it takes some time!
[13 Jul 2005 13:36]
John Clement
I am also having this problem. I did notice the (CR?) characters and took them out, but am still having trouble. The restore continues to stop stating it has completed, but really has not.
[17 Aug 2005 15:30]
Peter Martinson
When I load the offending sql backup file into a mega editor and delete all the other table info, then run it through the analyzer it completes and restores the remaining table correctly. So I don't think it is necessarily attibutable to corrupt SQL table info in the backup file. It does seem related to gross size of the backup file.
[26 Sep 2005 11:40]
Michael Job
I got the same problem and it seems to be in the analyzing process! When you run it often it stops allways on a different point. I tried it with a 16 mb backup and after 6 tries it completes the analyzing and I could continiue. But on a 288 MB file it never reaches the end! So this must be an error in the administration tool! It happens on xp and on w2k3 server! So what to do? Please help!!!!! Thanks, Michael
[6 Oct 2005 14:06]
Mike Lischke
Thank you for your bug report. This issue has been committed to our source repository of that product and will be incorporated into the next release. If necessary, you can access the source repository and build the latest available version, including the bugfix, yourself. More information about accessing the source trees is available at http://www.mysql.com/doc/en/Installing_source_tree.html Additional info: I *think* that I have fixed the issue, although some of the descriptions here cannot be explained by what was wrong. Actually, two things made up this issue, one is that a backup file stored in anything else but utf-8 and containing blob data is processed as utf-8 where the analyzation stops as soon as the blob data is read. The internal utf-8 check fails in this case the analyzation (as well as restore) stop at this point. The other thing was that no error was reported in that case and the background thread simply disappeared without a sign. The fix for the first problem is: simply specify the correct encoding of the backup file. This is particularly important for files that have not been created by MA (MA always creates utf-8 encoded files). The fix for the second problem should now help you to spot the actual cause of the trouble if there is any. As a test I analyzed a 500 MB backup sql script, which went fine.
[22 Oct 2005 14:42]
Chris DeBrusk
We're still seeing the problem with version 1.1.4 of MA. We have a 1.5gig database with lots of text column types and when we do a backup from MA and then immediately try and do a restore to a different target schema it either stops part way through the analyze step and indicates that it completed successfully or it just quits with no error.