Page MenuHomePhabricator

script & docs to rename wiki databases
Open, Stalled, MediumPublic


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.
Springle created this task.Mar 7 2014, 1:36 PM

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

Springle reassigned this task from Springle to jcrespo.May 18 2015, 4:10 AM
Springle set Security to None.

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
  • ???
jcrespo added a comment.EditedMay 25 2015, 3:16 PM

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 moved this task from Triage to Blocked external/Not db team on the DBA board.
jcrespo changed the task status from Open to Stalled.Jul 3 2015, 1:20 PM
Restricted Application added a subscriber: Matanya. · View Herald TranscriptJul 3 2015, 1:20 PM
jcrespo removed jcrespo as the assignee of this task.May 2 2016, 9:56 AM
jcrespo added a subscriber: jcrespo.

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

jcrespo added a comment.EditedAug 11 2016, 7:23 AM

@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".