Page MenuHomePhabricator

create script & docs to rename wiki databases
Closed, DeclinedPublic


external storage, es1 manual
sanitarium replication rules



Event Timeline

rtimport raised the priority of this task from to Medium.Dec 18 2014, 1:50 AM
rtimport added a project: ops-core.
rtimport set Reference to rt6987.

Queue changed from todo to core-ops by springle

Subject changed from 'sciprt & docs to rename wiki databases' to 'script & docs to rename wiki databases' by jeremyb

This needs investigation. @Reedy and @Dzahn have had past input. The issues are:

  • Assess impact of renaming a production wiki db name
  • External Storage is also affected. Just db name here, or more?
  • Extension1 cluster too, as above
  • Sanitarium (db1069) and labsdb100x may need triggers & views regenerated
  • ???

Adding more issues to @Springle actionables:

  • The following databases have to update some of its rows:
    • centralauth on s7
    • anything else?
  • Check dns-based monitoring, for example puppet/manifests/role/wikimetrics.pp
  • update dblist/private.dblist for dumps and other tasks
  • some hardcoded wiki names on labs files: puppet/modules/toollabs/files/hosts
  • Recheck DNS and mediawiki config

Seeing all the potential problems and the past reversion, I would opt for creating a new wiki and migrating data instead of moving tables around.


  • Deployment can be tested in r/w mode for some days, even by the own users
  • The new wiki would be 100% functional, it is more secure that moving around files/tables
  • Easy reversion process
  • Synchronization within a shard is automatic and fully consistent


  • It will be slower
  • We could miss actions pointing to the old wiki while it is still active
  • The migration process will (while the wikis are in R/O mode) take longer
  • If the wiki is large, it may cause some extra traffic for other wikis in the same shard (to the point that it would not be practical for large wikis).
  • Could it affect negatively any common storage for changes to be reverted (SUL, caching)?

The main problem with renaming databases is that there are many of them, distributed, and independent. It is impossible to perform the rename in a consistent way- it requires read-only mode for a significant amount of time.

This doesn't include user-generated content that may be part of the page revisions, or cache-related issues in front of the application.

If wiki rename is a regular thing, maybe databases should have an arbitrary name and link those on a list on code (enwiki => db18989234).

jcrespo changed the task status from Open to Stalled.Jul 3 2015, 1:20 PM

@jcrespo, Is it possible to open this task up? I got a request recently asking about it, as it blocks T21986

@Krenair, you know my thoughts on renaming databases. That ticket has nothing to do with databases- wiki rename is a mediawiki bug and should not depend on the database physical name. The fact that wiki rename depends on database renaming is a software issue. You do not dbs nor reuse its name for security and privacy concerns.

My last recommendation was to have a enwiki => 'db18989234' solution (which I supposed we already had), feel free to reopen and work on that if we don't have.

I am also open to export and reimport data; I do not think you need me for that; but I am happy to help. Anything that does not imply reusing names is safe.

@jcrespo, okay, I think there's been a misunderstanding. What I meant by 'open this task up' is that it's currently non-public (the default for an RT import)... Can we please make it public?

Krenair changed the visibility from "WMF-NDA (Project)" to "Public (No Login Required)".Aug 12 2016, 12:01 PM
Krenair changed the edit policy from "WMF-NDA (Project)" to "All Users".


Marostegui subscribed.

I am going to close this. I don't think we'll really work on this.
First of all, renaming a database isn't possible on MySQL (there is no rename database or similar command for it). It would require creating a new database and copying all the content, and then presumably, we'd need to change lots of things on MW side.
We'd also need RO time and/or complex and risky triggers or even replication filters.

If someone feels this tasks needs to stay open, please reopen it.

Dcljr renamed this task from script & docs to rename wiki databases to create script & docs to rename wiki databases.Oct 20 2020, 11:14 PM

Took the liberty of changing the task name, to try to clarify what exactly was being discussed here. It would be nice to have a better task description, but maybe it doesn't really matter now that it's been declined?