☰

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

tag-icon • tag-icon ubuntu mongodb systemd
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 でこれをすぐに使用できるように構成しない理由はあるのでしょうか?

答え1

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

プロセスがシャットダウンする理由が、mongod手動介入なしでは修正できない不変条件（ディスク容量不足やデータファイルの破損など）である場合、自動再起動は役に立たず、状況を悪化させる可能性があります。一般的に、mongod回復可能なエラーではシャットダウンしないでください。MongoDBサーバー例外アーキテクチャは、操作ごとの致命的なエラーとプロセス全体にとって致命的なエラーを区別します。プロセスに致命的なエラーとは、続行するとデータの損失やディスク上のデータの破損などの悲惨な結果につながる可能性がある状況です。ユーザーまたはO/Sがプロセスを終了するために開始したシグナル（メモリ不足、別名 OOM キラーLinux の場合もmongodシャットダウンが発生します。

コメントで言及されているエラーの例は、MongoDB の古いバージョンで一部のセカンダリでセグメント違反が発生したインデックス ビルドです。サービスの自動再起動により、このシナリオは、セカンダリがクラッシュし、再起動し、インデックス ビルドを再開し、同じ状況に遭遇し、再起動する…という無限ループにつながる可能性があります。結局、インデックス ビルドは失敗に終わります。この再起動ループが進行中、セカンダリの断続的な可用性により、セカンダリ読み取り設定を使用しているクライアントやレプリカ セットの他のメンバー (たとえば、同期を再開するためにアップストリーム oplog を繰り返しシークする) が影響を受ける可能性があります。

システム管理者としては、MongoDBのログを確認してプロセスがシャットダウンした理由を理解し、根本的な原因に対処したい。理想的には、デプロイメントには十分なフォールトトレランスメンバーが不在の場合でも対処でき、状況を調査して改善する時間を確保できます。

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

答え2

systemd を使用している場合は、セクションRestart=alwaysで[Service]クラッシュ後にサービスを再起動できるようにする必要があります。

答え3

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

私は個人的に、5 年間にわたって大規模なシャード化された MongoDB デプロイメントを運用環境で管理してきましたが、レプリカセットでローテーションに戻る前に問題を調査したいので、インスタンスが自動的に再起動しない方がよいと思います。

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

関連情報