PolarDB:SHOW COLUMNAR OFFSET

Usage notes

Requires PolarDB-X 5.4.19-16989811 or later.

Syntax

SHOW COLUMNAR OFFSET

Example

SHOW COLUMNAR OFFSET;

Output:

+--------------------+---------------+-----------+---------------------+-------------------------+-------------+
| TYPE               | BinlogFile    | Position  | TSO                 | TIME                    | LATENCY(ms) |
+--------------------+---------------+-----------+---------------------+-------------------------+-------------+
| CDC                | binlog.000010 | 223718750 | 7185913700627251264 | 2024-04-16 16:15:34.050 | 218         |
| COLUMNAR_LATENCY   | binlog.000010 | 223718418 | 7185913684139442240 | 2024-04-16 16:15:30.119 | 3931        |
| CN_MIN_LATENCY     | binlog.000010 | 223718418 | 7185913684139442240 | 2024-04-16 16:15:30.119 | 3931        |
| CN_MAX_LATENCY     | binlog.000010 | 223714434 | 7185912425433006144 | 2024-04-16 16:10:30.020 | 304030      |
| CN_PURGE_WATERMARK | binlog.000010 | 223713604 | 7185912174181613632 | 2024-04-16 16:09:30.117 | 363933      |
+--------------------+---------------+-----------+---------------------+-------------------------+-------------+

Return values

Each row in the output corresponds to one of the following TYPE values: CDC, COLUMNAR_LATENCY, CN_MIN_LATENCY, CN_MAX_LATENCY, and CN_PURGE_WATERMARK.

Columns

Row type semantics

• CDC: The BinlogFile and Position values indicate the latest checkpoint of the primary instance. The TSO is the timestamp of the binary log checkpoint for data synchronized from Change Data Capture (CDC) nodes to data nodes. The TIME is the actual time of the TSO. The LATENCY is the time CDC nodes spend collecting data from multiple data nodes to produce a globally consistent binary log.

• COLUMNAR_LATENCY: The BinlogFile and Position values indicate the binary log checkpoint to which column store nodes are synchronized. The TSO is the timestamp of that synchronization checkpoint. The TIME is when the TSO took effect. The LATENCY is calculated by subtracting the TSO time from the TIME value of the CDC row.

• CN_MIN_LATENCY: Records the minimum latency across compute nodes.

• CN_MAX_LATENCY: Records the maximum latency across compute nodes.

• CN_PURGE_WATERMARK: Records the watermark purged by compute nodes.

Checking consistency

When the BinlogFile and Position values of the CDC row are close to those of the COLUMNAR_LATENCY row, the column-oriented data is consistent with the primary instance.

FAQ

Why is no COLUMNAR_LATENCY row returned?

No column store nodes are available, or the column store nodes are not synchronizing data.

Why does the binary log checkpoint of the CDC row slightly differ from the COLUMNAR_LATENCY row?

In idle conditions with no DML updates, CDC nodes generate 3 TSO heartbeat events every 30 seconds to advance the binary log checkpoint. Column store nodes listen for binary log events and commit the first TSO event at regular intervals. This periodic batching causes a small checkpoint difference between the two rows.

Does the LATENCY value of the COLUMNAR_LATENCY row reflect the true replication lag?

Use this value for reference only. The LATENCY reflects the interval between the most recent CDC TSO and the TSO of the last binary log commit by column store nodes. In idle conditions, binary log events occur only every 30 seconds, so LATENCY can reach 30 seconds even when no actual data lag exists — no data is written to the binary log during that interval, and column store nodes commit events in batches, which inflates the heartbeat interval.

How do I view the binary log files and events of the primary instance?

Run SHOW BINARY LOGS to list binary log files, and SHOW BINLOG EVENTS to inspect specific events within a file.