[4057]SMF 2.0 RC2 - Upgrade issues on large memberbase

[Ensiferous]

During database changes I would encounter a "MySQL server has gone away" error whenever an ALTER TABLE query was run on forum_members. (I couldn't figure out why it went away though, I upped all the time limits) I could see that the query actually did finish so I tried clicking the continue button at no avail, finally my solution was to base64_decode the $upgradeData string in settings.php, increment the substep by one and then re-encode it.

Obviously, this is silly. I see no point in having it base64_encoded except hiding the data from the user.

The most obvious solution to me is to make the continue button work even on error, or perhaps a force continue button to make it skip the step and go to the next one, having to do all that work just to manually skip it is annoying.

[Norv]

Tracked as http://dev.simplemachines.org/mantis/view.php?id=4057, to be considered and eventually a decision taken on it.

[karlbenson]

Regarding mysql gone away error, see:

Re: MySQL has gone away / Lost connection to server during query

I don't necessarily think there is a bug in smf here.

[Ensiferous]

It is not specifically a SMF bug, but it can be fixed in SMF. I forgot about this post (only just noticed it in Mantis) and the problem was that the socket timeout was set to 60 seconds, which is default. I have a large members table so the ALTER TABLE queries were taking more than the socket timeout, which meant that PHP saw the connection as lost while the queries finished in the background.

I still recommend allowing continue even after a supposed error as there's really no reason to completely lock out users, (or making them jump through hoops) but a potential fix is adding the following two lines to the upgrade script. If the user's hosting allows this then it will remove the socket timeout issue and hopefully allow the queries to finish without PHP timing out.

Code Select Expand

ini_set('mysql.connect_timeout', -1);
ini_set('default_socket_timeout', 900);

[karlbenson]

Unfortunately most of the problematic hosts (eg Godaddy) [as I understand it] do not allow you to set mysql settings via ini_set.

[Ensiferous]

I'm not sure this will hit shared hosting too much, it will mainly hit big forums, and if they're on shared hosting then they sort of deserve it.

Anyway, adding those lines does not have any negative effects, either it's allowed or it isn't. One way you're at status quo the other way the problem is fixed.

[Joshua Dickerson]

if (!ini_get('safe_mode'))
  ... ini_set(); ... ini_set();

Godaddy has assured me they haven't disabled the functions, so it shouldn't return errors unless you're in safe_mode AFAICT. So, we should just check for safe_mode.

IMO, this should really be done prior to final so we can upgrade large forums.

[emanuele]

Here we are again.

+1 to "unlock" the continue button...just because javascript works on the first page doesn't mean it couldn't stop on the subsequent one.

[Arantor]

Consolidated to Github: https://github.com/SimpleMachines/SMF2.1/issues/1394