5

は、次のシナリオを検討中でありCouchDBレプリケーションは、失敗/回復されたサーバでどのように動作しますか?

3つのEC2インスタンス:

  • 米国-WEST
  • アイルランド
  • 東京

各インスタンス専用のCouchDBサーバです。各CouchDBサーバーは、他のすべてのサーバーとの連続レプリケーション(双方向)を実行するように設定されています。

ここで、アイルランドのサーバーがAWSの停止によってオフラインになったとします。 US-WESTとTokyo CouchDBサーバーはX回再試行し、最終的にそのサーバーとの複製に失敗します(これは間違いありません)。

6時間後にAWSが領域をオンラインに戻し、サーバーが戻ってきます

アイルランドのCouchDB _replicator擬似セッティング: - まで私は、US-WESTと東京はアイルランドのCouchDBのサーバーの再起動し、それらの両方との双方向の同期、ラまでアイルランドでサーバーを無視すると仮定します

  • replicate [source = localホスト、ターゲット=米国西部]
  • 複製[ソース=米国西部、ターゲット= localhostの]
  • 複製[ソース= localhostを、ターゲット=東京]
  • 複製[ソース=東京、ターゲット= localhostの]

Q1:Couchのレプリケーションの失敗/復旧についての私の理解は正しいですか?

Q2:1時間後にネットワーク障害が発生した場合(具体的には、起動時に再起動するようにサーバーを再起動する必要はありません)、それぞれのCouchDBインスタンスはどのようにこれに反応しますか?私たちは西と東はアイルランドを忘れるだろうと思っていますが、アイルランドは突然二人のサーバーと再び話し始め、双方向の連続複製を再初期化しますか?

私は特にEC2環境での障害復旧に関心があります。その環境に具体的な詳細がある場合は、私に知らせてください。

ありがとうございます!

答えて

4

1より前のバージョンでは、レプリケーションタスクは永続的ではなく、継続的なタスクでもありません。切断された場合、再試行する試みは限られていますが、最終的には停止します。接続が再開されると、再度複製を開始する必要があります。レプリケーションは等冪なので(同じレプリケーションタスクを2回起動するのは同じものを2回起動するのと同じです)、毎分(または何らかの間隔が間違っているように見える)cronジョブを追加するだけです。タスクがすでに実行されている場合、試行は成功を返します(ただし、別のレプリケーションは開始しません)。

1.1では、特殊_replicatorデータベースにドキュメントを作成することで、永続レプリケーションタスクを作成できます。 CouchDB クラッシュまたは接続が中断された場合は、再試行してください。注:1.1.0は最終的に次のリリース(1.1.1)で無限再試行を許可します。

CouchDBはマルチマスターレプリケーションをサポートするように設計されているため、接続の中断が非常にうまく処理されていることに驚くことはありません。中断中に発生した変更は、迅速に検出され、複製されます。

+1

ロバート、それはちょうど素晴らしいです。 SimpleDB、RedisとMongoを使用した後、私は突然、カウチの複製へのこだわりを知り、私の頭の中で明かりが消えたようでした...突然、NoSQLのデータストア/永続性/安全性に関する私の痛みは消え去りました。このまっすぐ進む、シンプルで頑丈なシステムは、*ちょうど動作します*。明確化のために非常にありがとう! –

関連する問題