Which never ever happens.
Right after posting about this fantastic large MySQL file upload script… it stalled out around insert #2,650,000. Thus, much fiddling with file offsets and start positions ensued. So, fair warning – the script has zero upload recovery modes.
That said, it’s still significantly easier than using any of the methods I had tried earlier.
Anyhow, if your BigDump <shudder – what a name!> script fails on you, there is a way to force it to resume the upload. I was performing the upload on a GZipped file – which makes the recovery process more difficult. Nevertheless, here’s how you do it:
- Using FireFox and the FireBug plugin (you are using FireFox, right?) examine the last AJAX call
- Copy and paste the URL of the last AJAX call into a new browser tab
- Look for the GET variables in the URL named “start” and “foffset”
- This is the tedious part. You’ll need to play with those two numbers until your script restarts. When you get these numbers wrong, BigDump will be kind enough to show you the last bad MySQL line – it will almost certainly be a partial line.
- Looking at what has already been uploaded into your database, estimate whether the current MySQL error falls before or after the last entry.
- If after, crank the “foffset” number way down and re-try. You want to start ratcheting the “foffset” number up – but from a point below the last good entry. This will ensure you don’t accidentally resume the upload at a point after the last good entry.
- When you hit the correct “foffset” value, the browser window will take a while to pull up the page. When it does, you will see the standard status screen with the file transfer data resumed.
I’ve used this process exactly once to resume a transfer of a GZipped file. There’s no guarantee it will work for you, so use the above at your own risk.