Schema changes
(Redirected from Schema change)
Schema changes on a live database are hard, and they should not be done lightly. That doesn't mean that schema changes should be avoided, not at all, a good database design is essential for security and performance.
Wikimedia infrastructure
Data centres and PoPs
If you are a MediaWiki hacker, please note that the following only applies to changes that will be deployed to WMF servers. MediaWiki schema changes and standards are not covered here. But it has been agreed that update.php is avoided in our servers, as it would cause huge production issues. For that reasons, the following workflow has been created in order to attend schema change requests as fast as possible.
What is not a schema change
Workflow of a schema change
  1. Add the schema-change tag to the relevant Phabricator task the moment you propose a change that involves a change in the table design
  2. Make sure to involve as many relevant people as possible. For example, a DBA can provide constructive feedback in time if requested.
  3. Once the solution has been agreed among all developers (usually that means merged to HEAD including the schema change, but disabled on configuration), and you need to apply that to the live databases, create a separate specific task (subtask of the main issue) for the #blocked-on-schema-change, tag also #DBA project, providing the following specific information, one per batch (group of alters to be done at the same time):
    1. The ALTER TABLEs to run (usually, a link to a commit diff is the best way)
    2. Where to run those changes (specific dblist file or the complete list of wikis, in text, to apply the change to). "All wikis" or "everywhere" are not specific enough and has been the cause of outages in the past.
    3. When to run those changes (if it depends on a particular code deployment or can be done at any time)
    4. If the schema change is backwards compatible (is compatible with the current code deployed and can be performed at any time now)
    5. If the schema change has been tested already on some of the test/beta wikis. Usually, as a last test, change should be applied to testwiki first.
    6. If it involves new columns or tables, if the data should be made available on the labs replicas and/or dumps or not because they contain private or sensitive data (consult legal if you are unsure). Similar question if it involves deletion of data previously available on labs.
Example ticket:
The alter will be performed as soon as possible within the available resources. If the schema change has to be done in a particular timeframe (for example, depending on code deployment), pinging with enough time in advance is strongly suggested (an easy change can take 1 week, but a very complex one can take months).
Additional notes on scheduling
Schema changes are usually attended in the order they are requested (assuming they can be applied right away). If in doubt, request it/notify #DBAs as early as possible. SREs follow a 3-month goal schedule, so task prioritization and support needs are discussed at the end of March, June, September and December. Those teams that communicated with SREs Managers or the DBA team before the 3-month period explicitly will have a guaranteed window and dedicated time in the following 3 months. Those that communicate late in the 3-month schedule will be queued in order and susceptible of delays due to variable workload and variable available time (e.g. vacations) time.
Related tags
Wikimedia projects
These are used to request the attention of an operator and are proactively monitored by WMF DBAs:
MediaWiki projects
These are freely managed by MediaWiki developers and are not proactively monitored by WMF DBAs, as they may or not be merged, or may or may not be used by WMF wikis:
Advice on schema changes
Dangers of schema changes
For all those reasons, which can be summarized on assuring our system's reliability, schema changes should be carefully reviewed and applied by a Database administrator, or by someone at Operations/Platform engineering to avoid larger issues.
See also

This page is a part of the SRE Data Persistence technical documentation
(go here for a list of all our pages)
Last edited on 9 June 2021, at 09:47
Content is available under CC BY-SA 3.0 unless otherwise noted.
Privacy policy
Terms of Use
HomeRandomLog inSettingsDonateAbout WikitechDisclaimers