Last modified: 2014-06-20 21:01:44 UTC
Using update.php on a wiki with replication has the potential of hitting a race condition where the master has finished an update operation, but the slave(s) hasn't; and then a query hits the slave but fails due to missing columns etc. This can be shown more clearly by broken replication: [20:37:15] <jcl> I'm having trouble upgrading MW from 1.20.8 to 1.23: during the update.php script, I'm getting a db query error: "select page_namespace, etc. from page where ..." from the function Title::newFromID is erroring with "Unknown column page_content_model" in 'field list' -- I've seen a few similar results from googling but nothing I've done so far has helped. Any suggestions? <INSERT DEBUGGING> [20:59:59] <jcl> well there you go, the slave threads aren't running, gr... In a lot of cases, update.php may not be the correct tool for the job for updating these wikis, but it happens. Maybe it should bail if more than 1 server. Or maybe more sensibly, queries to the slaves should be disabled. To go along with this, some wfWaitForSlave() type calls should probably be added between updater operations too.
Change 141049 had a related patch set uploaded by Reedy: Add wfWaitForSlaves() call in DatabaseUpdater::runUpdates() https://gerrit.wikimedia.org/r/141049
21:04:21] <bawolff> I think update.php is written with the assumption that anyone using it has a db small enough to not need replication ^ In that case, it's see bug 1
