Couchbase Server 3.0の紹介

土田　行一

内容

• Couchbase Server 3.0で何が変わるのか？公開情報をもとに解説します。

• 拙訳ですが、元資料の訳文を添付します。

注意点

• 現在公開されている内容はベータ版に関する記述であり、正式版では内容が異なる可能性があります。

出典元について• 以下を参考資料として用いました。

http://docs.couchbase.comhttp://www.slideshare.net/Couchbase/webinar-

couchbase-30-beta-whats-new-in-30

Couchbase Server 3.0 • 最新版はCouchbase Server 3.0 Beta2です

New Features in 3.0No Title1 Database Change Protocol (DCP)2 Shared thread pool3 Tunable memory4 Disk I/O priority5 Stream-based views 6 Stream-based XDCR7 Graceful failover8 Delta node recovery9 Incremental backup and restore10 XDCR pause and resume replication11 Encrypted admin access/Encrypted data access12 Cluster-wide diagnostics

主にパフォーマンスアップ

主に信頼性向上

セキュリティ障害報告

Database Change Protocol (DCP)

• Bucketへのデータストリーミングのためのプロトコル(DCP)が追加されました。

• データストリーミングに該当するのは、クラスタ間のレプリケーション（レプリカデータ）、View、XDCR、バックアップ（インクリメンタル）です。

• Viewのデータ更新やXDCRのレプリケーション時のレイテンシを著しく低減する効果が期待できます。

• スナップショットの仕組みが組み込まれている様です。（現時点では断片的な情報）

Shared Thread Pool• 従来は特定のBucketと特定のスレッドが強く関連づけされていました。このためBucketを追加するだけでCPUリソースを圧迫し、パフォーマンスに影響が出ていました。

• 3.0ではBucketとスレッドを分離し、スレッドは共有化することになりました。このためスレッドは、どのBucketのためにも実行することができるようになり、より少ないスレッドワーカーでより多くのBucketを取り扱えるようになります。

• より効率的なI/Oリソース管理が可能になります。

• より多数のBucketが利用できるのでは？と期待しましたが、現時点では使用できるBucket数の上限は従来と同じ10のままです。

Shared Thread Pool

Tunable Memory• これまではドキュメントを削除する場合メタデータは削除されませんでした。

• 3.0ではメタデータも一緒に削除するオプション(Full Metadata ejection)が追加されました。

3000万件での比較 CB3.0 = 0.0８GB 　　CB2.5.1 = 3GB

Disk I/O Priority• BucketごとにI/O処理の優先順位を指定(High/Low)できるようになりました。

Stream Based Views

• DCPを利用し、ディスクに永続化する前にメモリ上でインデックスを作成するようになりました。

• View更新に伴うレイテンシの低減が期待できます。

• Stale=false/Stale=okの両方ともより最新の更新データが反映されるようになりました。

Stream Based XDCR• DCPを利用し、ディスクに永続化する前に、転送先のサーバに直接データ転送を行うようになりました

• データ更新に伴うXDRのレイテンシが低減され、データセンタ間のデータレプリケーションの時間ギャップが縮小します。

• 災害時にデータロスが生じる範囲が縮小します。

Graceful Fail Over• 動作中のオペレーションの完了を待って、データの一貫性を保った上でフェールオーバするGraceful Fail Overが追加されました。

• 例えばドキュメントの書き込みオペレーションが動作中の場合、レプリカデータのレプリケートの完了まで待ってフェールオーバします。

Delta Node Recovery• Fail Overにより一度クラスタから切り離したノードを再びクラスタに追加する際、差分更新により高速にリカバリを行うDelta Node Recoveryが追加されました。

Incremental Backup & Restore

• 従来のフルバックアップに加え、差分バックアップと、累積増分バックアップが追加されました。

Incremental Backup & Restore

• フルバックアップ／差分バックアップ／累積増分バックアップを組み合わせて利用できます。

XDCR Pause and Resume replication

• XDCRレプリケーション中にポーズ・再開するオペレーションが追加されました。

Encrypted Admin access• Web Consoleへの接続とREST APIへの接続を暗号化できるようになりました。

• 接続を暗号化するには以下の暗号化ポートからアクセスすることになります。

非暗号化ポート 暗号化ポート

Web Administration port

8091 18091

Couchbase API port 8092 18092

Encrypted Data access• クライアントからCouchbase Serverに接続する経路も暗号化するオプションが提供されました（アクセスポートは新しいポート番号11207を利用します）。

1. Couchbase ServerからSSL証明書を取得

2. SSL証明書をJVMキーストアに格納

3. reference.conf コンフィギュレションファイルを変更してSSLを有効化（以下設定例）

$ keytool -import -file certificate-file-name

com.couchbase.client.bootstrap { sslEnabled = true sslKeystoreFile = /path/to/keystorefile sslKeystorePassword = “" }

Java Clientの場合

Cluster-wide diagnostics• Web Consoleのログ出力方法が変更されました

Cluster-wide diagnostics• cbcollect_info相当のログ収集をWebコンソールから実施できるようになりました。 • ノード全体／特定のノードを選択できます。 • 収集したログを直接Couchbase社に送付することができるようになりました。

まとめ• 新しいデータ更新プロトコルであるDCPを中心とした機能強化が図られました。

• これにより、これまで常にささやかれていたView on the memoryが実現化されたのではないでしょうか。

• （訂正）上記記載は誤りであり、実際にはViewは依然としてファイル上に作成され、Viewを検索する際にはファイルを参照することが分かりましたので訂正いたします。

• また、Graceful fail overやDelta node Recoveryのような新規の障害対策も、DCPを活用して実現されているようです。

• 未だ不明な点も多いですが、Couchbaseが培ってきた低レイテンシ・高スループット・ハイスケーラビリティの製品としての良さを犠牲にすることなく、むしろその良さをさらに拡張していく開発姿勢が明確になったと考えます。

• 次の基盤としてまずは、良いスタートを切ったと言えるのではないでしょうか？

3.0はいつ正式リリースされるのか？

僕にはわかりません

可能性としては・・・

Couchbase connect

10/6 - 7 (米国時間)

翻訳文

01. Database Change Protocol!    データベース更新プロトコル"

Database Change Protocol (DCP) is the protocol used to stream data changes to buckets."データベース更新プロトコル(DCP)は、ストリームデータでバケットへ更新を行う際に使用されるプロトコルです。"

"The Database Change Protocol (DCP) is a streaming protocol that significantly reduces latency for view updates. With DCP, changes made to documents in memory are immediately streamed to be indexed without being written to disk."DCPはView更新時のレイテンシを著しく低減させる効果をもつ、ストリーミングプロトコルです。"

DCPを使用することにより、メモリ上で行われたドキュメント更新は、ディスクへの書込みを伴わずに直ちにインデックス作成のためストリーミングされます。"

This provides faster view consistency which provides fresher data. DCP reduces latency for cross data center replication (XDCR). Data is replicated memory-to-memory from the source cluster to the destination cluster before being written to disk on the source cluster."このプロトコルによる高速なデータ供給により、Viewには（従来と比較して）より迅速なデータ一貫性がもたらされます。"

DCPはXDCRによるレプリケーション処理のレイテンシも低減します。あるソース・クラスタから、ディスィネーション・クラスタへのレプリケーション処理は、ソースクラスタのディスクへの書込みよりも前に、メモリ－メモリ間で行われます。"

To work with DCP, you need to be familiar with the following concepts, which are listed in alphabetical order for convenience."DCPの動作の理解には、いくつかのコンセプトを理解する必要があります。以降にアルファベット順にリストしました。"

""

以下の翻訳文は、下記リンクの資料を元に新機能（全14機能）を順に資料の掲示順に翻訳したものです。理解の助けのため、各機能の解説毎に01-14までの番号を振りました。 http://docs.couchbase.com/prebuilt/couchbase-manual-3.0/Features/features.html

翻訳文Application client"アプリケーションクライアント"A normal client that transmits read, write, update, delete, and query requests to the server cluster, usually for an interactive web application."通常のクライアントです。これは読み込み、書き込み、更新、削除及びクエリリクエストをサーバクラスタへ送信します。"通常インタラクティブWebアプリケーションのために使用します。""DCP client"DCPクライアント"A special client that streams data from one or more Couchbase server nodes, for purposes of intracluster replication (to be a backup in case the master server fails), indexing (to answer queries in aggregate about the data in the whole cluster), XDCR (to replicate data from one cluster to another cluster, usually located in a separate data center), incremental backup, and any 3rd party component that wants to index, monitor, or analyze Couchbase data in near real time, or in batch mode on a schedule.""特別なクライアントです。これは1つかそれ以上のCouchbase Server ノードからデータをストリーミングします。"クラスタ間のレプリケーションの目的のため（マスターサーバに障害が起きた際のバックアップ（訳注：レプリカデータ））、インデクシング（クエリへの返答のため、クラスタ全体からデータをアグリゲートするため（訳注：Couchbase ServerのViewは、インデックスを各サーバに分散配置しているため、クエリへの返答時にデータをアグリゲートする動作を行う））、XDCR（クラスタから別のクラスタへデータをレプリケートする。通常各クラスタは異なるデータセンタに配置される）、インクリメンタルバックアップ、もしくはその他のサード・パーティ製のコンポーネントで使用します。（サード・パーティ製のコンポーネントは）インデキシング、モニタリングやCouchbase データをリアルタイムもしくは、スケジューリングされたバッチモードの中で分析するための用途で使用されるでしょう。""Failover log"フェールオーバ・ログ"A list of previously known vBucket versions for a vBucket. If a client connects to a server and was previously connected to a different version of a vBucket than that server is currently working with, the failure log is used to find a rollback point."直前のvBucketバージョン（後述）のリストです。もしもクライアントがサーバに接続し、この現在動作しているサーバとの接続が以前とは異なるvBucketのバージョンで接続されていたならば、フェーリアー・ログ（訳注：Failover logの意か）は、ロールバックポイントを発見するために使用されます。

翻訳文ヒストリー・ブランチ"

Whenever a node becomes the master node for a vBucket in the event of a failover or uncontrolled shutdown and restart, "

if it was not the farthest ahead of all processes watching events on that partition and starts taking mutations, it might reuse sequence numbers that other processes have already seen on this partition. "

This may be a history branch, and the new master must assign the vBucket a new vBucket version so that DCP clients in the distributed system can recognize that they are ahead of the new master and roll back changes at the point this happened in the stream. "

フェールオーバもしくは制御不能なシャットダウンやリスタートを契機として、（訳注：レプリカデータを保持している）ノードがそのvBucketのマスターノードになった場合に、仮にこれが、このパーティションのイベントを監視しているすべてのプロセスの中で、最も時間が長いものではなく、かつ（既に、データ）更新を開始しているならば、このパーティションを既に見ている他のプロセスのシーケンス番号を再利用するでしょう。"

これがヒストリーブランチです。新しいマスターノードは、（自ら保持している）vBucketを新しいvBucketバージョンに関連づける必要があります。（ヒストリーブランチにより）DCPクライアントは、新しいマスターのための先頭位置と、ロールバックによる変更がストリーム中のある時点で行われたことを認識することができます。"

During a controlled handover from an old master to a new master, the sequence history cannot have branches, so there is no need to assign a new version to the vBucket being handed off. "

Controlled handovers occur in the case of a rebalance for elasticity (such as adding or removing a node) or a swap rebalance in the case of an upgrade (such as adding a new version of Couchbase Server to a cluster or removing an old version of Couchbase Server)."

（通常の）制御可能下での古いマスターから新しいマスターへの委譲の間は、ヒストリー・ブランチを持つことはできません。（通常の）委譲に際して新しいバージョンのvBuketに関連づける必要性はありません。"

（通常の）制御可能下の委譲には、エラスティック（ノードの追加や削除）のためのリバランスや、アップグレード時(Couchbase Serverのバージョンアップや旧バージョンのCouchbase Serverの削除)のスワップ・リバランスが該当します。

翻訳文Mutation"ミューテーション"A mutation is an event that deletes a key or changes the value a key points to. Mutations occur when transactions such as create, update, delete or expire are executed."ミューテーションとは、Keyの削除もしくはKeyに対応するValue値の変更です。ミューテーションは、データ生成、データのアップデート、削除、そして有効期限切れの場合に発生します。"

"Rollback point"ロールバック・ポイント"The server uses the failover log to find the first possible history branch between the last time a client was receiving mutations for a vBucket and now. The sequence number of that history branch is the rollback point that is sent to the client."サーバは、クライアントがvBucketのためのミューテーションを受け取った最後の時点と、現時点との間で、最初の可能な履歴ブランチを発見するためにフェールオーバ・ログを使用します。このヒストリー・ブランチのシーケンス番号は、クライアントに送られたロールバックポイントとなります。"

"Sequence number"シーケンス番号"Each mutation that occurs on a vBucket is assigned a number, which strictly increases as events are assigned numbers (there is no harm in skipping numbers, but they must increase), that can be used to order that event against other mutations within the same vBucket. This does not give a cluster-wide ordering of events, but it does enable processes watching events on a vBucket to resume where they left off after a disconnect."vBucketが関連づけした番号上に起きた各ミューテーション、について、イベントがシーケンス番号を関連づけするごとに（シーケンス番号は）厳密に増分します（シーケンス番号がスキップすることでは影響は発生しないけれども、増分する必要があります）。これは、同じvBucketに対する他のミューテーションに対するイベントを順序づけるために使用されることになります。これは、クラスタ全体のイベントの順序づけのためには提供されませんが、接続遮断後に処理を再開する目的でvBucket上に起きたイベントを監視することを可能にします。

翻訳文Server：サーバー"

A master or replica node that serves as the network storage component of a cluster. For a given partition, only one node can be master in the cluster. If that node fails or becomes unresponsive, the cluster selects a replica node to become the new master."クラスタのネットワークストレージコンポーネントとして使用されるマスタノードもしくはレプリカノードを指します。"

与えられたパーティションごとに、クラスタ内でマスタとなれるのはただ一つのノードとなります。"

マスタノードに障害が発生したか、反応が無くなった場合、クラスタはレプリカノードの中から新たなマスタ（ノード）を選択します。"

Snapshot：スナップショット"

To send a client a consistent picture of the data it has, the server takes a snapshot of the state of its disk write queue or the state of its storage, depending on where it needs to read from to satisfy the client’s current requests. "This snapshot represents the exact state of the mutations it contains at the time it was taken. Using this snapshot, the server can send the items that existed at the point in time the snapshot was taken, and only those items, in the state they were in when the snapshot was taken. "Snapshots do not imply that everything is locked or copied into a new structure. In the current Couchbase storage subsystem, snapshots are essentially “free." The only cost is when a file is copy compacted to remove garbage and wasted space, the old file cannot be freed until all snapshot holders have released the old file. It’s also possible to “kick” a snapshot holder if the system determines the holder of the snapshot is taking too long. DCP clients that are kicked can reconnect and a new snapshot will be obtained, allowing it to restart from where it left off."一貫したデータをクライアントに送信するため、サーバはクライアントの現在のリクエストを満足するためにこれから読み込む必要性に応じて、ディスク・ライト・キューのステート、あるいはこのストレージのステートのスタップショットを取ります。このスナップショットには、これが取られた時点で含まれるミューテーションの実際のステートが示されています。このスナップショットを使用することで、サーバは、スナップショットが取られた時点で存在したアイテムに限りそのスナップショットが取られた時点のステータスで送信できます。

スナップショットは、新しい構造で全てがロックされたかコピーされたということを意味しません。現在のCouchbaseストレージ・サブシステムでは、スナップショットは本質的に”自由”です。唯一のコストは、コンパクションを行った際にファイルをコピーする点と、ディスクスペースを余分に使用する点です。古いファイルは、全てのスナップショット保持者が、古いファイルを開放する時点まで開放されません。もしもシステムが、スナップショットの保持者があまりにも長期間保持し続けたと判断した場合には、このスナップショット保持者を”キック”することもできます。キックされたDCPクライアントも再接続が可能であり、以後のリスタートを可能にするため、新しいスナップショットを取得することができます。

翻訳文vBucket"

Couchbase splits the key space into a fixed amount of vBuckets, usually 1024. Keys are deterministically assigned to a vBucket, and vBuckets are assigned to nodes to balance the load across the cluster."

Couchbaseは、キー空間を固定されたvBucketに分割します。通常これは1024個（訳注：OS X版のみ64個）です。キーはvBucketに確定的に関連づけられます。そしてvBucketは、クラスタ全体にロードバランシングするために各ノードに関連づけられます。"

vBucket stream"

vBucketストリーム"

A grouping of messages related to receiving mutations for a specific vBucket. This includes mutation, deletion, and expiration messages and snapshot marker messages. The transport layer provides a way to separate and multiplex multiple streams of information for different vBuckets. All messages between snapshot marker messages are considered to be one snapshot. A snapshot contains only the recent update for any given key within the snapshot window. It might require several complete snapshots to get the current version of the document."

特定のvBucketのためのミューテーションをレシーブすることを目的とした、関連メッセージのグルーピングです。これは、ミューテーション、削除、メッセージの有効期限切れ、そして、マーカーメッセージのスナップショットが含まれます。"

転送レイヤーは、異なるvBucketごとに、情報の複数ストリームを多重化したり分離するための方法を提供します。スナップショットは、スナップショット・ウインドウ内の全てのキーについての最新のアップデートのみが含まれます。ドキュメントのカレントバージョンを取得するためには、複数の完全なスナップショットを必要とするでしょう。"

vBucket version"

vBucketバージョン"

A universally unique identifier (UUID) and sequence number pair associated with a vBucket. A new version is assigned to a vBucket by the new master node any time there might have been a history branch. The UUID is a randomly generated number, and the sequence number is the sequence number that vBucket last processed at the time the version was created."

vBucketと関連づけられたUUIDとシーケンス番号のペアです。新しいバージョンは、ヒストリー・ブランチが存在したしたいかなる時点の新しいマスターノードに対してもvBucketと関連づけられるでしょう。UUIDはランダムに番号が生成されます。またシーケンス番号は、vBucketの新しいバージョンが生成された時点で最後に生成されたシーケンス番号となります。

翻訳文02. Shared thread pool!

    共有スレッドプール"

　　A shared thread pool is a collection of threads which are shared across multiple buckets."

　　共有スレッドプールは、複数のバケットに対して横断的に共有された、スレッドのコレクションです。"

A thread pool is a collection of threads used to perform similiar jobs. Each server node has a thread pool that is shared across multiple buckets."

Shared thread pool optimizes dispatch tasks by decoupling buckets from thread allocation."

スレッドプールはスレッドのコレクションで、類似のジョブを実行するのに適しています。各サーバノードは、スレッドプールを保持します。これは、複数のバケットを横断的に共有します。共有されたスレッドプールは、バケットからスレッド割当てを切り離すことにより、タスクのディスパッチを最適化します。"

Threads are spawned at initial startup of a server node instance and are based on the number of CPU cores."

スレッドは、サーバノードインスタンスの初期スタートアップ時に、CPUコア数に基づき生成されます。"

With the shared thread pool associated with each node, threads and buckets are decoupled. By decoupling threads from specific buckets, threads can run tasks for any bucket.Since the global thread pool allows for bucket priority levels, a separate I/O queue is available with the reader and writer workers at every priority level. This providesimproved task queueing. For example, when a thread is assigned to running a task from an I/O queue and a second task is requested, another thread is assigned to pick up the second task."

共有スレッドプールは各ノードに関連付けられ、スレッドとバケットは切り離されます。特定のバケットからスレッドを切り離すことにより、スレッドは、どのバケットのためにも実行することができるようになります。グローバル・スレッドプールは、バケットのプライオリティレベルを許容するので、個別のI/Oキューは、リーダ・ワーカーとライタ・ワーカーを、各プライオリティレベルで実行することができます。これは、タスクキューイングを改善します。例えば、あるスレッドがI/Oキューと二次タスクがリクエストされたことにより、ランニングタスクに割り当てられたとき、他のスレッドは、第二のタスクをピックアップして割り当てられます。

翻訳文Shared thread pool management promotes:"

・Better parallelism for thread workers with more efficient I/O resource management."

・Better system scalability with more buckets being serviced with fewer worker threads."

・Availability of task priority if the disk bucket I/O priority setting is implemented."

共有スレッドプールによる改善点："

・スレッドワーカのためのより良い並列性。より効率的なI/Oリソース管理。"

・より良いシステムスケーラビリティ、より少ないワーカスレッドによるより多くのバケットの提供。"

・タスク優先度の許容、（ディスクバケットI/Oプライオリティの設定が行われていた場合）。"

The following circumstances describes how threads are scheduled to dispatch tasks:"

・If all buckets have the same priority (default setting), each thread evenly round-robins over all the task queues of the buckets."

・If buckets have different priorities, the threads spend an appropriate fraction of time (scheduling frequency) dispatching tasks from queues of these bucket."

・If a bucket is being compacted, threads are not allocated to dispatch tasks for that bucket."

・If all buckets are either empty or being serviced by other threads, the thread goes to sleep."

スレッドのディスパッチに関するスケジュール方法の解説："

・全てのバケットが同じプライオリティ（デフォルト設定）の場合、各スレッドはラウンドロビンで割り当てられます。"

・バケットが異なるプライオリティの場合、スレッドは、適切な僅かな時間を費やし（頻繁にスケジューリングして）、これらのバケットのキューから（プライオリティの高い）タスクをディスパッチします。"

・バケットがコンパクションを行っている最中の場合は、このバケットのためのタスクのディスパッチを行いません。"

・すべてのバケットが空の場合、もしくは他のスレッドによりサービスされている場合は、スレッドは休眠します。

翻訳文Viewing thread status"スレッドステータスの照会"

The cbstats raw workload is used to view the status of the threads. The following is example code and results."

cbstats raw workload コマンドは、スレッドのステータスの照会に適しています。以下にサンプルコードと結果を掲載します。"

＜省略＞

翻訳文03. Tunable memory!　　チューナブルメモリ"

　　Tunable memory allows both value-only ejection and full metadata ejection from memory."

　　チューナブルメモリは、メモリからのValueのみのイジェクションと、メタデータも含めたイジェクションの両方を可能にします。"

The following summarizes the behavior of value-only versus full metadata ejection:"

以下のものは、Valueのみイジェクションと フルメタデータイジェクションの挙動を要約したものです。"

" •" Value-only ejection (the default) removes the data but keeps all keys and metadata in memory. When the value bucket ejection occurs, the item's value is reset."

" •" Full metadata ejection removes all data including keys, metadata, and key-values, thus, reducing the RAM requirement for large buckets." " •" Valueのみイジェクション（デフォルト）は、データを削除するが、すべてのキーとメタデータをメモリ中にキープします。その値についてバ

ケット・イジェクションが発生したとき、アイテムの値がリセットされます。"" •" フルメタデータ・イジェクションは、キーとメタデータを含めたすべてのデータを削除します。このことは、巨大なバケットのためのRAM要件を

削減します。""Full-bucket ejection supports very large data footprints (a large number of datasets or items/keys) since the working sets in memory are smaller. The smaller working sets allow efficient cache management and reduced warmup times. Metadata ejection is configured at the bucket-level."

フルバケット・イジェクションは、非常に大きいデータ（多数のデータセットあるいはアイテム／キー）フットプリントをサポートしており、メモリ中のワーキングセットがより小さくなります。より小さいワーキングセットは、効率的なキャッシュマネージメントを可能とし、ウォームアップ時間も低減します。メタデータ・イジェクションは、バケットレベルで設定します。"

For example, you might want to enable the full metadata ejection on that bucket if you need to store huge amounts of data (for example, tera or peta bytes)."

例えば、非常に巨大な量のデータ（例えば、テラバイト・ペタバイト）の格納を必要とするようなバケットの場合、フルメタデータ・イジェクションを可能にしたいと考えるかもしれません。

翻訳文

Backward compatibility!In previous releases, the values for all active data sets are ejected and the metadata and key value are not ejection. In version 3.0, both value and metadata and key value are ejected."

後方互換性"

以前のリリースでは、すべてのアクティブデータセットの値は、イジェクトされ、そしてメタデータとキーはイジェクトされませんでした。バージョン3.0では、値とメタデータとキー値はイジェクトされます。"

翻訳文04. Disk I/O priority：Disk I/Oプライオリティ!

Disk I/O priority allows workload priorities to be set at the bucket level."

Disk I/Oプライオリティは、バケットレベルでワークロードの優先順位づけを可能にします。 "

Bucket priority settings can be specified at the bucket-level. The bucket disk I/O priority can be set as either high or low, whereas, low is the default. Bucket priority settings determine whether I/O tasks for a bucket are enqueued in either low or high priority task queues. Threads in the global pool poll the high priority task queues more often compared to the low priority task queues. Bucket latency and I/O operations are impacted by the setting value. When a bucket has a high priority, its I/O tasks are picked up at a high frequency and, thus, are able to processed faster compared to tasks belonging to a low priority bucket."

バケットプライオリティ設定は、バケットレベルで指定できます。バケットディスクI/0プライオリティは、ハイやロウのどちらかを設定できます。"

デフォルトはロウです。バケットプライオリティ設定は、バケットのためのI/Oタスクを、低いもしくは高いプライオリティに応じてタスクキューにキューイングします。"

グローバルプール中にのスレッドは、低プライオリティタスクキューと比較して、より高頻度に、高プライオリティタスクキューにポーリングします。バケットのレイテンシとI/Oオペレーションは、設定値による影響を受けます。バケットが高い優先度であった場合、このI/Oタスクは、高い頻度でピックアップされます。これにより、低い優先度のバケットに属するタスクに比較して、より高速に処理されることが可能になります。"

The default buckets settings can be set during initial setup as well as be edited after setup. However, changing bucket priority after setup results in a restart of the bucket and reset of the client connections."

デフォルトバケット設定は、初期セットアップ中に設定できますし、後から設定することもできます。ただし、バケット優先度の変更は、バケットのリスタートと、クライアントのコネクションのリセット後に反映されます。"

Backward compatibility：後方互換性!

When upgrading from a 2.x release to a 3.x release, Couchbase converts an existing thread value to either a low or a high priority based on the following:"

バージョン2.x系から3.x系にアップグレードするときは、Couchbaseは、現存するスレッド値から、以下の条件により、低優先度もしくは高優先度にコンバージョンされます。"

" •" Buckets allocated six to eight (6-8) threads are high priority." " •" Buckets allocated three to five (3-5) threads are low priority." " •" 6-8スレッドにアロケートされていたバケットは、高優先度とする" " •" 3-5スレッドにアロケートされていたバケットは、低優先度とする

翻訳文05. Graceful failover!グレイスフル（上品な）フェィルオーバ―"

Graceful failover allows administrators to safely failover a node from the cluster after all in-flight operations are completed and without data loss."グレイスフル・フェイルオーバにより、管理者はクラスタからあるノードを全ての実行中のオペレーションが完了後、データロス無しに安全にフェールオーバすることを可能にします。"

With graceful failover, all in-flight operations are completed, for example, data in the process of being written to the node completes and is transferred to the replica vBuckets. The replica vBuckets are promoted to active vBuckets and the active vBuckets on the failed over node are transitioned to replica vBuckets. Because failover occurs after the replica vBuckert are synchronized with the active vBuckets, graceful failover might take more time to failover the node."

グレイスフル・フェイルオーバにより、全ての動作中のオペレーションは完了させられます。例えば、ノードに対する書き込みプロセス中のデータのデータ書き込みは完了し、レプリカvBucketにも転送されます。レプリカvBucketはアクティブなvBucketに昇格され、フェールオーバしたアクティブなvBacketは、レプリカvBucketにトンジションされます。フェールオーバが発生した後は、レプリカvBucketがアクティブなvBucketに同期された後に実施されるので、グレイスフル・フェールオーバは、（フェールオーバの完了までに）これまでのフェールオーバより多くの時間を必要とするでしょう。"

While the server node is being gracefully failed over (the in-flight operations are completing), the failover can be stopped. Subsequently, graceful failover can be restarted. When a node is failed over, it can be added back to the cluster via delta or fullrecovery."

サーバノードでグレイスフル・フェールオーバが実勢されている間（動作中のオペレーションは完了している）、フェールオーバは抑止させられます。"

その後、 グレイスフル・フェールオーバは（フェールオーバを）再開します。ノードがフェールオーバした時、のノードは、デルタあるいはフルリカバリを通じて、クラスタに再び追加しなおされる可能性があります。"

" •" When a node is added back to the cluster after a graceful failover has been performed, the replica vBuckets on the failed over node are resynchronized and promoted back to active."

" •" Topology changes (such as adding, removing, or failing over a server) after a graceful failover, initiates a different type of rebalance operation." " •" Each active vBucket on the failed over server node must have at least one replica vBucket for graceful failover, otherwise, hard failover is implemented." " •" ノードがグレイスフル・フェールオーバの後、クラスタに再び追加しなおされたとき、フェーフオーバノードの、レプリカvBucketは再度同期され、ア

クティブvBucketに復帰、昇格されます。"" •" グレイスフル・フェールオーバの後、（ノードの追加・削除・フェールオーバによる）トポロジの変更は、異なるタイプのリバランスオペレーション

を示します。"" •" フェイルオーバしたサーバノード上の各アクティブなvBucketは、グレイスフル・フェイルオーバのために、少なくとも１つのレプリカvBucketを持つ

必要があります。さもなければ、ハード・フェイルオーバが実行されます。

翻訳文Note:Hard failover immediately fails over a node from the cluster which might lead to data loss. Hard failover is typically used when the node is in a bad state. Auto-failover is a hard failover. ノート：ハード・フェールオーバは、クラスタから直ちにノードをフェールオーバさせ、データロースを引き起こす可能性があります。ハードフェールオーバは、典型的にはノードの状態が悪いときに使用されます。オートフェールオーバはハードフェールオーバです。

The following conditions must be met for graceful failover, otherwise, hard failover is implemented.

以下は、グレイスフル・フェールオーバのための適合条件です。条件に合致しない場合、ハード・フェールオーバが実行されます。

• The server node must be healthy. • Each active vBucket must have an equivalent replica bucket. • At least one (1) replica vBucket must be available. • サーバノードは健全な状態でなければなりません。 • 各アクティブvBucketは等価なレプリカバケットを持たなければなりません。 • 少なくとも1つのレプリカvBucketが利用可能でなければなりません。 For example:

例えば：

• In a 7 node cluster, if a bucket is configured for one replica, only one node can be gracefully failed over. • In a 7 node cluster, if a bucket is configured for two replica, two nodes can be gracefully failed over. • In a 7 node cluster, if a bucket is configured for three replica, three nodes can be gracefully failed over. • 7ノードクラスタの場合、対象バケットがレプリカ１ならば、１ノードに限りグレイスフル・フェールオーバが可能です。 • 7ノードクラスタの場合、対象バケットがレプリカ２ならば、２ノードまではグレイスフル・フェールオーバが可能です。 • 7ノードクラスタの場合、対象バケットがレプリカ３ならば、３ノードまではグレイスフル・フェールオーバが可能です。 "Graceful failover does not alter the number of active vBuckets (unlike hard failover), however, the number of replica vBuckets may reduce and not be equally distributed.

グレイスフル・フェールオーバは、アクティブなvBucketの数を変更しません。しかしながら、レプリカvBucketの数は削減され、かつ均等には配置されないでしょう。

翻訳文06. Delta node recovery!デルタノードリカバリ"

Delta node recovery allows nodes to be re-added to the cluster and incrementally caught up with the data changes."デルタノードリカバリは、クラスタに再び追加すべきノードとデータ更新のインクリメンタルな取戻しを可能にします。"

Delta node recovery allows a failed over node to be recovered by re-using the data on its disk and then resynchronizing the data based on the delta change. The failed over node is checked to identify the point when data mutations stopped and resynchronized beginning at that point. The server node catches up on data mutations for its vBuckets and starts serving data. Because the original data and data buckets are retained, the cluster starts functioning with minimal downtime. This operation improves recovery time and network resource usage."デルタノードリカバリは、ノードのフェールオーバを、ディスク上のデータを再利用し、その差分を元に再同期することにより、回復することを可能にします。"

フェールオーバされたノードは、データ変更が停止し、再同期が開始されたポイントを特定し、チェックされます。サーバノードは、該当するvBuketのデータ変更に追いつき、サービスを再開します。オリジナルデータと、データバケットは保留されているので、クラスタは、最小のダウンタイムで再開できます。このオペレーションは、リカバリタイムと、ネットワークリソースの使用量を改善します。"

Server nodes are removed from clusters under many circumstances. The following are circumstances (among many others) where a server node might be re-added to the cluster after being failed over."多くの状況により、サーバノードはクラスタから削除されることになります。"

以下が、その状況（その他も含めて）を示しています。サーバノードは、フェールオーバの後、クラスタに再度追加されます。"

" •" Node goes down for a short period of time" " •" Routine maintenance is scheduled" " •" Network connectivity is briefly disrupted" "" •" 短時間の間ノードがダウンした" " •" メンテナンス処理がスケジュールされた" " •" ネットワーク接続が、暫時切断された

翻訳文When a node is failed over, data files are preserved. The data files are used either for Couchbase support, data recovery, or delta node recovery."

ノードがフェールオーバされたとき、データファイルは温存されます。各データファイルは、Couchbase サポート、データリカバリ、もしくはデルタノードリカバリに利用されます。"

In the process of failing over a node, performing maintenance, adding the node back into the cluster, and rebalancing, data is recovered via either full recovery mode or delta recovery mode. With full recovery mode, the data files are removed from the failed over server node and then, during rebalance, the node is populated with new data files (active and replica vBuckets). With delta recovery mode, Couchbase detects (with the Database Change Protocol) which data files are up-to-date and which are out-of-date. During rebalance, the existing data files on the failed over server node are retained and the out-of-date files are updated."

フェールオーバノードの処理プロセスでは、メンテナンスを実行し、ノードをクラスタに再追加し、そしてリバランスします。データは、フルリカバリモードか、デルタリカバリモードを通じてリカバリされます。フルリカバリモードでは、データファイルはフェールオーバされたノードから削除され、その後リバランスの間に、ノードは新しいデータファイルを付随して追加されます(アクティブvBucketやレプリカvBucket)。デルタリカバリモードでは、Couchbaseは（DCPにより）、どのデータが更新され、どのデータが古いかを特定します。リバランス中、このフェールオーバされたノード上に存在するファイルと、古いデータについてはアップデートされます。"

"From the web console, the Delta Recovery and Full Recovery options display after the server node is failed over. Both recovery methods add the server node back into the cluster during the rebalance operation, however, full recovery removes the node's data prior to the rebalance and delta recovery schedules the node's existing data to be re-used."

Webコンソールからは、デルタリカバリと、フルリカバリオプションは、サーバノードがフェールオーバされた後に表示されます。どちらのメソッドも、リバランスオペレーションを通じて、そのサーバをクラスタに再追加します。しかしながら、フルリカバリはノードのリバランスを優先し、差分リカバリスケジュールや再利用可能なノードに存在するデータを削除します。"

翻訳文Delta recovery requirements:"

デルタリカバリ要件："

" •" A healthy server node and a healthy state for the cluster." " •" The server node is failed over. Delta recovery is not possible for a rebalance-in operation (add server) or rebalance-out operation (remove

server)."" •" Delta recovery must be possible for all buckets. For example, if delta recovery is possible for a subset of buckets but not possible for another

subset of buckets, then the Couchbase cluster does not permit a rebalance operation."" •" Because delta recovery relies on the existing data files on the failed over server node's disk, the exact same set of buckets must be transferred

to the failed over server node."・サーバノードは正常動作していること。クラスタは正常なステータスを示していること。"・サーバノードは、フェールオーバされていること。デルタリカバリは不可能、リバランス・インのオペレーション（サーバ追加）もしくはリバラ

ンス・アウト（サーバ削除）であること。"・デルタリカバリは、全てのバケットに対して使用可能であること。例えば、もしデルタリカバリがバケットのサブセットに対して可能であるが、

その他のサブセットに対しては不可能ならば、Couchbaseクラスタはリバランスオペレーションを許可しません。"・デルタリカバリはフェールオーバされたノードのディスクに存在するファイルに依存しているため、バケットのの正確に同じ集合は、フェールオー

バされたサーバに転送されることになります。""Delta recovery characteristics:"

デルタリカバリの特徴："

" •" Data files are "warmed up" into memory. Warmed up into memory means that data is loaded into memory. As a minimum, depending on whether metadata is retained in or not, all data file keys are loaded from disk prior to the rebalance operation."

" •" Indexes must be rebuilt on the server node that is being re-added." " •" Use in deployments where data size is much greater than RAM size, bucket eviction is set to full eviction (metadata is not retained in memory),

and indexes are not defined."・デルタリカバリはメモリへ”ウォームアップ”されます。メモリへのウォームアップとは、データがメモリへロードされることを意味します。少な

くとも、メタデータが、残存するか否かにより、全てのファイルのキーはリバランス処理び先立ち、ディスクからロードされます。"・再追加されたサーバノードのインデックスは再構築されます。"・データサイズがRAMサイズよりも大きい場合、バケットイジェクションは、フル・エビクション（メタデータはメモリ上に残存しない）に設定され、インデックスは定義されません。

翻訳文Tip:An environment with a large data footprint might use delta node recovery when re-adding a failed over server node."Tips:データフットプリントの大きな環境では、フェールオーバされたノードの再追加には、デルタノードリカバリが使用されます。"

Full recovery characteristics:"

フルリカバリの特徴："

" •" Data files are removed from the server node." " •" Indexes must be rebuilt on the server node that is being re-added." " •" A working set of documents is restored for the vBuckets that are being moved." " •" Use when the data size is smaller than the bucket quotas. In this case, moving data over the network and onto disk (full recovery) may be

faster than warming up data files (delta recovery)."・データファイルは、サーバノードから削除されます。"・インデックスは、サーバが再追加された時に再構築されます。"・ドキュメントのワーキングセットは、移動したvBucketのためにリストアされます。"・データサイズがバケットクオーターより小さい場合に使用されます。この場合、ネットワークを経由したデータのディスクへの移動（フルリカバ

リ）は、ウォーミングアップデータファイル（デルタリカバリ）よりも高速です。""Note:With full recovery, the disk is initialized and populated with active and replica buckets. This operation ensures a clean disk, but has overhead in terms of resource use and downtime due to disk re-population."注意：フルリカバリを使用することで、ディスクは初期化され、そして、アクティブとレプリカ（vBucket）が追加されます。このオペレーションは、ディスクをクリーンアップします。しかし、ディスクへの再投入を行うために、リソースのオーバヘッドとダウンタイムを必要とします。""" 2." Node 2 crashes." " 3." Rebalance is performed and fails." 2.ノード2が障害"3.レバランスが実行され、失敗する。

翻訳文Delta node recovery failure scenarios!デルタノードリカバリ障害シナリオ!

The following are conditions where delta node recovery either defaults to full recovery or is not available:"以下に、デルタノードリカバリもしくはフルリカバリが不可能な場合の条件を示します："

" •" If topology changes occur while a node is pending delta recovery, delta node recovery is impacted. For example, another node is added, a node is removed, or a node is swapped."

" •" If a down node is hard failed over and is marked for removal." " •" If rebalance-in-out operations are performed where the number of in and out nodes do not match (swap rebalance works in

this case)."" •" If certain bucket operations are performed while a node is pending delta recovery, delta node recovery is impacted. For

example, a new bucket is added, a bucket's replica configuration is changed, or a bucket is flushed."・トポロジ変更が、ノードがペンディング・デルタリカバリ中に発生し、デルタノードリカバリが影響を受けた場合。例えば、他

のノードが追加されたり、削除されたり、もしくはノードがスワップされた場合。"・ダウンしたノードが、ハードフェールオーバをし、削除対象としてマークされた場合。"・リバランスのイン・アウトオペレーションが、適合しない多数のイン・アウトノードにより実行された場合（スワップ・リバ

ランスが実行された場合が該当する）"・ノードがペンディング・デルタリカバリの状態の時に、特定のバケットオペレーションが、実行され、デルタノードリカバリが

影響を受けた場合。例えば、新しいバケットが追加されたり、バケットのレプリカ設定が変更されたり、バケットがフラッシュされたりした場合。"

"

翻訳文The provides detailed scenarios where delta node recovery either defaults to full recovery or is not available."以下の削除シナリオでは、デルタノードリカバリは、フルリカバリ若しくは使用不能となるかのいずれかとなります。"

" 1." Node 1 is failed over and delta recovery is specified. Now, Node 1 is pending delta recovery." " 2." Node 2, an active server, goes down.Note:The rebalance operation is not available." " 3." Fail over Node 2." " 4." Cancel the pending delta recovery, specify full recovery, and rebalance." " 5." Repair Node 2, add the server to the cluster, and rebalance." 1.ノード１は、フェールオーバし、デルタリカバリが指定された。ノード１は、ペンディング・デルタリカバリである。"2.ノード２は、アクティブサーバで、ダウンしようとしている。注意：リバランスオペレーションは使用不可である。"3.ノード２はフェールオーバした。"4.ペンディング・デルタノードがキャンセルされ、フルリカバリを指定し、リバランスを実行。"5.ノード2を修復し、クラスタに追加し、リバランスを実行""" 1." Node 1 is failed over, delta recovery is specified, and the rebalance operation is started." " 2." Node 1 crashes and the rebalance operation fails." " 3." Repair Node 1, re-start the server node, and rebalance. Node1 is added back to the cluster using full recovery." 1.ノード１は、フェールオーバし、デルタリカバリが指定され、リバランスオペレーションを実行。"2.ノード１は、クラッシュし、リバランスオペレーションが失敗。"3.ノード１を修復し、サーバノードを再スタートし、リバランスを実行。ノード１はフルリカバリを使用してクラスタに再度追

加。"

翻訳文

The bucket operations that cause rebalance to fail are adding bucket, changing replica configuration, or flushing bucket"リバランスが失敗させる原因となるバケットオペレーションは、バケット追加オペレーション、レプリカ設定の変更、バケットのフラッシュオペレーションです。"

" 1." Node 1 is failed over, delta recovery is specified, and then a bucket operation is performed." " 2." Rebalance is performed and fails." " 3." Cancel the pending delta recovery, specify full recovery, and rebalance." 1.ノード1は、フェールオーバし、デルタリカバリが指定され、その後バケットオペレーションが実行された。"2.リバランスが実行され、失敗。"3.ペンディング・デルタリカバリがキャンセルされ、フルリカバリが指定され、リバランスを実行。""Note:Bucket deletion does not lead to delta recovery failure."" 1." Both Node 1 and Node 2 are failed over, delta recovery is specified." " 2." Node 2 crashes." " 3." Rebalance is performed and fails." 注意：バケットの削除は、デルタリカバリの引き金にはなりません。"1.ノード1とノード2の両方ともフェールオーバし、デルタリカバリが選択された。"2.ノード2がクラッシュ。"3.リバランスが実行され、失敗。"

翻訳文07. Incremental backup and restore：インクリメンタルバックアップ・リストア"

Incremental backup and restore enables administrators to quickly back up only modified data in the database, making backup and restore more efficient for larger data"インクリメンタルバックアップ・リストアは、管理者に、データベース中で変更されたデータのみの、高速なバックアップを可能にします。より大きなデータセットに対するバックアップやリストアでより効果を発揮します。"

The purpose of an incremental backup is to back up only data that has changed since the previous backup. Incremental backups provide the following benefits:"インクリメンタルバックアップの目的は、１つ前のバックアップから変更されたデータのみをバックアップするものです。インクリメンタルバックアップは、以下の利益を提供します。"

" •" More options for backup strategies" " •" Greater flexibility in the restoration process" " •" Reduces the amount of time needed for daily backups" " •" Reduces the amount of disk storage needed for backups" " •" Reduces bandwidth usage when backing up over a network" "" •" バックアップ戦略のためのより多くのオプションの提供" " •" リストアプロセスのより柔軟性の提供" " •" 日時バックアップに要する時間の削減" " •" バックアップに要するディスクストレージの量の削減" " •" ネットワーク越しのバックップ時に要する帯域幅の削減" When you need to recover data, the restoration process uses the last full backup and one or more incremental backups. In addition to full backups, Couchbase Server offers the following types of incremental backups:"データのリカバリが必要なとき、リストアプロセスは、最新のフルバックアップと、その後のインクリメンタルバックアップを使用します。"

フルバックアップに加え、Couchbase Serverは、以下のタイプのインクリメンタルバックアップを提供します。"

" •" Differential incremental backup" " •" Cumulative incremental backup" " •" 差分インクリメンタルバックアップ" " •" 累積増分インクリメンタルバックアップ

翻訳文Differential incremental backup!差分インクリメンタルバックアップ"Differential incremental backups contain only the database changes that occurred since the last backup. Differential backups are created quickly because less data is backed up, but restorations from differential backups take longer than restorations from cumulative incremental backups."

差分インクリメンタルバックアップは、最後のバックアップからの変更のみを取得します。"

差分バックアップは、データバックアップの量が少ないために、高速に生成されますがが、累積増分バックアップに比べてリストアには多くの時間を要します。"

The following figure shows an example of a differential incremental backup strategy. Every Sunday, a full backup is made. On the other days of the week, a differential incremental backup is made."

以下の図は、差分インクリメンタルバックアップ戦略の例を示しています。"

毎日曜日、フルバックアッップが生成され、それ以外の日は差分インクリメンタルバックアップが生成されます。"

In this example, the Monday backup contains the changes made since the full backup on Sunday, the Tuesday backup contains the changes made since the Monday backup, the Wednesday backup contains the changes made since the Tuesday backup, and so on. If, for example, a restore operation is performed on Wednesday, the restoration process uses the full backup from Sunday and the differential incremental backups from Monday and Tuesday."

この例では、月曜日のバックアップは、日曜日のフルバックアップからの変更分が含まれます。火曜日のバックアップには、月曜日からのバックアップからの変更分が含まれます。水曜日のバックアップには、火曜日のバックアップからの変更分が含まれます。"

例えば、リストアオペレーションが水曜日に実行された場合、リストアプロセスは、日曜日のフルバックアップと月曜日と火曜日の差分インクリメンタルバックアップを使用します。"

翻訳文

Cumulative incremental backup!累積増分インクリメンタルバックアップ"Cumulative incremental backups contain all changes that occurred since the last full backup. Restorations from cumulative backups are faster than restorations from differential backups, but cumulative backups require a longer backup window and use more disk space than differential backups."

累積増分インクリメンタルバックアップは、直前のフルバックアップまでの全ての変更が含まれます。累積増分インクリメンタルバックアップからのリストアは、差分バックアップよりも高速である。しかし、累積増分バックアップは、より長いバックアップウインドウと、差分バックアップよりもより多くのディスクスペースを使用します。"

The following figure shows an example of a cumulative incremental backup strategy. Every Sunday, a full backup is made. On the other days of the week, a cumulative incremental backup is made."

以下の図は、累積増分インクリメンタルバックアップ戦略の例を示しています。"

各日曜日にフルバックアップが生成されます。他の日には、累積増分バックアップが生成されます。"

In this example, the Monday backup contains all the changes made since the full backup on Sunday, the Tuesday backup contains all the changes made since the full backup on Sunday, the Wednesday backup contains all the changes made since the full backup on Sunday, and so on. If, for example, a restore operation is performed on Wednesday, the restoration process uses the full backup from Sunday and the cumulative incremental backup from Tuesday."

この例では、月曜日のバックアップには、日曜日からのすべての変更が含まれます。火曜日のバックアップにも、日曜日からのすべての変更が含まれます。例えば水曜日にリストアオペレーションが実行される場合、リストアいは、日曜日のフルバックアップと、火曜日の累積増分バックアップを使用します。

翻訳文Combining incremental backup types!各インクリメンタルバックアップのコンビネーション"For greater flexibility in the restoration process, your backup strategy can include a combination of differential and cumulative incremental backups."リストアプロセスに対するより高い柔軟性のため、バックアップ戦略として、差分と累積増分のインクリメンタルバックアップのコンビネーションを選択することもできます。"

The following figure shows an example of a backup strategy that incorporates both differential and cumulative backups. Every Sunday, a full backup is made. For the remainder of the week, depending on the day, either a differential or cumulative incremental backup is made."以下の図では、差分バックアップと累積増分バックアプの両方を組み合わせたバックアプ戦略が示されています。"

各日曜日には、フルバックアップが生成されます。日によって、差分もしくは累積増分インクリメンタルバックアップのどちらかが生成されます。"

In this example, the backup schedule includes differential and cumulative incremental backups on different days. On Monday, Tuesday, Wednesday, Friday, and Saturday a differential incremental backup is made. On Thursday, a cumulative incremental backup is made. With this backup schedule, if a restore operation is performed on Saturday, the restoration process uses the full backup from Sunday, the cumulative incremental backup from Thursday, and the differential incremental backup from Friday."この例では、バックアップスケジュールは、差分及び累積増分インクリメンタルバックアプが異なる日付で含まれます。"

月曜日、火曜日、水曜日、金曜日、土曜日は、差分バックアップが生成されます。木曜日には、累積増分バックアプが生成されます。このバックアップスケジュールを使えば、もしも、リストアオペレーションが土曜日に実行されたとしても、リストアプロセスは、日曜日のフルバックアップと、木曜日の累積増分インクリメンタルバックアップと、金曜日の差分バックアップを使用するだけで対応できます。

翻訳文08. Stream-based views：ストリームベースView!

Stream-based views reduce latency for view updates, providing faster view consistency and fresher data."ストリームベースViewは、View更新に伴うレイテンシを低減し、より高速にViewの整合性と、データの新鮮さを保つ機能を提供します。"

 This feature uses the new streaming protocol, Database Change Protocol (DCP)."この機能は、新しいストリーミングプロトコルである、データベースチェンジプロトコル（DCP)を利用します。"With DCP, data does not need to be persisted to disk before you can retrieve it with a view query. DCP offers the following benefits for views:"DCPを使って、データは、viewクエリを受けるためにディスクに永続化する必要がなくなります。DCPはviewについて以下の利点を提供します。"

" •" Views are updated with key-value data sooner." " •" Latency for view updates is reduced." " •" Views are more closely synchronized with the data." " •" Viewは、より早期に、キー・バリューデータをアップデートされる。" " •" Viewのアップデートにかかるレイテンシが削減される。" " •" Viewはデータとより緊密に同期さされる。" When you submit a view query, you can include a parameter that specifies your data freshness requirements. The name of the parameter is stale and it takes the following values:"Viewクエリを実行したとき、データの新鮮度についての要件を特定するパラメータを含めることができます。パラメータ名はstaleで、以下の値を取ることができます。"

" •" ok—The server returns the current entries from the index file." " •" update_after—The server returns the current entries from the index, and then initiates an index update." " •" false—The server waits for the indexer to finish the changes that correspond to the current key-value document set and then returns

the latest entries from the view index."" •" ok - インデックスファイルのカレントエントリを返却する。" " •" update_after - まず、インデックスのカレントエントリを返却し、その後にインデックスの更新を実行する。" " •" false - サーバは、カレントのキー・バリュードキュメントの組に関する変更に対するインデクスの実行を待ち、最新のviewインデク

スからのエントリを返却する。

翻訳文Every 5 seconds the automatic update process checks whether 5000 changes have occurred. If a minimum of 5000 changes occurred, an index update is triggered. Otherwise, no update is triggered. When triggered, the indexer requests from DCP all changes since it was last run. The default number of changes to check for is 5000, but that number can be configured by setting theupdateMinChanges option. The update interval can also be configured by setting the updateInterval option."

5000個のドキュメントの変更か、各5秒毎に、自動的にアップデートプロセスが起動します。最低5000個のドキュメントの変更がなされたならば、インデックス更新が励起されます。さもなければ、インデックス更新が励起されません。インデックス更新が励起されたとき、インデクス生成プロセスは、DCPから前回実行したもの以降の全ての変更をリクエストします。デフォルト値は5000個です。この数値はupdateMinChangesオプションの設定値により変更できます。アップデートインターバル時間は、updateIntervalオプションにより変更できます。"

When an application sends a query that has the stale parameter set to false, the application receives all recent changes to the documents, including changes that haven't yet been persisted to disk."

staleパラメータを付けて、アプリケーションがクエリを送付したときは、すべての最新変更を受け取ります。これには、ディスクに永続化されていないものも含まれます。"

Best practice:For better scalability and throughput, we recommend setting the value of the stale parameter to ok. With the stream-based views feature, data returned when stale is set to ok is closer to the key-value data, even though it might not include all of it."ベストプラクティス："より良いスケーラビリティとスループットのため、我々はstaleパラメータの値をokとすることを推奨しています。"ストリームベースのView機能では、staleがokとセットたとき、たとえそれが、全てのデータを含めていなかったとしても、よりキーバリューデータに緊密にデータが返却されます。

翻訳文09. Pause and resume replication!

    (XDCR)レプリケーションのポーズ・レジューム"

　　During XDCR replication, the process can be paused and resumed."

    XDCRレプリケーションの間、このプロセスをポーズしたりレジューム（再開）することが可能です。"

XDCR streams between the source and destination cluster can be paused and later resumed. After XDCR is resumed, data continues to replicate between the source and destination clusters starting from where it previously left off."

ソースクラスタと転送先クラスタ間のXDCRストリーム は、ポーズし、後にレジュームすることができます。"

XDCRがレジュームされた後、レジューム直前の時点から改めて再度スタートし、ソースクラスタと転送先クラスタとのデータのレプリケートを継続することができます。

翻訳文10. Stream-based XDCR:ストリームベースXDCR!

Stream-based XDCR collects data changes from memory on the source cluster and streams the data changes directly to memory on the destination cluster."

ストリームベースXDCRは、ソースクラスタのメモリ上のデータ変更を集め、これを転送先のクラスタのメモリーに直接ストリーミングします。"

Stream-based XDCR replication is available due to the Database Change Protocol (DCP), a stream-based protocol. Once the data changes are detected and streamed to the destination cluster's memory, each cluster persists the data to disk. On the source cluster, the data changes (in memory) are queued and then persisted to disk. Correspondingly, on the destination cluster, the data changes (stream to memory) are queued and then persisted to disk."

ストリームベースのXDCRレプリケーションは、DCPのストリームベースプロトコルを利用可能です。一度データの変更が特定され、転送先のクラスタのメモリにストリームされると、各クラスタはデータをディスクに永続化します。ソースクラスタで、データが（メモリ上で）変更されているならば、キューイングされ、ディスクに永続化されます。一方、転送先クラスタではこのデータ変更（メモリ上にストリーミングされる）は、キューイングされディスクに永続化されます。"

Stream-based XDCR replication provides:"

ストリームベースのXDCRレプリケーションは以下を提供します。"

" •" Lower latency, that is, the time gap between data replication" " •" High availability and disaster recovery" " •" Improves recovery point objective (RPO)" " •" Smaller data loss window" " •" 低レイテンシ、これは、データレプリケーションの時間ギャップを少なくする。" " •" 高可用性と、ディザスタリカバリ。" " •" リカバリポイントオブジェクト(RPO)の改善。" " •" データロス・ウインドウの縮小。" Backward compatibility：後方互換性!

" •" Changes are made automatically through the upgrade." " •" Only the source cluster has to be upgraded. The destination cluster accepts the data changes into memory." " •" アップブレードを通じて、自動的に変更されます。" " •" ソースクラスタのみ、アップグレードされるだけで、転送先クラスタは、メモリへのデータ変更を受け入れます。

翻訳文11. Encrypted admin access：管理者権限アクセスの暗号化!

Encrypted administrator access provides encrypted REST API access using Secure Socket Layer (SSL) authentication."

　管理者権限アクセスの暗号化は、SSL認証を使用し、暗号化されたREST APIによるアクセスを提供します。"

The encrypted communication allows a connection to be configured for security using Secure Sockets Layer (SSL) encryption. Encryption protects data-in-flight from a remote machines to a Couchbase cluster using SSL. A secure channel is established between the remote machine and the server."

暗号化されたコミュニケーションは、セキュリティのための設定としてSSLを使用してコネクションを行うことを可能にします。暗号化は、リモートマシンからSSLを使用しているCouchbase クラスタへの動作中のデータを保護します。セキュアなチャネルは、リモートマシンとサーバーとの間に確立されます。"

The server generates a self-signed certification for the initial node which is propagated throughout the server nodes in the cluster. If the self-signed certificate is regenerated or updated as part of setting up XDCR data encryption (or for any other reason), the certificate retrieved by the client must be obtained again before secure server communication is re-established. The secure connection is on the cluster-level (rather than bucket-level) and is through the dedicated HTTPS REST port, 18091 or the HTTPS CAPI port, 18092."

サーバは、初期ノードのために、自己署名証明書を生成し、これはクラスタ内のサーバノード全体に展開されます。もしもこの自己署名証明書が再作成された場合あるいは、XDCRデータ暗号化のサインアップにより更新された場合(あるいはその他の理由で)最新の証明書は、セキュアなサーバコミュニケーションが再確立する以前に再びクライアントから再取得されます。セキュアなコネクションは、専用のHTTPS RESTポートである1891もしくは、HTTPS CAPIポートである 18092を通じて、クラスタレベルで行われます（バケットレベルではありません）。"

Encrypted administrator access is used under a variety of situations:"" •" An administrator is physically located in a different data center." " •" An administrator is outside of the firewall." " •" An additional level of security is required." "暗号化アドミニストレータアクセスは、以下の様々な用途で使用されるでしょう："・管理者が物理的に異なるデータセンタに位置している。"・管理者がファイアーウォールの外側にいる。"・追加のセキュリティレベルが要求されている。

翻訳文Secure administrative access is configured using the same method used for encrypted client-server communication:"セキュアなアドミニストレーション・アクセスは、暗号化されたクライアントーサーバコミュニケーションを使用して、同じメソッドにて、設定されます："

" 1." Connect to the server through an unencrypted port, 8091 REST HTTP or 8092 CAPI HTTP, and using the administrator username and password." " 2." Retrieve the SSL self-signed certificate and store in a local file, for example, clusterCert.pem." " 3." Create the cluster remote reference using the an encrypted port, 18091 REST HTTP or 18092 CAPI HTTP, and enabling data encryption." 1.非暗号化されたポートである8091番ポートあるいは8092番ポートを通じてサーバに接続し、管理者権限のユーザ名とパスワードを入力"2.Couchbase Serverが自己作成する電子化証明書を取得する。例えばcluserCert.pemファイルとして格納する。"3.18091番ポートもしくは18092番ポートを使用して、クラスタ・リモート参照を作成し、データ暗号化を実現する。"Secure cluster REST API!

セキュアクラスタREST API!

The following summarizes the HTTP methods used for defining data encryption:"

以下に、暗号化設定を使用したHTTPメソッドを要約しますと："

Table 1. URI paths for secure communication"HTTP method　:HTTPメソッド!URI path :URIパス!Destription:解説!GET"/pools/default/certificate"Retrieves the SSL self-signed certificate from the cluster.：SSL自己証明書を取得する"GET"/pools/default/remoteClusters"Retrieves the remote cluster reference.：リモートクラスタ参照を取得する"POST"/pools/default/remoteClusters"Creates the remote cluster reference.：リモートクラスタ参照を生成する"PUT"/pools/default/remoteClusters"Modifies the remote cluster reference.：リモートクラスタ参照を変更する

翻訳文Retrieving the certificate：証明書の取得（例）!

curl http://10.5.2.54:8091/pools/default/certificate > ./clusterCert.pemSSL certificate：SSL証明書（例）!

-----BEGIN CERTIFICATE-----MIIC/jCCAeigAwIBAgIIE3jc9BofgigwCwYJKoZIhvcNAQEFMCQxIjAgBgNVBAMTGUNvdWNoYmFzZSBTZXJ2ZXIgOTRmYTE3YTUwHhcNMTMwMTAxMDAwMDAwWhcNNDkxMjMxMjM1OTU5WjAkMSIwIAYDVQQDExlDb3VjaGJhc2UgU2VydmVyIDk0ZmExN2E1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxaaXsKm06xxzzYqejDAO3qW1x6vLz9jcLdZkNQgxGk4+/ulrfK4PSLHARf4vml8Ev3bcOzCwfyDCp2/TCSX0qDTn4iBRp9CJtxVyY/xqWkYkld+GGtj28P0CtZ1UKOHCRB7KInzxesxITg/a0vsLM8GrcwFpmZEJjeY7HGdUuBRcoMfm2Yn28drmr92SNSsz+npdfEFkQloYStqemOOGh1Jn7ldU5rBj/B2zcvh6guDXKKz/bMMeCTX84BmkG3rmiKQwxyizuxtYi5u1BthCX3aO58lC9uRMja1lA5TrJnZOCRT24G6VTh2bYhN98W6YmvF9l4ESDR4I7nE8E6GteQIDAQABozgwNjAOBgNVHQ8BAf8EBAMCAKQwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDwYDVR0TAQH/BAUwAwEB/zALBgkqhkiG9w0BAQUDggEBAF0Bz2MpQoBEdOdDRix3j0/XGKjH7kI5zDFiOlUvANMeErVZf9kM8xqS7Yd3bCa2rjT1Y8BM3Sciurtrd/CyiTVzpXjQOR/K1AFtiBtuNb2Hx5SXvgeW4p4uNmK74u1UUNmAyb3mwSQ+duuqK/EfD4wTolPTZP5gcricyWI3qUCi3pTeCz/2jcAWn3DI4KVtlAsOy9sFFo4RxBDgmOuSklUAb8eu4e2XxcLJ++geYoum0VIKa3ygjpZ800PupwZZetjD8/6tfbYFuoBTXL+r27M9ArsOxkVbh3fDQ8b8qnr5sam1P7IfSzqq/Lq4vjh1mvred62zuJlMvY9KmNJUrqw=-----END CERTIFICATE-----Syntax for creating an encrypted server connection：暗号化サーバコネクションの生成構文（例）!

A POST to /pools/default/remoteClusters creates the remote cluster reference. Setting the demandEncryption to one (1) and providing the certificate name and location enables data encryption."

/pools/default/remoteClusters へのPOSTにより、リモートクラスタ参照を生成します。demandEncryptionを1に設定してデータ暗号化をエネーブルにします。証明書名とロケーションを指定します。"

curl –X POST -u Admin:myPassword https://localHost:sslPort/pools/default/remoteClusters -d demandEncryption=[0|1] --data-urlencode "certificate=$(cat clusterCert.pem)" Creating an encrypted server connection：暗号化サーバコネクションの生成（例）!

curl –X POST https://Administrator:asdasd@192.168.0.1:18091/pools/default/remoteClusters/ -d demandEncryption=1 --data-urlencode "certificate=$(cat clusterCert.pem)"

翻訳文12. Encrypted data access：データアクセスの暗号化!

Encrypted data access is a communication connection between the client and Couchbase Server cluster using Secure Sockets Layer (SSL).　　"データアクセスの暗号化は、クライアントとCouchbase Serverクラスタ間のコミュニケーションを、SSLを使って暗号化します。"

 Encrypted data access is a communication connection between the client and Couchbase Server cluster using Secure Sockets Layer (SSL)."

暗号化されたデータアクセスは、SSLを使用した、クライアントとCouchbase Serverクラスタとの間を接続するコミュニケーションの１つです。"

The encrypted data access allows client connections to be configured for security using Secure Sockets Layer (SSL) encryption. Client-to-Server encryption protects data-in-flight from client machines to a Couchbase cluster using SSL. A secure channel is established between the client and the server."

暗号化されたデータアクセスは、SSL暗号化を使用したセキュリティを担保するために設定されたクライアント接続を可能とします。クライアントーサーバ間の暗号化は、SSLを使用して、、クライアントマシンとCouchbaseクラスタ間の動作中のデータを保護します。セキュアなチャネルは、クライアントとサーバ間で確立されます。"

The server generates a self-signed certification for the initial node which is propagated throughout the server nodes in the cluster. If the self-signed certificate is regenerated or updated as part of setting up XDCR data encryption (or for any other reason), the certificate retrieved by the client must be obtained again before secure client-server communication is re-established. The secure connection is on the cluster-level (rather than bucket-level) and is through the dedicated HTTPS REST port, 18091 or the HTTPS CAPI port, 18092."

＜以下前セクションと同じなため省略＞"

The client sets up SSL communication with a Couchbase server cluster in the following manner:"

クライアントは、以下の様式に従って、Couchbase ServerクラスととSSLコミュニケーションを構築します。"

" 1." Connect to the server through an unencrypted port, 8091 REST HTTP or 8092 CAPI HTTP, and using the administrator username and password." " 2." Retrieve the SSL self-signed cCouchbasee and store in the client local file." " 3." Create the cluster destination reference using the an encrypted port, 18091 REST HTTP or 18092 CAPI HTTP, and enabling data encryption." ＜これも前セクションと同じなため省略＞"

Creating an encrypted client-server connection：暗号化クライアントーサーバ接続の生成（例）!

curl –X POST https://Administrator:asdasd@192.168.0.1:18091/pools/default/remoteClusters/ -d demandEncryption=1 --data-urlencode "certificate=$(cat clusterCert.pem)"

翻訳文HTTP method：HTTPメソッド!URI path:URIパス!Destription:解説!GET"/pools/default/certificate"Retrieves the SSL self-signed certificate from the remote cluster.：リモートクラスタからのSSL自己証明書の取得"GET"/pools/default/remoteClusters"Retrieves the remote cluster reference.：リモートクラスタ参照の取得""POST"/pools/default/remoteClusters"Creates the remote cluster reference.：リモートクラスタ参照の生成""PUT"/pools/default/remoteClusters"Modifies the remote cluster reference.：リモートクラスタ参照の変更""Syntax for retrieving the certificate!curl –X GET -u adminName:adminPassword http://localHost:Port/pools/default/certificate "Retrieving the certificate!curl http://10.5.2.54:8091/pools/default/certificate > ./clusterCert.pem"

翻訳文SSL certificate:SSL証明書（例）!

-----BEGIN CERTIFICATE-----MIIC/jCCAeigAwIBAgIIE3jc9BofgigwCwYJKoZIhvcNAQEFMCQxIjAgBgNVBAMTGUNvdWNoYmFzZSBTZXJ2ZXIgOTRmYTE3YTUwHhcNMTMwMTAxMDAwMDAwWhcNNDkxMjMxMjM1OTU5WjAkMSIwIAYDVQQDExlDb3VjaGJhc2UgU2VydmVyIDk0ZmExN2E1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxaaXsKm06xxzzYqejDAO3qW1x6vLz9jcLdZkNQgxGk4+/ulrfK4PSLHARf4vml8Ev3bcOzCwfyDCp2/TCSX0qDTn4iBRp9CJtxVyY/xqWkYkld+GGtj28P0CtZ1UKOHCRB7KInzxesxITg/a0vsLM8GrcwFpmZEJjeY7HGdUuBRcoMfm2Yn28drmr92SNSsz+npdfEFkQloYStqemOOGh1Jn7ldU5rBj/B2zcvh6guDXKKz/bMMeCTX84BmkG3rmiKQwxyizuxtYi5u1BthCX3aO58lC9uRMja1lA5TrJnZOCRT24G6VTh2bYhN98W6YmvF9l4ESDR4I7nE8E6GteQIDAQABozgwNjAOBgNVHQ8BAf8EBAMCAKQwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDwYDVR0TAQH/BAUwAwEB/zALBgkqhkiG9w0BAQUDggEBAF0Bz2MpQoBEdOdDRix3j0/XGKjH7kI5zDFiOlUvANMeErVZf9kM8xqS7Yd3bCa2rjT1Y8BM3Sciurtrd/CyiTVzpXjQOR/K1AFtiBtuNb2Hx5SXvgeW4p4uNmK74u1UUNmAyb3mwSQ+duuqK/EfD4wTolPTZP5gcricyWI3qUCi3pTeCz/2jcAWn3DI4KVtlAsOy9sFFo4RxBDgmOuSklUAb8eu4e2XxcLJ++geYoum0VIKa3ygjpZ800PupwZZetjD8/6tfbYFuoBTXL+r27M9ArsOxkVbh3fDQ8b8qnr5sam1P7IfSzqq/Lq4vjh1mvred62zuJlMvY9KmNJUrqw=-----END CERTIFICATE-----Syntax for creating an encrypted client-server connection：暗号化クライアントーサーバコネクションの生成構文（例）!

A POST to /pools/default/remoteClusters creates the remote cluster reference. Setting the demandEncryption to one (1) and providing the certificate name and location enables data encryption."

/pools/default/remoteClusters へのPOSTにより、リモートクラスタ参照を生成します。demandEncryptionを1に設定し、データ暗号化をエネーブルにし、証明書名とロケーションを指定します。"

curl –X POST -u Admin:myPassword https://localHost:sslPort/pools/default/remoteClusters -d demandEncryption=[0|1] --data-urlencode "certificate=$(cat clusterCert.pem)" Creating an encrypted client-server connection：暗号化されたクライアントーサーバ接続の生成（例）!

curl –X POST https://Administrator:asdasd@192.168.0.1:18091/pools/default/remoteClusters/ -d demandEncryption=1 --data-urlencode "certificate=$(cat clusterCert.pem)"

翻訳文13. Configuring clients for SSL： SSLのためのクライアント設定!

The Couchbase Server client libraries support client-side encryption using the Secure Sockets Layer (SSL) protocol."

Couchbase Serve Clientライブラリは、クライアント側のSSLプロトコルを使った暗号化をサポートします。"

 The Couchbase Server client libraries support client-side encryption using the Secure Sockets Layer (SSL) protocol. To enable SSL on the client-side, you need to get an SSL certificate from Couchbase Server, as described in Encrypted data access, and then follow the steps specific to the client you are using."

Couchbase Serverクライアントライブラリは、クライアント側のSSL暗号化をサポートしています。SSLをクライアント側で利用可能にするために、SSL証明書をCouhbase Serverから取得する必要があります。詳細は「データアクセスの暗号化」セクションで記述されています。また以下の手順により具体的な利用方法を説明します。"

The following clients support SSL:"

SSLをサポートしているクライアントライブラリは以下："

" •" Java" " •" .NET" " •" Node.js" " •" PHP" " •" C" "Configuring the Java client for SSL：Java クライアントにおけるSSL暗号化の設定方法!

To configure SSL for the Java client　＜以下翻訳は省略＞:"

" 1." Get the SSL certificate from Couchbase Server." " 2." Store the certificate in your Java virtual machine (JVM) keystore.$ keytool -import -file certificate-file-name" " 3." Enable SSL by modifying the reference.conf configuration file.Set sslEnabled to true, specify the path to the keystore, and provide the keystore

password, as shown in the following example:com.couchbase.client.bootstrap {

4. sslEnabled = true 5. sslKeystoreFile = /path/to/keystorefile 6. sslKeystorePassword = "" 7.}"

翻訳文Configuring the .NET client for SSL：.NetクライアントにおけるSSL暗号化の設定方法!

To configure SSL for the .NET client:<以下翻訳は省略>"

" 1." Get the SSL certificate from Couchbase Server." " 2." Store the certificate in the Microsoft Windows Trusted Root Certification Authorities certificate store." " 3." Enable SSL support on the client.You can enable SSL at either the cluster level or on a per-Bucket basis. Setting SSL support at the cluster level

means that all buckets within the cluster will use SSL. If you want to use SSL only on specific buckets, just configure your individual bucket to use SSL. Here's some examples:"

var config = new ClientConfiguration()

4.{ 5. UseSsl = true 6.}; 7.var cluster = new CouchbaseCluster(config); 8.using (var bucket = cluster.OpenBucket()) 9.{ 10. //all buckets opened with this configuration will use SSL 11.} 12. 13.var config = new ClientConfiguration 14.{ 15. BucketConfigs = new Dictionary<string, BucketConfiguration> 16. { 17. {"customers", new BucketConfiguration 18. { 19. UseSsl = true 20. }} 21. } 22. }; 23.var cluster = new CouchbaseCluster(config); 24.using (var bucket = cluster.OpenBucket("customers")) 25.{ 26. //only the customers bucket will use SSL 27.} " 28."

翻訳文

Configuring the Node.js client for SSL!To configure SSL for Node.js:"

" 1." Get the SSL certificate from Couchbase Server." " 2." Store the certificate in the appropriate certificate storage area for your environment." " 3." Pass an SSL scheme with your connection string when creating your cluster object, as shown in the following example:var couchbase =

require('couchbase'); 4.var myCluster = new couchbase.Cluster('couchbases://10.1.1.1'); 5.var myBucket = myCluster.openBucket();" "Configuring the PHP client for SSL!To configure SSL for PHP:"

" 1." Get the SSL certificate from Couchbase Server." " 2." Store the certificate in the appropriate certificate storage area for your environment." " 3." TBD" "Configuring the C client for SSL!To configure SSL for C:"

" 1." Get the SSL certificate from Couchbase Server." " 2." Store the certificate in the appropriate certificate storage area for your environment." " 3." Pass an SSL scheme with your connection string when creating your cluster object, as shown in the following

example:cropts.v.v3.connstr = "couchbases://securehost.net/mybucket?ca_path=server_ca.pem";"

翻訳文14. Cluster-wide diagnostics!クラスター全体の診断"

The Couchbase support team uses logs and other system diagnostics to analyze customer issues."

Couchbase サポートチームは、ログと他のシステムの診断結果を、顧客の問題を分析するために使用します。"

If you contact Couchbase customer support, you might be asked to collect diagnostics from your cluster. Couchbase Server offers several methods that enable you to efficiently collect diagnostics for an entire cluster. To collect diagnostic information, you can use either the web console, the command-line interface, or the REST API."

Couchbaseカスタマーサポートにコンタクトする場合、使用しているクラスタの診断情報を収集することを求められる可能性があります。Couchbase Severは、クラスタ全体を対象に、効率よく診断情報を収集するいくつかの手段を提供します。診断情報を収集するためには、Webコンソール、コマンドラインインタフェース、若しくはREST APIを使用することができます。