Search:

Search all manuals
Search this manual
Manual
Couchbase Server マニュアル 2.0
Community Wiki and Resources
Couchbase Server 2.0をダウンロード
Couchbase 開発者ガイド 2.0
クライアントライブラリ
Couchbase Server フォーラム
Additional Resources
Community Wiki
Community Forums
Couchbase SDKs
Parent Section
5 管理タスク
Chapter Sections
Chapters

5.8. クロスデータセンターレプリケーション(XDCR)

5.8.1. XDCRの用途
5.8.2. レプリケーションの設定
5.8.3. レプリケーション状態の監視
5.8.4. レプリケーションのキャンセル
5.8.5. REST経由でXDCR設定の変更
5.8.6. XDCRのリトライ設定の変更
5.8.7. XDCRでのデータ通信のセキュリティ
5.8.8. クラウドでのXDCRの使用
5.8.9. XDCRの動作の理解

クロスデータセンターレプリケーション(XDCR)はCouchbase Server 2.0での新しい機能です。これにより、自動的にクラスタ間およびデータバケットの間でデータを複製することができます。XDCRを使う主な利点は以下の2つです:

XDCRを使用するときは、送信元宛先クラスタを指定します。送信元クラスタとは、コピーしたい元となるデータのあるクラスタで、宛先クラスタは、レプリカ・データを格納したいクラスタです。レプリケーションを構成するときは、Couchbaseの管理コンソールを使用して、個々のクラスタの選択肢を指定します。

XDCRは、指定したバケット間および、指定したのクラスタ間でデータを複製し、レプリケーションは単方向または双方向のいずれかに構成できます。単一方向レプリケーションはXDCRが送信元から宛先に複製されることを意味します。一方、双方向レプリケーションはXDCRが送信元から宛先に複製し、また宛先から送信元へも複製を行います。レプリケーションを設定するCouchbaseの管理コンソールの使用方法の詳細については、「レプリケーションの設定」を参照してください。

クラスタ内の各データバケットについて複数のレプリカを作ることもできますし、異なる宛先のクラスタにXDCRレプリカを指定することもできます。クラスタAとBとの間で、双方向のレプリケーションを構成する場合、双方のクラスタのデータに対して変更を実行でき、変更は互いのクラスタで複製されます。XDCRで利用可能なソース元と宛先の設定を以下に示します。

図5.9 XDCRレプリケーション 送信元と宛先

XDCRレプリケーション 送信元と宛先

XDCRを使ったレプリケーションの設定をするとき、送信元バケットに対し、一つもしくは複数の宛先を指定することができます。同様に、特定の宛先バケットに対し1つ以上の送信元バケットを指定することができます。レプリケーションは、1つ以上の送信元バケットと1つ以上の宛先バケットとの間で、単方向または双方向の両方を設定することができます。

CouchbaseのServer 2.0は現在、データの連続レプリケーションをサポートしています。これは、送信元クラスタ上のデータを変更した場合、データは送信元クラスタで永続化された後に、宛先クラスタに複製されることを意味します。

XDCRには、 クラスタ対応機能というものもあります。これは、宛先または送信元のクラスタ内のノードがダウンしたときにも、更新されたクラスタ情報を取得することが可能であるということであることを意味します。更新されたクラスタ情報を使用して、XDCRはまだ宛先クラスタで機能しているノードにデータを複製することができます。

例えば、AとBという2つのクラスタを持っていたとして、一つ目のクラスタには2つの送信元ノードが、2つ目のクラスタには2つの宛先ノードがあったとします。そこで、宛先ノードの1つが利用できなくなった場合は、送信元クラスタはクラスタBについての更新された情報を取得出来ます。そして、クラスタBの上で機能しているノードにレプリカデータを作成するためにこの情報を使うことができます。送信元クラスタ内のサーバーに障害が発生した場合も同様に、送信元クラスタ内の既存のサーバが障害を検出し、障害の発生したサーバーからの複製作業を引き継ぐことができます。 XDCRを利用することで、送信元クラスタで稼動中のサーバーから宛先クラスタにレプリケーションを継続することができます。宛先クラスタは、宛先クラスタ内の障害サーバーからレプリケーションのワークロードを引き継ぐことができ、送信元クラスタのサーバーに障害が起きたかを判断することができます。

効率化のために、Couchbase Serverは、ディスク上に格納されるのを待っている情報を重複しないようにできます。例えば、CouchbaseServer内の同一ドキュメントに対して5つの変更があり、それら5つがすべてキューとして待っていた場合、サーバーは最終の変更のみをディスクに書き込みます。XDCRによって複製されたアイテムは、ディスク上にあるため、宛先クラスタに複製されたドキュメントは、送信元クラスタからの最終変更バージョンとなります。XDCRは送信元クラスタで永続されたデータを複製し、宛先のRAMにデータのコピーを作ります。このことにより、宛先クラスタ上の複製データは、高速に読み書きすることができます。

CouchbaseのXDCRは、送信元と宛先クラスタ両方のドキュメントの一貫したバージョンを提供することができ、コンフリクト問題を解決します。XDCRにおけるコンフリクト解決のための最も基本的なルールは、更新の多いドキュメントが勝者とみなされることです。つまり、重複したドキュメントがあれば、更新の多いほうが最新とみなされるということです。勝者であるドキュメントが送信元クラスタ内にあり、クラスタが単一方向レプリケーションである場合は、宛先クラスタに複製されます。勝者となったドキュメントが宛先クラスタ内にあった場合で、双方向レプリケーションが設定されていた場合は、送信元クラスタに複製されます。

異なるレプリケーション構造や利用可能なスキーマについての詳細や例は以下を御覧ください「XDCRの用途」

XDCRの機能や実装法や制限については以下を御覧ください「XDCRの動作の理解」

複製を作成したり設定するためのガイドは、以下を参照してください「レプリケーションの設定」