OMS V4.2.1

Version information

• Current version: V4.2.1

• Previous version: V4.2.0

• Release date: November 3, 2023

• Upgrade path:

  • OceanBase Migration Service (OMS) of a version earlier than V3.2.1 must be first upgraded to V3.2.1.

  • OMS V3.2.1 and later can be directly upgraded to V4.2.1.

Compatible database versions

New features

Support for OceanBase Database V4.2.1

• Data migration

  • The reverse increment feature supports data backflow after you migrate data from homogeneous or heterogeneous databases such as Oracle, OceanBase, TiDB, and PostgreSQL databases to OceanBase Database V4.2.1.

  • OMS V4.2.1 supports OceanBase Database V4.2.1 as the source for data migration

    OMS V4.2.1 supports data migration between OceanBase Database V4.2.1 and OceanBase Database of other versions as well as data migration from OceanBase Database V4.2.1 to MySQL, Oracle, and DB2 LUW databases.

• Data synchronization

  • OMS V4.2.1 supports OceanBase Database V4.2.1 as the source for data synchronization. You can synchronize data from OceanBase Database V4.2.1 to Kafka, DataHub, and RocketMQ instances.

Configuration adjustment

The default value of the Handle Non-empty Tables in Target Database parameter is changed to Stop Migration.

• If you use the default value Stop Migration and a target table contains records, an error prompting migration unsupported is reported during full migration. In this case, you must process the data in the target table and then continue with the migration.

  Notice

  After an error is returned, if you click Resume in the dialog box, OMS ignores this error and continues to migrate data. Proceed with caution.

• If you set the value to Ignore and a target table contains records, OMS ignores or overwrites the existing data in the target table when writing data to the table.

  Notice

  • Overwrite is supported only when the target is a MySQL database or a MySQL-compatible tenant of OceanBase Database.

  • If you select Ignore, data is pulled in IN mode for full verification. In this case, the scenario where the target table contains more data than the source table cannot be verified, and the verification efficiency will be decreased.

Verification optimization

• In earlier versions, verification will be performed in IN mode if a partition fails to be matched. In the new version, exact match, case-insensitive match, and partition name mapping are supported, improving the verification efficiency.

• The logic for comparing columns of different data types is restructured to accelerate data verification and reduce CPU consumption.

• In earlier versions, an out-of-memory (OOM) error will be returned during verification if a single shard contains an excessively large amount of data. In the new version, verification is supported for a single shard that contains tens of thousands of records.

Bug fixes

Known issues