OMS V4.2.1

Version information

• 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 upgraded to V3.2.1 first.

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

Compatible database versions

New features

Improved support for OceanBase Database V4.2.1

• Data migration

  • Reverse incremental migration is supported for migration from homogeneous and heterogeneous databases such as Oracle, OceanBase Database, TiDB, and PostgreSQL to OceanBase Database V4.2.1. This feature allows the business data to flow back into the source database.

  • Data migration from OceanBase Database V4.2.1 is supported.

    Data migration is supported between OceanBase Database V4.2.1 and OceanBase Database of other versions and from OceanBase Database V4.2.1 to other databases such as MySQL, Oracle, and DB2 LUW databases.

• Data synchronization

  • Data synchronization is supported from OceanBase Database V4.2.1 to big data instances such as Kafka, DataHub, and RocketMQ instances.

Configuration adjustments

Unlike OMS V4.1.0 and V4.2.0, the default value of the Processing Strategy When Destination Table Has Records parameter is changed to Stop Migration in OMS V4.2.1.

• If you select Stop Migration and a destination table contains records, an error is returned during full migration, indicating that the migration is not allowed. In this case, you must clear the data in the destination table before you can 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 select Ignore and a destination table contains records, OMS writes data to the destination table by ignoring or overwriting existing records. This strategy is supported only when the destination is a MySQL database or a MySQL tenant of OceanBase Database.

  Notice

  If you choose this strategy, data is pulled in IN mode for verification. In this case, the scenario where the destination table contains more data than the source table cannot be verified, and the verification efficiency will be compromised.

Data verification optimization

• Exact partition matching, case-insensitive partition matching, and partition name mapping are supported to improve the verification efficiency. You no longer need to verify data by using the IN mode due to the issue of mismatching partitions.

• The logic for comparing fields of all data types is reconstructed to increase the data verification speed and reduce CPU consumption.

• A single shard with tens of thousands of data records can be verified without the Out Of Memory (OOM) issue.

Bug fixes

Known issues