The migration feature of OceanBase Cloud and its cross-region synchronization capability can efficiently implement cross-cloud active-active and high availability architectures.
Note
The cross-cloud vendor data synchronization migration feature is an allowlist feature. To use it, please contact OceanBase Cloud technical support.
Overview
OceanBase Cloud supports deploying the same data and services across different cloud service providers. Each cloud environment is active and processes business requests simultaneously, maintaining data consistency through real-time data synchronization. If one cloud environment fails, another can seamlessly take over all traffic, ensuring service continuity. This architecture enhances system fault tolerance, reduces reliance on a single cloud provider, and boosts overall reliability and stability. For more information, see Achieving high availability with cross-cloud active-active architecture.
Scenario
In this scenario, the business of the mall is deployed across different cloud providers. After the customer places an order on AWS and Google Cloud respectively, the two databases are kept in real-time synchronization through a real-time cross-cloud active-active replication link. This best practice introduces how to implement cross-cloud active-active operations in the OceanBase Cloud console.
Prerequisites
Transactional instances with Google Cloud and AWS as cloud providers have been created, namely Instance A and Instance B. Instance A serves as the source, and Instance B as the target.
Only users with the Project Owner, Project Admin, or Data Services Admin role can create data migration tasks.
Avoid performing DDL operations for database or table schema changes in the source database during schema migration or full migration. Otherwise, data migration tasks may be interrupted.
Data migration is only supported between tenants of the same type in OceanBase Database. Specifically, data can be migrated from a MySQL-compatible tenant to another MySQL-compatible tenant, or from an Oracle-compatible tenant to another Oracle-compatible tenant.
Data migration only supports migrating databases, tables, and column objects with ASCII-compliant names that do not contain special characters (.,'`()=;/& or line breaks).
Data migration is not case-sensitive. If the target database or table has the same name but differing only in capitalization, a precheck will fail.
If the target is a database, data migration does not support triggers in the target database. If triggers exist, data migration may fail.
Procedure
The following describes how to build a cross-cloud disaster recovery and high-availability database architecture by using the migration feature and synchronization mechanism of OceanBase Cloud.
Create tenants and database accounts
Create tenants, databases, and database accounts for instances A and B, and save the database account password.
In the instance overview page, click Create Tenant to create a MySQL tenant. For more information, see Create a tenant.
Click Create Database and then Create.
Go to the account management page, and then click Create Account. In the dialog box that appears, specify the account name, account type, and other parameters. For more information, see Create and manage an account.
Execute the following statement to create a
studenttable in the database of Instance A.CREATE TABLE `student` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(50) NOT NULL, `age` int(11) NOT NULL, `gender` enum('male','female') NOT NULL, `enrollment_date` date NOT NULL, PRIMARY KEY (`id`) )
Create a data migration task
Log in to the OceanBase Cloud console.
In the left-side navigation pane, choose Data Services > Migrations.
On the Migrations page, click the Migrate Data tab.
On the Migrate Data tab, click Create Task.
In the Source Profile section, configure the parameters.
Parameter Description Cloud Vendor Select Google Cloud. Database Type Select OceanBase MySQL Mode for the source. Instance Type Select Dedicated (Transactional). Region Select the region where the source database is located. Instance Select Instance A. Database Account The username of the OceanBase Cloud MySQL-compatible database for data migration. Password The password of the database user. In the Target Profile section, configure the parameters.
Parameter Description Cloud Vendor Select AWS. Database Type Select OceanBase MySQL Mode for the target. Instance Type Select Dedicated (Transactional). Region Select the region where the target database is located. Instance Select Instance B. Database Account The username of the OceanBase Cloud MySQL-compatible database for data migration. Password The password of the database user. Click Test Connection and Continue to configure two-way synchronization.
Configure two-way synchronization
When the synchronization topology is set to two-way sync, the supported migration types include Schema Migration, Full Migration, Incremental Synchronization, and Full Validation.
Parameter Description Schema Migration During schema migration, you need to define the character set mapping relationships. Data migration only copies the data (schema) from the source database to the target database without affecting the source data (schema). Full Migration After a full migration task is initiated, the data migration service will migrate the existing data from the source database tables to the corresponding tables in the target database. Incremental Synchronization After an incremental synchronization task is initiated, data migration will synchronize the data that has changed in the source database (new data, modified data, or deleted data) to the corresponding tables in the target database. Incremental Synchronization includes DML Synchronization and DDL Synchronization, and you can customize the settings as needed. For more information, see Customize DML/DDL settings. Full Validation After full migration is completed and incremental data is synchronized to the target database and is basically synchronized with the source database, data migration will automatically initiate a full validation task for the source and target tables.
Data migration only supports full validation for tables with unique keys (tables with primary keys or non-null unique keys).In the Select Migration Objects section, configure the method for selecting migration objects. You can select migration objects by using the Specify Objects and Match by Rule options. In the Select Migration Scope section, select the
studenttable in the target database. For more information, see Configure a two-way synchronization task.Confirm the migration options.
Click Next. The system performs a pre-check on the forward task.
In the Pre-check section, data migration checks whether the read and write permissions of the database user and the network connection of the database meet the requirements. You can start the data migration task only after all check tasks are passed. If the pre-check fails:
You can troubleshoot and resolve the issue, and then reinitiate the pre-check until it succeeds.
You can also click Skip in the Actions column of the failed pre-check item, and a dialog box will appear, prompting you about the specific impact of skipping this operation. After you confirm the impact, click OK in the dialog box.
After the pre-check succeeds, click Purchase & Start.
After the purchase is successful, return to the data migration page to view the task progress.
When the forward task is in the incremental synchronization phase of the Monitoring state and the task status is Running, click the Configure button next to the reverse task, confirm the source and target information, and click Next to configure the reverse task.
After the pre-check succeeds, go to the Purchase Data Migration Instance page to purchase the instance.
Return to the data migration page to view the progress of the two-way synchronization task.
Data synchronization and validation
After the two-way synchronization task is configured, view the initial data of the
studenttable in Instance B to verify the data synchronization from Instance A to Instance B.Add data to the
studenttable in Instance B.View the data in the table in Instance A to verify the data synchronization from Instance B to Instance A.