Get desktop application:
View/edit binary Protocol Buffers messages
The API version the server and the client is using. See more details in https://github.com/tikv/rfcs/blob/master/text/0069-api-v2.md.
Used in:
, , , , , , , , ,`V1` is mainly for TiDB & TxnKV, and is not safe to use RawKV along with the others. V1 server only accepts V1 requests. V1 raw requests with TTL will be rejected.
`V1TTL` is only available to RawKV, and 8 bytes representing the unix timestamp in seconds for expiring time will be append to the value of all RawKV entries. For example: ------------------------------------------------------------ | User value | Expire Ts | ------------------------------------------------------------ | 0x12 0x34 0x56 | 0x00 0x00 0x00 0x00 0x00 0x00 0xff 0xff | ------------------------------------------------------------ V1TTL server only accepts V1 raw requests. V1 client should not use `V1TTL` in request. V1 client should always send `V1`.
`V2` use new encoding for RawKV & TxnKV to support more features. Key Encoding: TiDB: start with `m` or `t`, the same as `V1`. TxnKV: prefix with `x`, encoded as `MCE( x{keyspace id} + {user key} ) + timestamp`. RawKV: prefix with `r`, encoded as `MCE( r{keyspace id} + {user key} ) + timestamp`. Where the `{keyspace id}` is fixed-length of 3 bytes in network byte order. Besides, RawKV entires must be in `default` CF. Value Encoding: TiDB & TxnKV: the same as `V1`. RawKV: `{user value} + {optional fields} + {meta flag}`. The last byte in the raw value must be meta flags. For example: -------------------------------------- | User value | Meta flags | -------------------------------------- | 0x12 0x34 0x56 | 0x00 (0b00000000) | -------------------------------------- Bit 0 of meta flags is for TTL. If set, the value contains 8 bytes expiring time as unix timestamp in seconds at the very left to the meta flags. -------------------------------------------------------------------------------- | User value | Expiring time | Meta flags | -------------------------------------------------------------------------------- | 0x12 0x34 0x56 | 0x00 0x00 0x00 0x00 0x00 0x00 0xff 0xff | 0x01 (0b00000001) | -------------------------------------------------------------------------------- Bit 1 is for deletion. If set, the entry is logical deleted. --------------------- | Meta flags | --------------------- | 0x02 (0b00000010) | --------------------- V2 server accpets V2 requests and V1 transactional requests that statrts with TiDB key prefix (`m` and `t`).
Used in:
Used in:
Used in:
,Used in:
Used in:
,No assertion.
Assertion is enabled, but not enforced when it might affect performance.
Assertion is enabled and enforced.
Similar to a `Get` request.
Used as request type in: tikvpb.Tikv.KvBatchGet
Used as field type in:
Used as response type in: tikvpb.Tikv.KvBatchGet
Used as field type in:
Time and scan details when processing the request.
This KeyError exists when some key is locked but we cannot check locks of all keys. In this case, `pairs` should be empty and the client should redo batch get all the keys after resolving the lock.
Rollback a prewritten transaction. This will remove the preliminary data from the database, unlock locks, and leave a rollback tombstone.
Used as request type in: tikvpb.Tikv.KvBatchRollback
Used as field type in:
Identify the transaction to be rolled back.
The keys to rollback.
Reserved for file based transaction.
Used as response type in: tikvpb.Tikv.KvBatchRollback
Used as field type in:
Execution details about the request processing.
Used as request type in: tikvpb.Tikv.BroadcastTxnStatus
Used as field type in:
Used as response type in: tikvpb.Tikv.BroadcastTxnStatus
Used as field type in:
(message has no fields)
BufferBatchGet is introduced from the pipelined DML protocol. It is similar to a BatchGet request, except that it can only read the data that has been flushed by itself.
Used as request type in: tikvpb.Tikv.KvBufferBatchGet
Used as field type in:
Used as response type in: tikvpb.Tikv.KvBufferBatchGet
Used as field type in:
Time and scan details when processing the request.
Used as request type in: tikvpb.Tikv.CheckLeader
Used as response type in: tikvpb.Tikv.CheckLeader
Used as request type in: tikvpb.Tikv.CheckLockObserver
Used as response type in: tikvpb.Tikv.CheckLockObserver
Part of the async commit protocol, checks for locks on all supplied keys. If a lock is missing, does not have a successful status, or belongs to another transaction, TiKV will leave a rollback tombstone for that key.
Used as request type in: tikvpb.Tikv.KvCheckSecondaryLocks
Used as field type in:
Identifies the transaction we are investigating.
Used as response type in: tikvpb.Tikv.KvCheckSecondaryLocks
Used as field type in:
For each key in `keys` in `CheckSecondaryLocks`, there will be a lock in this list if there is a lock present and belonging to the correct transaction, nil otherwise.
If any of the locks have been committed, this is the commit ts used. If no locks have been committed, it will be zero.
Execution details about the request processing.
CheckTxnStatusRequest checks the status of a transaction. If the transaction is rollbacked/committed, return that result. If the TTL of the transaction is exhausted, abort that transaction and inform the caller. Otherwise, returns the TTL information for the transaction. CheckTxnStatusRequest may also push forward the minCommitTS of a large transaction.
Used as request type in: tikvpb.Tikv.KvCheckTxnStatus
Used as field type in:
Primary key and lock ts together to locate the primary lock of a transaction.
Starting timestamp of the transaction being checked.
The start timestamp of the transaction which this request is part of.
The client must specify the current time to TiKV using this timestamp. It is used to check TTL timeouts. It may be inaccurate.
If true, then TiKV will leave a rollback tombstone in the write CF for `primary_key`, even if that key is not locked.
This field is set to true only if the transaction is known to fall back from async commit. Then, CheckTxnStatus treats the transaction as non-async-commit even if the use_async_commit field in the primary lock is true.
If the check request is used to resolve or decide the transaction status for a input pessimistic lock, the transaction status could not be decided if the primary lock is pessimistic too and it's still uncertain.
Whether it's needed to check if the lock on the key (if any) is the primary lock. This is for handling some corner cases when a pessimistic transaction changes its primary (see https://github.com/pingcap/tidb/issues/42937 for details). This field is necessary because the old versions of clients cannot handle some results returned from TiKV correctly. For new versions, this field should always be set to true.
Reserved for file based transaction.
Used as response type in: tikvpb.Tikv.KvCheckTxnStatus
Used as field type in:
Three kinds of transaction status: locked: lock_ttl > 0 committed: commit_version > 0 rollbacked: lock_ttl = 0 && commit_version = 0
The action performed by TiKV (and why if the action is to rollback).
Execution details about the request processing.
Used in:
Cleanup a key by possibly unlocking it. From 4.0 onwards, this message is no longer used.
Used as request type in: tikvpb.Tikv.KvCleanup
Used as field type in:
The current timestamp, used in combination with a lock's TTL to determine if the lock has expired. If `current_ts == 0`, then the key will be unlocked irrespective of its TTL.
Used as response type in: tikvpb.Tikv.KvCleanup
Used as field type in:
Set if the key is already committed.
Used in:
,Normal is the default value.
The second phase of writing to TiKV. If there are no errors or conflicts, then this request commits a transaction so that its data can be read by other transactions.
Used as request type in: tikvpb.Tikv.KvCommit
Used as field type in:
Identifies the transaction.
All keys in the transaction (to be committed).
Timestamp for the end of the transaction. Must be greater than `start_version`.
commit_role indicates the current commit request is a primary commit or a secondary commit. It's value maybe `Unknown` when using a client with an old version.
primary_key indicates the primary key of the transaction. Its value may be empty when using an old version client.
Reserved for file based transaction.
Used as response type in: tikvpb.Tikv.KvCommit
Used as field type in:
If the commit ts is derived from min_commit_ts, this field should be set.
Execution details about the request processing.
CommitRole indicates the current commit request is a primary commit or a secondary commit.
Used in:
Unknown about the current request is a primary commit or a secondary commit;
Current request is a primary commit;
Current request is a secondary commit;
Used in:
Used in:
The calculated commit TS.
Used in:
Used in:
(message has no fields)
Used in:
(message has no fields)
Used in:
(message has no fields)
Used in:
(message has no fields)
Used as request type in: tikvpb.Tikv.Compact
If specified, the compaction will start from this start key. If unspecified, the compaction will start from beginning. NOTE 1: The start key should be never manually constructed. You should always use a key returned in CompactResponse. NOTE 2: the compaction range will be always restricted by physical_table_id.
The physical table that will be compacted. TODO: this is information that TiKV doesn't need to know. See https://github.com/pingcap/kvproto/issues/912
The logical table id of the compaction. When receiving parallel requests with the same logical table id, err_compact_in_progress will be returned. TODO: this is information that TiKV doesn't need to know. See https://github.com/pingcap/kvproto/issues/912
API version of the request
Keyspace of the table located in.
Used as response type in: tikvpb.Tikv.Compact
The compaction is done incrementally. If there are more data to compact, this field will be set. The client can request to compact more data according to the `compacted_end_key`.
Miscellaneous metadata attached to most requests.
Used in:
, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,True means execution time statistics should be recorded and returned.
True means RocksDB scan statistics should be recorded and returned.
Read requests can ignore locks belonging to these transactions because either these transactions are rolled back or theirs commit_ts > read request's start_ts.
After a region applies to `applied_index`, we can get a snapshot for the region even if the peer is a follower.
A hint for TiKV to schedule tasks more fairly. Query with same task ID may share same priority and resource quota.
Not required to read the most up-to-date data, replicas with `safe_ts` >= `start_ts` can handle read request directly
Any additional serialized information about the request.
Used to tell TiKV whether operations are allowed or not on different disk usages.
Indicates the request is a retry request and the same request may have been sent before.
API version implies the encode of the key and value.
Read request should read through locks belonging to these transactions because these transactions are committed and theirs commit_ts <= read request's start_ts.
The informantion to trace a request sent to TiKV.
The source of the request, will be used as the tag of the metrics reporting. This field can be set for any requests that require to report metrics with any extra labels.
The source of the current transaction.
If `busy_threshold_ms` is given, TiKV can reject the request and return a `ServerIsBusy` error before processing if the estimated waiting duration exceeds the threshold.
Some information used for resource control.
The keyspace that the request is sent to. NOTE: This field is only meaningful while the api_version is V2.
The buckets version that the request is sent to. NOTE: This field is only meaningful while enable buckets.
It tells us where the request comes from in TiDB. If it isn't from TiDB, leave it blank. This is for tests only and thus can be safely changed/removed without affecting compatibility.
The cluster id of the request
Used in:
The hash of `deadlock_key` field.
The key that the current transaction has already acquired and blocks another transaction to form the deadlock.
Used in:
Delete a range of data from TiKV.
Used as request type in: tikvpb.Tikv.KvDeleteRange
Used as field type in:
If true, the data will not be immediately deleted, but the operation will still be replicated via Raft. This is used to notify TiKV that the data will be deleted using `unsafe_destroy_range` soon.
Used as response type in: tikvpb.Tikv.KvDeleteRange
Used as field type in:
Operation allowed info during each TiKV storage threshold.
Used in:
The default value, means operations are not allowed either under almost full or already full.
Means operations will be allowed when disk is almost full.
Means operations will be allowed when disk is already full.
Used in:
,Available when ctx.record_time_stat = true or meet slow query.
Available when ctx.record_scan_stat = true or meet slow query.
Used in:
, , , , , , , , , , , , , , ,Available when ctx.record_time_stat = true or meet slow query. deprecated. Should use `time_detail_v2` instead.
Available when ctx.record_scan_stat = true or meet slow query.
Raftstore writing durations of the request. Only available for some write requests.
Available when ctx.record_time_stat = true or meet slow query.
Used in:
ReadOldValue represents to output the previous value for delete/update operations.
Flashback the region to a specific point with the given `version`, please make sure the region is "locked" by `PrepareFlashbackToVersionRequest` first, otherwise this request will fail.
Used as request type in: tikvpb.Tikv.KvFlashbackToVersion
Used as field type in:
The TS version which the data should flashback to.
The `start_ts` and `commit_ts` which the newly written MVCC version will use. Please make sure the `start_ts` is the same one in `PrepareFlashbackToVersionRequest`.
Used as response type in: tikvpb.Tikv.KvFlashbackToVersion
Used as field type in:
Flush is introduced from the pipelined DML protocol. A Flush request writes some keys and values to TiKV, storing in LOCK and DEFAULT CF, just like a Prewrite request.
Used as request type in: tikvpb.Tikv.KvFlush
Used as field type in:
generation of the flush request. It is a monotonically increasing number in each transaction.
Used as response type in: tikvpb.Tikv.KvFlush
Used as field type in:
Request TiKV to garbage collect all non-current data older than `safe_point`.
Used as request type in: tikvpb.Tikv.KvGC
Used as field type in:
Used as response type in: tikvpb.Tikv.KvGC
Used as field type in:
Actively request TiKV to report health feedback information. TiKV won't omit the health feedback information when sending the `BatchCommandsResponse` that contains this response. The health feedback information won't be replied in the response, but will be attached to `BatchCommandsResponse.health_feedback` field as usual. Only works when batch RPC is enabled.
Used as request type in: tikvpb.Tikv.GetHealthFeedback
Used as field type in:
Used as response type in: tikvpb.Tikv.GetHealthFeedback
Used as field type in:
The error field is added for keeping consistent. This request won't meet any region error as it's store level rather than region level.
Used as request type in: tikvpb.Tikv.GetLockWaitHistory
TODO: There may need some filter options to be used on conditional querying, e.g., finding the lock waiting status for some specified transaction.
Used as response type in: tikvpb.Tikv.GetLockWaitHistory
Used as request type in: tikvpb.Tikv.GetLockWaitInfo
TODO: There may need some filter options to be used on conditional querying, e.g., finding the lock waiting status for some specified transaction.
Used as response type in: tikvpb.Tikv.GetLockWaitInfo
A transactional get command. Lookup a value for `key` in the transaction with starting timestamp = `version`.
Used as request type in: tikvpb.Tikv.KvGet
Used as field type in:
Used as response type in: tikvpb.Tikv.KvGet
Used as field type in:
A region error indicates that the request was sent to the wrong TiKV node (or other, similar errors).
A value could not be retrieved due to the state of the database for the requested key.
A successful result.
True if the key does not exist in the database.
Time and scan details when processing the request.
Used in:
,The sequence number of the feedback message. It's defined as an incrementing integer, starting from the unix timestamp (milliseconds) at the time that the TiKV node is started. This can be useful for filtering out out-of-order feedback messages. Note that considering the possibility of system clock changing, this field doesn't guarantee uniqueness and monotonic if the TiKV node is restarted.
The slow_score calculated in raftstore module. Due to some limitations of slow score, this would be replaced by `SlowTrend` in the future.
Not yet implemented.
Used as request type in: tikvpb.Tikv.KvImport
Used as field type in:
Used as response type in: tikvpb.Tikv.KvImport
Used as field type in:
Used in:
SI = snapshot isolation
RC = read committed
RC read and it's needed to check if there exists more recent versions.
Used in:
, , , , , , , , , , , , , , , , , , ,Client should backoff or cleanup the lock then retry.
Client may restart the txn. e.g write conflict.
Client should abort the txn.
Write conflict is moved from retryable to here.
Key already exists
Deadlock is used in pessimistic transaction for single statement rollback.
Commit ts is earlier than min commit ts of a transaction.
Txn not found when checking txn status.
Calculated commit TS exceeds the limit given by the user.
Assertion of a `Mutation` is evaluated as a failure.
CheckTxnStatus is sent to a lock that's not the primary.
TxnLockNotFound indicates the txn lock is not found.
Extra information for error debugging
Used in:
, , , , , , ,Used in:
, , , , , ,Used in:
Used in:
, , , , , , , , , , ,How many keys this transaction involves in this region.
Fields for transactions that are using Async Commit.
The time elapsed since last update of lock wait info when waiting. It's used in timeout errors. 0 means unknown or not applicable. It can be used to help the client decide whether to try resolving the lock.
Reserved for file based transaction.
Used in:
, , ,Used in:
Used as request type in: tikvpb.Tikv.MvccGetByKey
Used as response type in: tikvpb.Tikv.MvccGetByKey
Used as request type in: tikvpb.Tikv.MvccGetByStartTs
Used as response type in: tikvpb.Tikv.MvccGetByStartTs
Used in:
, , ,Used in:
Used in:
Used in:
Used in:
, , ,insert operation has a constraint that key should not exist before.
Used in:
We allow a key be locked when there is write conflict (latest commit_ts > for_update_ts). In this case, the key is semantically locked by a newer for_update_ts. For each requested key, the field is non-zero if the key is locked with write conflict, and it equals to the commit_ts of the latest version of the specified key. The for_update_ts field of the lock that's actually written to TiKV will also be this value. At the same time, `value` and `existence` will be returned regardless to how `return_values` and `check_existence` are set.
Hint the client that resolving lock is not needed for this lock. For `PessimisticLock` requests only.
Used in:
Lock a set of keys to prepare to write to them.
Used as request type in: tikvpb.Tikv.KvPessimisticLock
Used as field type in:
In this case every `Op` of the mutations must be `PessimisticLock`.
Each locking command in a pessimistic transaction has its own timestamp. If locking fails, then the corresponding SQL statement can be retried with a later timestamp, TiDB does not need to retry the whole transaction. The name comes from the `SELECT ... FOR UPDATE` SQL statement which is a locking read. Each `SELECT ... FOR UPDATE` in a transaction will be assigned its own timestamp.
If the request is the first lock request, we don't need to detect deadlock.
Time to wait for lock released in milliseconds when encountering locks. 0 means using default timeout in TiKV. Negative means no wait.
If it is true, TiKV will acquire the pessimistic lock regardless of write conflict and return the latest value. It's only supported for single mutation.
If it is true, TiKV will return values of the keys if no error, so TiDB can cache the values for later read in the same transaction. When 'force' is set to true, this field is ignored.
If min_commit_ts > 0, this is large transaction proto, the final commit_ts would be infered from min_commit_ts.
If set to true, it means TiKV need to check if the key exists, and return the result in the `not_founds` feild in the response. This works no matter if `return_values` is set. If `return_values` is set, it simply makes no difference; otherwise, the `value` field of the repsonse will be empty while the `not_founds` field still indicates the keys' existence.
TiKV lock the record only when it exists
Specifies the behavior when the request is woken up after wating for lock of another transaction.
Used as response type in: tikvpb.Tikv.KvPessimisticLock
Used as field type in:
It carries the latest value and its commit ts if force in PessimisticLockRequest is true.
The values is set if 'return_values' is true in the request and no error. If 'force' is true, this field is not used. Only used when `wake_up_mode` is `WakeUpModeNormal`.
Indicates whether the values at the same index is correspond to an existing key. In legacy TiKV, this field is not used even 'force' is false. In that case, an empty value indicates two possible situations: (1) the key does not exist. (2) the key exists but the value is empty. Only used when `wake_up_mode` is `WakeUpModeNormal`.
Execution details about the request processing.
Results of the request. Only used when `wake_up_mode` is `WakeUpModeForceLock`.
Used to specify the behavior when a pessimistic lock request is woken up after waiting for another lock.
Used in:
When woken up, returns WriteConflict error to the client and the client should retry if necessary. In this mode, results of `return_values` or `check_existence` will be set to `values` and `not_founds` fields of the PessimisticLockResponse, which is compatible with old versions.
When woken up, continue trying to lock the key. This implicitly enables the `allow_lock_with_conflict` behavior, which means, allow acquiring the lock even if there is WriteConflict on the key. In this mode, `return_values` or `check_existence` fields of PessimisticLockResponse won't be used, and all results are carried in the `results` field.
Unlock keys locked using `PessimisticLockRequest`.
Used as request type in: tikvpb.Tikv.KVPessimisticRollback
Used as field type in:
Used as response type in: tikvpb.Tikv.KVPessimisticRollback
Used as field type in:
Execution details about the request processing.
Used as request type in: tikvpb.Tikv.PhysicalScanLock
Used as response type in: tikvpb.Tikv.PhysicalScanLock
Preparing the flashback for a region/key range will "lock" the region so that there is no any read, write or schedule operation could be proposed before the actual flashback operation.
Used as request type in: tikvpb.Tikv.KvPrepareFlashbackToVersion
Used as field type in:
The `start_ts` which we will use to write a lock to prevent the `resolved_ts` from advancing during the whole process.
The TS version which the data will flashback to later.
Used as response type in: tikvpb.Tikv.KvPrepareFlashbackToVersion
Used as field type in:
A prewrite is the first phase of writing to TiKV. It contains all data to be written in a transaction. TiKV will write the data in a preliminary state. Data cannot be read until it has been committed. The client should only commit a transaction once all prewrites succeed.
Used as request type in: tikvpb.Tikv.KvPrewrite
Used as field type in:
The data to be written to the database.
The client picks one key to be primary (unrelated to the primary key concept in SQL). This key's lock is the source of truth for the state of a transaction. All other locks due to a transaction will point to the primary lock.
Identifies the transaction being written.
TiKV can skip some checks, used for speeding up data migration.
For pessimistic transaction, some mutations don't need to be locked, for example, non-unique index key. Keys with deferred constraint checks are not locked.
How many keys this transaction involves in this region.
For pessimistic transactions only; used to check if a conflict lock is already committed.
If min_commit_ts > 0, this is a large transaction request, the final commit_ts will be inferred from `min_commit_ts`.
When async commit is enabled, `secondaries` should be set as the key list of all secondary locks if the request prewrites the primary lock.
When the transaction involves only one region, it's possible to commit the transaction directly with 1PC protocol.
The max commit ts is reserved for limiting the commit ts of 1PC or async commit, which can be used to avoid inconsistency with schema change.
The level of assertion to use on this prewrte request.
for_update_ts constriants that should be checked when prewriting a pessimistic transaction. See https://github.com/tikv/tikv/issues/14311
Reserved for file based transaction.
for_update_ts constriants that should be checked when prewriting a pessimistic transaction.
Used in:
The index of key in the prewrite request that should be checked.
The expected for_update_ts of the pessimistic lock of the key.
What kind of checks need to be performed for keys in a pessimistic transaction.
Used in:
The key needn't be locked and no extra write conflict checks are needed.
The key should have been locked at the time of prewrite.
The key doesn't need a pessimistic lock. But we need to do data constraint checks.
Used as response type in: tikvpb.Tikv.KvPrewrite
Used as field type in:
0 if the min_commit_ts is not ready or any other reason that async commit cannot proceed. The client can then fallback to normal way to continue committing the transaction if prewrite are all finished.
When the transaction is successfully committed with 1PC protocol, this field will be set to the commit ts of the transaction. Otherwise, if TiKV failed to commit it with 1PC or the transaction is not 1PC, the value will be 0.
Execution details about the request processing.
Used in:
Used as request type in: tikvpb.Tikv.RawBatchDelete
Used as field type in:
Used as response type in: tikvpb.Tikv.RawBatchDelete
Used as field type in:
Used as request type in: tikvpb.Tikv.RawBatchGet
Used as field type in:
Used as response type in: tikvpb.Tikv.RawBatchGet
Used as field type in:
Used as request type in: tikvpb.Tikv.RawBatchPut
Used as field type in:
The time-to-live for each keys in seconds, and if the length of `ttls` is exactly one, the ttl will be applied to all keys. Otherwise, the length mismatch between `ttls` and `pairs` will return an error.
Used as response type in: tikvpb.Tikv.RawBatchPut
Used as field type in:
Used as request type in: tikvpb.Tikv.RawBatchScan
Used as field type in:
scanning range
max number of returning kv pairs for each scanning range
Used as response type in: tikvpb.Tikv.RawBatchScan
Used as field type in:
Used as request type in: tikvpb.Tikv.RawCompareAndSwap
Used as response type in: tikvpb.Tikv.RawCompareAndSwap
The previous value regardless of whether the comparison is succeed.
Used as request type in: tikvpb.Tikv.RawChecksum
Used as response type in: tikvpb.Tikv.RawChecksum
Used as request type in: tikvpb.Tikv.RawCoprocessor
Used as field type in:
Coprorcessor version constraint following SEMVER definition.
Used as response type in: tikvpb.Tikv.RawCoprocessor
Used as field type in:
Error message for cases like if no coprocessor with a matching name is found or on a version mismatch between plugin_api and the coprocessor.
Used as request type in: tikvpb.Tikv.RawDeleteRange
Used as field type in:
Used as response type in: tikvpb.Tikv.RawDeleteRange
Used as field type in:
Used as request type in: tikvpb.Tikv.RawDelete
Used as field type in:
Used as response type in: tikvpb.Tikv.RawDelete
Used as field type in:
Used as request type in: tikvpb.Tikv.RawGetKeyTTL
Used as response type in: tikvpb.Tikv.RawGetKeyTTL
Used as request type in: tikvpb.Tikv.RawGet
Used as field type in:
Used as response type in: tikvpb.Tikv.RawGet
Used as field type in:
Used as request type in: tikvpb.Tikv.RawPut
Used as field type in:
Used as response type in: tikvpb.Tikv.RawPut
Used as field type in:
Used as request type in: tikvpb.Tikv.RawScan
Used as field type in:
For compatibility, when scanning forward, the range to scan is [start_key, end_key), where start_key < end_key; and when scanning backward, it scans [end_key, start_key) in descending order, where end_key < start_key.
Used as response type in: tikvpb.Tikv.RawScan
Used as field type in:
Sent from TiFlash to a TiKV node.
Used as request type in: tikvpb.Tikv.ReadIndex
TiKV checks the given range if there is any unapplied lock blocking the read request.
Used as response type in: tikvpb.Tikv.ReadIndex
If `locked` is set, this read request is blocked by a lock. The lock should be returned to the client.
Used in:
Used as request type in: tikvpb.Tikv.RegisterLockObserver
Used as response type in: tikvpb.Tikv.RegisterLockObserver
Used as request type in: tikvpb.Tikv.RemoveLockObserver
Used as response type in: tikvpb.Tikv.RemoveLockObserver
For all keys locked by the transaction identified by `start_version`, either commit or rollback the transaction and unlock the key.
Used as request type in: tikvpb.Tikv.KvResolveLock
Used as field type in:
`commit_version == 0` means the transaction was rolled back. `commit_version > 0` means the transaction was committed at the given timestamp.
Only resolve specified keys.
Reserved for file based transaction.
Used as response type in: tikvpb.Tikv.KvResolveLock
Used as field type in:
Execution details about the request processing.
Used in:
It's used to identify which resource group the request belongs to.
The resource consumption of the resource group that have completed at all TiKVs between the previous request to this TiKV and current request. It's used as penalty to make the local resource scheduling on one TiKV takes the gloabl resource consumption into consideration.
This priority would override the original priority of the resource group for the request. Used to deprioritize the runaway queries.
Only reserved for compatibility.
Used in:
Used in:
Number of user keys scanned from the storage. It does not include deleted version or RocksDB tombstone keys. For Coprocessor requests, it includes keys that has been filtered out by Selection.
Number of bytes of user key-value pairs scanned from the storage, i.e. total size of data returned from MVCC layer.
Approximate number of MVCC keys meet during scanning. It includes deleted versions, but does not include RocksDB tombstone keys. When this field is notably larger than `processed_versions`, it means there are a lot of deleted MVCC keys.
Total number of deletes and single deletes skipped over during iteration, i.e. how many RocksDB tombstones are skipped.
Total number of internal keys skipped over during iteration. See https://github.com/facebook/rocksdb/blob/9f1c84ca471d8b1ad7be9f3eebfc2c7e07dfd7a7/include/rocksdb/perf_context.h#L84 for details.
Total number of RocksDB block cache hits.
Total number of block reads (with IO).
Total number of bytes from block reads.
Total time used for block reads.
Time used for getting a raftstore snapshot (including proposing read index, leader confirmation and getting the RocksDB snapshot).
Time used for proposing read index from read pool to store pool, equals 0 when performing lease read.
Time used for leader confirmation, equals 0 when performing lease read.
Time used for read pool scheduling.
Used in:
Scan the database for locks. Used at the start of the GC process to find all old locks.
Used as request type in: tikvpb.Tikv.KvScanLock
Used as field type in:
Returns all locks with a start timestamp before `max_version`.
Start scanning from this key.
The maximum number of locks to return.
The exclusive upperbound for scanning.
Used as response type in: tikvpb.Tikv.KvScanLock
Used as field type in:
Info on all locks found by the scan.
Execution details about the request processing.
Scan fetches values for a range of keys; it is part of the transaction with starting timestamp = `version`.
Used as request type in: tikvpb.Tikv.KvScan
Used as field type in:
The maximum number of results to return.
Return only the keys found by scanning, not their values.
For compatibility, when scanning forward, the range to scan is [start_key, end_key), where start_key < end_key; and when scanning backward, it scans [end_key, start_key) in descending order, where end_key < start_key.
If sample_step > 0, skips 'sample_step - 1' number of keys after each returned key. locks are not checked.
Used as response type in: tikvpb.Tikv.KvScan
Used as field type in:
Each KvPair may contain a key error.
This KeyError exists when some key is locked but we cannot check locks of all keys. In this case, `pairs` should be empty and the client should redo scanning all the keys after resolving the lock.
Used in:
session alias set by user
Sent from PD to a TiKV node.
Used as request type in: tikvpb.Tikv.SplitRegion
when use it to do batch split, `split_key` should be empty.
Once enabled, the split_key will not be encoded.
Used as response type in: tikvpb.Tikv.SplitRegion
set when there are only 2 result regions.
set when there are only 2 result regions.
include all result regions.
Reserved for file based transaction.
Used as request type in: tikvpb.Tikv.GetStoreSafeTS
Get the minimal `safe_ts` from regions that overlap with the key range [`start_key`, `end_key`) An empty key range means all regions in the store
Used as response type in: tikvpb.Tikv.GetStoreSafeTS
Used as request type in: tikvpb.Tikv.GetTiFlashSystemTable
Used as response type in: tikvpb.Tikv.GetTiFlashSystemTable
Used in:
,Off-cpu wall time elapsed in TiKV side. Usually this includes queue waiting time and other kind of waitings in series. (Wait time in the raftstore is not included.)
Off-cpu and on-cpu wall time elapsed to actually process the request payload. It does not include `wait_wall_time`. This field is very close to the CPU time in most cases. Some wait time spend in RocksDB cannot be excluded for now, like Mutex wait time, which is included in this field, so that this field is called wall time instead of CPU time.
KV read wall Time means the time used in key/value scan and get.
Total wall clock time spent on this RPC in TiKV .
Used in:
Off-cpu wall time elapsed in TiKV side. Usually this includes queue waiting time and other kind of waitings in series. (Wait time in the raftstore is not included.)
Off-cpu and on-cpu wall time elapsed to actually process the request payload. It does not include `wait_wall_time` and `suspend_wall_time`. This field is very close to the CPU time in most cases. Some wait time spend in RocksDB cannot be excluded for now, like Mutex wait time, which is included in this field, so that this field is called wall time instead of CPU time.
Cpu wall time elapsed that task is waiting in queue.
KV read wall Time means the time used in key/value scan and get.
Total wall clock time spent on this RPC in TiKV .
Time spent on the gRPC layer.
Time spent on waiting for run again in grpc pool from other executor pool.
Used to update the lock_ttl of a psessimistic and/or large transaction to prevent it from been killed.
Used as request type in: tikvpb.Tikv.KvTxnHeartBeat
Used as field type in:
The key of the lock to update.
Start timestamp of the large transaction.
The new TTL the sender would like.
Optionally update PK's min_commit_ts. Only for non-async-commmit and non-1PC transactions. If it is 0, ignore this field.
Reserved for file based transaction.
Used as response type in: tikvpb.Tikv.KvTxnHeartBeat
Used as field type in:
The TTL actually set on the requested lock.
Execution details about the request processing.
Used in:
Reserved for file based transaction.
Used in:
Used in:
Used in:
a non-zero min_commit_ts indicates the transaction is ongoing
a non-zero commit_ts indicates the transaction is committed
The txn has unlocked all keys, implying that it can be removed from txn_status_cache.
Used as request type in: tikvpb.Tikv.UnsafeDestroyRange
Used as response type in: tikvpb.Tikv.UnsafeDestroyRange
Used in:
Used in:
in optimistic transactions.
a lock acquisition request waits for a lock and awakes, or meets a newer version of data, let TiDB retry.
the transaction itself has been rolled back when it tries to prewrite.
RcCheckTs failure by meeting a newer version, let TiDB retry.
write conflict found in lazy uniqueness check in pessimistic transactions.
Used in:
Wait duration in the store loop.
Wait duration before sending proposal to peers.
Total time spent on persisting the log.
Wait time until the Raft log write leader begins to write.
Time spent on synchronizing the Raft log to the disk.
Time spent on writing the Raft log to the Raft memtable.
Time waiting for peers to confirm the proposal (counting from the instant when the leader sends the proposal message).
Wait duration in the apply loop.
Total time spend to applying the log.
Wait time until the KV RocksDB lock is acquired.
Wait time until becoming the KV RocksDB write leader.
Time spent on writing the KV DB WAL to the disk.
Time spent on writing to the memtable of the KV RocksDB.
Time spent on waiting in the latch.
Processing time in the transaction layer.
Wait time because of the scheduler flow control or quota limiter throttling.
Wait time in the waiter manager for pessimistic locking.