Page MenuHomePhabricator

Update.php failure when upgrading from 1.32.1 to 1.33
Open, Needs TriagePublic

Description

Via: https://www.mediawiki.org/wiki/Topic:V380yju69y3evxlc

Trying to migrate to a new install of 1.33.0 on a new server from a 1.32.1 Mysql dump
On running update.php I'm getting the above. Manually running migrateactors.php doesn't seem to do it either.

Wikimedia\Rdbms\DBQueryError from line 1587 of /var/lib/mediawiki/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?
Query: SELECT ar_id,ar_comment FROM wiki_archive WHERE ar_comment_id = '0' AND (1=1) ORDER BY ar_id LIMIT 100
Function: MigrateComments::migrate
Error: 1054 Unknown column 'ar_comment_id' in 'where clause' (localhost)

Full output of update.php in P8734

Event Timeline

TheDJ created this task.Jul 10 2019, 1:22 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 10 2019, 1:22 PM
TheDJ updated the task description. (Show Details)Jul 10 2019, 1:22 PM
TheDJ updated the task description. (Show Details)
Reedy added a subscriber: Reedy.Jul 10 2019, 3:24 PM

...comment table already exists.

			[ 'addTable', 'comment', 'patch-comment-table.sql' ],

^ So, it thinks it has already run the patch-comment-table.sql update... Which was in 1.30... So should've been added a while ago, and won't do any further modifications

But similarly, migrateComments in in 1.30 too... So why is this only surfacing in 1.33?

TheDJ added a comment.Jul 10 2019, 7:56 PM

User is using MariaDb. Another user just reported:

Similar problem with 1.32.x to 1.33 upgrade of migrateComments script, except on column 'pt_reason_id'. Checked MySQL schema and column does not exist in database. DB is MySQL Community 8.0.16. No settings in LocalSettings that seem to be migration related.

Maybe something in the big drop of the old comments fields or something ??
https://github.com/wikimedia/mediawiki/commit/0abb9338f870824e258a7a138ad07efbaa6b3894#diff-a22af9c6d1b8ab836a50a290227b98c9

I have the same problem. Using MySQL. Used to use MW 1.29, then 1.30. Switched to 1.32 two weeks ago and tried switching to 1.33 today when I ran into the same error. I don't have a column "ar_comment_id". "DESCRIBE archive;" shows a table that looks identical to the one in the Mediawiki versions 1.25 - 1.29 table shown on the Archive Table page of the Manual. "ar_comment_id" didn't come until the next version but I've never had one.

I was able to "fix" the problem and get MW 1.33 up and running by adding all of the columns it told me didn't exist. When they were created, and the update script run, they filled up with info and the update completed normally. Glad it was something as simple as need to create missing tables!

Added requested details on support desk page.

Similarly, added more details on support desk page.

Would appreciate any comments on whether @Bttfvgo's solution of manually adding is a good way forward please. Or to hold to help test

Anomie added a subscriber: Anomie.Jul 11 2019, 6:28 PM

...comment table already exists.

			[ 'addTable', 'comment', 'patch-comment-table.sql' ],

^ So, it thinks it has already run the patch-comment-table.sql update... Which was in 1.30... So should've been added a while ago, and won't do any further modifications

What most likely happened is that an error occurred when you first upgraded to MW 1.30+ in the middle of update.php applying patch-comment-table.sql, after the comment table itself was created but before it got to the point of adding ar_comment_id. Unfortunately DDL statements in MySQL aren't transactable or we'd have wrapped the whole thing in a transaction. As it is, that schema change was only partially applied.

To fix it, you might be able to just manually apply that patch file again, or you might have to determine at which point it errored out and run only the commands from there on.

In hindsight we probably should have put creation of the comment table last in that patch so update.php would re-run it in situations like this, or done each bit as a separate "change". But it's somewhat too late now. As a side note, I'm hoping that T191231 will include making the latter option much less involved.

But similarly, migrateComments in in 1.30 too... So why is this only surfacing in 1.33?

In 1.32 and earlier, migrateComments.php wouldn't run if $wgCommentTableSchemaMigrationStage was MIGRATION_OLD or MIGRATION_WRITE_BOTH, and the default was MIGRATION_OLD. In 1.33 $wgCommentTableSchemaMigrationStage was removed and all code was updated to keep only the MIGRATION_NEW code paths.

Since this has happened to two separate people, it seems likely that there are a number of other people experiencing the same problem that we don't know about.

Is there an improvement we can include in 1.33.1 that will allow people who couldn't upgrade to 1.33.0 to upgrade to 1.33.1 so we can announce "If you experienced problems with 1.33.0, please try 1.33.1 since we've addressed a problem that has affected multiple people."

Maybe migrateComments.php could check the table schema and change it if needed?

Wiki working once migrateComments issue remediated. maintenance/migrateActors.php still failing, but not preventing wiki from functioning. MigrateActors previously did a lengthy step on "Beginning migration of revision.rev_user and revision.rev_user_text to revision_actor_temp.revactor_actor". Now, I see:
c:\localpath\maintenance>php migrateactors.php
Creating actor entries for all registered users
... 1 - 1
Completed actor creation, added 0 new actor(s)
Beginning migration of revision.rev_user and revision.rev_user_text to revision_actor_temp.revactor_actor
Completed migration, updated 0 row(s) with 0 new actor(s), 0 error(s)
Beginning migration of archive.ar_user and archive.ar_user_text to archive.ar_actor
[4a72608562cbb816c1e72081] [no req] Wikimedia\Rdbms\DBQueryError from line 1587 of C:\Users\Public\Documents\website\RTWWiki\includes\libs\rdbms\database\Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?
Query: SELECT ar_id,ar_user,ar_user_text,CASE WHEN ar_user = 0 OR ar_user IS NULL THEN (SELECT actor_id FROM actor WHERE (ar_user_text = actor_name) ) ELSE (SELECT actor_id FROM actor WHERE (ar_user = actor_user) ) END AS actor_id FROM archive WHERE ar_actor = '0' AND (1=1) ORDER BY ar_id LIMIT 100
Function: MigrateActors::migrate
Error: 1054 Unknown column 'ar_actor' in 'where clause' (localhost)

Would appreciate some advice on how to patch DB table structure to ensure future reliability.

Thanks,
Jason

maintenance/migrateActors.php running after following SQL commands executed against MySQL DB:

ALTER TABLE archive ADD COLUMN ar_actor BIGINT NOT NULL;
ALTER TABLE image ADD COLUMN img_actor BIGINT NOT NULL;

Current pace looks like it will take a long time for update to run, so will report back in a day or two.

Maybe migrateComments.php could check the table schema and change it if needed?

No, that would not at all be appropriate.

We could potentially change the test for whether the patch file needs to be applied to test for something done at the end rather than the start, or we could split the file into several smaller files that would each have their own test.

Error: 1054 Unknown column 'ar_actor' in 'where clause' (localhost)

Seems like the same issue with respect to patch-actor-table.sql. The fix would be the same as described above.

MadX added a subscriber: MadX.Jul 30 2019, 12:20 AM

Hi,

Could I just confirm what the current advice is please?

Is this something that will be solved in the next update automatically, or will it require the manual intervention?

Please compare with Jagatronic's comments on the original support desk page - I'm not sure I understand that

Change 530374 had a related patch set uploaded (by Reedy; owner: Reedy):
[mediawiki/core@master] Split down patch-comment-table.sql

https://gerrit.wikimedia.org/r/530374