MySQL との連動

設定の名前と既定の値は、2026 年 10 月時点の各プラグインと MySQL の公式のドキュメントによります。

データベースが必要になる場面

1 台のサーバーでは、プラグインのデータはサーバーの中のファイル (H2 や SQLite など) に保存されます。サーバーを分けると、それぞれのサーバーが別々のファイルを持つため、データがそろわなくなります。

権限: ロビーで管理者にした人が、ゲームのサーバーでは一般の参加者のまま
インベントリ: ネザーのサーバーに移ったら、持っていたアイテムが消えている
記録: ランキングやポイントが、サーバーごとに別々に数えられる

すべてのサーバーが同じデータベースを読み書きするようにすると、どのサーバーにいても同じデータを使えます。さらに、あるサーバーでの変更をほかのサーバーにすぐ知らせるために、Redis などの連絡の仕組みを組み合わせます。

データはデータベースに、変更の知らせは Redis で。

Velocityプロキシ

インターネットから直接は接続できないネットワーク

ロビーPaper

ゲームPaper

ネザーPaper

MySQL・MariaDB権限、インベントリ、記録を保存する

Redis変更をほかのサーバーにすぐ知らせる

データベースに対応する主なプラグイン

プラグイン	用途	データベース
LuckPerms	権限の管理	MySQL、MariaDB (MySQL より推奨)、PostgreSQL、MongoDB。複数のサーバーでは、これらのどれかが必要
HuskSync	インベントリ、体力、経験値などのサーバーの間の同期	MySQL、MariaDB、MongoDB、PostgreSQL のどれかと、Redis (5.0 以上) が必要
Plan	プレイヤーの分析	プロキシを使うネットワークでは MySQL が必要
CoreProtect	ブロックの変更の記録と巻き戻し	新しく導入するときの既定は DuckDB (25.0 以降)。MySQL と SQLite は以前からの方式として残っている
Dynmap	Web の地図	ファイル、MySQL・MariaDB、SQLite、PostgreSQL、Amazon S3

どのデータベースを使えるかは、プラグインのバージョンによって変わります。CoreProtect のように、既定の方式が変わることもあるため、導入と更新のときに公式のドキュメントを確認します。

LuckPerms の設定の例

LuckPerms のドキュメントは、複数のサーバーで使う場合、すべてのサーバーを同じデータベースに接続し、サーバーごとに server の値を変えるよう案内しています。

# plugins/LuckPerms/config.yml(各サーバー)
server: lobby                  # サーバーごとに変える(lobby、game1、nether など)

storage-method: mariadb
data:
  address: 10.0.0.20:3306       # データベースのプライベートなアドレス
  database: luckperms
  username: luckperms           # LuckPerms 専用のユーザー
  password: "********"

# 変更をほかのサーバーにすぐ知らせる
messaging-service: redis
redis:
  enabled: true
  address: 10.0.0.21:6379
  password: "********"

# 連絡の仕組みを使う場合、定期的な同期は止める
sync-minutes: -1

連絡の仕組み (messaging-service) には、データベースを使う sql、プロキシを通す pluginmsg、redis などがあります。pluginmsg はプロキシが複数あると使えないため、LuckPerms のドキュメントは、プロキシが複数のときは Redis を勧めています。

接続のプール

多くのプラグインは、HikariCP という仕組みで、データベースへの接続を一定の数だけ開いたまま使い回します (接続のプール)。LuckPerms の既定は、最大 10 の接続です。

プールの大きさ: HikariCP の資料は、プールは小さく保つことを勧め、目安を「CPU のコアの数 × 2 + ディスクの数」としている。サーバーの数 × プラグインの数 × プールの大きさが、データベースの接続の上限を超えないようにする
接続の寿命: プールの接続の寿命 (maxLifetime、既定 30 分) は、データベースやネットワークの機器が接続を切る時間より、数秒短くする
変更の判断: LuckPerms は、プールの設定を、理由がない限り変えないよう案内している

メインのスレッドを止めない

データベースへの問い合わせは、ネットワークを通るため、数ミリ秒から、混んでいると数百ミリ秒かかります。メインのスレッドの上で問い合わせの結果を待つと、その間ワールド全体が止まります (ティックとスレッドの仕組み)。

問い合わせは非同期のタスクで行い、結果を使ってワールドを変える処理だけを、メインのスレッドに戻す
参加のときに必要なデータは、参加の前の非同期のイベントで読み込んでおく
データベースは、サーバーと同じデータセンターや同じネットワークに置き、往復の時間を短くする。HuskSync のドキュメントも、Redis を外部の遠い場所に置くことは遅延のため避けるよう案内している

自作のプラグインでデータベースを使う場合は、この作りが特に重要です。Paper の Watchdog のメッセージも、メインのスレッドで MySQL の処理が行われていれば、そのプラグインの作者に報告するよう案内しています。

安全な置き方

データベースには、参加する方の UUID や IP アドレス、運営の権限などの情報が入ります。Web のシステムと同じ水準で守ります。MySQL のセキュリティのガイドラインと Redis のドキュメントは、次の点を挙げています。

MySQL の 3306 番は、サーバーとの間のプライベートな接続だけに制限する。データベースはファイアウォールの内側に置く
必要以上の権限を与えない。すべてのホストからの接続を許可しない。プラグインごとに専用のユーザーを作り、そのプラグインのデータベースだけを扱えるようにする
Redis は、信頼できる環境の中で使う前提の作り。インターネットから誰でも接続できる状態にせず、サーバーとの間のプライベートな接続だけに制限する。パスワードか ACL を設定する。通信は既定で暗号化されないため、別のネットワークを通る場合は TLS を使う
データベースのパスワードは、設定ファイルを共有するときに漏れないようにする。管理画面やバックアップの置き場所の権限も確かめる

バックアップと復旧

定期のバックアップ: mysqldump --single-transaction で、サーバーを止めずに整合した状態を取れる (InnoDB の場合)
時点を指定した復旧: バイナリログを残しておくと、最後のバックアップから障害の直前までを戻せる。MySQL 8.4 では既定で有効
ワールドとの組み合わせ: ワールドのバックアップとデータベースのバックアップの時刻がずれると、インベントリとワールドの状態が合わなくなる。企画の前後には、両方を同じ時点でそろえて取る
復旧の練習: バックアップから実際に戻せるかを、検証用の環境で確かめておく

ワールドのバックアップは、バックアップと更新で説明しています。

参考にした資料

データベースとの連動は、KEY SELECT に

MySQL・MariaDB と Redis の構築、プラグインとの接続の設定、権限の最小化、バックアップと復旧の手順まで、KEY SELECT がお引き受けできます。Web のシステムの開発と同じ水準で設計します。

データベースとの連動のご相談 Minecraft サーバー運営

記事や技術資料の内容についてのご質問とサポートは、保守・サポートのご契約、またはスポットでのご契約をいただいたうえでお受けしています。無償でのサポートは行っておりません。
記事や技術資料の内容は、公開の時点の情報にもとづいて作成しています。内容の正確性、完全性、最新性を保証するものではなく、内容にもとづいて行った作業の結果について、弊社は責任を負いかねます。設定や変更は、ご自身の責任で、検証用の環境で確かめてから行ってください。
記事や技術資料の内容について、ご指摘や誤りにお気づきの点がありましたら、その他のお問い合わせからお知らせください。
技術資料の内容は、引用元として資料の名前と URL を明記していただければ、ご自身の動画や資料としてご利用いただけます。全文の Web サイトでの引用はご遠慮ください。