0

スナップショットが可能なさまざまなテクノロジーを使用して Mongo がどのように機能するかを評価するための実験をセットアップしたいと思います。

  • ext3 の R1Soft HotCopy
  • xfs 上の R1Soft HotCopy
  • ext3 を使用した LVM
  • xfs を使用した LVM
  • btrfs

ディスク IO にバインドする必要があるため、すべての書き込みが本質的に同期していることを確認する必要があります。そうしないと、RAM とスワップの制約に違反するデータセットを作成する必要がありますが、すべての挿入でファイルシステムのフラッシュを有効にすると、各操作は次の操作の前にフラッシュされます。

> db.runCommand({getlasterror:1,j:true})

MongoDB プロセスの IO の性質を実際に活用するには、他に何ができるでしょうか?

  • 読み取りと書き込みをインターリーブできます。

一定の挿入率などをテストし、次の期間中にプロセスがどのように動作するかを観察します

  1. スナップショット関連の活動や存在はありません。
  2. スナップショットが作成され、コミットされているとき。
  3. スナップショットがバックアップ スクリプトによって読み取られているとき。
  4. スナップショットが冗長だがアクティブな場合。
  5. スナップショットが廃止されるとき。

アクティビティとハードウェアが一定に保たれている間、パフォーマンスの相対的なベンチマークが発生することを確認したいと考えています.

ヒントをありがとう。

4

1 に答える 1

0

ロブ、これは素晴らしい。この結果は、すべての人に利益をもたらすはずです。

MongoDBの本番環境展開の一般的なスナップショット操作をテストする際に役立つ可能性のあるいくつかの点に注意したいと思います。

スナップショットを撮る

ご指摘のとおり、ライブサーバーでスナップショットを作成する際の主な問題は、IOの競合です。これを回避するために、ほとんどの場合、3つ以上のメンバーを持つレプリカセットをデプロイします。

多くの場合、このシナリオでは、セカンダリの1つがfsyncでスナップショット中にロックされるか、非表示のメンバーとして構成されるか、または単にオフラインになります。これにより、ホットバックアップ（他のセカンダリ）が自動フェイルオーバーに引き続き使用できる間にスナップショットを作成できます。

これにより、他に2つのことが保証されます。まず、スナップショットをタイムリーに実行できること（本番環境の負荷がバックアップ時間に影響を与えないこと）、次に、スナップショットを取得するために必要な負荷が本番環境の読み取りに影響を与えないこと（セカンダリからの読み取りが許可されている場合-slaveOk） 。

バックアップの仕組み

スナップショット戦略に関する上記の点は重要です。ほとんどの人は、セカンダリがプライマリと同じ書き込み負荷を持っているという事実を見落としているからです。

MongoDBにはマルチマスターレプリケーションがありません。一度に1つのサーバー（セット/シャード内）のみが書き込み（プライマリまたはマスター）に対してアクティブになります。

ただし、プライマリが書き込みと読み取りを受信して​​いる間、セカンダリはそのプライマリのoplog（上限付きコレクション）をテールします。セカンダリは定期的にリクエストを発行して、この調整可能なカーソルからの読み取りを待機しているデータがまだあるかどうかを確認します。ある場合、それらのoplogエントリはプライマリから読み取られ、セカンダリに書き込まれます（はい、これには書き込みロックがかかります）。

次に、セカンダリはoplogの新しいエントリをデータの独自のコピーに適用します（はい、これには書き込みロックが必要です）。

あなたはおそらくこれをすべて知っていますが、この素晴らしい研究を行うときはそれを覚えておいてください。

幸運を！

于 2012-04-27T14:55:46.923 に答える