Page MenuHomePhabricator

Wikis get bigger
Closed, ResolvedPublic

Description

// Use extension1 db for large and medium wikis
'wmgEchoCluster' => array(
	'default' => false,
	'medium' => 'extension1',
	'large' => 'extension1',
	// The following wikis should be using extension1 db but started with
	// the application main database, stick with the current setting
	'mediawikiwiki' => false,
	'metawiki' => false,
	'officewiki' => false,
),

We've got a "problem", wikis get bigger. It would seem I upset a few of them earlier this week (not knowing that anything like this depended on the size lists) - https://github.com/wikimedia/operations-mediawiki-config/commit/0ee8c95ab6cd0ad764982881d775a23f3f698b97#diff-32285bf4316ad70244851ab826ae3f07 . Previously it was used as a simple metric whether we run maintenance scripts on them or not.

4 wikis moved from small to medium. Which means they changed from not using the Echo cluster, to using it. Which caused dberrors because the database and/or tables didn't exist. I've fixed that now, but maintaining this list of "exceptions" is somewhat technical debt.

Tables and database are easily created, data isn't migrated so easily. Does it need to be?

What should we doing in these cases?


Version: wmf-deployment
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56211

Details

Reference
bz56222

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 2:40 AM
bzimport set Reference to bz56222.
bzimport added a subscriber: Unknown Object (MLST).

bsitu wrote:

There is not an easy way to do it, maybe we should just switch to extension1 db for all the small wikis

I'd love to see some ideas / discussion moving forward at least to agree on a plan.

Greg?

bsitu wrote:

This has been fixed already, all wikis were migrated to extension1 db

Reedy set Security to None.