「MongoDB」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎NUMA: 翻訳)
119行目: 119行目:
 
必要に応じて {{ic|mongodb.service}} を[[Systemd#ユニットを使う|再有効化]]・[[再起動]]してください。
 
必要に応じて {{ic|mongodb.service}} を[[Systemd#ユニットを使う|再有効化]]・[[再起動]]してください。
   
=== Clean Start and Stop ===
+
=== 完全な開始/停止 ===
   
  +
デフォルトでは、[[systemd]] は、サービスに開始/停止を要求して90秒経ってもその要求を完了しない場合、そのサービスを即座に kill します。
By default, [[systemd]] immediately kills anything after asking it to start or stop, if it has not finished doing so within 90 seconds.
 
   
  +
{{aur|mongodb}} は MongoDB の起動が完了するまで [[systemd]] を待たせますが、{{aur|mongodb-bin}} はそのようなことをしません。両パッケージは、MongoDB が90秒以内に起動を完了しなかった場合、停止を要求されたら MongoDB を kill することを [[systemd]] に許可しています。
{{aur|mongodb}} makes [[systemd]] wait as long as it takes for MongoDB to start, but {{aur|mongodb-bin}} does not. Both packages allow [[systemd]] to kill MongoDB after it is asked to stop, if it has not finished within 90 seconds.
 
   
  +
巨大な MongoDB データベースは、特にスワップが使用されている場合に、完全にシャットダウンするのに相当の時間がかかる可能性があります。(最上位機種の NVMe と 64GB の RAM、16 GB のスワップの環境でのアクティブな 450 GB のデータベースはシャットダウンするのに1時間かかる可能性があります。)
Large MongoDB databases can take a considerable amount of time to cleanly shut down, especially if swap is being used. (An active 450GB database on a top of the line NVMe with 64GB RAM and 16GB swap can take an hour to shut down.)
 
   
By default, MongoDB uses journaling. [https://docs.mongodb.com/manual/reference/configuration-options/#storage-options] With journaling, an unclean shutdown should not pose a risk of data loss. But, if not shutdown cleanly, large MongoDB databases can take a considerable amount of time to start back up. In this case, choosing whether to require a clean shutdown is a choice of a slower shutdown versus a slower startup. [https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/mongodb-user/KjBU_GcNcmw/gR2UxRIFAgAJ]
+
デフォルトでは、MongoDB はジャーナリングを使用します。[https://docs.mongodb.com/manual/reference/configuration-options/#storage-options] ジャーナリングを使用している場合、不完全なシャットダウンでデータが消失するリスクは無いはずです。しかし、シャットダウンが不完全だった場合、巨大な MongoDB データベースは起動し直すのに相当の時間がかかる可能性があります。この場合、完全なシャットダウンを要求するかどうかの選択は、遅いシャットダウンか遅い起動のどちらか一方を選ぶということになります。[https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/mongodb-user/KjBU_GcNcmw/gR2UxRIFAgAJ]
   
{{warning|If you disable journaling, failing to require a clean shutdown severely risks data loss, so you really need to require a clean shutdown. [https://docs.mongodb.com/manual/tutorial/recover-data-following-unexpected-shutdown/]}}
+
{{warning|ジャーナリングを無効化した場合、完全なシャットダウンを要求しないとデータが損失する危険性が高いので、完全なシャットダウンを要求する必要があります。[https://docs.mongodb.com/manual/tutorial/recover-data-following-unexpected-shutdown/]}}
   
To prevent [[systemd]] from killing MongoDB after 90 seconds, [[edit]] {{ic|mongodb.service}}.
+
90秒経っても [[systemd]] MongoDB kill しないようにするには、{{ic|mongodb.service}} を[[編集]]してください。
   
  +
MongoDB が完全にシャットダウンできるようにするには、{{ic|[Service]}} セクションに以下を[[追加]]してください(巨大なデータベースでは、これによりシステムのシャットダウンが大幅に遅くなることがありますが、次回の起動は早くなります。):
To allow MongoDB to cleanly shutdown, [[append]] to the {{ic|[Service]}} section: (On large databases, this may substantially slow down your system shutdown time, but speeds up your next MongoDB start time)
 
   
 
TimeoutStopSec=infinity
 
TimeoutStopSec=infinity
   
If MongoDB needs a long time to start back up, it can be very problematic for [[systemd]] to keep killing and restarting it every 90 seconds [https://jira.mongodb.org/browse/SERVER-38086], so {{aur|mongodb}} prevents this. If using {{aur|mongodb-bin}}, to make [[systemd]] wait as long as it takes for MongoDB to start, [[append]] to the {{ic|[Service]}} section:
+
MongoDB が起動し直すのに長い時間が必要になる場合、[[systemd]] が90秒ごとに MongoDB kill して再起動させるのは大きな問題となる可能性があります [https://jira.mongodb.org/browse/SERVER-38086]。なので、{{aur|mongodb}} はそうならないようにします。{{aur|mongodb-bin}} を使用している場合、MongoDB が起動するまで [[systemd]] を待たせるには、{{ic|[Service]}} セクションに以下を[[追加]]してください:
   
 
TimeoutStartSec=infinity
 
TimeoutStartSec=infinity

2022年5月4日 (水) 00:16時点における版

MongoDB (由来は humongous から) はオープンソースのドキュメント指向データベースです。MongoDB Inc. (旧 10gen) によって開発・サポートされています。MongoDB はデータベースシステムの NoSQL ファミリーの一員です。"古典的"なリレーショナルデータベースでそうあるように、データをテーブルに保存する代わりに、MongoDB は動的なスキーマ (MongoDB では BSON と呼称されるフォーマット) によって JSON ライクなドキュメントとして構造的データを保存して、特定のタイプのアプリケーションでデータを簡単かつ高速に扱えるようにします。

インストール

MongoDB は再ライセンス上の問題により公式リポジトリから削除されました [1]

PKGBUILDAUR で提供されています:

  • mongodbAUR - ソースコードからビルドします。180GB 以上のディスク空き領域が必要で、おそらくビルドに数時間かかります。(例: Intel i7 で6.5時間、ハイエンドの NVMe と 32 Xeon cores で1時間。)
  • mongodb-binAUR - ビルド済みの MongoDB バイナリを公式 MongoDB Ubuntu リポジトリから抽出します。ビルドに使用されたコンパイラオプションは不明です。

選んだメインの PKGBUILD に対応する、AUR にある PKGBUILD を使ってツール(mongoimportmongoexportmongodumpmongorestore など) をインストールしてください:

使用方法

mongodb.service デーモンを起動・有効化します。

ノート: mongodb サービスは初回起動時に大きいファイルを作成することにより領域を事前に確保します(ジャーナルや他のデータ用)。この処理には時間が掛かり、その間、MongoDB シェルは使用不能となります。

データベースシェルにアクセスするには、ターミナルに以下を入力:

$ mongo

または、認証設定がなされている場合:

$ mongo -u userName

Configuration

ファイルのフォーマット

MongoDB は 設定ファイルに YAML ベースのフォーマットを使用します。利用可能な設定オプションについては https://docs.mongodb.com/manual/reference/configuration-options/ を見てください。

/etc/mongodb.conf
systemLog:
   destination: file
   path: "/var/log/mongodb/mongod.log"
   logAppend: true
storage:
   journal:
      enabled: true
processManagement:
   fork: true
net:
   bindIp: 127.0.0.1
   port: 27017
setParameter:
   enableLocalhostAuthBypass: false
..


認証を要求する

警告: デフォルトでは MongoDB は認証を要求しません。MongoDB はデフォルトで localhost のインターフェイスのみをリッスンしますが、これでもローカルなユーザは認証せずに接続でき、データベースを晒すことになるかもしれません。望ましくないアクセスを防ぐためにアクセス制御を有効化することをおすすめします。

管理者のアクセス権を持つ MongoDB のユーザアカウントを作るには[2]:

$ mongosh
use admin
db.createUser(
  {
    user: "myUserAdmin",
    pwd: "abc123",
    roles: [ { role: "userAdminAnyDatabase", db: "admin" }, "readWriteAnyDatabase" ]
  }
)

以下を /etc/mongodb.conf追加してください:

/etc/mongodb.conf
security:
  authorization: "enabled"

mongodb.service再起動してください。

NUMA

MongoDB を Non-Uniform Access Memory (NUMA) で実行するとパフォーマンスに大きな影響を与えることがあります。[3]

システムが NUMA を使用しているかどうかを確認するには:

# dmesg | grep -i numa

また、NUMA が使用中で MongoDB が numactl を通して起動されていない場合、/var/log/mongodb/mongod.log に警告が残ります。(mongo シェルもこの警告を表示しますが、認証を有効化していない場合に限ります。)

システムが NUMA を使用している場合、パフォーマンスを向上させるためには MongoDB を numactl を通して起動させる必要があります。

インストールしたパッケージに合わせて mongodb.service編集してください。

mongodbAUR を使用している場合、

ExecStart=/usr/bin/mongod $OPTIONS

から

ExecStart=/usr/bin/numactl --interleave=all /usr/bin/mongod $OPTIONS

のように変更してください。 mongodb-binAUR を使用している場合、

ExecStart=/usr/bin/mongod --quiet --config /etc/mongodb.conf

から

ExecStart=/usr/bin/numactl --interleave=all /usr/bin/mongod --quiet --config /etc/mongodb.conf

のように変更してください。 ゾーンの回収も無効化する必要がありますが、arch では /proc/sys/vm/zone_reclaim_mode はデフォルトで 0 となっています。

必要に応じて mongodb.service再有効化再起動してください。

完全な開始/停止

デフォルトでは、systemd は、サービスに開始/停止を要求して90秒経ってもその要求を完了しない場合、そのサービスを即座に kill します。

mongodbAUR は MongoDB の起動が完了するまで systemd を待たせますが、mongodb-binAUR はそのようなことをしません。両パッケージは、MongoDB が90秒以内に起動を完了しなかった場合、停止を要求されたら MongoDB を kill することを systemd に許可しています。

巨大な MongoDB データベースは、特にスワップが使用されている場合に、完全にシャットダウンするのに相当の時間がかかる可能性があります。(最上位機種の NVMe と 64GB の RAM、16 GB のスワップの環境でのアクティブな 450 GB のデータベースはシャットダウンするのに1時間かかる可能性があります。)

デフォルトでは、MongoDB はジャーナリングを使用します。[4] ジャーナリングを使用している場合、不完全なシャットダウンでデータが消失するリスクは無いはずです。しかし、シャットダウンが不完全だった場合、巨大な MongoDB データベースは起動し直すのに相当の時間がかかる可能性があります。この場合、完全なシャットダウンを要求するかどうかの選択は、遅いシャットダウンか遅い起動のどちらか一方を選ぶということになります。[5]

警告: ジャーナリングを無効化した場合、完全なシャットダウンを要求しないとデータが損失する危険性が高いので、完全なシャットダウンを要求する必要があります。[6]

90秒経っても systemd が MongoDB を kill しないようにするには、mongodb.service編集してください。

MongoDB が完全にシャットダウンできるようにするには、[Service] セクションに以下を追加してください(巨大なデータベースでは、これによりシステムのシャットダウンが大幅に遅くなることがありますが、次回の起動は早くなります。):

TimeoutStopSec=infinity

MongoDB が起動し直すのに長い時間が必要になる場合、systemd が90秒ごとに MongoDB を kill して再起動させるのは大きな問題となる可能性があります [7]。なので、mongodbAUR はそうならないようにします。mongodb-binAUR を使用している場合、MongoDB が起動するまで systemd を待たせるには、[Service] セクションに以下を追加してください:

TimeoutStartSec=infinity

トラブルシューティング

MongoDB が起動しない

データベースのパスが正しく設定されているか確認してください:

$ cat /usr/lib/systemd/system/mongodb.service

"ExecStart" 行に "--dbpath /var/lib/mongodb" を追加してください:

ExecStart=/usr/bin/numactl --interleave=all mongod --quiet --config /etc/mongodb.conf --dbpath /var/lib/mongodb

最低でも (ジャーナルファイル用の) 3GB の空き容量があることを確認してください。容量が足りない場合 MongoDB が起動できないことがあります (その場合ユーザーにメッセージは表示されません):

$ df -h /var/lib/mongodb/

ロックファイルが存在しないかどうか確認:

# ls -lisa /var/lib/mongodb

ロックファイルが存在する場合、mongodb.service を停止してください。データベースのパスを指定してデータベースの修復を実行します (Arch Linux では /var/lib/mongodb/ がデフォルトの --dbpath です):

# mongod --dbpath /var/lib/mongodb/ --repair

修復が完了すると、dbpath に修復されたデータファイルと空の mongod.lock ファイルが作られます。

警告: ファイルを削除して、破損したファイルを使ってデータベースを起動して、データベースからデータの復旧を試みることもできます。ただし、データベースの状態を予想することはできません。詳しくは 上流のドキュメント を見てください。

root で修復を実行後、ファイルの所有者は root ユーザーになりますが、Arch Linux は別のユーザーで MongoDB を実行します。chown を使ってファイルの所有者を適切なユーザーに戻す必要があります (詳しくは こちら を参照):

# chown -R mongodb: /var/{log,lib}/mongodb/

mongodb の ドキュメント から設定ファイルをコピーした場合、以下の2行を削除して mongodb.service を再起動してください:

/etc/mongodb.conf
processManagement:
   fork: true

transparent_hugepage のカーネル設定について MongoDB がエラーを吐く

MongoDB の起動後、transparent_hugepage に関する警告が表示される場合、以下のファイルを編集することでシステム設定を永続的に無効化することができます (FreeDesktop tmpfiles.d マニュアル を参照):

/etc/tmpfiles.d/local.conf
w /sys/kernel/mm/transparent_hugepage/enabled - - - - never
w /sys/kernel/mm/transparent_hugepage/defrag - - - - never

sysctl を使ったり以下のように echo コマンドを使うことで一時的に無効化することもできます:

# echo never > /sys/kernel/mm/transparent_hugepage/enabled
# echo never > /sys/kernel/mm/transparent_hugepage/defrag

Warning about Soft rlimits too low

If you are using systemd service, then edit the unit file by systemctl edit mongodb.service:

[Service]
# Other directives omitted
# (file size)
LimitFSIZE=infinity
# (cpu time)
LimitCPU=infinity
# (virtual memory size)
LimitAS=infinity
# (locked-in-memory size)
LimitMEMLOCK=infinity
# (open files)
LimitNOFILE=64000
# (processes/threads)
LimitNPROC=64000

See following link for further details: Further reference