Unable to upgrade wiki family of 2 wikis from 1.32.0 to 1.33.0 due to DB structure being different than the upgrade.php expects
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Jukeboksi
	Sep 27 2019, 10:27 AM

Description

I am trying to upgrade a wiki family of 2 wikis from 1.32.0 to 1.33: https://develop.consumerium.org/wiki/ and https://test.consumerium.org/wiki/.

Duesen suggested to me to make a ticket of this issue.

The development wiki is the "important" wiki and the test wiki is not of high significance.

The test wiki uses the following shared tables from the development wiki:

$wgSharedDB = 'mediawiki_developwiki';
$wgSharedTables[] = 'ipblocks';
$wgSharedTables[] = 'user_groups';
$wgSharedTables[] = 'interwiki';

Before attempting to upgrade, I commented the above lines out from the LocalSettings.php of the test wiki and passed the server name by exporting $SERVER_NAME

Upgrade of the main wiki (development) runs fine, but trying to upgrade the test wiki it complains of finding a different database structure, than the one it expects.

I think I have narrowed it down that the problem arises when the updater runs 'php maintenance/migrateActors.php' and here is the error message produced by migrateActors.php:

$ php maintenance/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
User name "Jukeboksi" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

... rev_id=62
Completed migration, updated 0 row(s) with 0 new actor(s), 41 error(s)
Beginning migration of archive.ar_user and archive.ar_user_text to archive.ar_actor
User name "Jukeboksi" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

... ar_id=1
Completed migration, updated 0 row(s) with 0 new actor(s), 1 error(s)
Beginning migration of ipblocks.ipb_by and ipblocks.ipb_by_text to ipblocks.ipb_by_actor
[729843f9b05172a7b38a2ff9] [no req] Wikimedia\Rdbms\DBQueryError from line 1587 of /var/www/consumerium.org/develop/mw-1.33/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 ipb_id,ipb_by,ipb_by_text,CASE WHEN ipb_by = 0 OR ipb_by IS NULL THEN (SELECT actor_id FROM actor WHERE (ipb_by_text = actor_name) ) ELSE (SELECT actor_id FROM actor WHERE (ipb_by = actor_user) ) END AS actor_id FROM ipblocks WHERE ipb_by_actor = '0' AND (1=1) ORDER BY ipb_id LIMIT 100
Function: MigrateActors::migrate
Error: 1054 Unknown column 'ipb_by_actor' in 'where clause' (localhost)

Backtrace:
#0 /var/www/consumerium.org/develop/mw-1.33/includes/libs/rdbms/database/Database.php(1556): Wikimedia\Rdbms\Database->getQueryExceptionAndLog(string, integer, string, string)
#1 /var/www/consumerium.org/develop/mw-1.33/includes/libs/rdbms/database/Database.php(1274): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean)
#2 /var/www/consumerium.org/develop/mw-1.33/includes/libs/rdbms/database/Database.php(1784): Wikimedia\Rdbms\Database->query(string, string)
#3 /var/www/consumerium.org/develop/mw-1.33/maintenance/includes/MigrateActors.php(295): Wikimedia\Rdbms\Database->select(string, array, array, string, array)
#4 /var/www/consumerium.org/develop/mw-1.33/maintenance/includes/MigrateActors.php(115): MigrateActors->migrate(string, array, string, string, string)
#5 /var/www/consumerium.org/develop/mw-1.33/maintenance/Maintenance.php(1719): MigrateActors->doDBUpdates()
#6 /var/www/consumerium.org/develop/mw-1.33/maintenance/doMaintenance.php(96): LoggedUpdateMaintenance->execute()
#7 /var/www/consumerium.org/develop/mw-1.33/maintenance/migrateActors.php(27): require_once(string)
#8 {main}

Jukeboksi is my username on both of the wikis. The test wiki has always shared these tables from the main wiki.

This SQL is so complicated that I understand it only partially, and it seems that the situation is due to some error on my part in a previous upgrade of the wiki family. It is quite possible that I unwittingly broke the wiki family with a previous upgrade (to 1.32.0), as I did not realize right away to comment out the shared tables.

I uploaded the database structures of the development wiki and the test wiki here.

Let me know if any other information would be useful and I will try to deliver ASAP. Cheers.

development-wiki-database-schema-1.32.0-2019-09-27.sql86 KBDownload

test-wiki-database-schema-1.32.0-2019-09-27.sql61 KBDownload

Related Objects

Mentioned Here: T227662: Update.php failure when upgrading from 1.32.1 to 1.33

Event Timeline

Jukeboksi created this task.Sep 27 2019, 10:27 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 27 2019, 10:27 AM

Aklapper added a project: MediaWiki-Maintenance-system.Sep 27 2019, 10:49 AM

pinging @Anomie to have a look

It is quite possible that I unwittingly broke the wiki family with a previous upgrade (to 1.32.0), as I did not realize right away to comment out the shared tables.

That's the most likely cause of the problem here, yes. This task is probably a duplicate of T227662: Update.php failure when upgrading from 1.32.1 to 1.33.

Thanks for including those schema files. I see from them that patch-comment-table.sql seems to have applied completely, but patch-actor-table.sql seems to have failed at some point in the past on your test wiki without executing the following changes

ALTER TABLE /*_*/ipblocks
  ADD COLUMN ipb_by_actor bigint unsigned NOT NULL DEFAULT 0 AFTER ipb_by_text;

ALTER TABLE /*_*/image
  ALTER COLUMN img_user_text SET DEFAULT '',
  ADD COLUMN img_actor bigint unsigned NOT NULL DEFAULT 0 AFTER img_user_text;
CREATE INDEX /*i*/img_actor_timestamp ON /*_*/image (img_actor, img_timestamp);

ALTER TABLE /*_*/oldimage
  ALTER COLUMN oi_user_text SET DEFAULT '',
  ADD COLUMN oi_actor bigint unsigned NOT NULL DEFAULT 0 AFTER oi_user_text;
CREATE INDEX /*i*/oi_actor_timestamp ON /*_*/oldimage (oi_actor,oi_timestamp);

ALTER TABLE /*_*/filearchive
  ALTER COLUMN fa_user_text SET DEFAULT '',
  ADD COLUMN fa_actor bigint unsigned NOT NULL DEFAULT 0 AFTER fa_user_text;
CREATE INDEX /*i*/fa_actor_timestamp ON /*_*/filearchive (fa_actor,fa_timestamp);

ALTER TABLE /*_*/recentchanges
  ALTER COLUMN rc_user_text SET DEFAULT '',
  ADD COLUMN rc_actor bigint unsigned NOT NULL DEFAULT 0 AFTER rc_user_text;
CREATE INDEX /*i*/rc_ns_actor ON /*_*/recentchanges (rc_namespace, rc_actor);
CREATE INDEX /*i*/rc_actor ON /*_*/recentchanges (rc_actor, rc_timestamp);

ALTER TABLE /*_*/logging
  ADD COLUMN log_actor bigint unsigned NOT NULL DEFAULT 0 AFTER log_user_text;
CREATE INDEX /*i*/actor_time ON /*_*/logging (log_actor, log_timestamp);
CREATE INDEX /*i*/log_actor_type_time ON /*_*/logging (log_actor, log_type, log_timestamp);

If you execute those manually, your wiki should be in a working state to be able to run update.php.

Big thank you to everyone that has helped.

After running the above SQL into the mediawiki_testwiki -database and disabling the shared tables (ipblocks, user_groups and interwiki) the updater finished, but made a mess of the wiki contents e.g. Main Page missing, other pages having missing histories.

Then I thought of rolling back to 1.32, copying the above 3 tables from mediawiki_developwiki to the mediawiki_testwiki and running the upgrade again, but it left Main Page missing.

SOLVED:

Then I rolled back and tried again this time also copying the 'user'-table too and after that upgrade and re-enabling the shared tables, the testwiki seems now to be in an ok state (MW 1.33 and articles showing up as expected).

Question:

Should I share also the user-table from the main wiki to the testwiki and give the testwiki user rights to update it. The thinking behind this is that if someone would create an account on the testwiki, then the shared login would break (?)

Grants to the mediawiki_testwiki@localhost are currently as follows:

MariaDB [mediawiki_testwiki]> show grants for mediawiki_testwiki@localhost;
+---------------------------------------------------------------------------------------------------------------------------+

Grants for mediawiki_testwiki@localhost

+---------------------------------------------------------------------------------------------------------------------------+

GRANT USAGE ON *.* TO 'mediawiki_testwiki'@'localhost' IDENTIFIED BY PASSWORD 'PASSWORDHASHREDACTEDFORSANITY'

GRANT ALL PRIVILEGES ON mediawiki_testwiki.* TO 'mediawiki_testwiki'@'localhost'

GRANT SELECT ON mediawiki_developwiki.interwiki TO 'mediawiki_testwiki'@'localhost'

GRANT SELECT, UPDATE ON mediawiki_developwiki.user TO 'mediawiki_testwiki'@'localhost'

GRANT SELECT ON mediawiki_developwiki.ipblocks TO 'mediawiki_testwiki'@'localhost'

GRANT SELECT, UPDATE ON mediawiki_developwiki.user_properties TO 'mediawiki_testwiki'@'localhost'

GRANT SELECT ON mediawiki_developwiki.user_groups TO 'mediawiki_testwiki'@'localhost'

+---------------------------------------------------------------------------------------------------------------------------+
7 rows in set (0.00 sec)

Looking at the grants makes me think that the idea was to share also tables user and user_properties, but I have not done that.

Should I share those tables too, to stop things from breaking if anyone were ever to make an account on the testwiki, instead of using the one from the developwiki?

Big thanks @Anomie for solving the issue.

• CCicalese_WMF moved this task from Discussing to Done on the Platform Team Workboards (Clinic Duty Team) board.Oct 29 2019, 4:53 PM

Aklapper removed a subscriber: Anomie.Oct 16 2020, 5:38 PM

	F30483466: development-wiki-database-schema-1.32.0-2019-09-27.sql
	Sep 27 2019, 10:27 AM

	F30483465: test-wiki-database-schema-1.32.0-2019-09-27.sql
	Sep 27 2019, 10:27 AM

Unable to upgrade wiki family of 2 wikis from 1.32.0 to 1.33.0 due to DB structure being different than the upgrade.php expectsClosed, ResolvedPublicActions