レプリケーションはバケット単位で構成されます。クラスタ内のすべてのバケットからデータをレプリケートしたい場合、各バケットのレプリケーションを個別に構成する必要があります。

前回のレプリケーション以降に発生したドキュメントの変更のみが、宛先クラスタへレプリケートされます。Couchbase Serverはレプリケーション中に使用される個々のvBucketでチェックポイントを使用するので、最後のチェックポイント以降の変更のみがレプリケーションが再起動されたときに転送されます。

レプリケーションはあるクラスタから別クラスタへの単一方向の処理です。2つのクラスタ間での両方向のレプリケーションを構成するには、2つの別々のレプリケーションストリームを設定する必要があります。あるストリームはクラスタAからクラスタBへの変更をレプリケーションして、別のストリームはクラスタBからクラスタAへの変更をレプリケーションします。

各クラスタで同じ構成を提供する必要はなく、各クラスタで異なるノード数で、異なるRAM、永続化構成を持つことができます。XDCRもクラスタ対応です。これは送信元もしくは宛先クラスタでのノードがもはや利用可能でない場合、XDCRは更新されたクラスタ情報を受信して、利用可能なノードでレプリケーションを継続することができることを意味します。

各クラスタ内のすべてのノードは、宛先クラスタ内のすべてのノードと通信するように構成する必要があります。XDCRは、2つのクラスタ間でレプリケーションするために、クラスタ内の任意のノードを使用します。

Couchbase Serverのバージョンとプラットフォームは一致している必要があります。Linuxベースのクラスタからレプリケーションしたい場合、もうひとつのLinuxベースのクラスタなどにXDCRを設定する必要があります。

送信元クラスタを指定するとき、すべてのXDCRレプリケーションと構成は、送信元クラスタによって駆動されます。XDCRがクラスタAからクラスタBに情報をレプリケートするとき、クラスタAはレプリケートされなければならないドキュメントを決定する役割があります。

XDCRは構成済みバケットの個々のノードのvBuckets間で直接レプリケーションを実行します。したがって、各クラスタ内のすべてのノードは、2つのクラスタ間の情報交換の直接的な役割があります。

XDCRがレプリケーションを実行するとき、TCP/IPの8092ポート経由でクラスタ間のデータを交換します。Couchbase Serverはクラスタの構成情報を交換するためにTCP/IPの8091ポートを使用します。

XDCRは、断続的なネットワーク障害に弾力性があります。ネットワークの中断が原因で宛先クラスタが利用できないとき、XDCRはレプリケーションを一時停止して、30秒ごとにクラスタへの接続のリトライをします。一旦宛先クラスタへ再接続が成功すると、レプリケーションを再開します。

宛先のクラスタが30秒以上利用不可能になるようなより長時間のネットワーク障害が発生すると、送信元クラスタは宛先クラスタのポーリングを継続し、様々な時間切れエラーとなるかもしれません。このケースでは、CouchbaseのWebコンソールでレプリケーションを削除し、システムの問題を修正したり、その後、レプリケーションを再作成します。新しいXDCRレプリケーションは、古いレプリケーションが停止していた場所からアイテムのレプリケーションを再開します。

構成は、ホストが再起動、リブートしても保持されます。システム障害が発生した場合、レプリケーション構成を再設定する必要はありません。

XDCRはドキュメントがディスクに書き込まれた後のみデータをレプリケートします。ディスクに永続化されていないRAMのドキュメントはレプリケートされません。

可能なとき、同じドキュメントへの複数の変更はデータ交換の量を減らし、レプリケーションに必要なネットワーク全体の帯域幅を減らすために、ひとつの変更のみがレプリケートされます。

XDCRは、ビューとビューインデックスをレプリケートしません。手動でクラスタ間のビュー定義を交換し、宛先クラスタ上でインデックスの再作成をする必要があります。

同じドキュメントは送信元と宛先クラスタで更新できるので、XDCRはドキュメントを比較し、どちらのドキュメントがもっとも新しく有効な変更を含んでいるかを決めるための自動的な競合解消機能を提供します。

送信元クラスタ上のUTF-8エンコード可能でないドキュメントIDは、自動的にフィルタリングされ、ログに記録され、リモートクラスタに転送されません。

XDCRは送信元と宛先クラスタ間で自動的に競合解消を実行し、個々のドキュメントがうまくレプリケートされるように変更を保証するよう設計されています。それぞれの格納されたドキュメントについて、XDCRは競合を解決するためのチェック値を作成するために次のアイテムを参照します：

競合解決の間、最も高いリビジョン番号を持つドキュメントを識別するまで、XDCRは順番に値を確認します。XDCRはレプリケーションのためにドキュメントのこの説明を使用します。アルゴリズムは一貫して送信元もしくは宛先クラスタのいずれかで、同じドキュメントを選択するように設計されています。

変更ドキュメントが最も高いリビジョン番号を持っていない場合、このドキュメントへの変更は格納されたり、レプリケートされません。代わりに最も高いリビジョン番号を持つドキュメントが優先され、使用されます。リビジョンコントロールは自動的に行われ、ドキュメントの手動補正や選択を必要としません。