TiDB

TiDB can supply either side of the split store using the MySQL wire protocol. Its transaction and replication behavior must be qualified from the actual TiDB/TiKV/PD deployment rather than inferred from a connection URL.

Metadata

mount_rs_tidb_metadata stores the namespace LONGTEXT, revision, writer owner/fence/expiry, keyed by the caller'svolume_key.

Immutable blocks

mount_rs_tidb_blocks stores volume_key, a content-derived block ID, and LONGBLOB bytes. Metadata and blocks may use separate TiDB options or different providers.

Storage anatomy

Follow one file through both planes.

A mount-rs namespace stores names, attributes, directory entries, layouts, and block references. The bytes stay in the independent block plane. The example below is illustrative; the provider-specific schema, keys, and prefixes are the inspectable contract.

Logical file/docs/readme.mdinode 42 · size 8,192NodeMetadata → NodeData::File(FileLayout)

metadatamount_rs_tidb_metadatanamespace + extents + revision/lease

blocksmount_rs_tidb_blocksBlockId → raw bytes

Illustrative Namespace / FileLayout record (shape, not serialized bytes)

Namespace {
  nodes[42] = NodeMetadata {
    stats: { ino: 42, size: 8192, mode: regular },
    data: File(FileLayout {
      chunker: { algorithm: "fixed-size", version: 1, chunk_size: 4096 },
      extents: [
        { file_offset: 0,    block: "b012...", block_offset: 0, length: 4096 },
        { file_offset: 4096, block: "bfed...", block_offset: 0, length: 4096 }
      ]
    })
  }
}

BlockId "b012..." -> [4 KiB raw bytes]
BlockId "bfed..."  -> [4 KiB raw bytes]

Relational storage

TiDB / MySQL wire schema

2 active tables

TiDB keeps the split provider deliberately small: one metadata row per volume and one content-addressed block table. There are no hidden version tables in this adapter.

metadata

`mount_rs_tidb_metadata`

PK volume_key

One row per volume: namespace LONGTEXT plus pessimistic-lock lease state.

Column	Type	Stored meaning
`volume_key`	`VARBINARY(1020)`	PRIMARY KEY; volume scope
`revision`	`BIGINT`	namespace CAS revision
`namespace`	`LONGTEXT NULL`	serialized Namespace
`owner`	`VARBINARY(1020) NULL`	current writer owner
`fence`	`BIGINT`	monotonic fencing token
`expires`	`BIGINT`	provider-clock lease expiry

blocks

`mount_rs_tidb_blocks`

PK (volume_key, id)

Content-derived immutable blocks scoped by volume.

Column	Type	Stored meaning
`volume_key`	`VARBINARY(1020)`	volume scope
`id`	`VARBINARY(65)`	content-derived BlockId
`bytes`	`LONGBLOB`	raw immutable block bytes

Read the live relational schema

SELECT TABLE_NAME, COLUMN_NAME, COLUMN_TYPE, COLUMN_KEY
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME LIKE 'mount_rs_tidb_%'
ORDER BY TABLE_NAME, ORDINAL_POSITION;

Preview — scoped evidence

Functional qualification is complete for the defined hosted TiDB/RustFS scope, including durable 3PD/3TiKV restart, fencing/ambiguous commit, and Linux/macOS consumer rows; production topology, IAM, DR, SLO/capacity, release, canary, and rollback gates remain open. W08 is 100% complete for its defined functional acceptance scope: terminal hosted jobs qualify the durable 3PD/3TiKV restart sequence, provider fencing and ambiguous-commit behavior, live Linux TiDB/RustFS Node/CLI/FUSE composition, ARM Node, Ubuntu NFS, and macOS native-NFS rows. Authoritative hosted runs include35624385556, 35627761501, and35631063978; each remains revision- and scope-specific. The repository now also enforces a credential-free W08.39 backup, restore, and disaster-recovery policy with an eight-case regression: transactionally consistent TiDB metadata snapshots, revision capture, encrypted immutable/versioned blocks, isolated restore without a production-writer identity, fresh-client readback, corruption, partial-object and region-loss cases, bounded 60-minute RPO and 240-minute RTO, a second region, and named owner sign-offs are required by the checked-in control. This is implementation/static qualification, not a backup, restore, second-region drill, or production approval. Production is still NO-GO: topology, secret management/IAM, backup and restore, upgrade/rollback, SLOs/capacity, security sign-off, on-call, canary, and release-owner approval remain open. A green functional packet is not production deployment evidence. W08.40 adds the credential-free upgrade, compatibility, and rollback policy: pinned current/previous versions, wire/data compatibility, expand-contract migration, interrupted recovery, quorum-preserving rolling upgrades, retained rollback artifacts, writer fencing, and fresh-client readback. Its eight-case static policy/test passed at source 66164b78; hosted run35718296219 was cancelled before job creation, so P04 remains an implementation/static qualification rather than a live upgrade rehearsal. W08.41 adds the matching credential-free observability, SLO, and alerting policy with retention, redaction, error-budget, paging, acknowledgement, runbook, and health-contract controls. Its eight-case static policy/test is integrated at sourcec0782e3c; current-tip hosted run35721851677 remains queued, so no live collector, dashboard, pager, or acknowledgement evidence is claimed.

Layout and chunking

Fixed-size chunks are represented as block rows and references in the namespace JSON. Defaults cap block and namespace payloads at 4 MiB to stay below common TiDB/TiKV entry and packet limits; deployments that raise those limits must make the matching chunk choice explicit.

Durability and consistency

Metadata operations require pessimistic transactions and a provider clock, with a volume-row SELECT ... FOR UPDATE. A flush is an acknowledgement round trip, not an fsync command. Setdurable only when the TiDB/TiKV replication and sync-log policy supports that assertion.

Across every split-store composition, new blocks are flushed before metadata references are published. A provider acknowledgement is not automatically a power-loss or distributed-locking guarantee.

Query only the owned volume key

Read-only inspection example

-- Run through an authenticated TiDB SQL client.
SELECT volume_key, revision, OCTET_LENGTH(namespace) AS namespace_bytes
FROM mount_rs_tidb_metadata
WHERE volume_key = '<owned-volume-key>';

SELECT volume_key, id, OCTET_LENGTH(bytes) AS block_bytes
FROM mount_rs_tidb_blocks
WHERE volume_key = '<owned-volume-key>'
ORDER BY id
LIMIT 20;

Credentials, cleanup, and safe operations

Use a dedicated database/user and keep the MySQL/TiDB URL in an environment variable. The integration tests use a unique volume key; clean only that key's metadata and blocks after all clients close, then close the pool. Do not drop provider tables shared by another run.

Current limits

A MySQL-compatible server is not TiDB acceptance. The durable 3PD/3TiKV topology and provider restart promotion remain capacity-gated. A bounded Node/CLI consumer slice now covers configuration, partial write, truncate, shutdown/reopen, and owned RustFS-prefix cleanup. The terminal W08 hosted packet qualifies the defined Linux/macOS consumer and durable-service scope, but native mount beyond that matrix and production deployment remain separate. Its live TiDB/RustFS rows require MOUNT_RS_TIDB_URL and loopback RustFS credentials; do not treat those credentials or hosted fixtures as production IAM.

Sources: TiDB provider README · TiDB provider source · TiDB/RustFS consumer matrix · Durable Ozone/TiDB CI gate · TiDB progress ledger · TiDB production rollout contract · W08.39 backup and restore policy · W08.40 upgrade and rollback policy · W08.40 hosted policy boundary · W08.41 observability and alerting policy · Current-tip W08.41 hosted policy

← Back to providers