| Backup import woes [message #157984] |
Sun, 18 January 2009 06:23  |
otherbird
Messages: 25
Registered: September 2006
Karma: 0
|
Junior Member |
|
|
Hi,
I had a fairly busy forum running FUDforum 2.7.6. Now I'm switching to a new hosting provider and decided to upgrade everything in sight during the migration.
So far it's not going too well, f.e. I'm still stuck with PHP 5.1.6 *grumble* and have no way to upgrade that (blame: Plesk). But FUDforum shouldn't care about that, right? 2.7.6 didn't have any problems with 5.1.6.
So I've wgetted and installed FUD about a million times, or so it feels, and the install always goes perfectly whether it's 2.7.7 or 2.7.6, but the data import fails even though I've made all the timeouts ludicrously high in php.ini. It doesn't seem to matter if I change my table prefix from the original or not, and it doesn't seem to matter which version of FUD I install. On the last attempt I had max_execution_time set to 2360 seconds and memory_limit at 256 MB, and the import script still died after about 20 minutes.
If I'm lucky I'm only locked out and unable to enter the admin page because my password isn't known to the forum db. Last time around I didn't even get that much, just totally blank pages all round.
Any bright ideas for getting around this? It all seems to run OK, in that tables are being populated up to a certain point, it's just that it dies before it can import all the data.
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Backup import woes - mystery solved, and a feature request [message #157999 is a reply to message #157988] |
Mon, 19 January 2009 00:56  |
otherbird
Messages: 25
Registered: September 2006
Karma: 0
|
Junior Member |
|
|
OK, so it's taken forever to figure it out but I'm there now.
The import is slow *anyway*, in that the page in the browser goes blank because it times out even though the process is still running in the background. This means you don't get to see error messages. Or at least, I don't. So it wasn't until I gunzipped the backup file and went through all 500 megs of it with a fine-toothed comb that I got a clue.
Two years ago, when our ME forum started up, we had problems attracting Arab contributors. One of the reasons - we thought - was that it can be physically dangerous for Arabs living in the Middle East to talk openly to Israelis. With this in mind, I tweaked the FUDforum code to allow anonymous sign-in with a username of choice, rather than 'Anonymous Coward'. (I also set up a random list of default names while I was in there, just for laughs.) For any of this to work I needed to add a new field to the fud_msg table, anon_user.
Obviously I did this manually, so the backup doesn't know anything about it; the table's created without the field, and then the backup script tries to populate it with my extra data. Kerboom. But only after an hour or so of updating nicely in silence and blankness.
I'm trying to remember now if I also touched the db when I added the 'search by message id' facility to our forum. I sincerely hope not (!) 'cos that's quite a useful feature.
It turns out that the fud.gz file isn't actually an sqlite db, it just includes one in the form of forum.db.php, which itself contains the table schema for FUDforum in sqlite3 format. This file isn't updated during a backup, so it 'knows' nothing about my db changes. Basically if I want to keep my custom field I'll need to make the same change in the newly generated db and then prevent the backup overwriting the table structure somehow. (I'll also need to do this when upgrading, natch.) The easier option would be to delete the extra field of data prior to upgrade, since obviously I changed a bunch of scripts 2 years ago too and I'd otherwise need to figure all that again to retain the existing behaviour. I'm moving toward the easier option; we don't have anonymous sign-in any more these days, so only our archives would be affected by the disappearance of anon_name.
One thing that came out of this experience (apart from 'steph don't mess with application code') is the sheer slowness of a FUD migration, without which debugging would've been relatively plain sailing; not having to wait over an hour every time to see if it worked would've been sweet! With that in mind, would it be possible to leave the geoip table out of the backup script in future FUDforum releases, or to offer the option to do so? It's relatively trivial to update geoip directly from the ip2country site, and excluding that table data should speed up both backup and migration quite considerably.
Cheers anon,
- Steph
|
|
|
|
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]