MediaWiki のデータベースの方針
 | このページでは公式なウィキメディアの開発方針を記載しています。 現在、TechCom RFC process は廃止されているため、変更を加えるためのメカニズムはありません。 |
| 開発の方針 |
|---|
| 関連項目 |
| 開発の指針 |
このページでは、公式の MediaWiki のデータベース方針の規範について説明します。 これは、RFC T220056 に従って TechCom の RFC プロセスを介して2019年12月に承認されました。
データベースのクエリ
- MediaWiki から SQL クエリを送信するすべての新しいコードは MariaDB/MySQL の厳格モード (RFC T112637 による) の下でいかなる警告も生成しないようにする必要があります。
- WMF は MariaDB/MySQL の厳格モード (T108255) を有効にする予定です。これは MySQL 5.7 でとにかく既定になる予定です。それ以前は、コードに警告が出ないようにする必要があります。
- データベースを操作するコードは、以下の MySQL SQL モードと互換性がある必要があります:
TRADITIONAL(以下と同等: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
- データベースのコードは、MediaWiki インストール要件のデータベース サーバーに列挙された古いバージョンと互換性がある必要があります。 ただし、サポートされていないリリースにのみ適用されるものよりも、サポートされている最新のバージョン (またはその既定値や広く推奨されている既定値) にのみ適用されるような性能向上は優先すべきです。
- レプリケーション環境では、非決定論的クエリや binlog 用の安全ではないステートメントの使用は避けるべきです。 後者は、「[Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT」というテキストの警告で検出されます。 これには、自動インクリメント キーを使用して
INSERT ... SELECTを実行する場合、ORDER BYがないUPDATE ... LIMITを実行する場合、およびSYSDATE()などの決定論的ではない関数を使用する場合が含まれます。 詳細情報はこちら。
スキーマの変更
- すべての新しいテーブルには主キーが必要です。 主キー候補を作成できなかった場合 (例: すべての列が繰り返される可能性がある場合) は、別の auto_increment 列またはその他の任意のフィールド (ケースによって異なります) を追加する必要があります。
- 主キーおよびそれを参照するフィールドは、最大値を増やすために符号なしである必要があります。
- MediaWiki コア、ウィキメディアで展開された拡張機能、および MediaWiki に同梱された拡張機能のすべてのテーブルは、抽象スキーマ システムを使用して実装する必要があり、それらの新しいスキーマ変更は自動的に生成する必要があります。
スキーマ変更の互換性
データベース スキーマの変更は、2 つ前の LTS リリース以降のすべてのリリースからアップグレードするための経路を提供する必要があります (phab:T259771 参照)。
データベースのパッチ
データベース スキーマを変更する場合は、以下の規則に従ってください:
- インストーラーを更新 – 更新には
includes/installerを含め、maintenance/archives/に適切な SQL パッチ ファイルを追加します。 フィールドを追加する場合の命名規則は、patch-{table}-{field}.sqlです。 フィールドを除去する場合は、patch-drop-{table}-{field}.sqlです。 テーブルを追加する場合は、patch-{table}.sqlです。 これらの操作を実行する方法の例は、includes/installer/(MySQL|Postgres|SQLite)Updater.phpのコミット履歴を参照してください。 同じテーブルにいくつかのフィールドを追加する場合は、すべての変更を 1 つのクエリで 1 つのパッチ ファイルにまとめます。 - スキーマ変更を省略可能にする – すべてのスキーマ変更は省略可能にする必要があります。 例:
- カラムの形式を変更する代わりに、新しいカラムを作成し、古いカラムと新しいカラムの両方に書き込みが行われるようにします (新しいカラムが存在する場合)。そして、古いカラムを廃止予定にします。 新しいカラムが存在するか確認するようにし、単に存在すると仮定しないようにします。 スキーマの移行が完了し、古いバージョンのソフトウェアにロールバックする必要がないことが明確になったら、古いカラムのサポートを終了できます。 これが実現不可能な場合は、Wikitech-l にメールを送信してアドバイスを求めるようにしてください。
- 新しい機能を、構成オプションに
trueが設定されている場合にのみ動作するように設定し、既定ではオプションにfalseを設定します。 その後、スキーマの変更が行われる前に、コミットを安全に展開できます。 ウィキメディア クラスターに機能を展開するには、関連プロジェクトで Phabricator のチケットを作成し、#schema-changeタグを追加してください。 変更が行われたことを確認した後、構成オプションを除去して機能を有効にできます。 - これはコードでスキーマ変更をオプションにすることを意味することにご注意ください。ウィキメディアの展開では、関連するデータベース テーブルを持つすべてのウィキにスキーマの変更が適用されることが期待されます。 異なるウィキで異なるスキーマが必要な場合は、拡張機能を使用して変更を適用し、その拡張機能に依存する新しいテーブルを作成するようにしてください。
「スキーマの変更を省略可能にする」規則は、パフォーマンスまたはロジスティクスの観点から禁止される場合があります。 ただし、そのようなスキーマの変更はそもそもまれであるため、wikitech-l メーリング リストで目立つようにして議論する必要があります。 スキーマの変更を省略可能にすることが不可能な場合でも、変更前の状態にロールバックするスクリプトを作成することが重要です。
- WMF データベース管理者から入力を収集する – MediaWiki は、ウィキメディアのようなサイズの大きな MySQL ベースのサイトにスキーマ変更を適用するには、かなりの計画が必要であり、毎週ウィキメディアのウェブサイト群に展開されています。2020年1月時点では、Jaime Crespo (LDAP では jcrespo、IRC では jynus) と Manuel (Arostegui, marostegui) をデータベース レビューに追加するのが最適です。ほとんどの場合、変更のロジスティクスについてのみ入力が必要です。
- ベータで変更をテストする - 特に、異なるクエリ プランになるようにインデックスと列定義を変更するということがよくある間違いです。 EXPLAIN のようなツールを使用して生成されたクエリの計画をテストするようにしてください。そうしないと、ローカルでわずか1秒かかるクエリでも、トラフィックが遥かに多く、テーブルが大きくなると、本番環境で問題が発生する可能性があります。
注記
バージョン 1.36 以降、MediaWiki は 2 つの主要な LTS リリース からのアップグレードをサポートすることのみを保証しています (phab:T259771 を参照)。 MediaWiki の古いバージョンからのアップグレードは、複数のステップで実行する必要があります。
これは、1.34 以前のバージョンから 1.42 にアップグレードする場合、最初に 1.34 のウィキを 1.35 (または 1.39) にアップグレードし、さらに 1.35 (または 1.39) から 1.42 にアップグレードする必要があることを意味します。