OMS V2.1.2

OceanBase Migration Service (OMS) V2.1.2 has improved the features of the data synchronization, O&M and monitoring, and data source management modules, and supports alert settings.

Version information

• Version number: V2.1.2

• Previous version: V2.1.1

• Version release date: March 28, 2021

Compatible database versions

New features

Data synchronization

• Supports data synchronization from an OceanBase database or Oracle Database to a DataHub instance, including schema initialization, full data synchronization, and incremental data synchronization.

• Supports aggregation and synchronization of DBP-based database and table shards to OceanBase Database, including logical table schema initialization, full data synchronization, and incremental synchronization.

• Supports synchronization of tables without a primary key (PK) from a MySQL tenant of OceanBase Database to a Kafka instance.

O&M and monitoring

• Provides a component monitoring dashboard for synchronization projects, which allows you to view component status and timestamp information and update component parameters.

• Allows you to view, search for, copy, and download logs of stores and connectors on the GUI.

Data source management

Before data migration, you must add source and destination databases as data sources. OMS V2.1.2 allows you to add a DataHub data source.

Alerting

• Automatically connects to the alerting channel of the associated OceanBase Cloud Platform (OCP) cluster after the alerting feature is deployed.

• Allows you to set an alert level for each synchronization project.

• Allows you to define the alerting thresholds and frequency of different levels of alerts for monitoring metrics.

• Optimizes the running status of synchronization projects and allows you to view projects in the alerting state.

Fixed issues

• During the synchronization of multiple tables from an Oracle tenant of OceanBase Database to a Kafka instance, the schemas displayed in the source database are not filtered.

• During the synchronization from a MySQL tenant of OceanBase Database to a DataHub instance, the topic length is not limited.

  An excessively long topic will cause a failure in starting the full synchronization project.

• When you create a project to synchronize data from a MySQL tenant of OceanBase Database to a Kafka instance, the specified timestamp is not effectively checked.

  If you specify an invalid timestamp when you create a data synchronization project, pulling of incremental synchronization logs will fail after the project is started.

• When data is synchronized from a logical table in an OceanBase database to a physical table in another OceanBase database, an exception occurs in full synchronization of data of the BIT type.

• The full synchronization of tables without a PK but with a not-null unique key (UK) from a MySQL tenant of OceanBase Database to a DataHub instance fails.

Known issues

During synchronization from an OceanBase database to a Kafka instance, the LogProxy environment does not support the ShareplexJsonSerializer format.

Limits

• Take note of the following limits when you synchronize data from an Oracle database to a DataHub instance:

  • For tables without a PK in an Oracle database, Shard Columns must be set to ensure successful synchronization to the DataHub instance.

  • OMS cannot parse the actual values of the generated columns used in the Oracle database. Therefore, the corresponding values are NULL when the data is synchronized to the DataHub instance.

  • If CLOB, BLOB, RAW, and LONG RAW data types are used in the Oracle database, when INSERT operations are performed on data of these types, the DataHub instance will receive the corresponding INSERT and UPDATE messages.

  • When data transfer is resumed on a link, some data within the last minute may be duplicate, and deduplication is required in downstream applications.

• Take note of the following limits when you synchronize data from a MySQL tenant of OceanBase Database to a DataHub instance:

  • Full synchronization of an OB_MySQL table without a PK to a DataHub instance is not supported.

  • When data transfer is resumed on a link, some data within the last minute may be duplicate, and deduplication is required in downstream applications.

  • DataHub limits the size of a message based on the cloud environment, usually to 1 MB.

    DataHub sends messages in batches, with each batch sized no more than 4 MB. If a single message meets the conditions for sending, you can modify batch.size at the connector sink. By default, 20 messages are sent at a time within 1 second.