Clone Metadata Protocol

Header

All metadata packets share the common header, which also matches the InnoDB clone metadata header format, coincidentally. There is no technical requirement to have the same format as InnoDB.

• uint32_t version: currently constant 1.
• uint32_t payload_len: the payload length without this header.
• uint32_t type: one of LOCATOR_V1 (constant 0), FILE_NAME_MAP_V1 (constant 1), FILE_CHUNK_V1 (constant 2), ADD_ESTIMATE_V1 (constant 3).

LOCATOR_V1

This metadata packet does not have an associated data packet.

• uint64_t id: a single monotonic ID, assigned to each created RocksDB snapshot, starting with 1. The ID of 0 is reserver for the client-created locator that is used for version negotiation, in which case it is the sole payload field in the packet.

The id field, if non-zero, may be followed by the applier state which consists of a variable number of pairs. The number of pairs is determined by the payload_len field in the header.

• uint64_t file_id: a clone file ID as established by a FILE_NAME_MAP_V1 packet.
• uint64_t applied_offset: the clone has fully applied data up to this offset.

FILE_NAME_MAP_V1

This metadata packet does not have an associated data packet.

• uint64_t file_id
• uint64_t file_size
• uint32_t file_name_length
• char[file_name_length] file_name

FILE_CHUNK_V1

This metadata packet is associated with the data packet that carries the file data payload.

• uint64_t file_id
• uint64_t chunk_length

ADD_ESTIMATE_V1

This metadata packet does not have an associated data packet.

• uint64_t estimate_delta: the size in bytes of clone MyRocks data, to be added to the clone size estimate value in performance_schema.clone_progress table.