Ops Manager によって管理される配置のバックアップおよび復元操作は、エージェント接続の問題、ディスク領域の制約、 oplog の不整合など、さまざまな理由で失敗する可能性があります。
このページでは、バックアップと復元の失敗を確認する方法、一般的な原因と解決策の概要、サポートに連絡する前に収集する内容に関するガイダンスを提供します。以下の手順を完了した後も問題が解決されない場合は、 テクニカル サポートにお問い合わせください。
前提条件チェック
バックアップまたは復元失敗の原因を調べる前に、 Ops Manager UIまたはAPIで関連するステータス インジケーターを確認して、障害が発生していることを確認してください。
バックアップの失敗を確認する
バックアップジョブまたはスナップショットが失敗したことを確認するには、次の方法を使用します。
スナップショットのステータスを確認
スナップショットが失敗したかどうかを確認するには、以下を実行します。
また、スナップショットの横にある JSON をクリックして、次のような追加のフィールドを表示することもできます。
statuscreatedDatecompletedDatetotalDurationtransferSpeed
これらのフィールドは、バックアップが正常に完了したかどうかを確認するのに役立ちます。
すべてのスナップショットの状態の説明については、「 バックアップの概要 」を参照してください。
バックアップ ジョブ ページの確認
進行中のバックアップジョブに問題がないかどうかを確認するには、以下を行います。
詳細については、「 ジョブ 」を参照してください。
バックアップ ログの確認
バックアップジョブからのエラーメッセージを確認するには、次の手順に従います。
ログには、バックアップジョブが失敗した理由を診断するのに役立つ、時間別にグループ化されたエラーメッセージが表示されます。
アラートの確認
Ops Manager は、バックアップジョブの失敗や問題を示す次のようなアラートを生成します。
「バックアップが大量の再試行回数に達しました」
「バックアップが予期しない状態です」
「レプリカセットのスナップショットが遅れています」
バックアップ関連のアラート条件の完全なリストについては、「 アラート条件 」を参照してください。
不完全なスナップショットのAPIのクエリ
完了していないスナップショットを検索するには、completed=false クエリ パラメータを使用して Ops Manager APIをクエリします。
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \ --header "Accept: application/json" \ "https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/clusters/{CLUSTER-ID}/snapshots?completed=false"
応答には、各オブジェクトがスナップショットを表す results 配列が含まれています。 completeフィールドは、スナップショットが正常に終了したかどうかを示します。
注意
スナップショットAPI、名前付き障害ステータスは提供されません。 complete: false を使用したスナップショットはまだ進行中または失敗した場合があります。
詳細については、「 1 つのクラスターのすべてのスナップショットを取得する 」を参照してください。
復元の失敗の確認
復元ジョブが失敗したことを確認するには、次の方法を使用します。
復元ページの確認
Ops Manager UIで復元ジョブのステータスを表示するには:
Restores ページには、最後の 300 復元ジョブのテーブルが表示されます。 Status 列を確認して、次の状態のジョブを識別します。
FAILEDCANCELEDIN_PROGRESSFINISHED
特定の 復元操作の詳細を表示するには、行をクリックします。
詳細については、「 復元 」を参照してください。
失敗した復元ジョブのAPIのクエリ
プログラムによって復元ジョブを検索するには、 Ops Manager APIをクエリします。
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \ --header "Accept: application/json" \ "https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/clusters/{CLUSTER-ID}/restoreJobs"
応答には、各オブジェクトが復元ジョブを表す results 配列が含まれます。 statusNameフィールドはジョブの状態を示します。可能な値は次のとおりです。
FINISHEDIN_PROGRESSBROKENKILLED
BROKEN または KILLED の statusName を使用する復元ジョブは失敗したと見なされます。
jq を使用して失敗したジョブをフィルタリングする方法
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \ --header "Accept: application/json" \ "https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/clusters/{CLUSTER-ID}/restoreJobs" \ | jq '.results[] | select(.statusName=="BROKEN" or .statusName=="KILLED")'
詳細については、「 1 つのクラスターのすべての復元ジョブを取得する 」を参照してください。
一般的な問題と解決策
次のセクションでは、バックアップと復元の失敗の一般的な原因とその解決方法について説明します。
バックアップの失敗
次のセクションでは、バックアップ失敗の一般的な原因とその解決方法について説明します。
ディスク容量の不足
レプリカセットノードに空きディスク領域がないと、クラスターが非正常的な状態になり、バックアップが失敗する可能性があります。
この問題を解決するには、影響を受けるノードの dbPath で利用可能なストレージキャパシティーを増やします。ディスク使用量を定期的に監視して、再現性を防ぎます。
MongoDB Agent がダウンしているか不安定になっている
バックアッププロセスは、継続的に実行中MongoDB Agent によって異なります。エージェントが停止するか再起動を続けると、バックアップは失敗します。
記号には、次のようなものがあります。
「バックアップoplogが遅れています」などのアラート
1 時間受信したoplogスライスはありません
この問題を解決するには、以下の手順を行います。
詳細については、「 バックアップ Oplog の問題の修正 」を参照してください。
エージェントがレプリカセットに到達できない
バックアップエージェントはレプリカセットへの接続を維持する必要があります。障害は、ネットワーク接続の問題、使用できないMongoDBノード、または認証の失敗により発生する可能性があります。
エージェントログのシンタックスは次のとおりです。
server selection timeoutAuthentication failed
この問題を解決するには、以下の手順を行います。
詳細については、「 バックアップ Oplog の問題の修正 」を参照してください。
oplog の問題
oplogが小さすぎると、バックアップエージェントが書込み (write) アクティビティに追いつけない場合、バックアップは遅延し、最終的に失敗します。
シンボリック アラートは次のアラートを含みます。
「バックアップには再同期が必要です」
"バックアップoplogが遅れています"
この問題を解決するには、以下の手順を行います。
oplog ウィンドウ が十分な履歴をカバーするようにoplogサイズを増やします(少なくとも 24 時間が推奨)。
バックアップが大幅に遅延した場合は、バックアップを再同期 します。
バックアップジョブがバックアップデーモンへのバインドに失敗
バックアップジョブには、バックアップされたレプリカセットのローカル コピーを保存するのに十分なスペースを持つバックアップデーモンが必要です。どのデーモンにも十分なスペースがある場合、ジョブはバインドに失敗します。この問題を解決するには、バックアップデーモンを追加してキャパシティーを増やします 。
この問題は、レプリカセット内でプライマリが検出されない場合にも発生する可能性があります。これを解決するには、バックアップを再試行する 前に、レプリカセットが正常で、プライマリがあることを確認します。
詳細については、「 バックアップFAQ 」を参照してください。
復元の失敗
次のセクションでは、復元が失敗する一般的な原因とその解決方法について説明します。
シャードクラスタ内の単一シャードの復元試行
シャーディングされたクラスターを復元するときは、すべてのシャードを復元する必要があります。単一のシャードを分離して復元しようとすると、復元プロセスは失敗します。
詳細については、「 復元の制限 」を参照してください。
バックアップとターゲット データベース間の設定が一致しない
ソースバックアップとターゲットデータベースの特定のストレージ設定が一致しない場合、自動復元が失敗することがあります。復元の試行が失敗した場合、Ops Manager は一致しない設定を表示します。
一致する必要がある設定のリストについては、「 自動復元が失敗する潜在的な原因 」を参照してください。
ポイントインタイム復元中の oplog のギャップ
ポイントインタイム復元には継続的なoplog履歴が必要です。 oplogにギャップがある場合、復元は失敗します。
oplogギャップの一般的な原因は次のとおりです。
バックアップエージェントがoplogのテーリングを停止しました。
エージェントが処理する前にoplog はロールオーバーされました。
クラスタートポロジーの変更が発生しました。
機能の互換性バージョン(FCV)の変更が発生しました。
MongoDB のバージョン変更全体で復元が試行されました。
この問題を解決するには、以下の手順を行います。
oplogギャップが 前に取得された最新の有効なスナップショットから復元する 、または
新しいスナップショットが作成されるまで待ってから、復元を再度実行します。
詳細については、「 特定の時点からの復元 」を参照してください。
復元ホストのディスク容量の不足
ターゲット ホストにスナップショット ファイルと復元されたデータベース用の十分なストレージがない場合、復元は失敗します。
この問題を解決するには、以下の手順を行います。
コマンドの詳細については、dbStats dbStatsを参照してください。
より多くのサポートのために収集する診断情報
問題が解決されない場合は、テクニカル サポートに連絡する前に以下の情報を収集してください。
Ops Manager UIまたはAPIからの完全なエラーメッセージ
バックアップエージェントのログファイル
MongoDBサーバーのバージョン
Ops Manager のバージョン
MongoDBサーバーの関連するログ
復元ページまたはAPI復元ジョブクエリからの出力