MediaWiki database policy/cs

Tato stránka popisuje oficiální zásady databáze pro kód MediaWiki. Byly schváleny v prosinci 2019 prostřednictvím TechCom RFC procesu na RFC T220056.



Požadavky na databázi

 * Žádný nový kód, který odesílá SQL dotazy z MediaWiki, nesmí generovat žádné varování v přísném režimu MariaDB/MySQL (na RFC T112637).
 * WMF povolí přísný režim MariaDB/MySQL (T108255), který bude stejně výchozí v MySQL 5.7. Před tím musí být kód bez varování.
 * Kód, který se dotýká databáze, musí být kompatibilní s následujícími režimy MySQL SQL:
 * (ekvivalentní )
 * Kód databáze musí být kompatibilní se staršími verzemi databází, jak je uvedeno v Instalačních požadavcích MediaWiki pro databázový server. Vylepšení výkonu, která by se týkala pouze nejnovějších podporovaných verzí (nebo jejich výchozích nebo široce doporučovaných výchozích hodnot), by však měla být upřednostňována před těmi, která se vztahují pouze na nepodporovaná vydání.
 * Je třeba se vyhnout nedeterministickým dotazům a nebezpečným příkazům pro binlog, protože by vracely/zapisovaly jiné výsledky v prostředí replikace. Posledně jmenované lze detekovat jako varování s textem "[Warning] Nebezpečný příkaz zapsaný do binárního protokolu pomocí formátu příkazu od BINLOG_FORMAT = STATEMENT". (Unsafe statement written to the binary log using statement format since) Patří mezi ně  při použití klíče auto_increment,   bez   a použití nedeterministických funkcí jako  . [|Více informací].
 * Je třeba se vyhnout nedeterministickým dotazům a nebezpečným příkazům pro binlog, protože by vracely/zapisovaly jiné výsledky v prostředí replikace. Posledně jmenované lze detekovat jako varování s textem "[Warning] Nebezpečný příkaz zapsaný do binárního protokolu pomocí formátu příkazu od BINLOG_FORMAT = STATEMENT". (Unsafe statement written to the binary log using statement format since) Patří mezi ně  při použití klíče auto_increment,   bez   a použití nedeterministických funkcí jako  . [|Více informací].



Změny schématu

 * All new tables must have a primary key. When a candidate for primary key could not be created (for example, if all columns can be repeated), a separate auto_increment column, or other arbitrary field (depending on the case), must be added.
 * Primary keys, and fields that reference them, should be unsigned, in order to increase the maximum values.
 * All tables in MediaWiki core, and Wikimedia-deployed and MediaWiki-bundled extensions must be implemented using the abstract schema system, and new schema changes to them must be generated automatically.

Schema change compatibility
Schema changes must provide a path for upgrading from all releases from two LTS releases before onwards (see T259771).

Database patches
If you change the database schema, follow these rules:


 * Update the installer – Update  and add an appropriate SQL patch file to  . The naming convention, if you're adding a field, is  . If you're removing a field, it is  . If you're adding a table, it is  . Look at the commit history of   to find examples of how it is done. If you're adding a bunch of fields to the same table, make all those changes in one query in one patch file.
 * Make your schema change optional – All schema changes must go through a period of being optional. Some examples:
 * Instead of changing the format of a column, create a new column, make all writes happen to the old and new column (if it exists), and deprecate use of the old column. Check if the new column exists before blindly assuming that it does. Only eliminate support for the old column after it is clear the schema migration has completed and there's no chance that we'll need to roll back to the old version of the software. If this doesn't seem feasible, send mail to Wikitech-l asking for advice.
 * You could set your new feature to only work if a config option is set to true, and set the option to false by default. Then the commit can be safely deployed before the schema change is made. To deploy your feature to the Wikimedia cluster, file a ticket in Phabricator in the relevant project with the  tag. Once you've confirmed the change has been made, you can remove the config option to enable your feature.
 * Note that this means your schema change should be optional in code - for wikimedia deployments, it is expected that every wiki with the relevant database table(s) will have the schema change applied to them. If you need different schema for different wikis, then apply the change using an extension and creating new tables dependent on that extension.

There might be cases where the "make your schema change optional" rule will be prohibitive from a performance or logistics perspective. However, schema changes like that should be rare to begin with, and should have prominent discussion on the wikitech-l mailing list. In the case where it is impossible to make your schema change optional, it is still critical to write scripts to roll back to the pre-change state.


 * Search for input from a WMF Database Administrator – MediaWiki is deployed to Wikimedia websites every week, and it takes considerable planning to apply schema changes to MySQL-based sites the size of Wikipedia. Jaime Crespo (jcrespo on LDAP, jynus on irc) and Manuel (Arostegui, marostegui) are the best people to add to database reviews. In most cases, input is just needed on the logistics of the change.
 * Test your changes on Beta - in particular, it is a common mistake to change indexes and column definitions that would result in different query plans. Try to test the generated queries' plan with tools such as EXPLAIN; not doing so could mean that, when scaled to production, queries that only take 1 second locally, they pileup on production when they receive much more traffic and have larger tables.