Understanding OMS Inmode Validation Anomalies in MySQL‑to‑OceanBase Migration

Background : A customer encountered an unexpected data consistency verification result after migrating from MySQL 8.0.27 to OceanBase 3.2.3.3, where the source and target tables appeared inconsistent but the OMS verification reported them as consistent.

Case Description : The source table flw_ev_databasechangeloglock had 0 records, while the target table had 1 record, yet the verification succeeded.

Environment Information

Source:

Database version: MySQL 8.0.27

lower_case_table_names=0

Table flw_ev_databasechangeloglock (0 rows) and FLW_EV_DATABASECHANGELOGLOCK (1 row)

Target:

Database version: OceanBase 3.2.3.3

lower_case_table_names=1

Table flw_ev_databasechangeloglock (1 row)

Phenomenon : Both source tables reported consistent verification results despite the record count mismatch.

Issue 1 Analysis : Log inspection showed that OMS used the Inmode verification method for flw_ev_databasechangeloglock . In Inmode mode, OMS retrieves primary‑key values from the source slice and then queries the target by those keys, so if the source table contains no rows, the target rows are never fetched, leading to a false‑positive match.

OMS Verification Modes :

Ordinary verification : Target reads data using the same slice method as the source.

Inmode verification : Target fetches rows by primary‑key values obtained from the source slice.

Example SQL for source slicing (table test with primary key id ):

-- Slice 1
select * from test where 0 < id <= 5;

-- Slice 2
select * from test where 5 < id <= 10;

Ordinary verification uses the same queries on the target.

-- Slice 1
select * from test where 0 < id <= 5;

-- Slice 2
select * from test where 5 < id <= 10;

Inmode verification queries the target by primary‑key values derived from the source slice:

-- Slice 1
select * from test where id = 2 or id = 3;

-- Slice 2
select * from test where id = 6 or id = 8;

Issue 2 Analysis : The locked column of the table is of type BIT . The source stored 0x00 while the target stored a NULL/empty value. Both values appear as hexadecimal 0 , so OMS considered them equal.

Conclusion : When Inmode verification is used, rows that exist only on the target side cannot be detected, and BIT fields are compared by their binary/hex representation.

Scenarios that trigger Inmode verification :

Explicit configuration via filter.verify.inmod.tables (e.g., filter.verify.inmod.tables = .*;.*;.* ).

Source tables that are hash or key partitioned, causing differing partition placement.

Different partition definitions between source and target.

Multi‑table aggregation where many source tables map to a single target table.

Understanding these behaviors helps avoid false‑positive consistency results during MySQL‑to‑OceanBase migrations.