external storage, es1 manual
sanitarium replication rules
- 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).
@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.