Version information
Version number: V3.3.0
Previous version: V3.2.2
Version release date: March 31, 2022
Version upgrade support:
OMS V3.2.2 can be directly upgraded to V3.3.0.
Other versions need to be upgraded to V3.2.1 first and then to V3.3.0.
Compatible database versions
| Feature | OceanBase database versions | Other database versions |
|---|---|---|
| Data migration |
|
|
| Data synchronization |
|
|
New features
Data migration and synchronization
Supports migration and synchronization from a MySQL-compatible tenant of OceanBase Database to a DB2 LUW database.
Supports incremental synchronization from an Oracle database to an Oracle-compatible tenant of OceanBase Database.
Supports schema synchronization and full synchronization from an OceanBase database to a Kafka instance.
Supports schema, full, and incremental synchronization from an OceanBase, MySQL, DBP, or IDB data source to a Blob DataHub instance.
Allows non-unique indexes to be created after the full migration is completed, reducing the full migration time by at least 30% and comprehensively improving the full migration efficiency.
Supports more Kafka versions, including V1.0 and V2.X, to meet different environment requirements.
Supports incremental DDL statements during synchronization from an OceanBase, DBP, or IDB data source to a Blob DataHub instance, improving product completeness.
Supports five JSON data formats and three common data partitioning rules.
Data source management
Physical OceanBase data sources are no longer forcibly associated with OceanBase Cloud Platform (OCP), thereby supporting more business scenarios.
Feature changes and optimization
Interaction experience optimization
Supports OpenAPIs for project status monitoring to facilitate incorporation of OMS into your own monitoring system.
Adds a component management module to improve the product management system.
Displays commonly used buttons at the frontend to facilitate operations, and applies operation confirmation to avoid misoperations.
Optimizes DingTalk alerts and the prompts at the frontend during forward switchover, and adds the prompts of the types of migrated tables at the frontend, comprehensively improving the ease-of-use of OMS.
Simplifies the process of creating data synchronization projects to enable you to quickly create projects.
Allows you to set installation and deployment parameters on the GUI to reduce product deployment complexity.
Optimizes the synchronization timestamp selection logic to improve the system robustness.
Allows you to quickly access projects from OMS, strengthening the association between projects and OMS and shortening the operation path.
Feature upgrades
Supports more DDL statement types for incremental migration from an Oracle database to an Oracle-compatible tenant of OceanBase Database, improving the core capabilities of OMS.
Supports user management through multiple administrator roles, encrypted storage of passwords, and OMS console access in HTTPS mode, thereby building an enterprise-level security architecture.
Supports five universal JSON formats and three data partitioning rules and adds the business label option, to meet customer requirements in different scenarios.
Supports rollback upon upgrade failures, ensuring upgrade security.
Optimizes the response speed of the monitoring page to improve user satisfaction.
Fixed issues
The time value in full verification is inconsistent with the database data due to the timezone setting during migration or synchronization from a MySQL database to a MySQL-compatible tenant of OceanBase Database.
The binary type is not supported (error code: 32673) during schema migration from a MySQL-compatible tenant of OceanBase Database to a DB2 LUW database.
Data of the YEAR type is inconsistent in verification during migration or synchronization from a MySQL-compatible tenant of OceanBase Database to a DB2 LUW database.
An error is reported when data of the BIT type is written into a table during migration or synchronization from a MySQL-compatible tenant of OceanBase Database to a DB2 LUW database.
An error is reported during full verification of the VARBINARY-VARCHAR schema mapping in the project for migrating data from a MySQL-compatible tenant of OceanBase Database to a DB2 LUW database.
The binary256 error is reported during schema migration from a MySQL-compatible tenant of OceanBase Database to a DB2 LUW database.
The SQL statement for full correction of the time-type data in the source database fails to be executed during migration or synchronization from a DB2 LUW database to an Oracle-compatible tenant of OceanBase Database.
Reverse incremental DDL statements fail to be deleted from multiple partitions during migration or synchronization from an Oracle database to an Oracle-compatible tenant of OceanBase Database.
The ETL time type configured for the source database fails the syntax verification during migration or synchronization from a MySQL database to a MySQL-compatible tenant of OceanBase Database.
Garbled characters are displayed during migration or synchronization from an Oracle-compatible tenant (that uses the GBK character set) of OceanBase Database to a Blob DataHub instance.
The date type 0000-00-00 is displayed as empty after full synchronization from a MySQL-compatible tenant of OceanBase Database to a DataHub instance is completed.
The progress is always displayed as 0 during full synchronization from an Oracle-compatible tenant of OceanBase Database to a DataHub instance.
The boundary values of the numeric and time types do not match the consumed values thereof during migration or synchronization from a MySQL-compatible tenant of OceanBase Database to a Kafka instance.
The "Out of Memory" error is frequently reported in data synchronization projects.
Known 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-compatible tenant of OceanBase Database to a Kafka instance, numeric format exceptions will cause connector exceptions.
During migration or synchronization from an Oracle database to an Oracle-compatible tenant of OceanBase Database, after the table is renamed by using an incremental DDL statement, the DML operations fail accordingly.
During migration from a MySQL-compatible tenant of OceanBase Database of a version earlier than 3.2.x to a DB2 LUW database, after the value of the partitioning key is updated for a multi-partition table with a globally unique index, data may be lost during data migration.
During migration or synchronization from a MySQL-compatible tenant of OceanBase Database to a MySQL database, the JSON column data is inconsistent during verification, but the actual database values are consistent.
Limits
When you migrate data from a MySQL-compatible tenant of OceanBase Database to a DB2 LUW database, only tables with a primary key (PK) or a not-null unique key (UK) can be migrated.
You can create data synchronization projects only by creating topics or selecting existing topics.
When you perform full synchronization from an OceanBase database to a Kafka or Blob DataHub instance, only tables with a PK or a not-null UK can be synchronized.
When you migrate or synchronize data from an Oracle or MySQL database to a DataHub instance, you must set a sharding column for tables without a unique key.
When you migrate or synchronize data from an Oracle, MySQL, OceanBase, DBP, or IDB database to a Tuple DataHub instance, tables and topics must be in one-to-one mapping.
When you migrate or synchronize data from a MySQL-compatible tenant of OceanBase Database to a DB2 LUW database, the source MySQL-compatible tenant must be case-insensitive.