Version 1 by MC Brown
on Jan 11, 2012 07:45.

compared with
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (17)

View Page History
Tap provides a mechanism to observe from the outside data changes going on within a memcached server.

{note:title=Caution}

The TAP API is an internal Couchbase Server API, used by much of the core functionality of Couchbase Server. It is currently not intended or supported as an API for external use. The API may change between releases. TAP usage without a complete understanding of the interface and its server side implementation can have a severe impact on memory and IO on cluster nodes. The performance impact can be high enough that nodes or the cluster may not be effectively used by other client workload.

{note}\\
{note:title=Please Note}
In current releases of Membase Server, TAP is only implemented for Membase bucket types, not for memcached buckets
list vbuckets
Name (28-32): [node1]
VBucket list (33-40):
# listed (33-34): 0x0003 (3)
vbucket (35-36): 0x0000 (0)
list vbuckets, takeover vbuckets
Name (28-32): [node1]
VBucket list (33-40):
# listed (33-34): 0x0003 (3)
vbucket (35-36): 0x0000 (0)
{{REGISTERED_CLIENT}} ( =0x80=) contains no extra data and is to notify the tap server that we (the consumer) would like to create a tap connection where the tap connection will exist until we deregister the tap client. Deregistering a tap client can only be done through the deregister tap client command through the memcached front end.

\*Note: A registered tap connection that is not being read from will not allow closed checkpoints in the memcached engine to be purged from memory causing out of memory errors. Use of a registered tap connection is only recommended for expert Couchbase users.

An example tap stream request that specifies that we would like a registered tap client would look like this:
Name (28-32): [node1]
Backfill date(33-40): 0x0000000000000005 (5)
VBucket list (41-52):
# listed (41-42): 0x0005 (5)
vbucket (43-44): 0x0000 (0)
{code}

\*In Couchbase 2.0\+ the engine private field is used to specify the length of any meta data sent along with the key and value. This meta-data will be placed between the Item Expiry field and the Key field.

h4. Delete
{code}

\*In Couchbase 2.0\+ the engine private field is used to specify the length of any meta data sent along with the key and value. This meta-data will be placed between the Item Expiry field and the Key field.

h4. Flush
In an opaque message the engine private field contains control message that are used to signal to the receiving engine that the state of the tap stream has changed. Below is a list of engine private control values:

+TAP_OPAQUE_ENABLE_AUTO_NACK+ (0) - When the receiving node initiates a tap stream with a sending node the receiver may specify that it wants to receive acknowledgment messages from the sender. The receiver does this by specifying an ACK flag when creating the connection. If the sending node receives this flag it sends the TAP_OPAQUE_ENABLE_AUTO_NACK in order to signal that the sender supports acknowledgement messages.
+TAP_OPAQUE_INITIAL_VBUCKET_STREAM (1)+ - \- Signals the beginning of the backfill operation. Backfill takes place when the newest checkpoint in the receiving node is behind the oldest checkpoint in the sending node. Backfill takes a snapshot of both disk and memory on the sending node and streams it to the receiving node in order to get the receiving node up to date.
+TAP_OPAQUE_ENABLE_CHECKPOINT_SYNC (2)+ - \- Signals to the receiving node that the sending node supports checkpoints.
+TAP_OPAQUE_OPEN_CHECKPOINT (3)+ - \- Signals that we are at the beginning of an open checkpoint. This message is only sent if the tap stream is a registered tap stream.
+TAP_OPAQUE_START_ONLINEUPDATE (4)+ - \- This signal can be sent by either the sender or receiver. It tells whatever engine that receives it to stop persisting data and only keep things in memory.
+TAP_OPAQUE_STOP_ONLINEUPDATE (5)+ - \- This message can also be sent by the sender or receiver. It signals to the receiving node that the persistence should be resumed.
+TAP_OPAQUE_REVERT_ONLINEUPDATE (6)+ - \- This message can also be sent by the sender or receiver. It signals to the receiving node that everything received since the TAP_OPAQUE_START_ONLINEUPDATE should be deleted from the engine. Note that this will remove everything received by the engine after TAP_OPAQUE_START_ONLINEUPDATE is received including message not send through the memcached front end as well as other tap streams.
+TAP_OPAQUE_CLOSE_TAP_STREAM (7)+ - \- Sent by the sending node to signal that the sending node is finished sending data and is closing it's connection to the receiver.
+TAP_OPAQUE_CLOSE_BACKFILL (8)+ - \- Signals the end of the backfill.

\*Note: Online update is a feature that can be used to test cluster usage with the addition of new data. It is not recommended for use in normal production setting.

h4. Set vbucket