mc table replicate status

The mc table replicate status command shows table replication status for a MinIO AIStor cluster.

The output reports the catalog scanner status and, for each warehouse, namespace, table, and view, the verified version, the latest version, how many versions the replica is behind, and any missing files. When a post-failover catalog rebuild is in progress, the output also reports the rebuild state and attempts.

Run this command against the replica site

The command reports the replication state tracked by the cluster you point it at, not by its peer. Only a replica runs the catalog scanner, so run this command against the replica site.

Run against the primary, the command reports Scanner: disabled and lists no tables. That is expected, and does not indicate a problem.

The exception is a post-failover recovery: an old primary with an open resync window reports Scanner: rebuilding.

Example Syntax

The command has the following syntax:

mc [GLOBALFLAGS] table replicate status ALIAS

Brackets [] indicate optional parameters.
Parameters sharing a line are mutually dependent.
Parameters separated using the pipe | operator are mutually exclusive.

Copy the example to a text editor and modify as-needed before running the command in the terminal/shell.

Parameters

ALIAS

Required

The alias of a MinIO AIStor cluster.

Global flags

This command supports any of the global flags.

Output

The output groups every table and view by warehouse and namespace, and ends with a count of each.

Table Replication Status
────────────────────────────────────────────────────────────
Scanner: tracking
Warehouse: analytics

  Namespace: sales

    Table: orders (019a3f7c-2b1e-7a4d-9f88-4c2e6b1d0a35)
      Verified: 14 | Latest: 14 | Status: OK | Discovered: 6 hours ago
    Table: returns (019a3f7c-8d02-7b19-83c1-5f7a9e4b2c60)
      Verified: 9 | Latest: 11 | Status: 2 versions behind | Discovered: 2 hours ago
      Missing Files: 1
      Missing File Names:
        - 019/a3f7c8d027b1983c15f7a9e4b2c60/data/00004-abc.parquet
    View: revenue_by_region (019a3f7c-c41a-7e55-b207-88d3f0a6e719)
      Verified: 3 | Latest: 3 | Status: OK | Discovered: 6 hours ago

Totals
  Warehouses: 1 | Namespaces: 1 | Tables: 2 | Views: 1

Scanner

The Scanner field reports the state of the replica catalog scanner:

Value	Meaning
`active`	The scanner is running with `replica_catalog_consistency=eventual`.
`tracking`	The scanner is running with `replica_catalog_consistency=strict`.
`waiting`	The scanner is enabled but is not reporting yet, such as just after startup or a change of cluster leader.
`disabled`	The scanner is off. This is the expected value on a primary site.
`rebuilding`	A post-failover catalog rebuild is in progress.
`failed`	A post-failover catalog rebuild failed.

For the consistency modes, see Replica catalog settings.

Because only the cluster leader runs the scanner, the command reports the leader’s view regardless of which node serves the request. The scanner holds this state in memory, so it starts empty again after a restart, a change of leader, or a catalog reset.

Per-table fields

Field	Meaning
`Verified`	The highest metadata version the scanner has accepted into the replica catalog. This is the version queries on the replica see. `-1` means the scanner has accepted no version for this table yet.
`Latest`	The highest metadata version the scanner has seen in the warehouse bucket, whether or not it accepted it.
`Status`	`OK` when `Verified` and `Latest` match, otherwise how many versions the replica is behind.
`Discovered`	How long ago the scanner first saw this table, counted from when the scanner last started. A restart, a change of leader, or a catalog reset resets this value.
`Missing Files`	How many files the newer versions are waiting on. In `strict` mode this covers manifests and data files; in `eventual` mode only a snapshot’s manifest list can appear here, because that is the only file the mode checks.
`Missing File Names`	The paths of those files, relative to the warehouse bucket. A table’s objects live under a prefix derived from its UUID: the first three hex characters, a slash, then the rest.

A table is behind while a newer version’s files are still replicating. A count that does not fall over several scan cycles points to a replication problem rather than lag. See Monitor replication.

A table reading Verified: -1 is held back, not lagging. The scanner reports this when it discovers a table that belongs to a multi-table transaction whose other members have not replicated yet, because it accepts the members together or not at all. The table clears once the remaining members arrive, or once the transaction exceeds replica_catalog_txn_stale_timeout and the scanner releases the members individually. Because the count is measured from -1, the reported versions behind is one higher than the number of versions involved.

Rebuild fields

During a post-failover rebuild, the output adds a line reporting Rebuild state, the number of Attempts, and the Last Error if one occurred. The state is one of Pending, InProgress, FailureRetry, Failed, or Completed.

Examples

Show table replication status

mc table replicate status myreplica

Show table replication status with JSON output

Use the --json global flag to output the results in JSON format:

mc table replicate status myreplica --json

The JSON output adds a retriedFiles count per table, which the plain output omits.