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.

Advantages:

• 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

Disadvantages

• 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, 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?

Sure.

Thanks.

I bold to mark both as parent tasks, like what happened in T112426

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?