Jump to content

Manual:共有データベース

From mediawiki.org
This page is a translated version of the page Manual:Shared database and the translation is 39% complete.

このページでは、MediaWikiで共有データベースを使用するための簡単な概要を説明します。 ここにある情報のほとんどは、MediaWiki拡張機能なしで動作するはずです。 延長の必要性がある場合は、その旨を記載します。 これはMySQLでの利用を想定して設計されています。 MySQL への対応は MediaWiki 1.17 で追加。 PostgreSQL への対応は MediaWiki 1.19 で追加。 他のデータベースエンジンでは、このような共有データベースをサポートしていない場合があります。

警告! 警告: このガイドでは、Wikiをゼロから始めるか、1つのWikiから複数のWikiに移行することを想定しています。 これはuser テーブルの「統合」やCentralAuth を使ったウィキメディア スタイルのセットアップ(グローバル user テーブルとローカル user テーブルは保持)には対応していません。
警告! 警告: Renameuser is currently incompatible with $wgSharedDB. See phab:T104830.

基本

共有データベースは、LocalSettings.phpで3つの主要なグローバルConfiguration variables で構成されています。

環境によっては、これらすべてを使用する必要がない場合があります。

<span id="The_simplest_setup:_A_shared_user_table">

最も基本的な設定。共有 user テーブル

user テーブルを共有すると、利用者登録を共有する複数のウィキを持つことができ、利用者は 1 つのウィキのみに利用者登録すれば済むようになります。

$wgSharedDB = 'mainwiki'; # The $wgDBname for the wiki database holding the main user table
$wgSharedTables[] = 'actor';
$wgSharedPrefix = 'm_'; # The $wgDBprefix for the database. Defaults to the prefix of the current wiki if not specified

既定では $wgSharedTables は useruser_properties のテーブルを含みます。 For wikis first created after MediaWiki 1.35, it also includes the actor table.

2つのウィキがあり、両方に異なる利用者を作成し、後で actor テーブルの共有を開始すると、ローカルの actor テーブルで参照された利用者IDが共有 actor テーブルで参照されているのと同じ利用者IDではないため、データベースのデータは壊れます。 これは、多かれ少なかれ、多くの場所で問題とデータの破損を引き起こします。 Unfortunately, there is also a bug that breaks login for new users on wikis with shared user tables but separate actor tables. Suggestion: For the reason mentioned above, it is advisable to share tables (especially user tables) right after creating a new wiki. Before any users get created or edits are made.

ディレクトリのアクセス許可

The MySQL user of the shared wiki must have at least SELECT and UPDATE permissions for the main wiki user tables. If you use different MySQL users for each wiki, you will need to grant additional permissions to the shared wiki user as specified in that wiki's $wgDBuser setting. For those who use shared hosting, note that this is possible at some but not all providers. Granting permissions can be performed using MySQL commands similar to the following:

grant select, update on mainwiki.user to 'sharedwikiuser'@'localhost';
grant select, update on mainwiki.user_properties to 'sharedwikiuser'@'localhost';

This will allow your wiki to read users from the main table, and also update the tables, which happens whenever a user logs in.

データセットの共有

For up to date information on sessions in MediaWiki 1.27 and later, see SessionManager and AuthManager.

To share login sessions between your wikis, set $wgCookieDomain to include all subdomains under your root domain. For example, if you have the sites en.example.com、​fr.example.com および pool.example.com, set:

$wgCookieDomain = '.example.com';

アップグレード

As of MediaWiki 1.21, when upgrading MediaWiki from the web installer, $wgSharedTables must be temporarily removed from LocalSettings.php during upgrade. Otherwise, the shared tables are not touched at all (neither tables with $wgSharedPrefix, nor those with $wgDBprefix), which may lead to a failed upgrade.

When upgrading from the command line, running the update.php script, you need to use the --doshared parameter for the script to upgrade the shared tables.

In MediaWiki 1.24 the default password type for MediaWiki has been changed from MD5 to PBKDF2, and passwords hashes will automatically be updated as users log in. To prevent this from happening until all wikis are upgraded, set $wgPasswordDefault to 'B' on all wikis, and remove it on all wikis when they have been upgraded to ensure a stronger encryption is used.

更なるテーブルの共有

You can share tables other than the user table, but be careful when doing so. If a table contains any data specific to one wiki, sharing may cause problems. Note that each of the subsections here assume that you are also sharing the user table. Whenever adding other tables, be sure to either append to the array ($var[] = 'value') or include the user table in the new array definition.

<span id="The_ipblocks_table">

ipblocks テーブル

$wgSharedTables[] = 'ipblocks';

By sharing the ipblocks table, you can have "global blocks" so that a block on one wiki will block the user or IP on all other wikis using the shared database.

注意

There can be some minor issues when sharing the ipblocks table:

  • The ipb_reason field is set as the "reason" on Special:Block when blocking a user. When a blocked user sees the "You are blocked" message, this is parsed as wikitext, and links are parsed on Special:BlockList, you will need to make sure when blocking a user that the message makes sense on all wikis.
  • Block logs will not be shared (sharing the logging table is not recommended).

<span id="The_user_groups_table">

user_groups テーブル

$wgSharedTables[] = 'user_groups';

Sharing the user_groups table will allow you to have global user groups.

注意

  • As with the block log, the user rights log is not shared.
  • All user groups will be global. You can work around this somewhat by customizing your user groups. For example, to have admins on one wiki be separate from admins on another, you could do something like the following:
In the config for wiki 1:
$wgGroupPermissions['wiki1_admin'] = $wgGroupPermissions['sysop']; // Copy the default sysop permissions to the new group
unset($wgGroupPermissions['sysop']); // Then remove the default sysop group
$wgGroupPermissions['wiki2_admin'] = array(); // Don't give admins from other wikis any extra rights
In the config for wiki 2:
$wgGroupPermissions['wiki2_admin'] = $wgGroupPermissions['sysop'];
unset($wgGroupPermissions['sysop']);
$wgGroupPermissions['wiki1_admin'] = array();
  • To prevent bureaucrats on one wiki from assigning themselves rights on other wikis that they shouldn't have, you can do a similar configuration to the above, but remove the 'userrights' right that allows them to set any group, and use $wgAddGroups /$wgRemoveGroups instead.

その他のテーブル

This section covers other tables, with less common reasons to share, as well as which tables not to share.

  • The interwiki table contains mostly static data; it may be useful to share if you have many custom interwikis.
  • The site_stats table could possibly be shared, to aggregate data over all your wikis.
  • By default, the user_properties table is included in the list of shared tables. If your wikis were started using MediaWiki 1.15 or older, you should probably keep this for backward compatibility, as user preferences will be silently automatically migrated from the user table to the user_properties table. Otherwise, you can remove this from the array to allow users to have different preferences on each wiki (if desired)

Most other tables should not be shared, as they include wiki-specific data, typically connections to pages via a page ID or a namespace/title combination. This includes (but is not limited to):

  • Any of the links tables (pagelinks、​templatelinks, etc.)
  • page テーブル
  • revision テーブル
  • The image table (to have a shared media repository, see $wgForeignFileRepos )

詳細は Manual:テーブルの共有への適合性 を参照してください

関連項目

  • Extension:CentralAuth - A different method to have shared user tables. Used by Wikimedia, and probably the easiest option for merging already-established wikis.
  • Extension:GlobalBlocking - an extension that allows IP addresses to be blocked globally, without sharing other databases. The right to globally block users is separated from the normal 'block' right.
  • Extension:GlobalUserrights - An extension that enables global user groups and allows easy management of them via Special:GlobalUserrights.