web-dev-qa-db-ja.com

MongoDBが自動的に再起動しないのはなぜですか？

MongoDB 3.6は、クラッシュした場合に再起動するように自動的に構成されていないようです。 Ubuntu 16.04LTSの最新の.debパッケージにバンドルされているsystemdサービスを見ると、再起動が構成されていないようです。

$ Sudo systemctl cat mongod
# /lib/systemd/system/mongod.service
[Unit]
Description=High-performance, schema-free document-oriented database
After=network.target
Documentation=https://docs.mongodb.org/manual

[Service]
User=mongodb
Group=mongodb
ExecStart=/usr/bin/mongod --config /etc/mongod.conf
PIDFile=/var/run/mongodb/mongod.pid
# file size
LimitFSIZE=infinity
# cpu time
LimitCPU=infinity
# virtual memory size
LimitAS=infinity
# open files
LimitNOFILE=64000
# processes/threads
LimitNPROC=64000
# locked memory
LimitMEMLOCK=infinity
# total threads (user+kernel)
TasksMax=infinity
TasksAccounting=false

# Recommended limits for for mongod as specified in
# http://docs.mongodb.org/manual/reference/ulimit/#recommended-settings

[Install]
WantedBy=multi-user.target

SIGKILLとSIGSEGVを送信すると、プロセスは強制終了され、再起動されません。それらがsystemdによって「キャッチ」され、再起動されただけではないのかどうかはわかりません。

だからいくつかの質問：これはデータベースのような高可用性サービスにとって重要ですか？確かにそうです。 MongoDBがそのままでは構成されない理由はありますか？

ubuntumongodbsystemd
4
four43

予期しないシャットダウンは間違いなく、管理者の介入が強く推奨されるケースですが、デプロイメントのサービスのデフォルトはいつでも変更できます。

mongodプロセスのシャットダウンの理由が不変であり、手動による介入なしでは修正できない場合（たとえば、ディスク領域の不足またはデータファイルの破損）、自動再起動は役に立たず、状況を引き起こす可能性があります悪い。一般に、mongodは回復可能なエラーでシャットダウンしないでください。 MongoDB サーバー例外アーキテクチャ は、操作ごとの致命的なエラーとプロセス全体に致命的なエラーを区別します。プロセス致命的エラーは、継続すると、データの損失やディスク上のデータの破損などの悲惨な結果につながる可能性がある状況です。プロセスを終了するユーザーまたはO/Sが開始した信号（Linuxの Out-of-Memory aka OOM Killer など）もmongodをシャットダウンします。

コメントで言及されているエラーの例は、古いバージョンのMongoDBを使用している一部のセカンダリでセグメンテーション違反を起こしたインデックスビルドでした。自動サービス再起動により、このシナリオは、セカンダリがクラッシュし、再起動し、インデックスの構築を再開し、同じ条件に遭遇し、運命のあるインデックスの構築を再開するためだけに再起動する無限ループにつながる可能性があります。この再起動ループの進行中、セカンダリの断続的な可用性は、セカンダリ読み取り設定またはレプリカセットの他のメンバーを使用しているクライアントに影響を与える可能性があります（たとえば、同期を再開するためにアップストリームoplogを繰り返しシークします）。

システム管理者として、MongoDBのログを確認し、根本的な原因に対処できるようにプロセスがシャットダウンする理由を理解することをお勧めします。理想的には、デプロイメントには十分な フォールトトレランス があり、メンバーが利用できない場合に対処できるため、状況を調査して修正する時間があります。

問題の性質と展開（スタンドアロン、レプリカセット、またはシャードクラスター）によっては、自動または手動の回復を試みる前に、データファイルのバックアップを作成することもできます。たとえば、クリーンシャットダウン後に再起動すると、mongodには初期リカバリステージがあり、未処理のジャーナルエントリを適用し、dbPathのデータファイルの整合性のようにストレージエンジンチェックを実行します。スタンドアロンサーバーの場合、リカバリ/修復を試行する前に、変更されていないデータファイルのコピーを作成することをお勧めします。レプリカセットの展開では、データはレプリカセットの別のメンバーに既に複製されているため、標準の回復が失敗した場合は、修復を試みるのではなく、 このメンバーを再同期 します。

4
Stennie

高可用性について本当に心配している場合は、レプリカセットを実行していて、1つ以上のノードの障害に対処できます。

本番環境で大規模な分割されたmongodbデプロイメントを5年間個人的に管理してきたので、レプリカセットでローテーションに戻る前に問題を調査したいので、インスタンスを自動再起動しない方がいいと思います。

https://docs.mongodb.com/manual/core/replica-set-high-availability/

1
Jason Floyd

Systemdを使用している場合は、Restart=always 下 [Service]セクションでは、クラッシュ後にサービスを再起動できます。

1
Tux_DEV_NULL