Skip to content

Clone Metadata Protocol

sunshine-Chun edited this page Mar 19, 2023 · 2 revisions

metadata-3

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.
Clone this wiki locally