Ensuring Replication Consistency in GBase 8s: cdr repair vs cdr sync

#gbase #database #数据库

In an Enterprise Replication (ER) environment on GBase 8s, performing large DML operations before a replicate is fully active can leave standby nodes with missing rows. The cdr utility provides two repair mechanisms — cdr check repl --repair and cdr sync repl. This post demonstrates both, using the cdrtime column to reveal their different approaches.

Test Setup

Create a table with conflict resolution columns (CRCOLS) and a replicate across three nodes (er01, er02, er03).

CREATE TABLE t5(id INT, col DECIMAL(6,2), PRIMARY KEY(id)) WITH CRCOLS;

Method 1: cdr check repl --repair

This command repairs inconsistent data by re‑executing the missing operations. As a result, the cdrtime column is refreshed to the current timestamp.

Start the replicate, insert rows before and after activation. er02 and er03 are missing the first two rows.

  cdr check repl -m er01 -r testdb_t5 er02 er03
  # Reports: er02 missing 2, er03 missing 2

Repair:

  cdr check repl --repair -m er01 -r testdb_t5 er02 er03

After repair, all nodes contain 3 identical rows, and cdrtime now reflects the repair time.

Method 2: cdr sync repl

This approach synchronizes data using previously captured logs, leaving the original cdrtime intact.

Stop the replicate on er01, insert two additional rows, then restart replication. Again, er02 and er03 are behind.

  cdr sync repl -m er01 -r testdb_t5 er02 er03

Consistency is restored across all nodes, yet cdrtime values remain unchanged from the original insert timestamps.

Comparison

Method	Mechanism	`cdrtime` Behavior	Best For
`cdr check repl --repair`	Re‑applies missing operations	Updated to repair time	Smaller inconsistencies when a fresh timestamp is acceptable
`cdr sync repl`	Replays existing log capture	Preserved as original	Scenarios where original timestamp integrity matters