Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
Click here >
Docs Menu
Docs Home
/ /

バックアップと復元の失敗のトラブルシューティング

Ops Manager によって管理される配置のバックアップおよび復元操作は、エージェント接続の問題、ディスク領域の制約、 oplog の不整合など、さまざまな理由で失敗する可能性があります。

このページでは、バックアップと復元の失敗を確認する方法、一般的な原因と解決策の概要、サポートに連絡する前に収集する内容に関するガイダンスを提供します。以下の手順を完了した後も問題が解決されない場合は、 テクニカル サポートにお問い合わせください。

バックアップまたは復元失敗の原因を調べる前に、 Ops Manager UIまたはAPIで関連するステータス インジケーターを確認して、障害が発生していることを確認してください。

バックアップジョブまたはスナップショットが失敗したことを確認するには、次の方法を使用します。

スナップショットが失敗したかどうかを確認するには、以下を実行します。

1
  1. [ Adminをクリックします。

  2. [Backups] をクリックします。

  3. [Snapshots] をクリックします。

2
3

列には、スナップショットが成功したか、 が実行中いるか、または失敗したかが表示されます。

また、スナップショットの横にある JSON をクリックして、次のような追加のフィールドを表示することもできます。

  • status

  • createdDate

  • completedDate

  • totalDuration

  • transferSpeed

これらのフィールドは、バックアップが正常に完了したかどうかを確認するのに役立ちます。

すべてのスナップショットの状態の説明については、「 バックアップの概要 」を参照してください。

進行中のバックアップジョブに問題がないかどうかを確認するには、以下を行います。

1
  1. [Admin] をクリックします。

  2. [Backup] をクリックします。

  3. [Jobs] をクリックします。

2
3

Last SnapshotLast OplogHead Time などのフィールドが遅延すると強調表示されることがあります。これはバックアッププロセスに問題があることを示しています。

詳細については、「 ジョブ 」を参照してください。

バックアップジョブからのエラーメッセージを確認するには、次の手順に従います。

1
  1. [Admin] をクリックします。

  2. [Logs] をクリックします。

2

ログには、バックアップジョブが失敗した理由を診断するのに役立つ、時間別にグループ化されたエラーメッセージが表示されます。

Ops Manager は、バックアップジョブの失敗や問題を示す次のようなアラートを生成します。

  • 「バックアップが大量の再試行回数に達しました」

  • 「バックアップが予期しない状態です」

  • 「レプリカセットのスナップショットが遅れています」

バックアップ関連のアラート条件の完全なリストについては、「 アラート条件 」を参照してください。

完了していないスナップショットを検索するには、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で復元ジョブのステータスを表示するには:

1
2
3
4

Restores ページには、最後の 300 復元ジョブのテーブルが表示されます。 Status 列を確認して、次の状態のジョブを識別します。

  • FAILED

  • CANCELED

  • IN_PROGRESS

  • FINISHED

特定の 復元操作の詳細を表示するには、行をクリックします。

詳細については、「 復元 」を参照してください。

プログラムによって復元ジョブを検索するには、 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フィールドはジョブの状態を示します。可能な値は次のとおりです。

  • FINISHED

  • IN_PROGRESS

  • BROKEN

  • KILLED

BROKEN または KILLEDstatusName を使用する復元ジョブは失敗したと見なされます。

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 によって異なります。エージェントが停止するか再起動を続けると、バックアップは失敗します。

記号には、次のようなものがあります。

  • 「バックアップoplogが遅れています」などのアラート

  • 1 時間受信したoplogスライスはありません

この問題を解決するには、以下の手順を行います。

1
2

エージェントログは通常、次の場所にあります。

/var/log/mongodb-mms-automation/backup-agent.log
3

詳細については、「 バックアップ Oplog の問題の修正 」を参照してください。

バックアップエージェントはレプリカセットへの接続を維持する必要があります。障害は、ネットワーク接続の問題、使用できないMongoDBノード、または認証の失敗により発生する可能性があります。

エージェントログのシンタックスは次のとおりです。

  • server selection timeout

  • Authentication failed

この問題を解決するには、以下の手順を行います。

1
mongosh "mongodb://host:port"
2

以下のことを確認します。

  • エージェントホストとレプリカセットノード間のネットワーク アクセス

  • レプリカセットの可用性

  • バックアップユーザー認証情報と必要なロール

詳細については、「 バックアップ Oplog の問題の修正 」を参照してください。

oplogが小さすぎると、バックアップエージェントが書込み (write) アクティビティに追いつけない場合、バックアップは遅延し、最終的に失敗します。

シンボリック アラートは次のアラートを含みます。

  • 「バックアップには再同期が必要です」

  • "バックアップoplogが遅れています"

この問題を解決するには、以下の手順を行います。

  • oplog ウィンドウ が十分な履歴をカバーするようにoplogサイズを増やします(少なくとも 24 時間が推奨)。

  • バックアップが大幅に遅延した場合は、バックアップを再同期 します。

バックアップジョブには、バックアップされたレプリカセットのローカル コピーを保存するのに十分なスペースを持つバックアップデーモンが必要です。どのデーモンにも十分なスペースがある場合、ジョブはバインドに失敗します。この問題を解決するには、バックアップデーモンを追加してキャパシティーを増やします 。

この問題は、レプリカセット内でプライマリが検出されない場合にも発生する可能性があります。これを解決するには、バックアップを再試行する 前に、レプリカセットが正常で、プライマリがあることを確認します。

詳細については、「 バックアップFAQ 」を参照してください。

次のセクションでは、復元が失敗する一般的な原因とその解決方法について説明します。

シャーディングされたクラスターを復元するときは、すべてのシャードを復元する必要があります。単一のシャードを分離して復元しようとすると、復元プロセスは失敗します。

詳細については、「 復元の制限 」を参照してください。

ソースバックアップとターゲットデータベースの特定のストレージ設定が一致しない場合、自動復元が失敗することがあります。復元の試行が失敗した場合、Ops Manager は一致しない設定を表示します。

一致する必要がある設定のリストについては、「 自動復元が失敗する潜在的な原因 」を参照してください。

ポイントインタイム復元には継続的なoplog履歴が必要です。 oplogにギャップがある場合、復元は失敗します。

oplogギャップの一般的な原因は次のとおりです。

  • バックアップエージェントがoplogのテーリングを停止しました。

  • エージェントが処理する前にoplog はロールオーバーされました。

  • クラスタートポロジーの変更が発生しました。

  • 機能の互換性バージョン(FCV)の変更が発生しました。

  • MongoDB のバージョン変更全体で復元が試行されました。

この問題を解決するには、以下の手順を行います。

  • oplogギャップが 前に取得された最新の有効なスナップショットから復元する 、または

  • 新しいスナップショットが作成されるまで待ってから、復元を再度実行します。

詳細については、「 特定の時点からの復元 」を参照してください。

ターゲット ホストにスナップショット ファイルと復元されたデータベース用の十分なストレージがない場合、復元は失敗します。

この問題を解決するには、以下の手順を行います。

1
db.stats()
2

続行する前に、dbPath に復元されたデータを格納するのに十分な空きディスク領域があることを確認してください。

コマンドの詳細については、dbStats dbStatsを参照してください。

問題が解決されない場合は、テクニカル サポートに連絡する前に以下の情報を収集してください。

  • Ops Manager UIまたはAPIからの完全なエラーメッセージ

  • バックアップエージェントのログファイル

  • MongoDBサーバーのバージョン

  • Ops Manager のバージョン

  • MongoDBサーバーの関連するログ

  • 復元ページまたはAPI復元ジョブクエリからの出力

戻る

予期しないシャットダウン後のスタンドアロンの回復

項目一覧