web-dev-qa-db-ja.com

MongoDBの復元/スナップショットスケジュール-特定の時点とOplogのタイムスタンプ

docs バックアップからレプリカセットを復元する これらの復元ポイントが利用可能です：

  • スナップショット
  • ポイントインタイム
  • Oplogタイムスタンプ

これらの復元ポイントの違いは何ですか？既存のファイルを宛先にコピーするだけなので、Snapshotは高速な復元だと思います。ただし、スナップショットは6時間ごとに生成されるコンピューティングリソースとストレージリソースを必要とし、3日間のみ保存されます。

Point In TimeとOplog Timestampの違いがわかりません。何を選択するのか（長所と短所）？ Point in Timeは24時間前までしか利用できませんが、Oplog Timestampは最初のバックアップ（Oplog Store）以降ですか？

これがsnapshotScheduleです。個々の顧客を知らない、汎用DBaaSプロバイダーの改善点はありますか？問題はありますか？

configureDefaultBackupOptions = true
snapshotIntervalHours = 6 //Supported values are 6, 8, 12, and 24
snapshotRetentionDays = 3 // Supported values are 1 - 5
dailySnapshotRetentionDays = 10 //Supported values are 1 - 365
weeklySnapshotRetentionWeeks = 6 //Supported values are 1 - 52.
monthlySnapshotRetentionMonths = 6 // Supported values are 1 - 36
pointInTimeWindowHours = 24
retryIntervalInSeconds = 15
maxRetryDurationInMinutes = 30
backupmongodbrestoremongodb-3.2ops-manager
3
Ivanov

これらの復元ポイントの違いは何ですか？既存のファイルを宛先にコピーするだけなので、Snapshotは高速な復元だと思います。ただし、スナップショットは6時間ごとに生成されるコンピューティングリソースとストレージリソースを必要とし、3日間のみ保存されます。

スナップショットは、特定の間隔でキャプチャされたデータの完全バックアップです。保存されたスナップショットからの復元は、復元ファイルを提供するためにOps Managerが最小限の操作を行う必要があるため、最も高速なオプションです。 snapshotIntervalHours（構成で6時間）およびsnapshotRetentionDays（構成で3日）は、アーカイブされた毎日/毎週/毎月のスナップショットと比較して、最近のデータに対してより頻繁な復元ポイントを提供することを目的としています。現在の構成では、次のことが可能になります。過去3日間の6時間間隔で保存されたスナップショット、過去24時間以内の特定の時点、または毎日/毎週/毎月のスナップショット。

Point In TimeとOplog Timestampの違いがわかりません。何を選択するのですか（長所と短所）？

これらは両方とも、カスタムのポイントインタイムスナップショットのオプションであり、Ops Managerが処理するために時間とリソースを大量に消費する可能性があります。バックエンド処理では、最も近い（古い）保存されたスナップショットを復元し、指​​定された時点までのoplogの変更を適用します（秒単位の日付/時刻またはoplogタイムスタンプでマーク）。どちらも、pointInTimeWindowHours構成で指定された使用可能なoplog履歴によって制限されます（つまり、24時間）。

Point In Time復元ポイントは、選択した日時までのカスタムスナップショットを作成します。 Oplog Timestampは、より正確なカスタムスナップショットであり、復元先の正確なoplogタイムスタンプを知っていることを前提としています（たとえば、偶発的なコレクションのドロップの前のエントリまで）。

個々の顧客を知らない一般的なDBaaSプロバイダーの改善点はありますか？問題はありますか？

顧客に提供するバックアップ/復元の粒度のレベルによって異なります。スナップショットの頻度または保持を増やすと、サーバーのリソースが多く消費されますが、おそらく顧客にとってはより快適になります。逆に、リソースを節約するために、スナップショットの頻度または保持を減らすことができます。

DBaaSプロバイダーとして、サービスモデルに標準のバックアップとライセンスのコストをかけ、顧客がサブスクリプションプランまたはプレミアムに基づいてバックアップオプションを変更できるようにすることを期待しています（たとえば、MongoDB Cloud Managerのように）。

注： MongoDB Ops Managerは、現時点ではDBaaSオファリングのベースになることを目的としていないため、MongoDB Enterprise Advancedサブスクリプション（構成などの質問に対する商用サポートを含む）の一部として本番環境でのみ使用する必要があります。キャパシティプランニング、チューニングなど）。

3
Stennie