は、次のシナリオを検討中であり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環境での障害復旧に関心があります。その環境に具体的な詳細がある場合は、私に知らせてください。
ありがとうございます!
ロバート、それはちょうど素晴らしいです。 SimpleDB、RedisとMongoを使用した後、私は突然、カウチの複製へのこだわりを知り、私の頭の中で明かりが消えたようでした...突然、NoSQLのデータストア/永続性/安全性に関する私の痛みは消え去りました。このまっすぐ進む、シンプルで頑丈なシステムは、*ちょうど動作します*。明確化のために非常にありがとう! –