4

Q：テストと開発のためのライフコピーに最適なアーキテクチャはどれですか？

現在の設定：

次のような2つのamazon/EC2mongodサーバーがあります。

Machine A:
    A production database (on an amazon/EC2 server) (name it ‘PROD’)
    Other databases (‘OTHER’)

Machine B:
    a pre-production database (name it ‘PRE’)
    a copy for developer 1 own tests (call it ‘DEVEL-1’)
    a copy for developer 2 (DEVEL-2)
    …DEVEL-n

PREデータベースは、本番環境にデプロイする前の統合テスト用です。

DEVEL-nは、他の開発者を煩わせることなく、各開発者が自分のデータを破棄するためのものです。

時々、PRODからPREおよびDEVEL-nベースに新しいデータを「復元」したいと考えています。

現在、.copyDatabase（）コマンドを介してPRODからPREに渡しています。次に、.copyDatabase（）を「n」回発行して、PREからDEVEL-nにコピーを作成します。

トラブル：

コピーには非常に長い時間がかかり（コピーあたり1時間、DBsizeが10GBを超える）、通常はMongodが飽和状態になるため、サービスを再起動する必要があります。

私たちは次のことを発見しました：

  • ダンプ/復元システム（.copyDatabase（）のように飽和します）
  • レプリカセット
  • マスター/スレーブ（非推奨のようです）

レプリカセットが勝者のようですが、深刻な疑問があります。

レプリカセットでライブA/PRODをB/PREに同期する必要があるとします（Aはプライマリであり、Bはセカンダリである可能性があります）。

a）PRODを複製するためにAから「いくつかの」データベースを選択できますが、OTHERはそのままにしておきますか？

b）マスターにない「追加の」データベース（DEVEL-nなど）をBに含めることはできますか？

c）PREにデプロイし、新しいデータでソフトをテストし、テストでデータを破棄し、テストが完了した後、レプリカを「再リンク」してPREの変更を削除し、 PRODの変更はPREに適切に転送されますか？

d）この場合に適したレプリカセット以外のより良い方法はありますか？

ありがとう。マリーナとシャビ。

4

2 に答える 2

1

レプリカセットが勝者のようですが、深刻な疑問があります。

レプリカセットでライブA/PRODをB/PREに同期する必要があるとします（Aはプライマリであり、Bはセカンダリである可能性があります）。

a）PRODを複製するためにAから「いくつかの」データベースを選択できますが、OTHERはそのままにしておきますか？

MongoDB 2.4と同様に、レプリケーションには常にすべてのデータベースが含まれます。設計の目的は、すべてのノードが結果整合性のあるレプリカになることです。これにより、同じレプリカセット内の非表示になっていない別のセカンダリにフェイルオーバーできます。

b）マスターにない「追加の」データベース（DEVEL-nなど）をBに含めることはできますか？

いいえ、レプリカセットにはプライマリが1つだけあります。

c）PREにデプロイし、新しいデータでソフトをテストし、テストでデータを破棄し、テストが完了した後、レプリカを「再リンク」してPREの変更を削除し、 PRODの変更はPREに適切に転送されますか？

プライマリは1つしか存在できないため、同じレプリカセットで本番とテストの役割を混在させるユースケースは、想定した方法では不可能です。

ベストプラクティスは、予期しない相互作用が発生しないように、本番環境と開発/ステージング環境を分離することです。

d）この場合に適したレプリカセット以外のより良い方法はありますか？

転送する必要のあるデータの量を制限して、データベース全体（10Gb）を本番環境から毎回コピーしないようにするために、いくつかのアプローチをとることができます。レプリカセットはソリューションの一部として適していますが、PRE環境用に個別のスタンドアロンサーバーまたはレプリカセットが必要になります。

いくつかの提案：

これらのアプローチのいずれかを使用すると、バックアップをPRODからPREに転送するタイミングを制御したり、テスト後に前のポイントから再開したりできます。

于 2013-04-13T13:52:01.367 に答える
0

このセットアップでは、EBSスナップショットを使用して、ステージング環境で本番データベースをすばやく複製します。スナップショットは、バックアップサイクルの一部として数時間ごとに実行されます。ステージングで新しいDBサーバーを起動すると、最新のDBスナップショットが検索され、EBSドライブに使用されます。スナップショットの作成はほぼ瞬時に行われ、リカバリも非常に高速です。このアプローチも非常にうまくスケールアップします。実際には、巨大なシャーディングされたMongoDBインストールで使用しています。唯一の欠点は、AWSサービスに依存して実装する必要があることです。これは、場合によっては望ましくないことがあります。

于 2013-01-22T18:04:39.157 に答える