Upgrade 4.22 to 5.5.2 - Zero posts, Zero topics.

[ayjayef]

Going around in circles for a week and really need a little direction please.


Original live server: VB 4.22, IIS v7, PHP 5.3.9, MySQL 5.1.59, Win2012R2
Threads: 38,000 - Posts: 470,000 - Members 52,000

* Cloned the existing site to a new (virtual, off-line) server
* Confirmed that 4.2.2 was working properly

Disabled VBSEO

* Forum root is now: /forum.php
* Sub forums are: /forumdisplay.php?f=41
* Posts are: /showthread.php?t=51297

Everything appears to be working fine in the clone without VBSEO.
* backed up the forum to a 1Gb file.


Built a new server: VB 5.5.2, IIS v10, PHP 7.3.1, MySQL 8.0.16, Win2019

* vb_test.php -- passes okay.
* new empty website created
* moved VB5 UPLOAD, edited the two config.php files.
* imported the VB 4 backup into MySQL (can see the 470,00 posts in the database)
* /install/upgrade.php - completed without error, script cleaned-up the tables that wouldn't be used, upgrade detail logs looked fine.


VB 5.52 opens with 0 posts.

Just shows: Main Forum, zero topics, zero posts.

Can login to admincp fine.
Have run maintenance/general update tools (rebuild search index / rebuild topic / rebuild Forum Info etc etc)
...and each task runs near instantly like you could expect on a forum with 1 user and zero posts.

I have repeated the process many times with the same result.
I can browse the database in MySQLworkbench and the post table has 461,000 rows

I've read so many VB4-VB5 forum posts my head is spinning, lots of similar sounding problems that 'aint this.


Am I missing a step somewhere?

Thanks in anticipation,

Andy

[ayjayef]

hmmm... out of frustration I just thought of something I hadn't tried.

I just did a "repair/optimise tables" on the VB4.2.2 before exporting the database.
Imported it into the new server MySQL and started yet another upgrade.

This one is going really slow at "step 145 of 166" which I haven't seen before so it might actually be doing something different or maybe it just hung

I'll post back if this simple little change was enough to fix the problem when it finishes.

[In Omnibus]

In most cases you can simply continue the upgrade by refreshing the page.

If it continues to stop during the upgrade you may find upgrading to 4.2.5 first and then to 5.5.3 helpful as it will require fewer steps.

[ayjayef]

Thanks for the tips In Omnibus.

The real upgrade didn't ever stop, it just took an hour or more to complete. The upgrade screen says it might take a long time but if multiple upgrades take 15 minutes then you have nothing to gauge how long it really should be for a 470,000 post forum.

The forum was stuck on 4.2.2 as it wouldn't upgrade to other 4.x versions, never found the reason but it had a lot of manual bug fixes and security patches over the years and while the version said 4.2.2. it was far more mongrel than that.

So, the punchline to this story is:

1: "repair/optimise tables" on the original forum before the export
2: Upgrade really should take a long time on big forum
3: The "upgrade details" viewed at the end will have way more references to upgrading in steps eg: 4.2.3 Alpha 1, 4.2.3 Beta 1... etc etc.

I can't believe I wasted more than a week before trying a repair. This was just the first step test-run. Need to sort the templates and work out how to do that neatly in an upgrade process (but that's a question for another thread after playing). I can sleep well tonight knowing we are a little closer.

Call this thread done. Hopefully it saves someone else a headache one day.

[Mark.B]

Glad you sorted it, I would just add that other users should not attempt a repair on the database routinely before an upgrade, not at any other time. It should only be done if specific symptoms present themselves.
Database repairs run unnecessarily can cause permanent damage to tables.

[ayjayef]

Thanks Mark.

should not attempt a repair on the database routinely before an upgrade, not at any other time.

Database repairs run unnecessarily can cause permanent damage to tables.

Wow, first I knew that. We have had to do many over the years, typically to fix searchcore and a couple of other tables that corrupt after a dirty shutdown. I had no idea it could cause a problem too.

Good warning.

[Mark.B]

Thanks Mark.



Wow, first I knew that. We have had to do many over the years, typically to fix searchcore and a couple of other tables that corrupt after a dirty shutdown. I had no idea it could cause a problem too.

Good warning.

Obviously if you have a crashed table like that, then yes you should run a repair on it.

The key point is that table repairs should not be considered 'routine maintenance'.