Zásady databáze MediaWiki

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:
    • TRADITIONAL (ekvivalentní STRICT_TRANS_TABLES, STRICT_ALL_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER)
    • ONLY_FULL_GROUP_BY
• 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ě INSERT ... SELECT při použití klíče auto_increment, UPDATE ... LIMIT bez ORDER BY a použití nedeterministických funkcí jako SYSDATE(). [informací].

Změny schématu

• Všechny nové tabulky musí mít primární klíč. Pokud nelze vytvořit kandidáta na primární klíč (například pokud se všechny sloupce mohou opakovat), je třeba přidat samostatný sloupec auto_increment nebo jiné libovolné pole (v závislosti na velikosti písmen).
• Primární klíče a pole, která na ně odkazují, by měly být unsigned, aby se zvýšily [maximální hodnoty https://dev.mysql.com/doc/refman/5.6/en/integer-types.html].
• Všechny tabulky v jádru MediaWiki a rozšíření nasazená na Wikimedii a MediaWiki-bundled musí být implementovány pomocí systému abstraktních schémat a nové změny schémat v nich musí být generovány automaticky.

Kompatibilita změn schématu

Změny schématu musí poskytovat cestu pro aktualizaci ze všech verzí ze dvou verzí LTS dříve (viz phab:T259771).

Záplaty databáze

Pokud změníte schéma databáze, postupujte podle těchto pravidel:

• Aktualizování instalačního programu – Aktualizujte includes/installer a přidejte příslušný opravný soubor SQL do sql/abstractSchemaChanges/. Konvence pojmenování, pokud přidáváte pole, je patch-{table}-{field}.sql. Pokud odebíráte pole, je to patch-drop-{table}-{field}.sql. Pokud přidáváte tabulku, je to patch-{table}.sql. Podívejte se na historii odevzdání includes/installer/(MySQL|Postgres|SQLite)Updater.php, abyste našli příklady, jak se to dělá. Pokud do stejné tabulky přidáváte spoustu polí, proveďte všechny tyto změny v jednom dotazu v jednom záplatovém souboru.
• Vytvoření změny schématu volitelnou – Všechny změny schématu musí projít obdobím, kdy jsou nepovinné. Příklady použití:
  • Namísto změny formátu sloupce vytvořte nový sloupec, proveďte všechny zápisy do starého a nového sloupce (pokud existuje) a ukončete používání starého sloupce. Než budete slepě předpokládat, že ano, zkontrolujte, zda nový sloupec existuje. Podporu pro starý sloupec zrušte až poté, co bude jasné, že migrace schématu byla dokončena, a není šance, že se budeme muset vrátit ke staré verzi softwaru. Pokud se vám to nezdá proveditelné, pošlete e-mail na Wikitech-l s žádostí o radu.
  • Svou novou funkci můžete nastavit tak, aby fungovala pouze v případě, že je možnost konfigurace nastavena na true, a ve výchozím nastavení tuto možnost nastavit na false. Poté lze potvrzení, před provedením změny schématu, bezpečně nasadit. Chcete-li nasadit svou funkci do clusteru Wikimedie, založte tiket do Phabricator v příslušném projektu s tagem #schema-change. Jakmile potvrdíte, že změna byla provedena, můžete odebrat možnost konfigurace a aktivovat svou funkci.
  • Všimněte si, že to znamená, že vaše změna schématu by měla být v kódu volitelná – pro nasazení Wikimedie se očekává, že každá wiki s příslušnou databázovou tabulkou (tabulkami) bude mít změnu schématu. Pokud potřebujete různé schéma pro různé wikiny, použijte změnu pomocí rozšíření a vytvořte nové tabulky závislé na tomto rozšíření.

Mohou nastat případy, kdy pravidlo "udělejte změnu schématu jako volitelnou" bude z hlediska výkonu nebo logistiky nepřípustné. Nicméně takové změny schématu by měly být zpočátku vzácné a měly by mít výraznou diskusi na wikitech-l mailing listu. V případě, že není možné provést změnu schématu jako volitelnou, je stále důležité napsat skripty pro návrat do stavu před změnou.

• Vyhledání vstupu od správce databáze WMF – MediaWiki je nasazena na stránky Wikimedia každý týden a aplikace změn schématu na stránky založené na MySQL o velikosti Wikipedie vyžaduje značné plánování. Do ledna 2020 Jaime Crespo (jcrespo na LDAP, jynus na irc) a Manuel (Arostegui, marostegui) jsou nejlepší lidé, které lze přidat do recenzí databáze. Ve většině případů je potřeba pouze vstup do logistiky změny.
• Otestujte své změny v beta verzi - Zejména je běžnou chybou měnit indexy a definice sloupců, což by vedlo k různým plánům dotazů. Pokuste se otestovat plán generovaných dotazů pomocí nástrojů, jako je EXPLAIN; Pokud tak neučiníte, může to při škálování na produkci znamenat, že dotazy, které lokálně zaberou pouze 1 sekundu, se hromadí v produkci, když dostávají mnohem větší provoz a mají větší tabulky.

Poznámka

Od Verze 1.36 se MediaWiki zavazuje podporovat pouze aktualizace ze dvou LTS vydání před (viz phab:T259771). Aktualizace starších verzí MediaWiki budou muset být provedeny v několika krocích. To znamená, že pokud chcete aktualizovat na 1.43 z 1.34 nebo dřívější, budete muset nejprve aktualizovat svou 1.34 wiki na 1.35 (nebo 1.43) a z 1.35 (nebo 1.43) budete moci aktualizovat na 1.43.