Version information
Current version: V3.3.1
Previous version: V3.3.0
Version release date: July 20, 2022
Version upgrade support:
OceanBase Migration Service (OMS) V3.3.0 can be directly upgraded to V3.3.1.
Versions earlier than OMS V3.2.1 must be upgraded to V3.2.1 first. OMS V3.2.1 or later can be upgraded only to the next version. Upgrade path: V3.2.1 -> V3.2.2 -> V3.3.0 -> V3.3.1.
Compatible database versions
| Feature | OceanBase database version | Other database version | 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.76BP1, V2.2.77, V3.1.0, V3.1.1, V3.1.2, V3.2.1, V3.2.2, and V3.2.3 |
|
V2.3.9, V2.4.5, V2.5.0, V3.1.0, V3.1.1, V3.1.2, V3.2.1, V3.2.2, V3.2.3, V3.3.0, and V3.3.1 |
| 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, and V3.2.3 |
|
V2.3.9, V2.4.5, V2.5.0, V3.1.0, V3.1.1, V3.1.2, V3.2.1, V3.2.2, V3.2.3, V3.3.0, and V3.3.1 |
New features
Data migration and synchronization
The Arm architecture is supported to adapt to more infrastructures.
Data migration from a DB2 LUW database to a MySQL tenant of OceanBase Database is supported.
Data migration from a TiDB database to a MySQL tenant of OceanBase Database is supported.
Data migration and synchronization from a MySQL tenant of OceanBase Database to Cobar, a middleware for database and table sharding, is supported. Grayscale traffic switchover at the link level is provided.
Data migration from a MySQL 5.5 database to a MySQL tenant of OceanBase Database is supported.
Major version upgrade from OceanBase Database V1.4.x to V2.2.x is supported.
The estimated data volume and completed data volume parameters are added in full migration and full verification to help you estimate the completion time.
The performance data such as records per second (RPS), traffic, and performance benchmark are added in full migration and full verification to help you identify performance issues.
You are allowed to import or export the source and destination database objects, as well as corresponding row and column filtering information, through CSV files.
The minimum privileges for data migration from an Oracle database to an OceanBase database are provided. You can grant privileges to the migration user as needed.
Data source management
The Configurl, drc_user, drc_password, and __oceanbase_inner_drc_user (user for migrating tables without primary keys) options are added for physical OceanBase data sources. These updates can reduce dependency on OceanBase Cloud Platform (OCP) and make deployment easier with higher security.
The OceanBase Proxy address as well as the database username and password are added for logical OceanBase data sources to adapt to more business scenarios.
Feature changes and optimization
Interaction experience optimization
You are allowed to save unsupported and failed tables before migrating the schema, improving the multi-table fixing efficiency.
You are allowed to refresh logs and view the latest logs, improving the efficiency in the case of a large number of logs.
A note is added to tell you that the logical results of the destination are displayed in the hierarchy of Topic -> Database -> Table.
Error codes and details are provided to help improve the problem fixing efficiency.
More prompts are displayed when you select the migration or synchronization type, to help you understand the restrictions in advance.
The prompts displayed when you select Match Rules as the method of selecting migration objects are optimized, to help you better configure the matching rules.
An obvious prompt is displayed when the project latency exceeds 300 seconds.
Numeric values are displayed by dividing each three digits with a comma.
The description of forward switchover steps is provided.
Feature upgrades
The information about OMS migration latency is displayed in the following format: X seconds (updated Y seconds ago). Normally, Y is less than 20. This way, you can identify latency problems easily.
If the destination tables are partitioned tables of OceanBase Database, data is imported by partition. The full migration efficiency can reach 50 million RPS, greatly reducing the migration time.
After the incremental log component is optimized, 5 TB of incremental log data can be parsed per day, meeting the requirements of most customer scenarios.
If hotspot rows exist in the data source of the source database, data is merged based on hotspot rows, reducing the link latency.
A full verification supports the option of Verify Inconsistent Objects, which improves the overall verification efficiency.
Inconsistency cause analysis and row IDs (data source: Oracle) are provided for inconsistent records during data verification.
The topic type and basic settings are added to the configurations of data synchronization projects so that you can view the basic project information conveniently.
You can manually input existing topics in data synchronization projects, avoiding project creation failures due to privilege related factors.
Some security problems are fixed.
Fixed issues
The syntax of the incremental DDL statement
DROP INDEXdoes not support filtering of statements without table names.During incremental migration or synchronization from an Oracle tenant of OceanBase Database to a Kafka instance, numeric format exceptions will cause connector exceptions.
Known issues
If you pause a data migration project in the full migration stage, the status of the project is displayed as Paused, but the Checker is still in running state.
In a project for data synchronization from an Oracle database to a DataHub database, the Oracle Store port may be occupied by another process, causing a synchronization exception.
If you log on to the OMS console as a non-admin user, you cannot create a data source with the same name as an existing data source under the admin user.
In OMS Docker, after supervisorctl successfully executes
stop oms_drc_supervisor, the corresponding process is still running.