Wish me luck

[Steve Machol]

Glad you got it working.

[Mark.B]

Glad you got it working.

Thanks.

Certainly my most fraught upgrade yet. Closest I've ever come to putting to good use my meticulous backups.

[stingray27]

I thought the new upgrade system was designed so that if these big changes timed out the page, all you had to do was to refresh the browser page and it would carry on ?

[Mark.B]

I thought the new upgrade system was designed so that if these big changes timed out the page, all you had to do was to refresh the browser page and it would carry on ?

I had heard that too, but mine was having none of it.

[Joe Gronlund]

I use those settings in my config.php also. Glad you got it sorted out.

[Colin F]

The upgrade script now tries to rerun such steps, but it's not really aimed at big boards, but rather at places where an error in the middle of the script makes it halt.

[Mark.B]

Not to worry. All is now well and I'm glad I persevered.

I had a feeling it was going to be difficult this time as soon as I saw all the changes to the POST table.

The advice given in this thread and also on the page I linked to meant I got through ok by running the POST and THREAD table queries in putty instead. Not for beginners, but then if you are upgrading a board that's big enough for this to be a problem, then you aren't a beginner!

My problem is that I ought to be on a dedicated server really. I can't afford one, but in any event my host is so good that my shared server performs almost as well (on a day to day basis at least) as a dedicated one...loads of less than 0.5 are the norm. As my number of active members at any one time rarely exceeds 50 I am just about ok, but I have been lucky in that respect...

Anyway, great job again guys, the upgrade process is actually flawless, this was entirely a server issue. I hope I haven't put anyone with smaller boards off upgrading - the problems I had will NOT happen to you, and there is no problem whatsoever with the vB upgrade scripts. Thought I ought to clarify that for anyone reading.

[dreamer81]

I think it's very lousy that this can happen.
I thought vbulletin developers made intelligent code, instead of what i call junk-code.

What is the strategy with this??

[Matthew Gordon]

It's not a code problem, it's a PHP limitation.

[dreamer81]

It's not a code problem, it's a PHP limitation.

its always a code problem. The coders are using php.. and therefor should implement their code with the limitations that php offer.

[Kier]

its always a code problem. The coders are using php.. and therefor should implement their code with the limitations that php offer.

Unfortunately that is simply impossible. If you are going to run an ALTER query on a post table that contains a million posts it is going to cause a problem for PHP unless the time limit for execution is extended. There simply is no way to make the ALTER query run faster.

[Floris]

I have helped quite a few vB customers with their big upgrades, some went without a glitch, some took almost a week. I have learned to have a proper development server at my house (localhost) where I have enough hard drive space, root access, and enough RAM. Together it helps to dump the .sql dump to my localhost and restore it there. Use the same MySQL and PHP as the customer is using and run the vB upgrade without the internet closing ssh2 and things like that. There have been times I have had 3gb dumps that I let run and just went to bed and woke up and it had finished an hour later - taking 5 or 6 hours. Then I dump again and restore on the live site. The biggest problems I have found were the forums who have a lot of posts (millions) and who have a lot of attachments (over 1gb).

[sabret00the]

what we need is the ability to run upgrades via SSH

[Floris]

what we need is the ability to run upgrades via SSH

I second that

[Kier]

what we need is the ability to run upgrades via SSH

It's something we are seriously looking into.