MediaWiki database policy/ja

このページでは、公式の MediaWiki のデータベース方針の規範について説明します. これは、RFC T220056 に従って TechCom の RFC プロセスを介して2019年12月に承認されました.



データベースのクエリ

 * MediaWiki から SQL クエリを送信するすべての新しいコードは MariaDB/MySQL の厳格モード (RFC T112637 による) の下でいかなる警告も生成しないようにする必要があります.
 * WMF は MariaDB/MySQL の厳格モード (T108255) を有効にする予定です. これは MySQL 5.7 でとにかく既定になる予定です. それ以前は、コードに警告が出ないようにする必要があります.
 * データベースを操作するコードは、以下の MySQL SQL モードと互換性がある必要があります:
 * (以下と同等: )
 * データベースのコードは、MediaWiki インストール要件のデータベース サーバーに列挙された古いバージョンと互換性がある必要があります. ただし、サポートされていないリリースにのみ適用されるものよりも、サポートされている最新のバージョン (またはその既定値や広く推奨されている既定値) にのみ適用されるような性能向上は優先すべきです.
 * レプリケーション環境では、非決定論的クエリや binlog 用の安全ではないステートメントの使用は避けるべきです. 後者は、「[Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT」というテキストの警告で検出されます.  これには、自動インクリメント キーを使用して   を実行する場合、  がない   を実行する場合、および   などの決定論的ではない関数を使用する場合が含まれます.  詳細情報はこちら.
 * レプリケーション環境では、非決定論的クエリや binlog 用の安全ではないステートメントの使用は避けるべきです. 後者は、「[Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT」というテキストの警告で検出されます.  これには、自動インクリメント キーを使用して   を実行する場合、  がない   を実行する場合、および   などの決定論的ではない関数を使用する場合が含まれます.  詳細情報はこちら.



スキーマの変更

 * すべての新しいテーブルには主キーが必要です. 主キー候補を作成できなかった場合 (例: すべての列が繰り返される可能性がある場合) は、別の auto_increment 列またはその他の任意のフィールド (ケースによって異なります) を追加する必要があります.
 * 主キーおよびそれを参照するフィールドは、最大値を増やすために符号なしである必要があります.
 * MediaWiki コア、ウィキメディアで展開された拡張機能、および MediaWiki に同梱された拡張機能のすべてのテーブルは、抽象スキーマ システムを使用して実装する必要があり、それらの新しいスキーマ変更は自動的に生成する必要があります.



スキーマ変更の互換性
データベース スキーマの変更は、2 つ前の LTS リリース以降のすべてのリリースからアップグレードするための経路を提供する必要があります (T259771 参照).



データベースのパッチ
データベース スキーマを変更する場合は、以下の規則に従ってください:


 * インストーラーを更新 – 更新には  を含め、  に適切な SQL パッチ ファイルを追加します.  フィールドを追加する場合の命名規則は、  です.  フィールドを除去する場合は、  です.  テーブルを追加する場合は、  です.  これらの操作を実行する方法の例は、  のコミット履歴を参照してください.  同じテーブルにいくつかのフィールドを追加する場合は、すべての変更を 1 つのクエリで 1 つのパッチ ファイルにまとめます.
 * スキーマ変更を省略可能にする – すべてのスキーマ変更は省略可能にする必要があります. 例:
 * 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. 新しいカラムが存在するか確認するようにし、単に存在すると仮定しないようにします. スキーマの移行が完了し、古いバージョンのソフトウェアにロールバックする必要がないことが明確になったら、古いカラムのサポートを終了できます.  これが実現不可能な場合は、Wikitech-l にメールを送信してアドバイスを求めるようにしてください.
 * 新しい機能を、構成オプションに true が設定されている場合にのみ動作するように設定し、既定ではオプションに false を設定します. その後、スキーマの変更が行われる前に、コミットを安全に展開できます.  ウィキメディア クラスターに機能を展開するには、関連プロジェクトで Phabricator のチケットを作成し、  タグを追加してください.  変更が行われたことを確認した後、構成オプションを除去して機能を有効にできます.
 * 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. 異なるウィキで異なるスキーマが必要な場合は、拡張機能を使用して変更を適用し、その拡張機能に依存する新しいテーブルを作成するようにしてください.

「スキーマの変更を省略可能にする」規則は、パフォーマンスまたはロジスティクスの観点から禁止される場合があります. ただし、そのようなスキーマの変更はそもそもまれであるため、wikitech-l メーリング リストで目立つようにして議論する必要があります. スキーマの変更を省略可能にすることが不可能な場合でも、変更前の状態にロールバックするスクリプトを作成することが重要です.


 * 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.

注記
