Version information
Version: V4.1.0
Previous version: V4.0.2
Release date: July 15, 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 and later can be directly upgraded to V4.1.0.
Recommended oblogproxy version: V2.1.0 and later
Compatible database versions
| Feature | OceanBase Database version | Versions of other data sources | OCP version |
|---|---|---|---|
| Data migration | V1.4.79, V2.1.1, V2.2.20, V2.2.30, V2.2.50, V2.2.52, V2.2.70, V2.2.72, V2.2.74, V2.2.75, V2.2.76, V2.2.76 BP1, V2.2.77, V3.1.0 ,V3.1.1, V3.1.2, V3.2.1, V3.2.2, V3.2.3, V3.2.4, V4.0.0, and V4.1.0 |
|
|
| Data synchronization | V2.2.20, V2.2.30, V2.2.50, V2.2.52, V2.2.70, V2.2.72, V2.2.74, V2.2.75, V2.2.76, V2.2.76BP1, V2.2.77, V3.1.0, V3.1.1, V3.1.2, V3.2.1, V3.2.2,V 3.2.3, V3.2.4, V4.0.0, and V4.1.0 |
|
|
New features
Improved support for OceanBase Database V4.1.0
Data migration
The reverse incremental migration feature is provided for data backflow after data is migrated from a homogeneous or heterogeneous database, such as Oracle, OceanBase Database, TiDB, or PostgreSQL, to OceanBase Database V4.1.0.
OceanBase Database V4.1.0 can serve as the source data source for data migration.
Data migration is supported between instances of OceanBase Database V4.1.0 or from an OceanBase Database V4.1.0 instance to other databases such as MySQL, Oracle, and DB2 LUW.
Data synchronization
- Data synchronization from OceanBase Database V4.1.0 to data sources in the big data domain, such as Kafka, DataHub, and RocketMQ, is supported.
Support for more heterogeneous databases and instance types
Incremental synchronization: Incremental data can be synchronized from an Oracle tenant of OceanBase Database to a MySQL database. At present, only incremental DML data of tables with a unique key can be synchronized.
Message format compatibility: The DebeziumFlatten and DebeziumSmt JSON formats are supported for data synchronization from a MySQL tenant of OceanBase Database to a Kafka, DataHub, or RocketMQ instance. This allows you to conveniently process the data from OceanBase Database in the downstream big data ecosystem.
Improved ease-of-use
APIs: 20 APIs are added for creating and querying data sources such as MySQL and OceanBase Database instances. You can call these APIs to create, query, manage, and delete synchronization projects. This allows you to automatically schedule multiple tasks at a time.
Batch operation: Six types of common batch operations, including batch start projects and batch pause projects, are provided to significantly improve project management efficiency.
Incremental DDL operations: You can create migration and synchronization projects by specifying objects in a selection shuttle. Incremental DDL operations are supported.
Notice
The objects involved in incremental DDL operations must be synchronization objects that you have selected.
Full synchronization performance monitoring:
You can view real-time information about the full synchronization progress, including the progress, total estimated number of rows, number of synchronized rows, requests per second (RPS), and traffic.
The following metrics are added and are displayed in charts: RPS at the source and destination data sources, synchronization traffic at the source and destination data sources, average read time at the source data source, average slicing time at the source data source, and average write time at the destination data source.
Interaction experience improvement: The default migration type is changed to All Tables for data migration from a MySQL database to a MySQL tenant of OceanBase Database. This reduces the time required to load migration objects when many background resources are consumed to query tables with primary keys.
UI optimization:
The issue that long project names are truncated is fixed.
The project name is added into the alert information.
More basic information about data sources is added in connection details.
The schema migration failure information and the prompt button are optimized.
The Import CSV File and Download CSV Template buttons are added in the lower part of the Import Objects window.
Forward switchover improvement: During a forward switchover, the related Store files and information are cleared after the Store and Incr-Sync components are stopped in the source database to resolve data security issues caused by unexpected data synchronization when a component is mistakenly started.
Improvement for data source editing: When you edit a data source, you can change only the username or password of the database or the AccessKey ID or AccessKey secret of the message object. This prevents errors from occurring when you modify unsupported attributes.
Precheck improvement:
When a precheck fails, you can first save the project information and then resolve the issue.
If a table does not exist in the destination database or the engine type is not supported, you can remove the corresponding table object from the precheck items.
Bug fixes
| Issue | Introduced in |
|---|---|
| When you migrate data from a MySQL tenant of OceanBase Database to a DB2 LUW database, the data synchronized in incremental synchronization is inconsistent. | OMS V4.0.1 BP1 |
| If you query data of a table whose partitioning key is set to NULL, some data is lost. | OMS V3.3.1 |
When DDL synchronization is supported by the connector, skipping the ADD COLUMN statements causes some columns to be lost. |
OMS V3.3.0 |
| Concurrently releasing multiple projects that share the same Store may fail. | OMS V4.1.0 BP1 |
| When you use an upgrade script to process topics in the Store component, subtopics in existing synchronization projects are missing or incorrect. | OMS V4.0.1 |
| When you migrate data from a DB2 LUW database to a MySQL tenant of OceanBase Database, an error is returned even if the source table has a primary key and change data capture (CDC) precheck is enabled. | OMS V4.0.2 |
| When the data source is in Standby Database Only mode, an error indicating insufficient privileges is returned during the precheck. | OMS V4.0.1 |
| The full migration and full verification features are not properly functioning for primary and standby databases. | OMS V3.4.0 |
Known issues
| Issue | Introduced in | Solution |
|---|---|---|
| An out-of-memory (OOM) error occurs due to low verification efficiency in full verification scenarios. | OMS V4.0.1 | N/A |
| If a table with a primary key contains the OMS_PK_INCRMT column, full migration fails due to a __pk_increment query in the table. | OMS V3.3.1 | Delete the OMS_PK_INCRMT column from the source table. |
| In a project for data synchronization from OceanBase Database to a Kafka instance, the Connector component cannot start after synchronization because authentication is required in Kafka. | OMS V3.2.1 | Copy the authentication files of Kafka to the new directory of the Connector component. |