Couchbase Enterprise 2.5：AWS、Rack Awareness、XDCR
Couchbase Enterprise 2.5には、Rack Awarenessが付属しています。これは、XDCRや追加の設定を必要とせずに、レプリカデータが個別のAWSアベイラビリティーゾーンに自動的に保持されることを示唆しています。
Rack AwarenessレプリケーションはXDCRとどのように比較されますか？
XDCRは何らかの点で異なりますか、帯域幅が優れていますか、変更を異なる方法で比較しますか、プロトコルは異なりますか？
AWSのベストプラクティスはどれですか：
- ラック認識のためのサーバーグループとしてアベイラビリティーゾーンを使用していますか？
- XDCRを使用して、別々のアベイラビリティーゾーンにある別々のクラスターを接続しますか？
RZAとXDCRは異なる目的のためのものです。 RZAはCouchbaseのクラスター内レプリケーションの一部であり、XDCRはクラスター間レプリケーション用です。
RZAが行うのは、クラスターのレプリカvBucket（シャード）を、プライマリvBucketがある場所とは異なるサーバーグループに保持することだけです。自動ではありません。サーバーグループを指定し、それらのグループにノードを移動または作成してから、クラスターをリバランスしてvBucketを移動し、時間の経過とともにノードをクラスターに出し入れするときにそのリストを維持する必要があります。複数のAWSゾーンの場合、たとえばUS-West-2のクラスターに6つのノードがあるとすると、各AZに2つのノードがあります。 Couchbaseには3つのグループがあり、各グループに2つのノードがあり、各グループはAZを表します。リバランスすると、グループ1のノード上のアクティブなvBucketに対応するレプリカvBucketは、常にグループ2または3になります。ドキュメント内の写真は、ここで参照するとよいでしょう。 http://docs.couchbase.com/admin/admin/Concepts/concept-rack-awareness.html したがって、RZAは、HAとフォールトトレランスのための標準のCouchbaseクラスター内レプリケーションと連携して機能しています。 。
一方、XDCRは、2つの完全に別個のクラスターがあることを意味します。したがって、クラスター間レプリケーションと言ったのはなぜですか。したがって、XDCRを使用して、DRの目的でリージョン1のクラスターAからリージョン2のクラスターBに、単方向または各双方向で複製できます。双方向複製を使用してアクティブ/アクティブで実行できますが、必ず実行する必要があります。今日の競合解決の方法を十分に認識し、それを念頭に置いてアプリケーションをコーディングし、競合解決がユースケースに適合することを確認してください。その競合解決は、Couchbaseの将来のバージョンのオプションを拡張するために積極的に取り組んでいるものですが、今日の競合解決のスタイルは1つだけです。また、同じ地域の両方のクラスターでXDCRを使用している人もいます。 1つはアクティブなもので、もう1つはバックアップの実行元、レポートなどです。 XDCRを使用してElasticSearchまたはSolrと統合することもできますが、それは別の議論です。私が見たXDCRの最も一般的な使用法は、データセンター間でのディザスタリカバリの複製です。暗号化されたXDCRを使用できるように、エンタープライズライセンスIMOを購入し、トラフィックがリージョン間で正しくルーティングされるようにAWSVPCを設定することをお勧めします。次に、このようなもののように、それらのリンクが常にアップしていることなどを監視しますが、これはCouchbaseに固有のものではありません。