You are here
Clint Thomson - Wed, 2011/01/05 - 22:01
When restoring a server using TKLBAM the following error is displayed when TKLBAM startes to restore a database:
mysql got a packet bigger than max_allowed_packet
Any guidance would be appreciated.
Forum:
Resolved
I used Webmin to increase the size of the max_allowed_packet value to 50M and it fixed this problem.
Thanks for sharing the solution!
I ran into the same problem.
I ran into the same problem. I have a TurnKey LAMP 11.1 server running on VMware and I have been using TKLBAM to back it up to an in-house backup server. The backups work great but when I tested the restore on a new TurnKey LAMP 11.1 vm the restore crashed with the same "Got a packet bigger than 'max_allowed_packet' bytes" error mentioned above.
If you don't want to permanently reconfigure your mysql server to do the restore you can login to your TKL server as root and run the following commands before running tklbam-restore.
# the following will set max_allowed_packet to 100MB
mysql -p -e 'SET GLOBAL max_allowed_packet=100*1024*1024;'
# the following will verify the mysql server accepted the new setting
mysql -p -e 'SELECT @@global.max_allowed_packet;'
This setting will only last until the mysql server is restarted.
Liraz, I wonder if this can be incorporated into TKLBAM mysql.py somehow so this can be done without the end user knowing about it? Thanks for looking into it.
Yes, I'm planning on fixing the mysql max packet issue
I wonder if you can 'pre screen" the data for this.
I started having this problem in Magento, now in Joomla as well. In Joomla just now it did not "break" the restore, but actually thought it was successful, even though when I looked at it, I did have a max-allowed-packets error on one file.
In Magento that would completely break the Restore process. Joomla version thought all was good.
The lesson likely is to simply increase the packets permanently but I think there is some danger there as well.
Need more information
How to extract a mysqldump from your tklbam backup
First we'll need to hack TKLBAM so it keeps around the "mysqlfs" file structure your MySQL backup is stored in. Normally this is deleted. Apply this patch to tklbam's source code:
Now restore the backup with --skip-database. After the restore your data should be in /tmp/extras/myfs, but it is encoded so we'll need to convert it back to mysqldump using this script: Save this script to the same directory where tklbam's source code lives (e.g., as fs2mysql.py). Now you can run the following command: When you get to the bottom of this, please try to isolate the issue and report back after you figure what is going on.how big is your database / mysqldump?
Same problem here
I'm getting the same error when I try and restore. It says out of memory, but no amount of RAM I throw at it helps. Did anyone ever try manually restoring the mysqldump? Did it work?
typo in command line
Urgent: restore keeps restoring my.cnf
I have an urgent issue, and cannot restore; the above suggestions don't appear to work. The max_allowed_packet value keeps getting reset to 16M, then the restore dies. I tried adding "--skip-files" to see if it would leave /etc/my.cnf alone, but I still see max_allowed_packet errors, on the same table in the same database.
Does anyone have any suggestions? Can I do restores in pieces? Can I directly access the backup data and do parts of it manually? Are there good examples of the tklbam-restore commands to do so, like restore a particular backup, from a particular tiem, skipping certain files, like /etc/my.cnf?
Have you edited it from the commandline
I would use nano to edit your my.cnf and make sure you save. Perhaps if you stop MySQL first and then edit it, save it and restart MySQL. So something like this:
You can also exclude the MySQL DB (check the TKLBAM docs for details) if you wish which will at least allow you to get your other data back, but obviously won't solve your issue.
Thanks for the suggestion,
Thanks for the suggestion, Jeremy. I ended just restoring everything but the databases with tklbam, and was lucky enough to have a pretty recent SQL dump on another system. Using the mysql commandline tools worked fine, even when tklbam continued to complain about packet size (I'd tried editing both via webmin and vim'ing my.cnf directly, then restarting).
So far, every time I've really been in a jam, tklbam hasn't worked for me. Twice I've had systems run out of disk space, and there wasn't enough room to restore, and this time it was mysql and the packet business. I guess I'll switch back to snapshots/rsync/manual mysql dumps.
Relatedly, root can no longer log into phpmyadmin, even though it works fine on the command line (mysql -u root -p). Dunno what happened there, or what tklbam may not have restored. Maybe the mysql management tables themselves are still fubar, but tklbam won't restore them, so I don't know what to do about that. I'm perfectly comfortable using the command line mysql client, but I'm concerned about data corruption.
I would love it if tklbam had some kind of extract command, where you could give it a backup id and date, then just pull specific files out, so I could nab just the mysql.* tables and restore them.
Sounds like you haven't had much joy with it...
But I do like your idea of being able to download and extract your TKLBAM backup, so I registered it as a Blueprint.
Also you should be able to reset the MySQL admin password with the firstboot script (IIRC /usr/lib/inithooks/bin/mysql.py) although as you say, it should be that same for the commandline and for phpMyAdmin (and I thought that it always is...)
Try a Debian (TKL 12) Build then Restore
With version 11 I had ongoing problems with TKLBAM and max-packets etc.. What did work very well was to get my Version 11 Magento upgraded to Magento 1.6.2 then do a TKLBAM Restore to a new Debian Machine. No hickups what soever. I even ran the restore from within WebMin.
I do find that certain issues like my.cnf can get lost in such Resores and it is good to have your own internal documentation/checklist to see that you get items back to normal.
If wrestling with max_allowed_packet use Jeremy's recomendation (but likely go bigger than this, like 300mb)
# the following will set max_allowed_packet to 100MB mysql -p -e 'SET GLOBAL max_allowed_packet=100*1024*1024;' # the following will verify the mysql server accepted the new setting mysql -p -e 'SELECT @@global.max_allowed_packet;' This setting will only last until the mysql server is restarted.
I've only done one Jump to Debian but worked like a charm without setting any packet size. Try that first.
Add new comment