SMF Support > SMF 1.1.x Support

upgrading from 1.1.15 to 2..0.17 Ubuntu 18.04

(1/2) > >>

SteveZand:
Here are some tips for people like me who still need to upgrade their old version of the board.

I picked up my server from the datacenter, since I also had to upgrade Ubuntu.

After upgrading to Ubuntu version 18.04 LTS, PHP 7.2.24, MySQL 5.7.29

I tried to run the old version of smf , which off course gave lot of errors.

So i tried to run the smf installer 2.0.17 which started find, but suddenly midway halted with an unclear error-code, 1292 i believe. I couldn't find any solution online.

So I tried smf installer 2.0.15 which also didn't succeed,  I got some MySQL error.

So I thought instead of trying to install an older version of PHP on the server, lets run smf from xampp-win32-5.6.36-0-VC11 and let smf connect to the server MySQL database instead of the xampp MariaDB database which is also incompatible with the Smf upgrade script.

Than again I got some errors, which where cause by the strict Sql mode of MySql.

One of the errors was:

Incorrect date value: '0000-00-00' for column 'eventDate' at row 1

These SQL modes are standerd configured on Ubuntu MySQL


--- Code: ---ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
--- End code ---

You should at least disable these two:


--- Code: ----ONLY_FULL_GROUP_BY
-STRICT_TRANS_TABLES

--- End code ---

More info about SQL modes here [nofollow]


After trying to upgrade for the umpteenth time and the script again halted with an unclear error-code, with no warning that I was still busy.
I tried to DROP the smf database for re-importing the backup.

Than I noticed that the database wasn't immediately dropped, so i used in MySQL to see what process was locking the smf database,

I saw that the upgrade script query to alter a table was still running.


--- Code: ---
SHOW FULL PROCESSLIST;

1660 | steve | 192.168.1.10:12246 | forum | Query   |  405 | copy to tmp table | ALTER TABLE smf_messages
                                 CHANGE COLUMN subject subject varchar(255) NOT NULL default '' |

1660 = process id
405 = number of seconds the script is running


--- End code ---

Several of these alter table queries took more than 4 minutes each to complete, because I have a pretty large board.

No warning at all from the upgrade page only a small error-code, which make you falsely think, that the upgrade halted with an error-code.

So what I did the next time I run the upgrade script, every-time it seemed like the script halted with an error-code I run


--- Code: ---SHOW FULL PROCESSLIST;

--- End code ---

To check if the query was finished. when it was I did a refresh of the page and the script continued.

Finally after many hours of frustration I was able to upgrade the board to version 2.0.17.  :)

shawnb61:
Helpful post for very large boards.  I see two major takeaways:
 - Set the sql mode to '' before upgrade.  An empty string should be fine. 
 - On large boards, some queries can run for several minutes.  Any time the server disappears for > 30 seconds, your browser gives you a warning.  Your browser doesn't know if it died or not, just that it hasn't heard back in 30 seconds... 

Under most circumstances, just waiting is the right course of action.  But how do you know for sure?  Your suggestion of querying the processes is a good way to tell whether it died or whether it's still working on a long-running query. 

SteveZand:

--- Quote from: shawnb61 on April 12, 2020, 10:48:59 PM --- - On large boards, some queries can run for several minutes.  Any time the server disappears for > 30 seconds, your browser gives you a warning.  Your browser doesn't know if it died or not, just that it hasn't heard back in 30 seconds... 

--- End quote ---

The thing is that it isn't your browser which times out. It's the script itself which gives you a unclear error-code, 1292, something like this:


--- Code: ---Fixing guest voter tallys on existing polls...done

   Error!
          1292

--- End code ---

And than nothing happens for minutes.

Clicking the "Continue" button also doesn't work!

Which makes you assume that the script halted with some script error! And that's very confusing.

The script only continues as the MySQL query is finished and you refreshes the page (F5), not intuitive at all.


I think that for many people with a large bord a commanline upgrade tool would be a much better option then a web-script.


But nevertheless I know your doing a lot of hard work and I like many really appreciate this!  :)

shawnb61:
The 1292 is fallout from the sql_mode being too strict ("incorrect date value"), and was a real failure.  It really stopped. 

You can, in fact, run the upgrade via the command line.  It has some quirks, but it works.  (For some things CLI is better, for others, the browser is better.)

The message that is confusing is the "Server has not responded for 30 seconds" message (pic below).  When you see this, all the browser knows is that it hasn't heard back from the server.  This could be an outright failure or a query just taking too long.  It almost always makes sense just to give it more time when you see these - for large forums, a lot more time.   THESE errors are much more clear via CLI - a failure would stop outright, whereas a long-running query would still be running.  Via browser, your suggestion would be helpful here - check the processes before giving up.

SteveZand:

--- Quote from: shawnb61 on April 13, 2020, 07:02:13 PM ---You can, in fact, run the upgrade via the command line.  It has some quirks, but it works.

--- End quote ---

How? And what are the quirks? :-)

Navigation

[0] Message Index

[#] Next page

Go to full version