Best practices for achieving high availability through cross-cloud active-active deployment

The migration feature and cross-region synchronization capability of OceanBase Cloud enable efficient implementation of cross-cloud active-active and high-availability architectures.

How it works

OceanBase Cloud supports deploying the same data and services across different cloud service providers. Each cloud environment remains active, processing business requests simultaneously, while maintaining data consistency through real-time data synchronization. If a failure occurs in one cloud environment, another can take over business traffic to support service continuity. This architecture not only enhances the system's fault tolerance but also reduces reliance on a single cloud provider, improving the overall reliability and stability of the system. For more information, see High availability with cross-cloud active-active architecture.

Scenario introduction

The mall business is deployed on different cloud providers. After customers place orders on Google Cloud and AWS respectively, the databases at both ends are kept in real-time synchronization through a real-time cross-cloud active-active replication link. This best practice describes how to implement cross-cloud active-active operation in the OceanBase Cloud console.

Prerequisites

• Taking Google Cloud and AWS instances as examples, transactional instances A and B have been created. Instance A is the source, and Instance B is the destination.

• Only users with the Project Owner, Project Admin, or Data Services Admin role can create a data migration task.

• Operation restrictions on the source database: Do not perform DDL operations that modify database or table schemas during schema migration or full migration. Otherwise, the data migration task may be interrupted.

• Data migration is only supported between tenants of the same type in OceanBase Database. That is, you can migrate data from a tenant in MySQL-compatible mode to another tenant in MySQL-compatible mode, or from a tenant in Oracle-compatible mode to another tenant in Oracle-compatible mode.

• Data migration only supports migrating objects whose database, table, and column names are in ASCII and do not contain special characters (including .|"'`()=;/& and line breaks).

• Data migration is not case-sensitive. If a database or table with the same name but different case exists at the destination, the precheck will report an error.

• If the destination is a database, data migration does not support triggers at the destination. If triggers exist, data migration may fail.

Procedure

The following procedure describes how to build a cross-cloud active-active, high-availability database architecture using the migration and synchronization mechanisms of OceanBase Cloud.

Create tenants and accounts

Create tenants, databases, and database accounts for Instance A and Instance B respectively, and save the database account passwords.

1. In the instance workspace, click Create Tenant to create a MySQL tenant. For details, see Create a tenant.

2. Click Create Database, then click Create.

3. Click Accounts to go to the account management page. Click Create Account. In the dialog box that appears, enter the account name, select the account type, and perform other operations. For details, see Create accounts.

4. Execute the following statement to create a student table 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

1. Log in to the OceanBase Cloud console.

2. In the left-side navigation pane, click Data Services > Data Migration.

3. On the Data Migration page, click the Data Migration tab.

4. On the Data Migration tab, click Create Task in the upper-right corner.

5. In the Source section, configure the parameters.

   Parameter	Description
   Cloud Provider	Select Google Cloud.
   Database Type	Select OceanBase MySQL Mode as the source.
   Instance Type	Select Cluster Instance (Transactional).
   Region	Select the region where the source database is located.
   Instance	Select Instance A.
   Database Account	The username of the OceanBase Cloud MySQL database user used for data migration.
   Password	The password of the database user.

6. In the Target section, configure the parameters.

   Parameter	Description
   Cloud Provider	Select AWS.
   Database Type	Select OceanBase MySQL Mode as the target.
   Instance Type	Select Cluster Instance (Transactional).
   Region	Select the region where the target database is located.
   Instance	Select Instance B.
   Database Account	The username of the OceanBase Cloud MySQL database user used for data migration.
   Password	The password of the database user.

7. Click Test and Continue to configure bidirectional synchronization.

Configure bidirectional synchronization

1. When the synchronization topology is set to bidirectional, the supported migration types include Schema Migration, Full Migration, Incremental Synchronization, and Full Validation.

   Parameter	Description
   Schema Migration	Schema migration requires you to define the character set mapping relationships. Data migration only replicates the data (schema) from the source database to the target database without affecting the original data (schema).
   Full Migration	After a full migration task starts, the data migration service migrates the existing data from the source database tables to the corresponding tables in the target database.
   Incremental Synchronization	After an incremental synchronization task starts, data migration synchronizes the changed data (newly added, modified, or deleted) from the source database to the corresponding tables in the target database. Incremental Synchronization includes DML Synchronization and DDL Synchronization. You can configure them as needed. For details, see Configure DML/DDL synchronization.
   Full Validation	After full migration is completed, incremental data is synchronized to the target and catches up with the source, data migration automatically initiates a full data verification task for the data tables configured in the source and target databases. Data migration only supports full data verification for unique key tables (tables with a primary key or a non-null unique key).

2. In the Select Migration Objects section, configure how to select migration objects. You can choose migration objects by using Specify Objects or Match by Rule. In the Select Migration Scope section, select the objects to migrate, and choose the student table under the target database. For more details, see Configure a bidirectional synchronization task.

3. Confirm the migration options.

4. Click Next. The system performs a precheck on the forward task.

   In the Pre-check step, data migration checks whether the database user's read and write permissions, network connectivity, and other requirements are met. The data migration task can only be started after all checks pass. If the precheck fails:

   • You can troubleshoot and resolve the issue, then re-execute the precheck until it succeeds.

   • You can also click Skip in the Actions column of the failed precheck item. A dialog box appears, explaining the specific impact of skipping this operation. After confirming it is acceptable to skip, click OK in the dialog box.

5. After the precheck succeeds, click Purchase to go to the Purchase Data Migration Instance page.

6. After the purchase succeeds, return to the data migration page to view the task progress.

7. When the forward task is in the Monitoring phase and the task status is Running, click the Configuration button next to the reverse task. Confirm the source and target information, then click Next to configure the reverse task.

8. Complete the precheck, click Purchase, and complete the purchase on the Purchase Data Migration Instance page.

9. Return to the data migration page to view the progress of the bidirectional task.

Data synchronization and verification

1. After configuring the bidirectional task, check the initial data in the student table in Instance B to verify data synchronization from Instance A to Instance B.

2. Add data to the student table in Instance B.

3. In Instance A, check the data in the table to verify data synchronization from Instance B to Instance A.