User Guide - Huawei Cloud

Data Replication Service

User Guide

Issue 35

Date 2021-11-30

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2021. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without priorwritten consent of Huawei Technologies Co., Ltd. Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.All other trademarks and trade names mentioned in this document are the property of their respectiveholders. NoticeThe purchased products, services and features are stipulated by the contract made between Huawei andthe customer. All or part of the products, services and features described in this document may not bewithin the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,information, and recommendations in this document are provided "AS IS" without warranties, guaranteesor representations of any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in thepreparation of this document to ensure accuracy of the contents, but all statements, information, andrecommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.Address: Huawei Industrial Base

Bantian, LonggangShenzhen 518129People's Republic of China

Website: https://www.huawei.com

Email: [email protected]

Issue 35 (2021-11-30) Copyright © Huawei Technologies Co., Ltd. i

https://www.huawei.com

mailto:[email protected]

Contents

1 Getting Started........................................................................................................................ 1

2 Permissions Management..................................................................................................... 22.1 Creating a User and Granting Permissions.....................................................................................................................22.2 Creating a Custom Policy..................................................................................................................................................... 3

3 Real-Time Migration............................................................................................................... 53.1 Migrating Accounts.................................................................................................................................................................53.2 Parameters for Comparison................................................................................................................................................. 93.3 Configuring Migration Tasks in Common Scenarios.................................................................................................133.3.1 Creating a Migration Task in a VPN or Direct Connect Network..................................................................... 133.3.2 Creating a Migration Task in a VPC Network..........................................................................................................263.3.3 Migrating MongoDB Sharded Clusters to DDS....................................................................................................... 413.3.4 Migrating Databases from MySQL to GaussDB(for MySQL) Primary/Standby...........................................513.3.5 Migrating Databases from DDS to MongoDB.........................................................................................................593.4 Task Management................................................................................................................................................................ 683.4.1 Viewing Task Details.........................................................................................................................................................683.4.2 Editing Migration Task Information............................................................................................................................ 693.4.3 Editing a Migration Task................................................................................................................................................. 703.4.4 Resuming a Migration Task........................................................................................................................................... 763.4.5 Resetting a Migration Task............................................................................................................................................ 763.4.6 Pausing a Migration Task............................................................................................................................................... 773.4.7 Stopping a Migration Task............................................................................................................................................. 783.4.8 Deleting a Migration Task.............................................................................................................................................. 793.4.9 Modifying the Flow Control Mode.............................................................................................................................. 803.4.10 Quick Comparison.......................................................................................................................................................... 823.4.11 Batch Operations.............................................................................................................................................................833.4.12 Managing Tags................................................................................................................................................................ 83

4 Backup Migration.................................................................................................................. 854.1 Viewing Task Details............................................................................................................................................................ 854.2 Editing Migration Task Information............................................................................................................................... 854.3 Viewing Migration Logs...................................................................................................................................................... 864.4 Deleting a Migration Task................................................................................................................................................. 874.5 Batch Operations.................................................................................................................................................................. 88

Data Replication ServiceUser Guide Contents

Issue 35 (2021-11-30) Copyright © Huawei Technologies Co., Ltd. ii

4.6 Tag Management..................................................................................................................................................................88

5 Real-Time Synchronization................................................................................................. 905.1 Data Synchronization Topologies.................................................................................................................................... 905.2 Configuring Synchronization Tasks................................................................................................................................. 925.2.1 From DDM to RDS MySQL............................................................................................................................................. 925.2.2 From DDM to GaussDB(DWS)......................................................................................................................................995.2.3 From DDM to Kafka....................................................................................................................................................... 1065.2.4 From DDM to DDM........................................................................................................................................................1135.2.5 From Oracle to Kafka.................................................................................................................................................... 1205.2.6 From Oracle to GaussDB(for MySQL) Primary/Standby................................................................................... 1265.2.7 From Oracle to GaussDB(for openGauss) Distributed....................................................................................... 1375.2.8 From Oracle to GaussDB(DWS)................................................................................................................................. 1495.2.9 From RDS MySQL to Kafka......................................................................................................................................... 1585.2.10 From RDS MySQL to ElasticSearch.........................................................................................................................1665.2.11 From RDS MySQL to Oracle......................................................................................................................................1735.2.12 From MySQL to GaussDB(for MySQL) Primary/Standby............................................................................... 1815.2.13 From MySQL to GaussDB(DWS)............................................................................................................................. 1895.2.14 From MySQL to GaussDB(DWS) (Many-to-One Scenario)........................................................................... 1985.2.15 From MySQL to PostgreSQL..................................................................................................................................... 2085.2.16 From Self-built MySQL to Self-built Kafka.......................................................................................................... 2165.2.17 From Self-built MySQL to ElasticSearch............................................................................................................... 2235.2.18 From GaussDB(for openGauss) Distributed to GaussDB(DWS)...................................................................2315.2.19 From GaussDB(for openGauss) Distributed to GaussDB(for openGauss) Distributed.........................2395.2.20 From GaussDB(for openGauss) Primary/Standby to Kafka........................................................................... 2495.2.21 From GaussDB(for openGauss) Primary/Standby to GaussDB(DWS)....................................................... 2555.2.22 From GaussDB(for openGauss) Primary/Standby to GaussDB(for openGauss) Distributed............. 2625.2.23 From GaussDB(for openGauss) Primary/Standby to GaussDB(for openGauss) Primary/Standby.. 2715.2.24 From GaussDB(for MySQL) Primary/Standby to MySQL............................................................................... 2815.2.25 From GaussDB(for MySQL) Primary/Standby to GaussDB(DWS)...............................................................2885.2.26 From GaussDB(for MySQL) Primary/Standby to Kafka.................................................................................. 2975.2.27 From GaussDB(for MySQL) Primary/Standby to ElasticSearch.................................................................... 3045.2.28 From GaussDB(for MySQL) Primary/Standby to Oracle.................................................................................3115.2.29 From PostgreSQL to GaussDB(for openGauss) Distributed...........................................................................3195.2.30 From PostgreSQL to PostgreSQL.............................................................................................................................3265.2.31 Incremental DDL Synchronization from PostgreSQL to PostgreSQL.......................................................... 3365.2.32 From DDS to MongoDB............................................................................................................................................. 3375.2.33 From DB2 to GaussDB(for openGauss) Distributed......................................................................................... 3445.2.34 Kafka Message Format............................................................................................................................................... 3505.2.35 Forcibly Stopping Synchronization from GaussDB(for openGauss) Distributed.....................................3545.2.36 Forcibly Stopping Synchronization from GaussDB(for openGauss) Primary/Standby..........................3555.2.37 Forcibly Stopping Synchronization from PostgreSQL.......................................................................................3565.3 Task Management..............................................................................................................................................................358


Issue 35 (2021-11-30) Copyright © Huawei Technologies Co., Ltd. iii

5.3.1 Viewing Task Details...................................................................................................................................................... 3585.3.2 Modifying Task Information........................................................................................................................................ 3595.3.3 Modifying Synchronization Information................................................................................................................. 3605.3.4 Editing Synchronization Objects................................................................................................................................ 3605.3.5 Importing Synchronization Objects.......................................................................................................................... 3625.3.6 Mapping Object Names................................................................................................................................................ 3635.3.7 Viewing Synchronization Mapping Information...................................................................................................3695.3.8 Editing a Synchronization Task...................................................................................................................................3705.3.9 Resuming a Synchronization Task............................................................................................................................. 3705.3.10 Skipping Data and Resuming a Synchronization Task.....................................................................................3715.3.11 Pausing a Synchronization Task.............................................................................................................................. 3715.3.12 Resetting a Synchronization Task........................................................................................................................... 3725.3.13 Stopping a Synchronization Task............................................................................................................................ 3735.3.14 Deleting a Synchronization Task............................................................................................................................. 3745.3.15 Cloning a Synchronization Task............................................................................................................................... 3755.3.16 Modifying the Flow Control Mode......................................................................................................................... 3765.3.17 Processing Data............................................................................................................................................................. 3785.3.18 Batch Operations.......................................................................................................................................................... 3845.3.19 Tag Management......................................................................................................................................................... 3845.3.20 Diagnosis of Abnormal Records.............................................................................................................................. 386

6 Data Subscription................................................................................................................3876.1 Introduction to SDK APIs................................................................................................................................................. 3876.2 SDK Operation Instructions.............................................................................................................................................3906.3 SDK Download Address.................................................................................................................................................... 3936.4 Viewing Task Details..........................................................................................................................................................3936.5 Editing Subscription Task Information........................................................................................................................ 3936.6 Editing a Subscription Task............................................................................................................................................. 3946.7 Viewing Subscription Information................................................................................................................................ 3956.8 Modifying Consumption Start Time.............................................................................................................................3976.9 Modifying Subscription Objects.....................................................................................................................................3986.10 Retrying a Subscription Task........................................................................................................................................ 3996.11 Deleting a Subscription Task........................................................................................................................................ 4006.12 Batch Operations..............................................................................................................................................................4016.13 Tag Management............................................................................................................................................................. 401

7 Real-Time Disaster Recovery............................................................................................ 4037.1 Viewing DR Data................................................................................................................................................................ 4037.2 Editing a DR Task............................................................................................................................................................... 4067.3 Resuming a DR Task.......................................................................................................................................................... 4097.4 Pausing a DR Task.............................................................................................................................................................. 4097.5 Stopping a DR Task............................................................................................................................................................4107.6 Deleting a DR Task.............................................................................................................................................................4107.7 Resetting a DR Task........................................................................................................................................................... 411


Issue 35 (2021-11-30) Copyright © Huawei Technologies Co., Ltd. iv

7.8 Viewing DR Metrics........................................................................................................................................................... 4127.9 Performing a Primary/Standby Switchover............................................................................................................... 4137.10 Modifying the Flow Control Mode.............................................................................................................................4147.11 Batch Operations..............................................................................................................................................................4167.12 Tag Management............................................................................................................................................................. 417

8 Interconnecting with Cloud Eye...................................................................................... 4198.1 Supported Metrics.............................................................................................................................................................. 4198.2 Setting Alarm Rules........................................................................................................................................................... 4258.3 Viewing Monitoring Metrics........................................................................................................................................... 427

9 Interconnecting with CTS..................................................................................................4299.1 Key Operations Recorded by CTS..................................................................................................................................4299.2 Viewing Traces..................................................................................................................................................................... 429

10 Solutions to Failed Check Items.................................................................................... 43110.1 Disk Space.......................................................................................................................................................................... 43110.1.1 Checking Whether the Destination Database Has Sufficient Storage Space.......................................... 43110.1.2 Checking Whether the Destination Server Has Sufficient Storage Space.................................................43310.2 Database Parameters......................................................................................................................................................43410.2.1 Checking Whether the Source Database Binlog Is Enabled.......................................................................... 43410.2.2 Checking Whether the Source Database Binlog Is Row-Based.................................................................... 43510.2.3 Checking Whether the Binlog Retention Period Is Set on the Source Database....................................43610.2.4 Checking Whether the Source and Destination Database Character Sets Are Consistent................. 43710.2.5 Checking Whether the Source Database server_id Meets the Incremental Migration Requirements......................................................................................................................................................................................................... 43910.2.6 Checking Whether the Source and Destination Database Table Names Are Consistent in CaseSensitivity......................................................................................................................................................................................43910.2.7 Checking Whether the Source Database GTID Is Enabled............................................................................. 44110.2.8 Checking Whether the Source Database Contains Object Names with Non-ASCII Characters........ 44210.2.9 Checking Whether the Source and Destination Database TIME_ZONE Values Are Consistent........44210.2.10 Checking Whether the COLLATION_SERVER Values of the Source and Destination Databases Arethe Same.......................................................................................................................................................................................44310.2.11 Checking Whether the SERVER_UUID Values of the Source and Destination Databases Are theSame.............................................................................................................................................................................................. 44310.2.12 Checking Whether the SERVER_ID Values of the Source and Destination Databases Are Different......................................................................................................................................................................................................... 44410.2.13 Checking Whether the Source Database Contains Invalid sql_mode Values........................................ 44410.2.14 Checking Whether the SQL_MODE Values of the Source and Destination Databases Are the Same......................................................................................................................................................................................................... 44510.2.15 Checking Whether the sql_mode Value in the Destination Database Is NotNO_ENGINE_SUBSTITUTION................................................................................................................................................. 44510.2.16 Checking Whether the innodb_strict_mode Values of the Source and Destination Databases Arethe Same.......................................................................................................................................................................................44610.2.17 Checking Whether the max_connections Value of the Destination Database Is Large Enough....44710.2.18 Checking Whether the max_worker_processes Value of the Destination Database Is Large Enough......................................................................................................................................................................................................... 447


Issue 35 (2021-11-30) Copyright © Huawei Technologies Co., Ltd. v

10.2.19 Checking Whether the max_prepared_transactions Value of the Destination Database Is LargeEnough.......................................................................................................................................................................................... 44810.2.20 Checking Whether the max_locks_per_transaction Value of the Destination Database Is LargeEnough.......................................................................................................................................................................................... 44810.2.21 Checking Whether the max_wal_senders Value of the Source Database Is Correctly Configured......................................................................................................................................................................................................... 44910.2.22 Checking Whether the wal_level Value of the Source Database Is Correctly Configured................ 45010.2.23 Checking Whether the max_replication_slots Value of the Source Database Is CorrectlyConfigured....................................................................................................................................................................................45010.2.24 Checking Whether the hot_standby Value of the Source Database Is Correctly Configured..........45110.2.25 Checking Whether the full_page_writes Value of the Source Database Is Correctly Configured.. 45210.2.26 Checking Whether the wal_keep_segments Value of the Source Database Is Correctly Configured......................................................................................................................................................................................................... 45210.2.27 Checking Whether the log_slave_updates Value of the Source Database Is Correctly Configured......................................................................................................................................................................................................... 45310.2.28 Checking Whether the WAL_BLOCK_SIZE Value of the Source Database Is the Same As That ofthe Destination Database....................................................................................................................................................... 45410.2.29 Checking Whether the BLOCK_SIZE Value of the Source Database Is the Same as That of theDestination Database............................................................................................................................................................... 45410.2.30 Checking Whether the binlog_row_image Value is FULL............................................................................ 45510.2.31 Checking Whether the Transaction Isolation Levels are Consistent......................................................... 45610.2.32 Checking Whether the lc_monetary Values of the Source and Destination Databases Are theSame.............................................................................................................................................................................................. 45610.2.33 Checking Whether the Source Database Contains Trigger Names with Non-ASCII Characters.....45710.2.34 Checking Whether the wal_level Value in the Source Database Is Logical........................................... 45810.2.35 Checking Whether the wal_level Value in the Source Database Is Logical........................................... 45810.2.36 Checking Whether the max_replication_slots Value of the Source Database Is Correct.................. 45910.2.37 Checking Whether the Source Database Collections Contain More Than 10 Indexes.......................45910.2.38 Checking Whether the Source Database Collections Contain TTL Indexes........................................... 46010.2.39 Checking Whether log_bin_trust_function_creators Is Set to On in Both the Source andDestination Databases............................................................................................................................................................. 46010.2.40 Checking Whether GTID Is Enabled for the Source Database....................................................................46110.2.41 Checking Whether GTID Is Enabled for the Destination Database.......................................................... 46110.2.42 Checking Whether log_bin_trust_function_creators Is Set to On in the Destination Database..... 46210.2.43 Checking Whether the Values in the Source Oracle Database Are Out of the Ranges of theMySQL Database....................................................................................................................................................................... 46310.2.44 Checking Whether the max_allowed_packet Value of the Destination Database Is too Small..... 46310.2.45 Checking Whether the Source Database User Has the Permission to Parse Logs.............................. 46410.2.46 Checking Whether the ExpireLogsDays Value Is 0......................................................................................... 46410.2.47 Checking Whether the Source Database Character Set Is Supported..................................................... 46510.2.48 Checking Whether the Length Table and Field Names Is Not Supported............................................. 46510.2.49 Checking Whether the Databases and Tables Exist....................................................................................... 46610.2.50 Checking Whether the Supplemental Log Level of the Source Database Meets Requirements....46610.2.51 Checking Whether the Length of the Source Database Object Names Exceeds the Limit.............. 46710.2.52 Checking the Replication Attribute of the Source Table...............................................................................467


Issue 35 (2021-11-30) Copyright © Huawei Technologies Co., Ltd. vi

10.2.53 Checking Whether session_replication_role of the Destination Database Is correctly Set...............46810.2.54 Checking the Database Compatibility Type...................................................................................................... 46810.2.55 Checking Whether the Collation of the Destination Database Is Correct..............................................46910.2.56 Checking Whether the Source Database Has the Permission to Parse OGG Logs............................. 47010.2.57 Checking Whether the Index Name Is Supported.......................................................................................... 47010.2.58 Checking Whether Tables Structures Are Consistent.....................................................................................47110.2.59 Checking Whether Existing Data Meets the Constraints..............................................................................47110.2.60 Checking the Additional Column of the Destination Database.................................................................47210.2.61 Checking Whether Implicit Primary Key Check Is Enabled for the Primary and Standby Databases......................................................................................................................................................................................................... 47210.3 DB Instance Statuses...................................................................................................................................................... 47310.3.1 Checking Whether the Destination Database Is Involved in Another Migration Task......................... 47310.3.2 Checking Whether the Destination DB Instance Is Empty............................................................................. 47410.3.3 Checking Whether the Destination Database Has a Read Replica............................................................. 47410.3.4 Checking Whether the Destination Database Is Read-Only..........................................................................47510.3.5 Checking Whether the Source Database Is Empty........................................................................................... 47510.3.6 Checking Whether the Source and Destination Databases Are of the Same Type............................... 47610.3.7 Checking Whether the Destination Database Exists........................................................................................ 47610.3.8 Checking Whether the Destination DB Instance Is Available........................................................................47710.3.9 Checking Whether the Destination Database Is Empty.................................................................................. 47810.4 Database User Permissions.......................................................................................................................................... 47810.4.1 Checking Whether the Source Database User Has Sufficient Permissions.............................................. 47810.4.2 Checking Whether the Destination Database User Has Sufficient Permissions.....................................48210.4.3 Checking Whether the Source Database Account Is Available.....................................................................48710.4.4 Checking Whether the Destination Database Account Has Required Permissions to Migrate Definer......................................................................................................................................................................................................... 48710.5 Database Versions........................................................................................................................................................... 48810.5.1 Checking Whether the Source Database Version Is Supported....................................................................48810.5.2 Checking Whether the Destination Database Version Is Supported.......................................................... 49110.5.3 Checking Whether the Migration Is from an Earlier Database Version to the Same or a LaterVersion........................................................................................................................................................................................... 49410.5.4 Checking Whether the MongoDB Instance Type Matches the Migration Mode....................................49810.5.5 Checking Whether the Plugin Versions of the Destination Database Are Later Than Those of theSource Database........................................................................................................................................................................ 49810.6 Network...............................................................................................................................................................................49910.6.1 Checking Whether the Source Database Is Connected................................................................................... 49910.6.2 Checking Whether the Destination Database Is Connected..........................................................................50110.6.3 Checking Whether the Destination Database Can Connect to the Source Database.......................... 50410.7 Database Objects............................................................................................................................................................. 50410.7.1 Checking Whether the Source Database Contains a MyISAM Table..........................................................50510.7.2 Checking Whether the Source Database Contains Unsupported Table Field Types..............................50510.7.3 Checking Whether the Source Database Is Available...................................................................................... 50610.7.4 Checking Whether the Source Database Contains the Functions or Stored Procedures that theSource Database User Is Not Authorized to Migrate....................................................................................................507


Issue 35 (2021-11-30) Copyright © Huawei Technologies Co., Ltd. vii

10.7.5 Checking Whether Objects with the Same Names Exist in the Source Database................................. 50710.7.6 Checking Whether the Source Database Contains Unlogged Tables......................................................... 50810.7.7 Checking Whether the Names of Views to Be Migrated Are the Same.................................................... 50810.7.8 Checking Whether the _Id Fields in the Collection of the Source Database Have Indexes................50910.7.9 Checking Whether the Index Length of the Source Database Exceeds the Limit.................................. 51010.7.10 Checking Whether the Source Database Tables Use Storage Engines Not Supported by theDestination Database............................................................................................................................................................... 51110.7.11 Checking Whether the Database Names Mapped to the Destination DB Instance ContainUnsupported Characters..........................................................................................................................................................51110.7.12 Checking Whether the Source Database Tables Contain Primary Keys.................................................. 51210.7.13 Checking Whether the Source Database Contains Triggers or Events.................................................... 51310.7.14 Checking Whether the Source Database Referenced Roles Pass the Check..........................................51310.7.15 Checking Whether the Source Database Referenced Accounts Pass the Check.................................. 51410.7.16 Checking Database Mapping Objects................................................................................................................. 51410.7.17 Checking Whether Associated Objects Are Selected..................................................................................... 51510.7.18 Checking Whether the Specified Objects Exist In the Destination Database........................................51510.7.19 Checking Whether the Source Table Contains Column Types that Cannot Be Used as DistributionKeys................................................................................................................................................................................................ 51610.7.20 Checking Whether the Source Table Contains Unsupported Table Field Types................................... 51610.8 Database Configuration Items.................................................................................................................................... 51710.8.1 Checking Whether the Source Database Name Is Valid.................................................................................51710.8.2 Checking Whether the Source Database Table Name Is Valid..................................................................... 51810.8.3 Checking Whether the Source Database View Name Is Valid...................................................................... 51910.8.4 Checking Whether the Source Database Collection Name Is Valid............................................................ 52010.8.5 Checking Whether the Shard Key Can Be Obtained from the Source Database................................... 52010.8.6 Checking Whether the Source Database Schema Name Is Valid................................................................ 52110.8.7 Checking Whether the Maximum Number of Chunks in the Destination Database Is Sufficient... 52210.8.8 Checking Whether Archive Logs Are Enabled on the Source Oracle Database...................................... 52210.8.9 Checking Whether Supplemental Logging of the Source Oracle Database Meets Requirements...52310.9 Conflicts............................................................................................................................................................................... 52310.9.1 Checking Whether the Names of the Source and Destination Databases Are the Same...................52310.9.2 Checking Whether the Same View Names Exist in Both the Source and Destination Databases... 52810.9.3 Checking Whether the Destination Database Contains a Non-Empty Collection with the SameName As the Source Database............................................................................................................................................. 52810.9.4 Checking Whether Destination Database Contains the Same Table Names As the SynchronizationObjects...........................................................................................................................................................................................52910.9.5 Checking Whether the Destination Database Contains Objects with the Same Name As Those inthe Source Database.................................................................................................................................................................53010.9.6 Checking Whether Collections in Both the Source and Destination Databases Are Not Capped....53210.10 SSL Connections............................................................................................................................................................. 53210.10.1 Checking Whether the SSL Connection Is Correctly Configured................................................................53210.10.2 Checking Whether the SSL Connection Is Enabled for the Source Database....................................... 53410.10.3 Checking Whether the SSL Certificate of the Source Database Exists.................................................... 53510.10.4 Checking Whether the SSL Certificate of the Destination Database Exists...........................................535


Issue 35 (2021-11-30) Copyright © Huawei Technologies Co., Ltd. viii

10.10.5 Checking Whether Both the Source and Destination Databases Use SSL............................................. 53610.11 Object Dependencies.................................................................................................................................................... 53610.11.1 Checking Whether the Objects Referenced by Views Are Selected for Migration...............................53710.11.2 Checking Whether Referenced Tables Are Selected for Migration........................................................... 53710.12 Source Database Information................................................................................................................................... 53710.12.1 Checking Whether the Shards and Mongos Are in the Same Cluster..................................................... 53810.12.2 Checking Whether the Balancers of the Source Database Is Enabled.................................................... 53810.12.3 Checking Whether the Source and Destination Database Types Match................................................ 538

11 Troubleshooting................................................................................................................ 54011.1 Backup Migration Failed Because Backup Files Cannot Be Found................................................................. 54011.2 Backup Migration Failed Because a Backup Database Cannot Be Found in the Backup Files............. 541

A Change History....................................................................................................................543


Issue 35 (2021-11-30) Copyright © Huawei Technologies Co., Ltd. ix

1 Getting Started

If you use Data Replication Service (DRS) for the first time, see the DataReplication Service Quick Start to help you understand DRS.

● Real-Time Migration● Backup Migration● Real-Time Synchronization● Data Subscription● Real-Time Disaster Recovery

Data Replication ServiceUser Guide 1 Getting Started

Issue 35 (2021-11-30) Copyright © Huawei Technologies Co., Ltd. 1

https://support.huaweicloud.com/intl/en-us/qs-drs/drs_online_migration.html

https://support.huaweicloud.com/intl/en-us/qs-drs/drs_offline_migration.html

https://support.huaweicloud.com/intl/en-us/qs-drs/drs_06_0003.html



2 Permissions Management

2.1 Creating a User and Granting PermissionsThis section describes how to use Enterprise Management orIAM to achieve fine-grained permissions management for your DRS tasks.

● For details about how to use Enterprise Management, see ProjectManagement.

● With IAM, you can:– Create IAM users for employees based on the organizational structure of

your enterprise. Each IAM user has their own security credentials,providing access to DRS resources.

– Grant only the permissions required for users to perform a task.– Entrust an account or cloud service to perform professional and efficient

O&M on your DRS resources.

If your account does not require individual IAM users, skip this chapter.

This section describes the procedure for granting permissions (see Figure 2-1).

PrerequisitesLearn about the permissions (see Permissions Management) supported by DRSand choose policies or roles according to your requirements. For the systempolicies of other services, see Permissions Policies.

Process Flow

Figure 2-1 Process for granting DRS permissions

Data Replication ServiceUser Guide 2 Permissions Management


https://support.huaweicloud.com/intl/en-us/usermanual-em/em-topic_02.html

https://support.huaweicloud.com/intl/en-us/usermanual-iam/iam_01_0001.html



https://support.huaweicloud.com/intl/en-us/productdesc-drs/drs_01_0201.html

https://support.huaweicloud.com/intl/en-us/usermanual-permissions/iam_01_0001.html

1. Create a user group and assign permissions to it.Create a user group on the IAM console, and assign the DRS Administratorpolicy to the group.

2. Create a user.Create a user on the IAM console and add the user to the group created in 1.

3. Log in and verify permissions.Log in to the management console by using the newly created user, and verifythat the user only has read permissions for DRS.Go to the DRS console, click Create Migration Task in the upper right cornerto create a migration task. If a migration task (assume that there is only theDRS Administrator permission) is created, the DRS Administrator policy hastaken effect.

2.2 Creating a Custom PolicyCustom policies can be created to supplement the system-defined policies of DRS.

You can create custom policies in either of the following ways:

● Visual editor: Select cloud services, actions, resources, and request conditions.This does not require knowledge of policy syntax.

● JSON: Edit JSON policies from scratch or based on an existing policy.

For details about how to create a custom policy, see Creating a Custom Policy.The following describes examples of common DRS custom policies.

Example Custom Policies● Example 1: Allowing users to create DRS instances

{ "Version": "1.1", "Statement": [{ "Action": ["drs:instance:create"], "Effect": "Allow" }]}

● Example 2: Denying DRS instance deletionA policy with only "Deny" permissions must be used in conjunction with otherpolicies to take effect. If the permissions assigned to a user contain both"Allow" and "Deny", the "Deny" permissions take precedence over the "Allow"permissions.The following method can be used if you need to assign permissions of theDRS FullAccess policy to a user but you want to prevent the user fromdeleting DRS instances. Create a custom policy for denying DRS instancedeletion, and attach both policies to the group to which the user belongs.Then, the user can perform all operations on DRS instances except deletingDRS instances. The following is an example of the deny policy:{ "Version": "1.1", "Statement": [{ "Action": ["drs:instance:delete"], "Effect": "Deny"







}]}



3 Real-Time Migration

3.1 Migrating Accounts

ScenariosDuring a database migration, accounts need to be migrated separately.

MySQL Databases OperationsDuring the migration of MySQL databases, accounts to be migrated can beclassified into the following types: accounts that can be migrated completely,accounts whose permissions need to be reduced, and accounts that cannot bemigrated.

● Accounts that can be completely migrated refer to the accounts that meet thepermission requirements of the destination database. By default, the systemautomatically migrates the permission of the database account to thedestination database.

● Accounts whose permissions need to be reduced refer to high-level accountsthat fail to meet the permission requirements of the destination database,such as super, file, and shutdown. To migrate these accounts, reduce thepermissions of the account. Otherwise, the migration fails.You can click View in the Remarks column to view detailed informationabout the permission to be reduced. You can then determine whether thepermission reduction will have an impact on your services.

● Accounts that cannot be migrated indicate that database users cannot meetthe migration requirements for certain reasons. These accounts will not bemigrated to the destination database. Ensure that services are not affected bythese accounts. After the migration is started, any operation of changing thepassword or permission for these accounts will result in an incrementalmigration failure.

You can choose whether to migrate the accounts or choose to migrate certain ofor all of the accounts. Perform the following operations to set the databaseusername, permission, and password. The following procedure uses all databaseusers that can be migrated as an example.

Data Replication ServiceUser Guide 3 Real-Time Migration


The account information consists of account name, permission, and password.

Step 1 The account name is in the 'Account name'+@+'host' format. host indicates theIP address of the destination database, which is allowed to access the sourcedatabase. You can change the IP address as required.

The IP address in the red box is shown in the following figure. If the sourcedatabase is MySQL 8.0, you are not advised to change the IP address.

Figure 3-1 Changing the IP address

Step 2 By default, account permissions cannot be modified. For accounts that can bemigrated (including accounts that can be completely migrated and accountswhose permissions need to be reduced), the system also migrates the permissionsof these accounts.

After the migration is successful, accounts in the destination database are thosewhose permissions need to be reduced.

Figure 3-2 Account permissions

Step 3 Migrate account passwords.

You can use either of the following methods to migrate account passwords:

DRS does not check your password strength during migration so you should set astrong password to ensure data security.

Method 1: Migrate the password.



Figure 3-3 Migrating password

You can directly migrate the current password of the source system. In this case,you do not need to select Reset Password. After the passwords are migrated tothe destination database, you can set a strong password to ensure databasesecurity.

Method 2: Reset the password.

Figure 3-4 Resetting a password

You can select Reset Password to reset the password of the source system andthen continue the password migration.

You can enter new passwords in the Passwords column for specified accounts thatcan be migrated, or select all accounts that can be migrated and select SetUnified Password to set a unified new password for them. After the migration issuccessful, you can run DDL statements on the destination database to reset thepassword.

Step 4 For accounts whose permissions need to be reduced and accounts that cannot bemigrated, you can click View to confirm the remarks before performing the nextstep. If there are multiple accounts, you can click Confirm All Remarks.



Figure 3-5 Remarks

If an account already exists in the destination database, it cannot be migrated. Youcan delete it from the destination database. After the deletion, you can continuethe migration.

NO TE

● Currently, only MySQL supports account migration.● The new password you set must meet the password policy of the destination

database.

----End

MongoDB Database OperationsDuring the migration of MongoDB databases, accounts to be migrated can beclassified into the following types: accounts that can be migrated completely andaccounts that cannot be migrated.

You can choose whether to migrate the accounts. If you need to migrate theaccounts, perform the following procedures.

The account information consists of account name and role.

Step 1 Select the accounts and roles to be migrated based on service requirements.

If the account to be migrated depends on some roles, you must migrate the roles.Otherwise, the migration fails.



https://support.huaweicloud.com/intl/en-us/drs_faq/drs_14_0004.html


Figure 3-6 Account migration

Step 2 For accounts or roles that cannot be migrated, you can click View to confirm theremarks before performing the next step. If there are multiple accounts, you canclick Confirm All Remarks.

Figure 3-7 Remarks

----End

3.2 Parameters for ComparisonParameter comparison helps you check consistency between the source anddestination database data to ensure your services will not be affected after beingmigrated.

This section lists the common parameters and performance parameters ofdifferent DB engine versions for your reference during parameter comparison.



MySQL 5.6

Table 3-1 MySQL 5.6 parameters to be compared

Parameter Type Restart Required

connect_timeout Common parameter No

event_scheduler Common parameter No

innodb_lock_wait_timeout

Common parameter No

max_connections Common parameter No

net_read_timeout Common parameter No

net_write_timeout Common parameter No

explicit_defaults_for_timestamp

Common parameter Yes

innodb_flush_log_at_trx_commit

Common parameter No

max_allowed_packet Common parameter No

tx_isolation Common parameter No

character_set_client Common parameter No

character_set_connection Common parameter No

collation_connection Common parameter No

character_set_results Common parameter No

collation_server Common parameter No

binlog_cache_size Performance parameter No

binlog_stmt_cache_size Performance parameter No

bulk_insert_buffer_size Performance parameter No

innodb_buffer_pool_size Performance parameter Yes

key_buffer_size Performance parameter No

long_query_time Performance parameter No

query_cache_type Performance parameter Yes

read_buffer_size Performance parameter No

read_rnd_buffer_size Performance parameter No

sort_buffer_size Performance parameter No

sync_binlog Performance parameter No



MySQL 5.7






Common parameter No





Common parameter No


Common parameter No











innodb_buffer_pool_size Performance parameter No



query_cache_type Performance parameter No








MySQL 8.0






Common parameter No





Common parameter No


Common parameter No











innodb_buffer_pool_size Performance parameter No






query_cache_type Performance parameter No





NO TE

● Currently, only MySQL databases support the parameter comparison function.

● The value of innodb_buffer_pool_size is set to not exceed 70% of the total memory ofthe destination database. If you set a larger value for parameter, the destinationdatabase startup may fail. Therefore, values of innodb_buffer_pool_size in the sourceand destination databases are different. You can adjust the value to suit your services.

3.3 Configuring Migration Tasks in Common Scenarios

3.3.1 Creating a Migration Task in a VPN or Direct ConnectNetwork

This section uses the migration from MySQL to RDS MySQL as an example todescribe how to configure a migration task on the DRS console in a VPN or DirectConnect network.

VPN and Direct Connect are suitable for migrations from on-premises databasesto cloud databases or between cloud databases across regions.

You can create a migration task that will walk you through each step of theprocess. After a migration task is created, you can manage it on the DRS console.

Prerequisites● You have logged in to the DRS console.● Your account balance is greater than or equal to $0 USD.● For details about real-time migration, see Real-Time Migration● For details about constraints on DRS usage, see Before You Start.

Procedure

Step 1 On the Online Migration Management page, click Create Migration Task.

Step 2 On the displayed page, select the region and specify Task Name, SendNotification, SMN Topic, Synchronization Delay Threshold, Stop AbnormalTasks After, Description, and replication instance details. Then, click Next.





Figure 3-8 Migration task information

Table 3-4 Task information

Parameter Description

Region The region where the replication instance isdeployed. You can change the region.

Task Name The task name consists of 4 to 50 characters, startswith a letter, and can contain only letters (case-insensitive), digits, hyphens (-), and underscores (_).

Send Notifications SMN topic. This parameter is optional. If anexception occurs during migration, the system willsend a notification to the specified recipients.

SMN Topic This parameter is available only after you enableSend Notification and create a topic on the SMNconsole and add a subscriber.For details, see Simple Message Notification UserGuide.

Synchronization DelayThreshold

During an incremental migration, a synchronizationdelay indicates a time difference (in seconds) ofsynchronization between the source and destinationdatabase.If the synchronization delay exceeds the thresholdyou specify, DRS will send alarms to the specifiedrecipients. The value ranges from 1 to 3,600. Toavoid repeated alarms caused by the fluctuation ofdelay, an alarm is sent only after the delay hasexceeded the threshold for six minutes.NOTE

● In the early stages of an incremental migration, there ismore delay because more data is waiting to besynchronized. In this situation, no notifications will besent.

● Before setting the delay threshold, enable SendNotification.



https://support.huaweicloud.com/intl/en-us/qs-smn/smn_ug_0004.html



Stop Abnormal TasksAfter

Number of days after which an abnormal task isautomatically stopped. The value must range from14 to 100.NOTE

Tasks in the abnormal state are still charged. If tasksremain in the abnormal state for a long time, they cannotbe resumed. Abnormal tasks run longer than the periodyou set (unit: day) will automatically stop to avoidunnecessary fees.

Description The description consists of a maximum of 256characters and cannot contain the following specialcharacters: !=<>'&"\

Figure 3-9 Replication instance information

Table 3-5 Replication instance settings


Data Flow Select To the cloud.The destination database must be an RDSdatabase on the current cloud.

Source DB Engine Select MySQL.

Destination DB Engine Select MySQL.




Network Type Select VPN or Direct Connect.Available options: VPC, VPN or Direct Connect,and Public network. By default, the value isPublic network.● VPC is suitable for migrations of cloud

databases.● Public network is suitable for migrations from

on-premises or external cloud databases to thedestination databases bound with an EIP.

● VPN is suitable for migrations from on-premises databases to cloud databases orbetween cloud databases across regions.

● Direct Connect is suitable for migrations fromon-premises databases to cloud databases orbetween cloud databases across regions.

Destination DB Instance Select the DB instance you have created.

Replication InstanceSubnet

Specifies the subnet where the replication instanceresides. You can also click View Subnet to go tothe network console to view the subnet where theinstance resides.By default, the DRS instance and the destinationDB instance are in the same subnet. You need toselect the subnet where the DRS instance resides,and there are available IP addresses for thesubnet. To ensure that the replication instance issuccessfully created, only subnets with DHCPenabled are displayed.

Destination DatabaseAccess

● Read-onlyDuring the migration, the destination databaseis read-only. After the migration is complete, itbecomes readable and writable. This optionensures the integrity and success rate of datamigration.

● Read/WriteDuring migration, the destination database canbe queried or modified. Data may be modifiedwhen operations are performed or applicationsare connected. It should be noted thatbackground processes can often generate ormodify data, which may result in data conflicts,task faults, and upload failures. Do not selectthis option if you do not fully understand therisks.




Migration Type ● FullThis migration type is suitable for scenarioswhere service interruption is acceptable. Allobjects and data in non-system databases aremigrated to the destination database at onetime. The objects include tables, views, andstored procedures.NOTE

If you perform a full migration, do not performoperations on the source database. Otherwise, datagenerated in the source database during themigration will not be synchronized to the destinationdatabase.

● Full+IncrementalThis migration type allows you to migrate datawithout interrupting services. After a fullmigration initializes the destination database,an incremental migration initiates and parseslogs to ensure data consistency between thesource and destination databases.

NOTEIf you select the Full+Incremental migration type, datagenerated during the full migration will be synchronizedto the destination database with zero downtime,ensuring that the source database remain accessible.

Enterprise Project If the DB instance has been associated with anenterprise project, select the target project fromthe Enterprise Project drop-down list.You can also go to the ProjectMan console tocreate a project. For details about how to create aproject, see the ProjectMan User Guide.

Tags This setting is optional. Adding tags helps youbetter identify and manage your tasks. Each taskcan have up to 10 tags.After a task is created, you can view its tag detailson the Tags tab. For detailed operations, see TagManagement.

Step 3 On the Configure Source and Destination Databases page, wait until thereplication instance is created. Then, specify source and destination databaseinformation and click Test Connection for both the source and destinationdatabases to check whether they have been connected to the replication instance.After the connection tests are successful, select the check box before theagreement and click Next.● Source database configuration



https://support.huaweicloud.com/intl/en-us/usermanual-drs/drs_online_tag.html


Figure 3-10 Source database information

Table 3-6 Source database settings


IP Address orDomain Name

The IP address or domain name of the source database.

Port The port of the source database. Range: 1 - 65535

DatabaseUsername

The username for accessing the source database.

DatabasePassword

The password for the database username.

SSL Connection SSL encrypts the connections between the source anddestination databases. If SSL is enabled, upload the SSLCA root certificate.NOTE

– The maximum size of a single certificate file that can beuploaded is 500 KB.

– If the SSL certificate is not used, your data may be at risk.

NO TE

The IP address, port, username, and password of the source database are encryptedand stored in the database and the replication instance, and will be cleared after thetask is deleted.

● Destination database configuration



Figure 3-11 Destination database information

Table 3-7 Destination database settings


DB Instance Name The RDS DB instance you selected whencreating the migration task and cannot bechanged.

Database Username The username for accessing the destinationdatabase.

Database Password The password for the database username.

Migrate Definer to User – YesThe Definers of all source database objectswill be migrated to the user. Other users donot have permissions for database objectsunless these users are authorized. For detailson authorization, see How Do I Maintainthe Original Service User PermissionSystem After Definer Is Forcibly ConvertedDuring MySQL Migration?

– NoThe Definers of all source database objectswill not be changed. You need to migrate allaccounts and permissions of the sourcedatabase in the next step.

NO TE

The username and password of the destination database are encrypted and stored inthe database and the replication instance during the migration. After the task isdeleted, the username and password are permanently deleted.

Step 4 On the Set Task page, select the accounts and objects to be migrated, and clickNext.







Figure 3-12 Migration type



Table 3-8 Migration types and objects


FlowControl

You can choose whether to control the flow.● Yes

You can customize the maximum migration speed.In addition, you can set the time range based on your servicerequirements. The traffic rate setting usually includes setting ofa rate limiting time period and a traffic rate value. Flow can becontrolled all day or during specific time ranges. The defaultvalue is All day. A maximum of three time ranges can be set,and they cannot overlap.The flow rate must be set based on the service scenario andcannot exceed 9,999 MB/s.

Figure 3-13 Flow control

● NoThe DR speed is not limited and the outbound bandwidth of thesource database is maximally used, which causes readconsumption on the source database accordingly. For example,if the outbound bandwidth of the source database is 100 MB/sand 80% bandwidth is used, the I/O consumption on the sourcedatabase is 80 MB/s.NOTE

– Flow control mode takes effect only during a full migration.– You can also change the flow control mode after creating a task. For

details, see Modifying the Flow Control Mode.



https://support.huaweicloud.com/intl/en-us/usermanual-drs/drs_03_0046.html


TakeSnapshot

If you perform a full migration, you can take a snapshot for yourdatabases.● No

This option applies to exports for which no data is written tothe source database. If data is modified during a full migration,the exported data is point in time inconsistent. The stability andperformance of a migration without a snapshot taken is betterthan that of a migration with a snapshot taken.

● YesA snapshot with point in time consistent data is generatedduring service running. Data changes during the migration arenot shown in the exported data.NOTE

– Snapshot reads use MySQL backup lock to lock global tables andautomatically unlock them within 3s after consistent reads areenabled. To prevent full migration failures, take a snapshot when thesource database is idle and not perform DML or DDL operationsduring snapshot migration.

– Only MySQL full migration tasks support snapshot mode.– Do not perform DDL operations during migration in snapshot mode.

Otherwise, full migration will fail.

MigrateAccount

During a database migration, accounts need to be migratedseparately.There are accounts that can be migrated completely, accountswhose permissions need to be reduced, and accounts that cannotbe migrated. You can choose whether to migrate the accountsbased on your service requirements. If you select Yes, you canselect the accounts to be migrated as required.● Yes

If you choose to migrate accounts, see section MigratingAccounts in the Data Replication Service User Guide to migratedatabase users, permissions, and passwords.

● NoDuring the migration, accounts, permissions, and passwords arenot migrated.






MigrateObject

You can choose to migrate all objects, tables, or databases basedon your service requirements.● All: All objects in the source database are migrated to the

destination database. After the migration, the object names willremain the same as those in the source database and cannot bemodified.

● Tables: The selected table-level objects will be migrated.● Databases: The selected database-level objects will be

migrated.

If the source database is changed, click in the upper rightcorner before selecting migration objects to ensure that the objectsto be selected are from the changed source database.NOTE

● If you choose not to migrate all of the databases, the migration may failbecause the objects, such as stored procedures and views, in thedatabase to be migrated may have dependencies on other objects thatare not migrated. To prevent migration failure, migrate all of thedatabases.

● When you select an object, the spaces before and after the object nameare not displayed. If there are multiple spaces in the middle of the objectname, only one space is displayed.

● The search function can help you quickly select the required databaseobjects.

Step 5 On the Check Task page, check the migration task.● If any check fails, review the cause and rectify the fault. After the fault is

rectified, click Check Again.For details about how to handle check failures, see section CheckingWhether the Source Database Is Connected in Data Replication ServiceUser Guide.



https://support.huaweicloud.com/intl/en-us/usermanual-drs/drs_precheck.html


Figure 3-14 Pre-check

● If the check is complete and the check success rate is 100%, click Next.

NO TE

You can proceed to the next step only when all checks are successful. If there are anyitems that require confirmation, view and confirm the details first before proceeding tothe next step.

Step 6 Compare source and destination parameters.

Comparing common parameters and performance parameters helps you evaluatethe consistency between source and destination databases without affecting themigration process. It mainly ensures that services are not affected after migrationis completed.● This process is optional, so you can click Next to skip the comparison.● Compare common parameters:

If the common parameter values in the comparison results are inconsistent,click Save Change to change the destination database values to be the sameas those of the source database.

Figure 3-15 Modifying common parameters



Performance parameter values in both the source and destination databasescan be the same or different.– If you need to change the performance parameter values that are

consistent in the comparison results to different values, locate the targetparameter, enter values in the Change To column, and click Save Changein the upper left corner.

– If you want to make the performance parameter values of the source anddestination database be the same:

i. Click Use Source Database Value.DRS automatically makes the destination database values the sameas those of the source database.

Figure 3-16 One-click modification

NO TE

You can also manually enter parameter values.

ii. Click Save Change to save your changes.The system changes the parameter values based on your settings forthe destination database values. After the modification, the list isupdated automatically.



Figure 3-17 Performance parameters

Some parameters in the destination database require a restart beforethe changes can take effect. The system will display these as beinginconsistent. In addition, before or after the migration, restart thedestination database at a scheduled time when your services areleast affected by the restart.For details about parameter comparison, see Parameters forComparison in the Data Replication Service User Guide.

iii. Click Next.

Step 7 On the Confirm Task page, specify Start Time, confirm that the configuredinformation is correct and click Submit to submit the task.

Set Start Time to Start upon task creation or Start at a specified time based onsite requirements.

After a migration task is started, the performance of the source and destinationdatabases may be affected. You are advised to start a migration task during off-peak hours.

Step 8 After the task is submitted, view and manage it on the Online MigrationManagement page.● For more information about task status, see Task Status.

● You can click in the upper-right corner to view the latest task status.

----End

3.3.2 Creating a Migration Task in a VPC NetworkDRS allows you to migrate cloud databases in a VPC network.

On the DRS console, you can follow the guidelines to create and manage amigration task.

This section uses the migration from MySQL to RDS MySQL as an example todescribe how to configure a migration task over a VPC network on the DRSconsole.







Procedure



















Data Flow Select To the cloud.The destination database must be an RDSdatabase on the current cloud.


Destination DB Engine Select MySQL.

Network Type Select VPC.Available options: VPC, VPN or Direct Connect,and Public network. By default, the value is Publicnetwork.● VPC is suitable for migrations of cloud

databases.● Public network is suitable for migrations from

on-premises or external cloud databases to thedestination databases bound with an EIP.

● VPN is suitable for migrations from on-premisesdatabases to cloud databases or between clouddatabases across regions.

● Direct Connect is suitable for migrations fromon-premises databases to cloud databases orbetween cloud databases across regions.

Destination DB Instance Select the DB instance you have created.





Specifies the subnet where the replication instanceresides. You can also click View Subnet to go tothe network console to view the subnet where theinstance resides.By default, the DRS instance and the destinationDB instance are in the same subnet. You need toselect the subnet where the DRS instance resides,and there are available IP addresses for the subnet.To ensure that the replication instance issuccessfully created, only subnets with DHCPenabled are displayed.

Destination DatabaseAccess

● Read-onlyDuring the migration, the destination databaseis read-only. After the migration is complete, itbecomes readable and writable. This optionensures the integrity and success rate of datamigration.

● Read/WriteDuring migration, the destination database canbe queried or modified. Data may be modifiedwhen operations are performed or applicationsare connected. It should be noted thatbackground processes can often generate ormodify data, which may result in data conflicts,task faults, and upload failures. Do not selectthis option if you do not fully understand therisks.




Migration Type ● FullThis migration type is suitable for scenarioswhere service interruption is acceptable. Allobjects and data in non-system databases aremigrated to the destination database at onetime. The objects include tables, views, andstored procedures.NOTE

If you perform a full migration, do not performoperations on the source database. Otherwise, datagenerated in the source database during themigration will not be synchronized to the destinationdatabase.

● Full+IncrementalThis migration type allows you to migrate datawithout interrupting services. After a fullmigration initializes the destination database,an incremental migration initiates and parseslogs to ensure data consistency between thesource and destination databases.

NOTEIf you select the Full+Incremental migration type, datagenerated during the full migration will be synchronizedto the destination database with zero downtime, ensuringthat the source database remain accessible.

Enterprise Project If the DB instance has been associated with anenterprise project, select the target project fromthe Enterprise Project drop-down list.You can also go to the ProjectMan console tocreate a project. For details about how to create aproject, see the ProjectMan User Guide.

Tags This setting is optional. Adding tags helps youbetter identify and manage your tasks. Each taskcan have up to 10 tags.After a task is created, you can view its tag detailson the Tags tab. For detailed operations, see TagManagement.

Step 3 On the Configure Source and Destination Databases page, wait until thereplication instance is created. Then, specify source and destination databaseinformation and click Test Connection for both the source and destinationdatabases to check whether they have been connected to the replication instance.After the connection tests are successful, select the check box before theagreement and click Next.

NO TE

Source databases are classified into two types: self-built databases on ECSs and RDS DBinstances. Configure parameters based on different scenarios.





● Scenario 1: Self-built databases on ECSs - source database configuration

Figure 3-20 Self-build on ECS - source database information

Table 3-11 Self-build on ECS - source database information


SourceDatabase Type

Select Self-built on ECS.

VPC A dedicated virtual network in which the source databaseis located. It isolates networks for different services. Youcan select an existing VPC or create a VPC.

Subnet A subnet provides dedicated network resources that arelogically isolated from other networks, improvingnetwork security. The subnet must be in the AZ wherethe source database resides. You need to enable DHCPfor creating the source database subnet.



Port The port of the source database.Range: 1 - 65535

DatabaseUsername


DatabasePassword








NO TE

The IP address, domain name, username, and password of the source database areencrypted and stored in DRS and will be cleared after the task is deleted.

● Scenario 2: RDS DB instance - source database configuration

Figure 3-21 RDS DB instance - source database information

Table 3-12 RDS DB instance - source database settings


SourceDatabase Type

Select RDS DB Instance.

DB InstanceName

Select the RDS DB instance to be migrated as the sourceDB instance.

DatabaseUsername


DatabasePassword








DB InstanceName

By default, this parameter is set to the RDS DB instanceyou have selected when you create the migration taskand cannot be changed.

DatabaseUsername

The username for accessing the destination database.

DatabasePassword


Migrate Definerto User

– YesThe Definers of all source database objects will bemigrated to the user. Other users do not havepermissions for database objects unless these users areauthorized. For details on authorization, see How Do IMaintain the Original Service User PermissionSystem After Definer Is Forcibly Converted DuringMySQL Migration?

– NoThe Definers of all source database objects will not bechanged. You need to migrate all accounts andpermissions of the source database in the next step.

NO TE

The database username and password are encrypted and stored in the system and willbe cleared after the task is deleted.










FlowControl




● NoThe DR speed is not limited and the outbound bandwidth of thesource database is maximally used, which causes readconsumption on the source database accordingly. For example,if the outbound bandwidth of the source database is 100 MB/sand 80% bandwidth is used, the I/O consumption on the sourcedatabase is 80 MB/s.NOTE







TakeSnapshot

If you perform a full migration, you can take a snapshot for yourdatabases.● No

This option applies to exports for which no data is written tothe source database. If data is modified during a full migration,the exported data is point in time inconsistent. The stability andperformance of a migration without a snapshot taken is betterthan that of a migration with a snapshot taken.

● YesA snapshot with point in time consistent data is generatedduring service running. Data changes during the migration arenot shown in the exported data.NOTE

– Snapshot reads use MySQL backup lock to lock global tables andautomatically unlock them within 3s after consistent reads areenabled. To prevent full migration failures, take a snapshot when thesource database is idle and not perform DML or DDL operationsduring snapshot migration.

– Only MySQL full migration tasks support snapshot mode.– Do not perform DDL operations during migration in snapshot mode.

Otherwise, full migration will fail.

MigrateAccount

During a database migration, accounts need to be migratedseparately.There are accounts that can be migrated completely, accountswhose permissions need to be reduced, and accounts that cannotbe migrated. You can choose whether to migrate the accountsbased on your service requirements. If you select Yes, you canselect the accounts to be migrated as required.● Yes








MigrateObject




migrated.


● If you choose not to migrate all of the databases, the migration may failbecause the objects, such as stored procedures and views, in thedatabase to be migrated may have dependencies on other objects thatare not migrated. To prevent migration failure, migrate all of thedatabases.

● When you select an object, the spaces before and after the object nameare not displayed. If there are multiple spaces in the middle of the objectname, only one space is displayed.










NO TE


Step 6 Compare source and destination parameters.

Comparing common parameters and performance parameters helps you evaluatethe consistency between source and destination databases without affecting themigration process. It mainly ensures that services are not affected after migrationis completed.● This process is optional, so you can click Next to skip the comparison.● Compare common parameters:

If the common parameter values in the comparison results are inconsistent,click Save Change to change the destination database values to be the sameas those of the source database.




Performance parameter values in both the source and destination databasescan be the same or different.– If you need to change the performance parameter values that are

consistent in the comparison results to different values, locate the targetparameter, enter values in the Change To column, and click Save Changein the upper left corner.

– If you want to make the performance parameter values of the source anddestination database be the same:

i. Click Use Source Database Value.DRS automatically makes the destination database values the sameas those of the source database.


NO TE

You can also manually enter parameter values.

ii. Click Save Change to save your changes.The system changes the parameter values based on your settings forthe destination database values. After the modification, the list isupdated automatically.



Figure 3-28 Performance parameters

Some parameters in the destination database require a restart beforethe changes can take effect. The system will display these as beinginconsistent. In addition, before or after the migration, restart thedestination database at a scheduled time when your services areleast affected by the restart.For details about parameter comparison, see Parameters forComparison in the Data Replication Service User Guide.

iii. Click Next.



After a migration task is started, the performance of the source and destinationdatabases may be affected. You are advised to start a migration task during off-peak hours.

Step 8 After the task is submitted, view and manage it on the Online MigrationManagement page.● You can view the task status. For more information about task status, see

Task Status.


----End

3.3.3 Migrating MongoDB Sharded Clusters to DDSOn the DRS console, you can follow the guidelines to create a migration task.After a migration task is created, you can manage it on the DRS console.

This section describes how to create an online migration task to migrateMongoDB databases in a public network. You can also migrate the MongoDBsharded cluster to the DDS Enhanced Edition cluster by referring to operations inthis section.







Procedure



















Data Flow Select To the cloud.The destination database must be a database on the currentcloud.

Source DBEngine

Select MongoDB.

Destination DBEngine

Select DDS.

Network Type Available options: VPC, VPN or Direct Connect, and Publicnetwork. By default, the value is Public network.● VPC is suitable for migrations of cloud databases.● Public network is suitable for migrations from on-

premises or external cloud databases to the destinationdatabases bound with an EIP.

● VPN is suitable for migrations from on-premisesdatabases to cloud databases or between clouddatabases across regions.

● Direct Connect is suitable for migrations from on-premises databases to cloud databases or between clouddatabases across regions.NOTE

The full+incremental migration of a sharded cluster cannot beperformed in a VPC network.

Destination DBInstance

Select the DB instance you have created.




ReplicationInstance Subnet

Specifies the subnet where the replication instance resides.You can also click View Subnet to go to the networkconsole to view the subnet where the instance resides.By default, the DRS instance and the destination DBinstance are in the same subnet. You need to select thesubnet where the DRS instance resides, and there areavailable IP addresses for the subnet. To ensure that thereplication instance is successfully created, only subnets withDHCP enabled are displayed.

Migration Type ● FullThis migration type is suitable for scenarios where serviceinterruption is acceptable. All objects in non-systemdatabases are migrated to the destination database atone time, including collections and indexes.NOTE

If you perform a full migration, do not perform operations onthe source database. Otherwise, data generated in the sourcedatabase during the migration will not be synchronized to thedestination database.

● Full+IncrementalThis migration type allows you to migrate data withoutinterrupting services. After a full migration initializes thedestination database, an incremental migration initiatesand parses logs to ensure data consistency between thesource and destination databases.

NOTEIf you select the Full+Incremental migration type, data generatedduring the full migration will be synchronized to the destinationdatabase with zero downtime, ensuring that the source databaseremain accessible.

Source DBInstance Type

Set this parameter based on the source database.● If the source database is a cluster instance, set this

parameter to Cluster instances.● If the source database is a replica set or a single node

instance, set this parameter to Non-cluster.● If the source database version is MongoDB 4.0+ and the

cluster instance cannot obtain the IP address of thesharded node, you can select Cluster (MongoDB 4.0+).

Source ShardQuantity

If Source DB Instance Type is set to Cluster instances,enter the number of source database instances.The default minimum number of source DB instances is 2and the maximum number is 32. You can set this parameterbased on the number of source database shards.




Enterprise Project If the DB instance has been associated with an enterpriseproject, select the target project from the Enterprise Projectdrop-down list.You can also go to the ProjectMan console to create aproject. For details about how to create a project, see theProjectMan User Guide.

Tags This setting is optional. Adding tags helps you better identifyand manage your tasks. Each task can have up to 10 tags.After a task is created, you can view its tag details on theTags tab. For detailed operations, see Tag Management.








mongos Address IP address or domain name of the source database in the IPaddress/Domain name:Port format. The port of the sourcedatabase. Range: 1 - 65534You can enter a maximum of three groups of IP addresses ordomain names of the source database. Separate multiplevalues with commas (,). For example:192.168.0.1:8080,192.168.0.2:8080. Ensure that the entered IPaddresses or domain names belong to the same shardedcluster.NOTE

If multiple IP addresses or domain names are entered, the testconnection is successful as long as one IP address or domain name isaccessible. Therefore, you must ensure that the IP address or domainname is correct.

AuthenticationDatabase

The name of the authentication database. For example: Thedefault authentication database of DDS instance is admin.

mongosUsername


mongosPassword


SSL Connection SSL encrypts the connections between the source anddestination databases. If SSL is enabled, upload the SSL CAroot certificate.NOTE

● The maximum size of a single certificate file that can beuploaded is 500 KB.

● If the SSL certificate is not used, your data may be at risk.

ShardedDatabase

Enter the information about the sharded databases in thesource database.

NO TE








DB InstanceName

The DB instance you selected when creating themigration task and cannot be changed.

DatabaseUsername


DatabasePassword


NO TE

The username and password of the destination database are encrypted and stored inthe database and the replication instance during the migration. After the task isdeleted, the username and password are permanently deleted.

Step 4 On the Set Task page, select migration objects and click Next.



Figure 3-33 Migration object

Table 3-19 Migration object


MigrateAccount

Accounts to be migrated can be classified into the following types:accounts that can be migrated and accounts that cannot bemigrated. You can choose whether to migrate the accounts.Accounts that cannot be migrated or accounts that are notselected will not exist in the destination database. Ensure thatyour services will not be affected by these accounts.● Yes

If you choose to migrate accounts, see section MigratingAccounts in the Data Replication Service User Guide to migratedatabase users and roles.

● NoDuring the migration, accounts and roles are not migrated.

OtherOptions

Determine whether to migrate the indexes you create during fullmigration. The default index based on _id is automatically createdin the destination. If indexes are not migrated, the indexes are notcompared.






MigrateObject


destination database. After the migration, the object nameswill remain the same as those in the source database andcannot be modified.


migrated.

If the source database is changed, click in the upper rightcorner before selecting migration objects to ensure that theobjects to be selected are from the changed source database.NOTE

● If you choose not to migrate all of the databases, the migration mayfail because the objects, such as stored procedures and views, in thedatabases to be migrated may have dependencies on other objects thatare not migrated. To prevent migration failure, migrate all of thedatabases.

● When you select an object, the spaces before and after the object nameare not displayed. If there are two or more consecutive spaces in themiddle of the object name, only one space is displayed.


Step 5 On the Check Task page, check the migration task.

● If any check fails, review the cause and rectify the fault. After the fault isrectified, click Check Again.

For details about how to handle check failures, see section CheckingWhether the Source Database Is Connected in Data Replication ServiceUser Guide.







NO TE



Step 7 After the task is submitted, view and manage it on the Online MigrationManagement page.● For more information about task status, see Task Status.


Step 8 After the migration task is created, complete data service cutover by referring toProcess in the Data Replication Service Getting Started.

----End

3.3.4 Migrating Databases from MySQL to GaussDB(forMySQL) Primary/Standby

On the DRS console, you can follow the guidelines to create a migration task.After a migration task is created, you can manage it on the DRS console.

This section describes how to configure a task for migration between MySQL andGaussDB(for MySQL) primary/standby in a public network.


Procedure













Data Flow Select To the cloud.The destination is a DB instance on the current cloud.



Select GaussDB(for MySQL) Primary/Standby Edition.

Network Type Available options: VPC, Public network, and VPN orDirect Connect. By default, the value is Public network.● VPC is suitable for migrations of cloud databases.● VPN and Direct Connect are suitable for migrations

from on-premises databases to cloud databases orbetween cloud databases across regions.

● Public network is suitable for migration from on-premises databases or external cloud databases to thedestination databases.


Select the GaussDB(for MySQL) primary/standby instanceyou have created.





Specifies the subnet where the replication instanceresides. You can also click View Subnet to go to thenetwork console to view the subnet where the instanceresides.By default, the DRS instance and the destination DBinstance are in the same subnet. You need to select thesubnet where the DRS instance resides, and there areavailable IP addresses for the subnet. To ensure that thereplication instance is successfully created, only subnetswith DHCP enabled are displayed.

Migration Type ● FullThis migration type is suitable for scenarios whereservice interruption is acceptable. All objects in non-system databases are migrated to the destinationdatabase at one time, including tables, views, storedprocedures, and triggers.NOTE

If you perform a full migration, do not perform operations onthe source database. Otherwise, data generated in the sourcedatabase during the migration will not be synchronized to thedestination database.

● Full+Incremental: This migration type allows you tomigrate data without interrupting services. After a fullmigration initializes the destination database, anincremental migration initiates and parses logs toensure data consistency between the source anddestination databases.NOTE

If you select the Full+Incremental migration type, datagenerated during the full migration will be synchronized tothe destination database with zero downtime, ensuring thatthe source database remain accessible.

DestinationDatabase Access

● Read-onlyDuring migration, the destination database is read-only. After the migration is complete, it restores to theread/write status. This option ensures the integrity andsuccess rate of data migration.

● Read/WriteDuring migration, the destination database can bequeried or modified. Data may be modified whenoperations are performed or applications areconnected. It should be noted that backgroundprocesses can often generate or modify data, whichmay result in data conflicts, task faults, and uploadfailures. Do not select this option if you do not fullyunderstand the risks. Set the destination database toRead/Write only when you need to modify other datain the database during the migration.




Enterprise Project If the DB instance has been associated with an enterpriseproject, select the target project from the EnterpriseProject drop-down list.You can also go to the ProjectMan console to create aproject. For details about how to create a project, see theProjectMan User Guide.

Tags This setting is optional. Adding tags helps you betteridentify and manage your tasks. Each task can have up to10 tags.After a task is created, you can view its tag details on theTags tab. For detailed operations, see Tag Management.







Port The port of the source database.Range: 1 - 65535





DatabaseUsername


DatabasePassword





NO TE






DB InstanceName

By default, this parameter is set to the DB instance youhave selected when you create the migration task andcannot be changed.

DatabaseUsername





DatabasePassword


Migrate Definerto User

– YesThe Definers of all source database objects will bemigrated to the user. Other users do not havepermissions for database objects unless these users areauthorized. For details on authorization, see How Do IMaintain the Original Service User PermissionSystem After Definer Is Forcibly Converted DuringMySQL Migration?

NOTEFor the migration from MySQL to GaussDB(for MySQL) primary/standby, you can only select Yes. After the migration, theDefiners of all source database objects will be migrated to theuser.

NO TE

The username and password of the destination databases are encrypted and stored inDRS, and will be cleared after the task is deleted.


Figure 3-39 Setting migration objects







Table 3-24 Migration object


MigrateAccount

During a database migration, accounts need to be migratedseparately.You can choose whether to migrate the accounts based on yourservice requirements. If you select Yes, you can select the accountsto be migrated as required.● Yes



MigrationObject




migrated.


● If you choose not to migrate all of the databases, the migration may failbecause the objects, such as stored procedures and views, in thedatabases to be migrated may have dependencies on other objects thatare not migrated. To prevent migration failure, migrate all of thedatabases.













NO TE



Step 7 After the task is submitted, view and manage it on the Online MigrationManagement page.

● For more information about task status, see Task Status.


Step 8 After the migration task is created, complete data service cutover by referring toProcess in the Getting Started with Data Replication Service.

----End

3.3.5 Migrating Databases from DDS to MongoDBDRS enables you to migrate data out of the cloud for data rollback.

This section describes how to migration DDS DB instances to your localMonogoDB database over the public network.

Prerequisites● You have logged in to the DRS console.

● Your account balance is greater than or equal to $0 USD.

● For details about real-time migration, see Real-Time Migration

● For details about constraints on DRS usage, see Before You Start.







Procedure
















Data Flow Select Out of the cloud.The source database is an RDS database on the currentcloud or a DDS DB instance. It is required that either thesource database or the destination database is on thecurrent cloud.

Source DB Engine Select DDS.


Select MongoDB.

Network Type Available options: Public network, VPC, VPN or DirectConnect● VPC is suitable for migrations of cloud databases.● VPN and Direct Connect are suitable for migrations

from on-premises databases to cloud databases orbetween cloud databases across regions.

● Public network is suitable for migrations from on-premises databases or external cloud databases todestination databases.

Source DB Instance Select the DDS DB instance to be migrated.


Specifies the subnet where the replication instanceresides. You can also click View Subnet to go to thenetwork console to view the subnet where the instanceresides.By default, the DRS instance and the destination DBinstance are in the same subnet. You need to select thesubnet where the DRS instance resides, and there areavailable IP addresses for the subnet. To ensure that thereplication instance is successfully created, only subnetswith DHCP enabled are displayed.




Migration Type ● FullThis migration type is suitable for scenarios whereservice interruption is acceptable. All objects in non-system databases are migrated to the destinationdatabase at one time, including collections andindexes.NOTE

If you perform a full migration, do not perform operationson the source database. Otherwise, data generated in thesource database during the migration will not besynchronized to the destination database.

● Full+Incremental● This migration type allows you to migrate data

without interrupting services. After a full migrationinitializes the destination database, an incrementalmigration initiates and parses logs to ensure dataconsistency between the source and destinationdatabases.

NOTEIf you select the Full+Incremental migration type, datagenerated during the full migration will be synchronized to thedestination database with zero downtime, ensuring that thesource database remain accessible.

Enterprise Project If the DB instance has been associated with an enterpriseproject, select the target project from the EnterpriseProject drop-down list.You can also go to the ProjectMan console to create aproject. For details about how to create a project, see theProjectMan User Guide.

Tags This setting is optional. Adding tags helps you betteridentify and manage your tasks. Each task can have upto 10 tags.After a task is created, you can view its tag details on theTags tab. For detailed operations, see Tag Management.








DB Instance Name The DB instance you selected when creating themigration task and cannot be changed.

Database Username The username for accessing the source database.


NO TE

The username and password of the source database are encrypted and stored in thedatabase and the replication instance during the migration. After the task is deleted, theusername and password are permanently deleted.






IP Address or DomainName

IP address or domain name of the source database inthe IP address/Domain name:Port format. The port ofthe source database. Range: 1 - 65534You can enter a maximum of three groups of IPaddresses or domain names of the source database.Separate multiple values with commas (,). For example:192.168.0.1:8080,192.168.0.2:8080. Ensure that theentered IP addresses or domain names belong to thesame instance.NOTE

If multiple IP addresses or domain names are entered, the testconnection is successful as long as one IP address or domainname is accessible. Therefore, you must ensure that the IPaddress or domain name is correct.


The name of the authentication database. For example:The default authentication database of HUAWEI CLOUDDDS instance is admin.

Database Username The username for accessing the destination database.








NO TE

The IP address, domain name, username, and password of the destination database areencrypted and stored in DRS and will be cleared after the task is deleted.


Figure 3-45 Setting migration objects

Table 3-29 Migration objects


OtherOptions

Determine whether to migrate the indexes you create during fullmigration. The default index based on _id is automatically createdin the destination. If indexes are not migrated, the indexes are notcompared.




MigrateObject


destination database. After the migration, the object names willremain the same as those in the source database and cannotbe modified.


migrated.

If the source database is changed, click in the upper rightcorner before selecting migration objects to ensure that theobjects to be selected are from the changed source database.NOTE











NO TE

You can proceed to the next step only when all checks passed. If there are any itemsthat require confirmation, view and confirm the details first before proceeding to thenext step.


NO TE

● Set Start Time to Start upon task creation or Start at a specified time based on siterequirements.

● After a migration task is started, the performance of the source and destinationdatabases may be affected. You are advised to start a migration task during off-peakhours.




----End

3.4 Task Management

3.4.1 Viewing Task DetailsThis section describes how to view details about a migration task, includinginformation about the task, replication instance, and migration.


● A migration task has been created.

ProcedureNO TE

In the task list, only tasks created by the current login user are displayed. Tasks created bydifferent users of the same tenant are not displayed.

Step 1 On the Online Migration Management page, click the target migration taskname in the Task Name/ID column.

Step 2 On the displayed Basic Information tab, view details about the migration task.

You can view information about the task, replication instance, and migration.

----End




3.4.2 Editing Migration Task InformationAfter a migration task is created, you can modify task information to identifydifferent tasks.

The following task information can be edited:

● Task name● Description● SMN topic● Synchronization delay threshold● Number of days when an abnormal task is stopped● Task start time

Prerequisites● You have logged in to the DRS console.● A migration task has been created.

Procedure


Step 2 On the Basic Information tab, locate the information to be modified in the TaskInformation area.

● You can click to modify the task name, SMN topic, delay threshold, thetime to stop abnormal tasks, and description.

– To submit the change, click .

– To cancel the change, click .


Task Information Description


Description The description consists of a maximum of 256characters and cannot contain the following specialcharacters: !<>&'\"

SMN Topic You can apply for a topic on the SMN console and adda subscription.For details, see Simple Message Notification UserGuide.

SynchronizationDelay Threshold

The delay ranges from 1s to 3600s.






Stop AbnormalTasks After

The value must range from 14 to 100.

● You can modify the task start time only when the task is in the Pending start

status.In the Task Information area, click Modify in the Scheduled Start Timefield. On the displayed page, specify the scheduled start time and click OK.

Step 3 View the change result on the Basic Information tab.

----End

3.4.3 Editing a Migration TaskThis section describes how to modify configuration information of a migrationtask, including information about the task, replication instance, and migration. Formigration tasks in the following statuses, you can edit the tasks again after thereplication instances are created:

● Creating● Configuration


Method 1

Step 1 In the task list on the Online Migration Management page, locate the targettask and click Edit in the Operation column.

Step 2 On the Configure Source and Destination Databases page, enter informationabout the source and destination databases and click Next.






Flow ControlNOTE

Only the migrationfrom MySQL toMySQL supportsthis function.


You can customize the maximum migration speed.In addition, you can set the time range based on yourservice requirements. The traffic rate setting usuallyincludes setting of a rate limiting time period and atraffic rate value. Flow can be controlled all day orduring specific time ranges. The default value is All day.A maximum of three time ranges can be set, and theycannot overlap.The flow rate must be set based on the service scenarioand cannot exceed 9,999 MB/s.


● NoThe migration speed is not limited and the outboundbandwidth of the source database is maximally used,which will increase the read burden on the sourcedatabase. For example, if the outbound bandwidth ofthe source database is 100 MB/s and 80% bandwidth isused, the I/O consumption on the source database is 80MB/s.NOTE

– Flow control mode takes effect only during a full migration.– You can also change the flow control mode after creating a

task. For details, see Modifying the Flow Control Mode.





Take Snapshot If you perform a full migration, you can take a snapshot foryour databases.● No

This option applies to exports for which no data iswritten to the source database. If data is modifiedduring a full migration, the exported data is point intime inconsistent. The stability and performance of amigration without a snapshot taken is better than thatof a migration with a snapshot taken.

● YesA snapshot with consistent data at the point in time isgenerated during service running. Data changes duringmigration are not shown in the exported data.NOTE

– Snapshot reads use MySQL backup lock to lock global tablesand automatically unlock them within 3s after consistentreads are enabled. To prevent full migration failures, take asnapshot when the source database is idle and does notperform DML or DDL operations during snapshot migration.

– The snapshot function is supported only for full migration ofdatabases whose engine is MySQL.

– Do not perform DDL operations during migration insnapshot mode. Otherwise, full migration will fail.

Migrate Account During a database migration, accounts need to be migratedseparately.There are accounts that can be migrated completely,accounts whose permissions need to be reduced, andaccounts that cannot be migrated. You can choose whetherto migrate the accounts based on your servicerequirements. If you select Yes, you can select the accountsto be migrated as required.● Yes

If you choose to migrate accounts, see MigratingAccounts in the Data Replication Service User Guide tomigrate database users, permissions, and passwords.

● NoDuring migration, accounts, permissions, and passwordsare not migrated.






Migrate Object You can choose to migrate all objects, tables, or databasesbased on your service requirements.● All: All objects in the source database are migrated to

the destination database. After the migration, the objectnames will remain the same as those in the sourcedatabase and cannot be modified.


migrated.

If the source database is changed, click in the upperright corner before selecting migration objects to ensurethat the objects to be selected are from the changed sourcedatabase.NOTE

● If you choose not to migrate all of the databases, the migrationmay fail because the objects, such as stored procedures andviews, in the databases to be migrated may have dependencieson other objects that are not migrated. To prevent migrationfailure, migrate all of the databases.

● When you select an object, the spaces before and after theobject name are not displayed. If there are two or moreconsecutive spaces in the middle of the object name, only onespace is displayed.

● The search function can help you quickly select the requireddatabase objects.









NO TE


Step 5 On the Confirm Task page, specify Start Time, confirm that the configuredinformation is correct, and click Submit to submit the task.

NO TE


● After a migration task is started, the performance of the source and destinationdatabases may be affected. You are advised to start a migration task during off-peakhours.

● Under specific conditions, the destination database needs to be restarted once duringthe task startup, which may interrupt database services.


● For more information about task statuses, see Migration Task Statuses.


----End

Method 2


Step 2 On the displayed page, click edit this task to go to the Configure Source andDestination Databases page.




Step 3 Perform Step 2 through Step 6 from method 1.

----End

3.4.4 Resuming a Migration TaskA fault may occur during the migration due to external factors, such as insufficientstorage space. After the fault is rectified based on the migration log information,you can resume the migration.

If a migration task in the Full migration status fails, DRS allows you to resumethe task.

NO TE

● If the full migration task fails due to non-network problems, the system willautomatically resume the task three times by default. If the failure persists, you canresume the task manually.

● If the full migration is performed in snapshot mode and fails, it cannot be resumed.

Prerequisites● You have logged in to the DRS console.● A migration task has failed.

Method 1

On the Online Migration Management page, locate the target task and clickResume in the Operation column.

Method 2

Step 1 In the task list on the Online Migration Management page, locate and click thetarget task.

Step 2 On the displayed page, click the Migration Progress tab, and click Resume in theupper left corner.

----End

3.4.5 Resetting a Migration TaskDuring MySQL to MySQL migration, if the migration task fails due to uncertaincauses, the background will resume the task several times. However, the task mayfail to be recovered in some scenarios. To continue the migration, DRS allows youto reset the task.

You can reset failed migration tasks in the following status:

● Incremental migration● Full migration




● A migration task has failed.

Method 1

Step 1 In the task list on the Online Migration Management page, locate the targettask and click Reset in the Operation column.

Step 2 In the displayed dialog box, check the migration task again.

Step 3 After the check is complete and the check success rate is 100%, click Start tosubmit the migration task again.

----End

Method 2

Step 1 On the Data Migration Management page, click the target task name in theTask Name/ID column.

Step 2 On the displayed page, click the Migration Progress tab, and click Reset in theupper left corner.

Step 3 Perform Step 2 to Step 3 from method 1.

----End

3.4.6 Pausing a Migration TaskDuring migration, if the flow control mode cannot meet the requirements duringpeak hours, you can pause the migration task.

Prerequisites● You have logged in to the DRS console.● The migration task is running properly.

Procedure

Step 1 In the task list on the Online Migration Management page, locate the targettask and click Pause in the Operation column.

Step 2 In the displayed Pause Task dialog box, select Pause log capturing and click Yes.

NO TE

● After the task is paused, the status of the task becomes Pause.

● After you select Pause log capturing, the DRS instance will no longer communicatewith the source and destination databases. If the pause duration is too long, the taskmay fail to be resumed because the logs required by the source database expire. It isrecommended that the pause duration be less than or equal to 24 hours.

● You can use the resumable transfer function to continue the migration.

----End



3.4.7 Stopping a Migration TaskAfter the source database and services are migrated to the destination database,you can stop the migration task. To prevent data from being overwritten after thesource database and services are migrated to the destination database, operationson the source database should not be synchronized to the destination database.This section describes how to stop a migration task to achieve this goal.

You can stop a task in any of the following statuses:

● Creating● Configuration● Pending start● Full migration● Incremental migration● Incremental migration failed● Task stopping● Fault rectification

NO TICE

● You are advised to stop the task before performing other operations, such asdisconnecting the network between the source database and the replicationinstance. Otherwise, an alarm indicating that the source database cannot beconnected will be generated.

● For a task in the Configuration state, it cannot be stopped if it fails to beconfigured.

● For a task in the Fault rectification state, it cannot be stopped if the fault isbeing rectified.

● After a task is stopped, it cannot be resumed.

Prerequisites● You have logged in to the DRS console.● A migration task is in progress.

Procedure

Step 1 On the Online Migration Management page, locate the target task and clickStop in the Operation column.

Step 2 In the displayed dialog box, click OK.



NO TE

● Generally, stopping a task can ensure the integrity of special objects (triggers and eventsare migrated in the final migration phase). In rare cases (for example, networkexceptions), a task may fail to be stopped. If a task fails to be stopped multiple times,you can select Forcibly stop task to reduce the wait time.

● If you forcibly stop a task, the migration task will be stopped first. Triggers and eventsmay not be completely migrated in some cases and you need to manually migratethem.

----End

3.4.8 Deleting a Migration TaskThis section describes how to delete a migration task that has been completed orhas failed. Deleted tasks will no longer be displayed in the task list. Exercisecaution when performing this operation.

Prerequisites● You have logged in to the DRS console.● A migration task that has been completed or fails to be configured exists.

Method 1

Step 1 In the task list on the Online Migration Management page, locate the targettask and click Delete in the Operation column.

Step 2 Click Yes to submit the deletion task.

----End

Method 2

Step 1 In the task list on the Online Migration Management page, select the targettasks and click Delete in the upper left of the migration task list.

Figure 3-50 Deleting migration tasks

NO TE

● You can select one or more tasks in a batch delete action.

● If you select a task that cannot be deleted, the batch delete operation cannot beperformed.


----End



3.4.9 Modifying the Flow Control ModeYou can choose whether to control the flow. DRS allows you to change the flowcontrol mode after a migration task is created. Currently, only real-time migrationfrom MySQL to MySQL supports this function.

NO TE

● Flow control mode takes effect only during a full migration.● After the traffic rate is modified in the incremental migration phase, the modification

takes effect when the task enters the full migration phase again.


Method 1

Step 1 In the Migration Information area on the Basic Information tab, click Modifynext to the Flow Control field.

Figure 3-51 Basic information

Step 2 In the displayed dialog box, modify the settings.



Figure 3-52 Modifying the flow console mode

----End

Method 2

Step 1 In the task list on the Online Migration Management page, locate the targettask and choose More > Speed or Speed in the Operation column.

Figure 3-53 Task list





----End

3.4.10 Quick ComparisonTo accelerate and simplify the migration process, DRS provides the quickcomparison function. You can directly perform a comparison on the migration tasklist. This function can be used to compare all migration objects only whenincremental migration tasks are in progress.

Creating a Comparison Task

Step 1 On the Online Migration Management page, locate the target migration taskand click Compare in the Operation column.

Step 2 On the Create Comparison Task page, select Start upon task creation or Startat a specified time and click Yes to start the comparison task.

----End

Viewing a Comparison Task

Step 1 On the Online Migration Management page, locate the target migration taskand click View in the Operation column.

Step 2 On the Migration Comparison tab, view the data comparison result.

----End



3.4.11 Batch OperationsTo facilitate task management, DRS supports batch operation. You can performthe following batch operations for real-time migration tasks:

● Delete● Stop● Pause● Resume● Configure Exception Notification

Procedure

Step 1 On the Online Migration Management page, select the tasks to be changed.

Step 2 Click the Batch Operation drop-down box in the upper left corner and select theoperation you want to perform, for example, Delete.

Step 3 In the displayed dialog box, confirm the task information and click Yes.

----End

3.4.12 Managing Tags

ScenariosTag Management Service (TMS) enables you to use tags on the managementconsole to manage resources. TMS works with other cloud services to managetags. TMS manages tags globally, and other cloud services manage their own tags.● You are advised to set predefined tags on the TMS console.● A tag consists of a key and value. You can add only one value for each key.● Each DB instance can have up to 10 tags.

Adding a Tag


Step 2 On the Basic Information tab, click the Tags tab.

Step 3 On the Tags tab, click Add Tag. In the displayed dialog box, enter a tag key andvalue, and click OK.



● When you enter a tag key and value, the system automatically displays alltags (including predefined tags and resource tags) associated with all DBinstances except the current one.

● The tag key must be unique and must consist of 1 to 36 characters. Onlyletters, digits, hyphens (-), and underscores (_) are allowed.

● The tag value can be empty or consist of 1 to 43 characters. Only letters,digits, hyphens (-), and underscores (_) are allowed.

Step 4 After a tag has been added, you can view and manage it on the Tags page.

----End

Editing a Tag



Step 3 On the Tags page, click Add/Edit Tags. In the displayed dialog box, modify thetag and click OK.

----End

Delete a Tag



Step 3 On the Tags page, locate the tag to be deleted and click Delete in the Operationcolumn. In the displayed dialog box, click Yes.

Step 4 After the tag is deleted, it will no longer be displayed on the Tags page.

----End



4 Backup Migration

4.1 Viewing Task DetailsThe Basic Information page of a backup migration task displays informationabout the task, backup files, and databases. This section describes how to viewdetails about current migration task.

Prerequisites

You have logged in to the DRS console.

ProcedureNO TE


Step 1 On the Backup Migration Management page, click the target migration taskname in the Task Name/ID column.

Step 2 On the displayed Basic Information tab, view details about the migration task.

You can view information about the task, backup files, and databases.

----End

4.2 Editing Migration Task InformationAfter a backup migration task is created, you can modify task information toidentify different tasks.


● Task name

● Description

Data Replication ServiceUser Guide 4 Backup Migration


Prerequisites


Procedure


Step 2 On the Basic Information page, click next to the information to modify.

● To submit the change, click .

● To cancel the change, click .

Table 4-1 Task information description


Task name The task name consists of 4 to 50 characters, starts with aletter, and can contain only letters (case-insensitive),digits, hyphens (-), and underscores (_).

Description The description consists of a maximum of 256 charactersand cannot contain the following special characters: !=<>'&"


----End

4.3 Viewing Migration LogsMigration logs refer to the warning-, error-, and info-level logs generated duringthe migration process. This section describes how to view migration logs to locateand analyze database problems, if any.

Prerequisites


Procedure


Step 2 On the displayed page, click Migration Logs to view the logs generated duringthe migration.



Figure 4-1 Viewing migration logs

You can view time, levels, and descriptions of the logs.

----End

4.4 Deleting a Migration TaskThis section describes how to delete a migration task. Deleted tasks will no longerbe displayed in the task list. Exercise caution when performing this operation.

PrerequisitesYou have logged in to the DRS console.

Method 1

Step 1 In the task list on the Backup Migration Management page, locate the targettask and click Delete in the Operation column.


----End

Method 2

Step 1 In the task list on the Backup Migration Management page, select the targettasks and click Delete in the upper left of the migration task list.

Figure 4-2 Deleting a backup migration task

NO TE




----End



4.5 Batch OperationsTo facilitate task management, DRS supports batch operation. You can performthe following batch operation for real-time migration tasks:

● Delete

Procedure

Step 1 On the Backup Migration Management page, select the task to be deleted.

Step 2 Click the Batch Operation drop-down list box in the upper left corner and selectDelete.


----End

4.6 Tag Management


Adding a Tag










----End

Editing a Tag




----End

Delete a Tag





----End



5 Real-Time Synchronization

5.1 Data Synchronization TopologiesDRS real-time synchronization supports multiple topology types. You can plan thetopology types as required. For details, see the following content.

NO TE

To ensure data consistency, do not modify the synchronization objects in the destinationdatabase.

One-to-One Real-Time Synchronization

You can create a one-to-one synchronization task.

Data Replication ServiceUser Guide 5 Real-Time Synchronization


One-to-Many Real-Time Synchronization

You need to create multiple synchronization tasks to implement one-to-many real-time synchronization. For example, to synchronize data from instance A toinstances B, C, and D, you need to create three synchronization tasks.



Many-to-One Real-Time Synchronization

You need to create multiple synchronization tasks to implement many-to-one real-time synchronization. For example, to synchronize data from instances B, C, and Dto instance A, you need to create three synchronization tasks. Multiple tables canbe synchronized to one table.

For details about the restrictions and operation suggestions on the many-to-onescenario, see FAQs.

5.2 Configuring Synchronization Tasks

5.2.1 From DDM to RDS MySQLThis section uses DDM to RDS MySQL synchronization as an example to describehow to configure a synchronization task.



● For details about real-time synchronization, see Real-Time Synchronization.







Procedure

Step 1 On the Data Synchronization Management page, click Create SynchronizationTask.

Step 2 On the displayed page, select the region and specify Task Name, SendNotification, SMN Topic, Synchronization Delay Threshold, Stop AbnormalTasks After, Description, and synchronization instance details. Then, click Next.

Figure 5-1 Synchronization task information

Table 5-1 Task and recipient description


Region The region where the synchronization instance is deployed.You can change the region.

Task Name The task name consists of 4 to 50 characters, starts with aletter, and can contain only letters (case-insensitive),digits, hyphens (-), and underscores (_).

Send Notifications SMN topic. This parameter is optional. If an exceptionoccurs during synchronization, the system will send anotification to the specified recipients.

SMN Topic This parameter is available only after you enable SendNotification and create a topic on the SMN console andadd a subscriber.For details, see Simple Message Notification User Guide.






During an incremental synchronization, a synchronizationdelay indicates a time difference (in seconds) ofsynchronization between the source and destinationdatabase.If the synchronization delay exceeds the threshold youspecify, DRS will send alarms to the specified recipients.The value ranges from 1 to 3,600. To avoid repeatedalarms caused by the fluctuation of delay, an alarm is sentonly after the delay has exceeded the threshold for sixminutes.NOTE

● In the early stages of an incremental synchronization, thesynchronization delay is long because a large quantity of datais awaiting synchronization. In this case, no notifications willbe sent.

● Before setting the delay threshold, enable Send Notification.


Number of days after which an abnormal task isautomatically stopped. The value must range from 14 to100.NOTE

Tasks in the abnormal state are still charged. If tasks remain in theabnormal state for a long time, they cannot be resumed.Abnormal tasks run longer than the period you set (unit: day) willautomatically stop to avoid unnecessary fees.

Description The description consists of a maximum of 256 charactersand cannot contain the following special characters: !=<>'&"\

Figure 5-2 Synchronization instance information



Table 5-2 Synchronization instance settings


Data Flow Select To the cloud.

Source DBEngine

Select DDM.


Select MySQL.

Network Type The public network is used as an example. Available options:Public network and VPC.


The RDS DB instance you created.

SynchronizationInstance Subnet

Select the subnet where the synchronization instance islocated. You can also click View Subnet to go to thenetwork console to view the subnet where the instanceresides.By default, the DRS instance and the destination DBinstance are in the same subnet. You need to select thesubnet where the DRS instance resides and ensure thatthere are available IP addresses. To ensure that thesynchronization instance is successfully created, only subnetswith DHCP enabled are displayed.

SynchronizationMode

Full+IncrementalThis synchronization mode allows you to synchronize data inreal time. After a full synchronization initializes thedestination database, an incremental synchronization parseslogs to ensure data consistency between the source anddestination databases.NOTE

If you select the Full+Incremental synchronization mode, datagenerated during the full synchronization will be synchronized tothe destination database in real time, ensuring that both the sourceand destination databases remain accessible.

Source DBInstanceQuantity

The default minimum number of source DB instances is 2and the maximum number is 16. You can set this parameterbased on the number of source database shards.






Step 3 On the Configure Source and Destination Databases page, wait until thesynchronization instance is created. Then, specify source and destination databaseinformation and click Test Connection for both the source and destinationdatabases to check whether they have been connected to the synchronizationinstance. After the connection tests are successful, select the check box before theagreement and click Next.




Middleware IPAddress orDomain Name



MiddlewareUsername

The username of the source DDM instance.

MiddlewarePassword

The password for the source DDM instance username.



https://support.huaweicloud.com/intl/en-us/usermanual-drs/drs_synchronization_tag.html





DB Instance The sharded database details.

NO TE





DB InstanceName

The RDS DB instance selected during synchronization taskcreation. This parameter cannot be changed.

DatabaseUsername


DatabasePassword

The database username and password are encrypted andstored in the system and will be cleared after the task isdeleted.

Step 4 On the Set Synchronization Task page, select the objects to be synchronized, andthen click Next.



Figure 5-5 Synchronization mode

Table 5-5 Synchronization mode and object


SynchronizationObject

DRS supports table-level synchronization. You can select data forsynchronization based on your service requirements. The searchfunction can help you quickly select the required database objects.

Step 5 On the Check Task page, check the synchronization task.● If any check fails, review the cause and rectify the fault. After the fault is


● If all check items are successful, click Next.






NO TE


Step 6 On the Confirm Task page, specify Start Time, confirm that the configuredinformation is correct, select the check box before the agreement, and click Next.

NO TE


● After a synchronization task is started, the performance of the source and destinationdatabases may be affected. You are advised to start a synchronization task during off-peak hours.

Step 7 After the task is submitted, you can view and manage it on the DataSynchronization Management page.● You can view the status of the task that has been submitted. For details about

the task status, see Task Status.


----End

5.2.2 From DDM to GaussDB(DWS)This section uses DDM to GaussDB(DWS) synchronization as an example todescribe how to configure a synchronization task.

Prerequisites● You have logged in to the DRS console.● Your account balance is greater than or equal to $0 USD.● For details about real-time synchronization, see Real-Time Synchronization.● For details about constraints on DRS usage, see Before You Start.

ProcedureStep 1 On the Data Synchronization Management page, click Create Synchronization

Task.












Source DBEngine

Select DDM.


Select GaussDB(DWS).

Network type The Public network is used as an example. Availableoptions: Public network, VPC, VPN or Direct Connect


An available GaussDB(DWS) instance.






SynchronizationMode




The default number of source DB instances is 2 and themaximum number is 16. You can set this parameter basedon the number of source database shards.













MiddlewareUsername


MiddlewarePassword






NO TE

The IP address, port, username, and password of the source database are encrypted andstored in the database and the synchronization instance, and will be cleared after the taskis deleted.






DB InstanceName

The default value is the GaussDB(DWS) instance selected forcreating the migration task. It cannot be changed.

DatabaseUsername


DatabasePassword


NO TE

The username and password of the destination database are encrypted and stored in thedatabase and the synchronization instance during the synchronization. After the task isdeleted, the username and password are permanently deleted.








Select Tables, Databases, or Import object file as required.● The search function can help you quickly select the required

database objects.

● If the source database is changed, click in the upper rightcorner before selecting migration objects to ensure that theobjects to be selected are from the changed source database.

● If the synchronization objects in source and destinationdatabases have different names, you can map the source objectname to the destination one. For details, see Mapping ObjectNames.

Step 5 On the Data Processing page, select the table object to be processed, enter thecolumn name, type, and operation type to be added, confirm the information, andclick Next.

Figure 5-12 Processing data









NO TE



NO TE





● You can click in the upper right corner to view the latest task status.

----End

5.2.3 From DDM to KafkaThis section uses DDM to Kafka synchronization as an example to describe how toconfigure a synchronization task.

Prerequisites● You have logged in to the DRS console.● Your account balance is greater than or equal to $0 USD.




● For details about real-time synchronization, see Real-Time Synchronization.● For details about constraints on DRS usage, see Before You Start.

Procedure

















Data Flow Select Out of the cloud.

Source DBEngine

Select DDM.


Select Kafka.

Network types The Public network is used as an example. Availableoptions: VPC, Public network and VPN or Direct Connect

Source DBInstance

An available DDM instance.



SynchronizationMode

IncrementalThrough log parsing, incremental data generated on thesource database is synchronized to the destination databasein real time.During synchronization, the source database continues toprovide services for external systems with zero downtime.



Step 3 On the Configure Source and Destination Databases page, after thesynchronization instance is created, specify source and destination databaseinformation and click Test Connection for both the source and destinationdatabases to check whether they have been connected to the synchronizationinstance. After the connection tests are successful, click Next.







DB InstanceName


DatabaseUsername


DatabasePassword


NO TE









NO TE


Step 4 On the Set Synchronization Task page, select the synchronization object and clickNext.


Table 5-15 Synchronization object


TopicSynchronizationPolicy

Topic synchronization policy. You can select A specific topic orAuto-generated topics.

Topic Select the topic to be synchronized to the destination database.This parameter is available when the topic is set to A specifiedtopic.

TopicNameFormat

Topic name format. This parameter is available when TopicSynchronization Policy is set to Auto-generated topics.Only variables database and tablename are supported. The othercharacters must be constants. Replace $database$ with thedatabase name and $tablename$ with the table name.For example, if this parameter is set to $database$-$tablename$and the database name is db1, and the table name is tab1, thetopic name is db1-tab1. If DDL statements are synchronized,$tablename$ is empty and the topic name is db1.




Synchronize Topic To

The policy for synchronizing topics to the Kafka partitions.● If topics are synchronized to different partitions by hash value

of the database and table names, the performance on a singletable query can be improved.

● If topics are synchronized to partition 0, strong consistency canbe obtained but write performance is impacted. If you selectPartition 0, only automatically created topics can besynchronized.

● If topics are synchronized to different partitions by hash valueof the primary key, one table corresponds to one topic.

DataFormat inKafka

Select the data format to be delivered to Kafka.● Avro refers to binary encoded format.● JSON: JSON message format, which is easy to interpret but

takes up more space.● JSON-C: A data format that is compatible with multiple batch

and stream computing frameworks.For details, see Kafka Message Format.


DRS supports database- and table-level synchronization. You canselect data for synchronization based on your service requirements.The search function can help you quickly select the requireddatabase objects.









NO TE



NO TE






----End

5.2.4 From DDM to DDMThis section uses DDM to DDM as an example to describe how to use DRS toconfigure a real-time synchronization task between two DB instances.

Prerequisites● You have logged in to the DRS console.● Your account balance is greater than or equal to $0 USD.● For details about real-time synchronization, see Real-Time Synchronization.






Procedure















Source DBEngine

Select DDM.


Select DDM.

Network Type The public network is used as an example. Available options:Public network, VPC, VPN or Direct Connect


The DDM instance you created.



SynchronizationMode




The default minimum number of source DB instances is 2and the maximum number is 16. You can set this parameterbased on the number of source database shards.






Step 3 On the Configure Source and Destination Databases page, after thesynchronization instance is created, specify source and destination databaseinformation and click Test Connection for both the source and destinationdatabases to check whether they have been connected to the synchronizationinstance. After the connection tests are successful, select the check box before theagreement and click Next.





The IP address or domain name of the source DDMmiddleware.

Port The port of the source DDM middleware. Value range: 1 to65535

MiddlewareUsername


MiddlewarePassword








NO TE

The IP address, domain name, username, and password of the source database areencrypted and stored in DRS, and will be cleared after the task is deleted.




DB InstanceName

The DDM instance selected when you create the replicationinstance.

DatabaseUsername


DatabasePassword








Incremental ConflictPolicy

The conflict policy refers to the conflict handling policy duringincremental synchronization. By default, conflicts in the fullsynchronization phase are ignored.


You can synchronize tables or databases based on the servicerequirements.● The search function can help you quickly select the required

database objects.







NO TE







NO TE



Step 7 After the task is submitted, view and manage it on the Data SynchronizationManagement page.● You can view the status of the task that has been submitted. For details about



----End

5.2.5 From Oracle to KafkaThis section uses Oracle to Kafka synchronization as an example to describe howto configure a synchronization task.


Procedure










Table 5-22 Synchronization instance information


Data Flow Choose Self-built to self-built.

Source DBEngine

Select Oracle.


Select Kafka.

Network Type The Public network is used as an example. Availableoptions: VPC, Public network and VPN or Direct Connect

AZ Select the AZ where you want to create the DRS instance.Selecting the one housing the source or destinationdatabase can provide better performance.

VPC Select an available VPC.






SynchronizationMode

Select Incremental.Through log parsing, incremental data generated on thesource database is synchronized to the destination databasein real time.During synchronization, the source database continues toprovide services for external systems with zero downtime.








Table 5-23 Source database information



The IP address or domain name of the source database.NOTE

For a RAC cluster, use a Scan IP address to improve accessperformance.


Database ServiceName

Enter a database service name (Service Name/SID). Theclient can connect to the Oracle database through thedatabase service name. For details about how to query thedatabase service name, see the prompt on the GUI.

PDB Name Container database (CDB) and pluggable database (PDB)are new features in Oracle 12c and later versions. Thisfunction is optional, but it must be enabled if you want tomigrate only PDB tables.Enter the service name, SID, username, and password of theCDB that contains the PDB tables to be migrated.

DatabaseUsername


DatabasePassword


SSL Connection SSL helps you encrypt the connections between the sourceand destination databases. If SSL is enabled, you need toupload the SSL CA root certificate.NOTE



NO TE





Table 5-24 Source database information




Step 4 On the Set Synchronization Task page, select a topic and objects to besynchronized, and then click Next.




Topic Select the topic to be synchronized to the destination database.

DataFormat inKafka

Select the data format to be delivered from MySQL to Kafka.● Avro refers to binary encoded format.● JSON refers to data interchange format.For details, see Kafka Message Format.


Select Tables or Import object file as required.For details about how to import an object file, see ImportingSynchronization Objects.









NO TE



NO TE






----End

5.2.6 From Oracle to GaussDB(for MySQL) Primary/StandbyThis section uses Oracle to GaussDB(for MySQL) primary/standby synchronizationas an example to describe how to configure a synchronization task.


Procedure
















Source DBEngine

Select Oracle.





The GaussDB(for MySQL) primary/standby instance youcreated.






SynchronizationMode

● Full+IncrementalThis synchronization mode allows you to synchronizedata in real time. After a full synchronization initializesthe destination database, an incremental synchronizationparses logs to ensure data consistency between thesource and destination databases.NOTE

If you select the Full+Incremental synchronization mode, datagenerated during the full synchronization will be synchronized tothe destination database in real time, ensuring that both thesource and destination databases remain accessible.

● FullAll database objects and data you selected aresynchronized to the destination database at a time. Thismode is applicable to scenarios where serviceinterruption is acceptable.

















DatabaseUsername


DatabasePassword








NO TE





DB InstanceName

The RDS DB instance you selected when creating themigration task and cannot be changed.

DatabaseUsername





DatabasePassword

The database username and password are encrypted andstored in the system and will be cleared after the task isdeleted. You can change the password if necessary. Tochange the password, perform the following operation afterthe task is created:If the task is in the Starting, Full synchronization,Incremental synchronization, or Incrementalsynchronization failed status, in the SynchronizationInformation area on the Basic Information page, clickUpdate Password next to the Destination DatabasePassword field. In the displayed dialog box, change thepassword. This action only updates DRS with the changedpassword.

Step 4 On the Set Synchronization Task page, select the synchronization type andsynchronization object, and click Next.






FlowControl




● NoThe migration speed is not limited and the outbound bandwidthof the source database is maximally used, which causes readconsumption on the source database accordingly. For example,if the outbound bandwidth of the source database is 100 MB/sand 80% bandwidth is used, the I/O consumption on the sourcedatabase is 80 MB/s.NOTE



SynchronizationMode

Available options: Table structure, Data, and Constraint● Data is selected by default.● If Table structure is selected, the destination database cannot

contain tables whose names are the same as the source tablesto be synchronized.

● If Table structure is not selected, the destination databasemust have tables that match the source tables, and the tablestructure must be the same as the selected source tablestructures.





Select Tables or Import object file as required. The searchfunction can help you quickly select the required database objects.● The search function can help you quickly select the required

database objects.


● For details about how to import an object file, see ImportingSynchronization Objects.


Step 5 On the Advanced Settings page, set the parameters for the full synchronizationor full+incremental synchronization selected in Step 2 and click Next.

Figure 5-38 Full synchronization



Table 5-31 Full synchronization settings

Parameter Description Default Value

ShardingMode

You can set this parameter to Auto, Do notshard, or Shard based on the siterequirements.● A table without a primary key is not

sharded. A table with less than 520,000rows is not sharded. Partitioned tables aresharded by partition.

● If Do not shard is selected, all tables arenot sharded except partitioned tables thathave primary keys with more than 520,000rows.

● If Shard is selected, tables that have aprimary key and more than 520,000 rowswill be sharded, and other tables will notbe sharded.

● If Auto is selected, tables without primarykeys and heap tables are not sharded.Other tables with more than 520,000 rowsare sharded.

Auto

ConcurrentExport Tasks

The number of threads to be exported. Thevalue ranges from 1 to 16.

8

ConcurrentImport Tasks

The number of threads to be imported. Thevalue ranges from 1 to 16.

8

Figure 5-39 Incremental synchronization

Table 5-32 Incremental synchronization settings


ConcurrentLog CaptureTasks

The number of concurrent threads thatread logs from the source database. Thevalue ranges from 1 to 16. Each threadreads logs in the sequence of log files.

2

Step 6 On the Process Data page, filter the data to be synchronized and click Next. Fordetails, see Processing Data.







NO TE



NO TE






----End






5.2.7 From Oracle to GaussDB(for openGauss) DistributedThis section uses synchronization from Oracle to GaussDB(for openGauss)distributed as an example to show how to configure a real-time synchronizationtask.


Procedure


















Source DBEngine

Select Oracle.


Select GaussDB(for openGauss) Distributed Edition.

Network Type The public network is used as an example. Available options:VPC, Public network and VPN or Direct Connect


The GaussDB(for openGauss) primary/standby instance youcreated.



SynchronizationMode

Available options: Full, Incremental, and Full+Incremental.


Step 3 On the Configure Source and Destination Databases page, specify source anddestination database information and click Test Connection for both the sourceand destination databases to check whether they have been connected to thesynchronization instance. After the connection tests are successful, click Next.














DatabaseUsername


DatabasePassword








Figure 5-44 Destination database settings



DB InstanceName


DatabaseUsername


DatabasePassword

The password for the database username. The password forthe database username. The database username andpassword are encrypted and stored in the system, and will becleared after the task is deleted.

Step 4 On the Set Synchronization Task page, select the synchronization object, enterthe name of the destination database, and click Next.







Select Tables or Databases as required.● If the synchronization objects in source and destination

databases have different names, you can map the source objectname to the destination one. For details, see Mapping ObjectNames.


Step 5 On the Advanced Settings page, view the parameters you set for fullsynchronization or incremental synchronization in Step 2. The default parametervalues cannot be modified. Click Next.



Figure 5-46 Full synchronization



Synchronization ObjectType

Available options: Table structure, Data, andConstraint Data is mandatory.

All options

Stream Mode In this mode, data is written to thedestination database by shard. Data issubmitted once for each shard. Otherwise,The data is submitted once every 16 MB ofdata is written to the destination database.

Enabled


The number of threads that can be started toexport data from the Oracle database.

8


The number of threads that can be started toconcurrently write data to GaussDB(foropenGauss).

8




Import Mode ● COPYData is written through the copy interfaceof GaussDB(for openGauss) to improveefficiency.

● INSERTData is written by combining insertstatements. The efficiency is relatively low.In this mode, primary key conflicts can beignored.

COPY

Rows perShard

Export tables in shards to improve theefficiency of real-time synchronization.● 0

All tables are not sharded, and each tableis synchronized as a whole.

● Other valuesThe table is sharded based on the specifiedvalue (or the primary key column). Whenthe number of records in the table is lessthan the value of this parameter, the tableis not sharded.

● If the table is a partitioned table, eachpartition is synchronized as a shard insteadof being sharded based on the value youset.

● If a table has no primary key or uniqueindex, the table is not sharded. In this case,this parameter is meaningless.

● If a table is not analyzed in a timelymanner, the value of NUM_ROWS in theALL_TABLES view is empty, and the tableis not sharded.

520000

Synchronization Point

Set this parameter to the current systemchange number (SCN). If you set thisparameter to a future SCN or the SCN rangewhere deleted archive logs are located, thetask will fail.

The defaultvalue is theSCN generatedwhen the taskis started.



Figure 5-47 Incremental synchronization



ConcurrentLog CaptureTasks

The number of concurrent threads forreading Oracle logs. The value rangesfrom 1 to 16.

1

Capture StartPoint

Specifies the SCN for starting the capture.SCNs are designed to meet servicerequirements. It consists of a start SCNfor capturing and a valid SCN. For details,see the SCN concepts of Oracle.

If this parameter isleft blank, thecurrent SCN of thedatabase is used asthe start point bydefault.

ConcurrentReplay Tasks

The number of concurrent threads forwriting data to GaussDB(for openGauss).The value ranges from 1 to 64.

64

Replay Policy ● AutomatedAfter the task is started, the replaycomponent is started automatically.

● ManualAfter a task is started, the replaycomponent needs to be startedmanually.

Automated




ConflictPolicy

● OverwriteThe data captured by DRS willoverwrite the data in the destinationdatabase.

● Report errorAn error message is displayed,indicating that the synchronizationtask is abnormal.

● IgnoreThe system skips the error record andcontinues the data replay.

Overwrite

Replay StartPoint

Specifies the SCN where the replay starts. If this parameter isnot specified, thereplay start point isthe same as thecapture start pointby default.

Step 6 On the Process Data page, select the columns to be processed.

● If data processing is not required, click Next.

● For details about how to process data, see Processing Data.


Step 7 On the Check Task page, check the synchronization task.









NO TE



NO TE



----End

Comparing Synchronization ItemsThis section describes how to compare synchronization items to check if there areany differences between source and destination databases. By comparing data-level objects, you can determine the proper time for service migration to minimizethe service downtime.

NO TE

The GaussDB(for openGauss) distributed edition does not support direct update ofdistribution keys. Therefore, this scenario is not supported during DRS synchronization.Otherwise, data loss and inconsistency will occur.

● Data-level comparison: The rows and values of tables can be compared.Compute resource cannot be selected for value comparison.

● Incremental task: You can manually create value comparison and rowcomparison tasks. After the verification is complete, the incrementalverification status, full verification status, running status, and row comparisonare automatically canceled. After the comparison is complete, you can viewthe row comparison results or the results of the canceled value comparison.



Table 5-40 Incremental synchronization task (value comparison)

Status Description

Running Viewing detailed comparison data isnot supported.

Incremental verification in progress Viewing detailed comparison data issupported

Canceled Viewing detailed comparison data issupported

Table 5-41 Incremental synchronization task (row comparison)

Status Description


Completed Viewing detailed comparison data issupported

● Full synchronization task: After a full synchronization task is complete, you

can manually create value comparison and row comparison. After a task iscomplete, you can view the detailed data of value comparison and rowcomparison.

Table 5-42 Full synchronization task (value comparison)

Status Description


Full verification in progress Viewing detailed comparison data isnot supported.


Table 5-43 Full synchronization task (row comparison)

Status Description





● In Oracle to GaussDB(for openGauss) synchronization comparison, differentdata types are processed differently. For details, see the Mappings in theData Replication Service Overview.

● Note that value comparison is not supported in the following scenarios:

– The number of inconsistent data records in the source and destinationdatabases is greater than 10,000.

– The number of table columns in the source database is different fromthat in the destination database.

– The table column names in the source database are different from thosein the destination database.

– The primary key name in the source database is different from that in thedestination database.

– A table without a primary key exists.

– The column precision of the same type in the source database is differentfrom that in the destination database.

5.2.8 From Oracle to GaussDB(DWS)This section uses Oracle to GaussDB(DWS) synchronization as an example todescribe how to configure a synchronization task.





Procedure












Source DBEngine

Select Oracle.



Network types The Public network is used as an example. Availableoptions: VPC, Public network and VPN or Direct Connect








SynchronizationMode




















DatabaseUsername


DatabasePassword








NO TE

The username and password of the source database are encrypted and stored in DRS andwill be cleared after the task is deleted.




DB InstanceName

The RDS DB instance you selected when creating thesynchronization task. This parameter cannot be changed.

DatabaseUsername


DatabasePassword


Step 4 On the Set Synchronization Task page, select the synchronization object type andsynchronization object. Click Next.





Flow Control You can choose whether to control the flow.● Yes

You can customize the maximum migration speed.In addition, you can set the time range based on your servicerequirements. The traffic rate setting usually includes settingof a rate limiting time period and a traffic rate value. Flowcan be controlled all day or during specific time ranges. Thedefault value is All day. A maximum of three time ranges canbe set, and they cannot overlap.The flow rate must be set based on the service scenario andcannot exceed 9,999 MB/s.


● NoThe synchronization speed is not limited and the outboundbandwidth of the source database is maximally used, whichcauses read consumption on the source database accordingly.For example, if the outbound bandwidth of the sourcedatabase is 100 MB/s and 80% bandwidth is used, the I/Oconsumption on the source database is 80 MB/s.NOTE

– The flow control mode takes effect only in the full synchronizationphase.

– You can also change the flow control mode after creating a task.For details, see Modifying the Flow Control Mode.


Available options: Table structure, Data, and Constraint● Data is selected by default.● If Table structure is selected, the destination database

cannot contain tables whose names are the same as thesource tables to be synchronized.





IncrementalConflictPolicy


Synchronization Object


database objects.


● If the synchronization objects in source and destinationdatabases have different names, you can map the sourceobject name to the destination one. For details, see MappingObject Names.


Step 5 On the Process Data page, select the columns to be processed, verify that thedata is correct, and click Next.● If data processing is not required, click Next.● For details about how to process data, see Processing Data.


CA UTION

● If you fill in a new column in database@table format, the new column and theprimary key of the source table form a composite primary key.









NO TE



NO TE






----End

5.2.9 From RDS MySQL to KafkaThis section uses MySQL to Kafka synchronization as an example to describe howto configure a synchronization task.





● Your account balance is greater than or equal to $0 USD.● For details about real-time synchronization, see Real-Time Synchronization.● For details about constraints on DRS usage, see Before You Start.

Procedure


















Source DBEngine

Select MySQL.


Select Kafka.

Network Type The Public network is used as an example. Availableoptions: Public network, VPC, VPN or Direct Connect

Source DBInstance

The RDS MySQL instance you created.



SynchronizationMode




Step 3 On the Configure Source and Destination Databases page, after thesynchronization instance is created, specify source and destination databaseinformation and click Test Connection for both the source and destinationdatabases to check whether they have been connected to the synchronization




instance. After the connection tests are successful, select the check box before theagreement and click Next.




DB InstanceName

By default, this parameter is set to the RDS DB instance youhave selected when you create the migration task andcannot be changed.

DatabaseUsername


DatabasePassword


NO TE













Synchronize DML

Select the DML operations to be synchronized. By default, all DMLoperations are selected.




TopicNameFormat










DataFormat inKafka

Select the data format to be delivered from MySQL to Kafka.● Avro: A binary encoded format that is efficient.● JSON: JSON message format, which is easy to interpret but




Available options: Tables, Databases, or Import object file.● The search function can help you quickly select the required

database objects.● If the synchronization objects in source and destination



Step 5 On the Process Data page, select the columns to be processed.● If data processing is not required, click Next.● If you need to process columns, set processing rules by referring to Processing

Data.








NO TE







NO TE






----End

5.2.10 From RDS MySQL to ElasticSearchThis section uses RDS MySQL to ElasticSearch synchronization as an example todescribe how to configure a synchronization task.


Procedure













Source DBEngine

Select MySQL.


Select CSS/ES.


Source DBInstance




SynchronizationMode

Select Full+Incremental.This synchronization mode allows you to synchronize data inreal time. After a full synchronization initializes thedestination database, an incremental synchronization parseslogs to ensure data consistency between the source anddestination databases.










DB InstanceName


DatabaseUsername


DatabasePassword


NO TE










DatabaseUsername


DatabasePassword


NO TE

The username and password of the destination databases are encrypted and stored in DRS,and will be cleared after the task is deleted.

Step 4 On the Set Synchronization Task page, select the synchronization policy andsynchronization object, and click Next.













Available options: Table structure and Data● Data is selected by default.● If Table structure is selected, the destination database








The conflict policy only applies to incremental synchronization.The default value is Overwrite. The conflict in the fullsynchronization phase is ignored by default.

ShardConfiguration

Configure the number of primary shards and the number ofreplicas. The default number of primary shards is 5, and thedefault number of shard replicas is 1.

Time Zone After the time zone is selected, the data of the datatime typewill be synchronized to CSS/ES with the selected time zone. Ifthe time zone is not required, you need to manually create thedocument type on the target end.

Index Name ● Table nameThe index name created in the target Elasticsearch instance isthe same as the table name.

● Database Name+Table Name.The name of the index created in the target Elasticsearchinstance is DatabaseName_TableName.


DRS supports table-level synchronization. You can select data forsynchronization based on your service requirements.● The search function can help you quickly select the required


databases have different names, you can map the sourceobject name to the destination one. For details, see MappingObject Names.

● When you select synchronization objects, the size of thedatabase table name and column name selected at a timecannot exceed 4 MB. If the number of synchronization objectsexceeds the limit, you can add synchronization objects inbatches when you re-edit the synchronization objects. Fordetails, see Editing Synchronization Objects.



rectified, click Check Again.For details about how to handle check failures, see Checking Whether theSource Database Is Connected in Data Replication Service User Guide.







NO TE



NO TE






----End

5.2.11 From RDS MySQL to OracleThis section uses synchronization from RDS MySQL to Oracle as an example todescribe how to use DRS to configure a synchronization task.







Procedure


























Source DBEngine

Select MySQL.





Select Oracle.


Source DBInstance




SynchronizationMode











DB InstanceName


DatabaseUsername


DatabasePassword


NO TE










Port The port of the destination database. Range: 1 - 65535

DatabaseService Name


DatabaseUsername


DatabasePassword



● The maximum size of a single certificate file that can be uploadedis 500 KB.


NO TE









database objects.







NO TE



NO TE







Step 7 After the task is submitted, view and manage it on the Data SynchronizationManagement page.

● You can view the status of the task that has been submitted. For details aboutthe task status, see Task Status.


----End

5.2.12 From MySQL to GaussDB(for MySQL) Primary/StandbyThis section uses synchronization from MySQL to GuassDB(for MySQL) primary/standby as an example to describe how to configure a synchronization task.





Procedure

















Source DBEngine

Select MySQL.





An available GaussDB(for MySQL) primary/standby instance.






SynchronizationMode

● Full+IncrementalThis synchronization mode allows you to synchronize data inreal time. After a full synchronization initializes thedestination database, an incremental synchronization parseslogs to ensure data consistency between the source anddestination databases.● IncrementalThrough log parsing, incremental data generated on thesource database is synchronized to the destination databasein real time.NOTE














DatabaseUsername


DatabasePassword





NO TE





DB InstanceName


DatabaseUsername





DatabasePassword








IncrementalConflict Policy

The conflict policy refers to the conflict handling policy duringincremental synchronization. By default, conflicts in the fullsynchronization phase are ignored.The following conflict policies are supported:● Ignore

The system will skip the conflicting data and continue thesubsequent synchronization process.

● OverwriteConflicting data will be overwritten.

● Report errorThe synchronization task will be stopped and fail.

Ignore and overwrite: Synchronization stability is prioritized, sotasks will not be interrupted as data conflicts occur.Report error: Data quality is prioritized. Any data conflicts arenot allowed, so once a conflict occurs, the synchronization taskfails and an error is reported. You need to manually find thecause of the fault. If the task is in the failed state for a longtime, the storage space may be used up and the task cannotbe restored.

Filter DROPDATABASE

During synchronization, executing DDL operations on thesource database may affect data synchronization. To reducethe risks involved in data synchronization, DDL operations canbe filtered out. That means that you can choose not tosynchronize certain DDL operations.The database deletion operation can be filtered by default.● If you select Yes, the database deletion operation performed

on the source database is not synchronized during datasynchronization.

● If you select No, related operations are synchronized to thedestination database during data synchronization.

Synchronize Whether to synchronize normal indexes.By default, DRS synchronizes the primary key or unique index.A normal index refers to an index other than the primary keyor unique index. If you select normal index, all indexes will besynchronized. If you do not select normal index, only theprimary key and unique index will be synchronized.

DataSynchronization Topology

Data synchronization supports multiple synchronizationtopologies. You can plan your synchronization instances basedon service requirements. For details, see Data SynchronizationTopologies.




SynchronizeDDLs

You can select the DDL types for incremental synchronizationas required. The DDL type depends on the application scenario.● One-to-one and one-to-many scenarios: If the DDL usage of

the source and destination databases must be consistent,high-risk DDLs must be synchronized. If you do not want ahigh-risk DDL to be performed in the destination, deselectthe high-risk DDL to protect destination data. However, thismay cause the synchronization to fail. However, filteringDDL may cause synchronization to fail, for example, columndeletion.

● Many-to-one scenarios: Synchronize only the Add Columnoperation, or tasks may fail or data may be inconsistent dueto changes in destination tables.



database objects.

● If the source database is changed, click in the upper rightcorner before selecting migration objects to ensure that theobjects to be selected are from the changed sourcedatabase.

● If the synchronization objects in source and destinationdatabases have different names, you can map the sourceobject name to the destination one. For details, seeMapping Object Names.

● For details about how to import an object file, seeImporting Synchronization Objects.

Step 5 On the Processing Data page, filter data or add additional columns for the tableobject to be processed, and click Next.● If you need to set data filtering, click Data Filtering and set related filtering

rules.● If you need to add additional columns, click the Additional Columns tab,

click Add in the Operation column, and enter the column name and theoperation type.For details, see Processing Data.



rectified, click Check Again.







NO TE



NO TE






----End

5.2.13 From MySQL to GaussDB(DWS)This section uses MySQL to GaussDB(DWS) synchronization as an example todescribe how to configure a synchronization task.

Prerequisites● You have logged in to the DRS console.● Your account balance is greater than or equal to $0 USD.






● For details about real-time synchronization, see Real-Time Synchronization.● For details about constraints on DRS usage, see Before You Start.

Procedure


















Source DBEngine

Select MySQL.








SynchronizationMode
















DatabaseUsername


DatabasePassword








NO TE





DB InstanceName


DatabaseUsername


DatabasePassword







FlowControl




● NoThe synchronization speed is not limited and the outboundbandwidth of the source database is maximally used, whichcauses read consumption on the source database accordingly.For example, if the outbound bandwidth of the source databaseis 100 MB/s and 80% bandwidth is used, the I/O consumptionon the source database is 80 MB/s.NOTE


– You can also change the flow control mode after creating a task. Fordetails, see Modifying the Flow Control Mode.

SynchronizationObjectType









Select Tables or Databases, or import an object file as required.● The search function can help you quickly select the required

database objects.




DataSynchronizationTopology

Data synchronization supports multiple synchronization topologies.You can plan your synchronization instances based on servicerequirements. For details, see Data Synchronization Topologies.

Synchronize DDLs

You can select the DDL types for incremental synchronization asrequired. The DDL type depends on the application scenario.● One-to-one and one-to-many scenarios: If the DDL usage of the

source and destination databases must be consistent, high-riskDDLs must be synchronized. If you do not want a high-risk DDLto be performed in the destination, deselect the high-risk DDLto protect destination data. However, this may cause thesynchronization to fail. However, filtering DDL may causesynchronization to fail, for example, column deletion.

● Many-to-one scenarios: Synchronize only the Add Columnoperation, or tasks may fail or data may be inconsistent due tochanges in destination tables.









NO TE



NO TE






----End

5.2.14 From MySQL to GaussDB(DWS) (Many-to-OneScenario)

This section uses many-to-one synchronization from RDS MySQL toGaussDB(DWS) as an example to describe how to use DRS to configure asynchronization task.





Procedure


















Source DBEngine

Select MySQL.



Network Type The VPC network is used as an example. Available options:VPC, Public network and VPN or Direct Connect





SynchronizationMode













Source DatabaseType

Select Self-built on ECS or RDS DB instance.

DB InstanceName

Select the RDS DB instance to be synchronized.

DatabaseUsername


DatabasePassword


NO TE








DB InstanceName


DatabaseUsername


DatabasePassword








FlowControl























DataSynchronizationTopology

Data synchronization supports multiple synchronization topologies.You can plan your synchronization instances based on servicerequirements. For details, see Data Synchronization Topologies.

Synchronize DDLs

You can select the DDL types for incremental synchronization asrequired. The DDL type depends on the application scenario.● One-to-one and one-to-many scenarios: If the DDL usage of the

source and destination databases must be consistent, high-riskDDLs must be synchronized. If you do not want a high-risk DDLto be performed in the destination, deselect the high-risk DDLto protect destination data. However, this may cause thesynchronization to fail. However, filtering DDL may causesynchronization to fail, for example, column deletion.

● Many-to-one scenarios: Synchronize only the Add Columnoperation, or tasks may fail or data may be inconsistent due tochanges in destination tables.

When selecting synchronization objects, you can map multiple tables to oneGaussDB(DWS) table.

1. Select the tables that need to be mapped from the synchronization objects onthe right area and click Edit.

2. In the displayed dialog box, enter the new database name and table name,and click OK. The new database name is the name of the database saved inthe destination DB instance.



Figure 5-99 Editing the database name and table name

3. If you select Import object file, you can map multiple tables to oneGaussDB(DWS) table and import up to 10,000 tables. If the table name or themapping rule is too long, the number of tables to be imported will beaffected.

CA UTION

– When you map multiple tables to one table, use the additional column toprocess data to avoid data conflicts.

– The structure of the source database tables to be mapped must be thesame as that of the destination database table.

Step 5 On the Data Processing page, select the table object to be processed, click Add inthe Operation column, enter the column name, type, and operation type, confirmthe information, and click Next.


CA UTION

● If you fill in a new column in serverName@database@table format, the newcolumn and the primary key of the source table form a composite primary key.








NO TE



NO TE



Step 8 After the task is submitted, you can view and manage it on the DataSynchronization Management page.



----End






5.2.15 From MySQL to PostgreSQLThis section uses synchronization from MySQL to PostgreSQL as an example todescribe how to configure a synchronization task.





Procedure


















Source DBEngine

Select MySQL.


Select PostgreSQL.

Network Type Available options: VPC, Public network and VPN or DirectConnect. Public network is used as an example.


The RDS PostgreSQL DB instance.



SynchronizationMode

● Full+IncrementalThis synchronization mode allows you to synchronizedata in real time. After a full synchronization initializesthe destination database, an incremental synchronizationparses logs to ensure data consistency between thesource and destination databases.

● FullAll objects and data in non-system databases aresynchronized to the destination database at a time. Thismode is applicable to scenarios where serviceinterruption is acceptable.













DatabaseUsername


DatabasePassword





NO TE







DB InstanceName

The RDS PostgreSQL instance you selected when creating themigration task and cannot be changed.

DatabaseUsername


DatabasePassword


NO TE


Step 4 On the Set Synchronization Task page, select the synchronization objects andaccounts and click Next.







You can customize the maximum migration speed.In addition, you can set the time range based on your servicerequirements. The traffic rate setting usually includes settingof a rate limiting time period and a traffic rate value. Flowcan be controlled all day or during specific time ranges. Thedefault value is All day. A maximum of three time rangescan be set, and they cannot overlap.The flow rate must be set based on the service scenario andcannot exceed 9,999 MB/s.


● NoThe synchronization speed is not limited and the outboundbandwidth of the source database is maximally used, whichcauses read consumption on the source databaseaccordingly. For example, if the outbound bandwidth of thesource database is 100 MB/s and 80% bandwidth is used,the I/O consumption on the source database is 80 MB/s.NOTE

– The flow control mode takes effect only in the fullsynchronization phase.










The conflict policy refers to the conflict handling policy duringincremental synchronization. By default, conflicts in the fullsynchronization phase are ignored.Select any of the following conflict policies:● Ignore




Filter DROPDATABASE

During synchronization, executing DDL operations on thesource database may affect data synchronization. To reduce therisks involved in data synchronization, DDL operations can befiltered out. That means that you can choose not tosynchronize certain DDL operations.The database deletion operation can be filtered by default.● If you select Yes, the database deletion operation performed








SynchronizeDDLs

You can select the DDL types for incremental synchronizationas required. The DDL type depends on the application scenario.● One-to-one and one-to-many scenarios: If the DDL usage of

the source and destination databases must be consistent,high-risk DDLs must be synchronized. If you do not want ahigh-risk DDL to be performed in the destination, deselectthe high-risk DDL to protect destination data. However, thismay cause the synchronization to fail. However, filteringDDL may cause synchronization to fail, for example, columndeletion.


Synchronize Incremental DDL synchronization is supported. You candetermine whether to synchronize data based on servicerequirements.


DRS supports table-level synchronization. You can select datafor synchronization based on your service requirements.● The search function can help you quickly select the required


databases have different names, you can map the sourceobject name to the destination one. For details, seeMapping Object Names.



For details about how to handle check failures, see Checking Whether theSource Database Is Connected in Data Replication Service User Guide.







NO TE



NO TE






----End

5.2.16 From Self-built MySQL to Self-built KafkaThis section uses a synchronization task from self-built MySQL database to a self-built Kafka database as an example to show how to use DRS to configure a real-time synchronization task.


ProcedureStep 1 On the Data Synchronization Management page, click Create Synchronization

Task.












Source DBEngine

Select MySQL.


Select Kafka.


AZ Select the AZ where you want to create the DRS instance.Selecting the one housing the source or destinationdatabase can provide better performance.




Security Group Select a security group. You can use security group rules toallow or deny access to the instance.

SynchronizationMode

Incremental












Port The port of the source database. Range: 1 – 65535

DatabaseUsername


DatabasePassword









NO TE








Figure 5-113 Synchronization Mode






Topic synchronization policy. The options are as follows:● Select A specified topic if the data volume of the source

database is small.● Select Auto-generated topics if each table contains a lot of

data. Then, the system automatically generates a topic for eachtable.


TopicNameFormat





● If topics are synchronized to partition 0, strong consistency canbe obtained but write performance is impacted.

● If topics are synchronized to different partitions by hash valueof the primary key, one table corresponds to one topic. Thisprevents data from being written to the same partition, andconsumers can obtain data from different partitionsconcurrently.

DataFormat inKafka

Select the data format to be delivered from MySQL to Kafka.● Avro refers to binary encoded format.● JSON: JSON message format, which is easy to interpret but











Step 5 On the Process Data page, select the columns to be processed.● If data processing is not required, click Next.● If you need to process columns, set processing rules by referring to Processing

Data.










NO TE



NO TE






----End

5.2.17 From Self-built MySQL to ElasticSearchThis section uses a synchronization task from self-built MySQL to ElasticSearch asan example to show how to use DRS to configure a real-time synchronizationtask.





Procedure
















Source DBEngine

Select MySQL.


Select CSS/ES.

Network Type Public network is used as an example. Available options:VPC, Public network and VPN or Direct Connect




Security Group Select a security group. You can use security group rules toallow or deny access to the instance.

SynchronizationMode

Available options: Full+Incremental and Incremental● Full+Incremental

This synchronization mode allows you to synchronizedata in real time. After a full synchronization initializesthe destination database, an incremental synchronizationparses logs to ensure data consistency between thesource and destination databases.NOTE


AZ Select the AZ where you want to create the DRS instance.Using the same AZ as your source or destination instance isrecommended.













DatabaseUsername


DatabasePassword








NO TE







DatabaseUsername


DatabasePassword


NO TE









ShardConfiguration



Index Name ● Table nameThe index name created in the target Elasticsearch instance isthe same as the table name.






● When you select synchronization objects, the size of thedatabase table name and column name selected at a timecannot exceed 4 MB. If the number of synchronization objectsexceeds the limit, you can add synchronization objects inbatches when you re-edit the synchronization objects. Fordetails, see Editing Synchronization Objects.










NO TE



NO TE






----End

5.2.18 From GaussDB(for openGauss) Distributed toGaussDB(DWS)

This section uses the real-time synchronization from GaussDB(for openGauss)distributed to GaussDB(DWS) as an example to describe how to use DRS toconfigure a real-time synchronization task.







Procedure
















Source DBEngine




Network Type The public network is used as an example. Available options:Public network and VPN or Direct Connect

Source DBInstance




SynchronizationMode

Available options: Full+Incremental, Full, and Incremental.Full+Incremental is used as an example.● Full+Incremental



● FullIn this mode, data is synchronized from the source to thedestination at a time.

● IncrementalThrough log parsing, incremental data generated on thesource is synchronized to the destination in real time.






Step 3 On the Configure Source and Destination Databases page, wait until thesynchronization instance is created. Then, specify source and destination databaseinformation and click Test Connection for both the source and destinationdatabases to check whether they have been connected to the synchronizationinstance. After the connection tests are successful, click Next.




DB InstanceName


DatabaseUsername


DatabasePassword


NO TE

The username and password of the source database are encrypted and stored in thedatabase and the synchronization instance during the synchronization. After the task isdeleted, the username and password are permanently deleted.








IP address or domain name of the destination database inthe IP address/Domain name:Port format. The port of thedestination database. Range: 1 - 65534You can enter up to 10 groups of IP addresses or domainnames of the source database. Separate multiple values withcommas (,). For example: 192.168.0.1:8080,192.168.0.2:8080.

DatabaseUsername


DatabasePassword


NO TE









DRS supports database-level and table-level synchronization. Youcan select data for synchronization based on your servicerequirements.● The search function can help you quickly select the required



Step 5 On the Advanced Settings page, set the parameters for full+incrementalsynchronization selected in Step 2 and click Next.

Figure 5-128 Parameter settings





Synchronization Mode

Select whether to synchronize indexes basedon the service requirements. Table structureand data are mandatory.

Select all thethree items.


Number of export threads. Value range: 1 to16. A larger value indicates higher load onthe source database.

8


Number of import threads. Value range: 1 to16. A larger value indicates higher load onthe destination database.

8

Rows perShard

Value range: 0 or 520,000 to 1,000,000,000● 0


● Other valuesThe table is sharded based on the specifiedvalue (or the primary key column). If thenumber of records in a table is less thanthe value of this parameter, the table isnot sharded.

520000




Number of concurrent threads for data replay.Value range: 1 to 64. Incremental data isconcurrently written to the destinationdatabase. A larger value indicates higher loadon the destination database.

64









NO TE



NO TE



----End

5.2.19 From GaussDB(for openGauss) Distributed toGaussDB(for openGauss) Distributed

This section uses real-time synchronization from GaussDB(for openGauss)distributed to GaussDB(for openGauss) distributed as an example to describe howto use DRS to configure a real-time synchronization task.





Procedure
















Source DBEngine





Source DBInstance







SynchronizationMode











DB InstanceName


DatabaseUsername


DatabasePassword


NO TE






IP address or domain name of the destination database inthe IP address/Domain name:Port format. The port of thedestination database. Range: 1 - 65534You can enter up to 10 groups of IP addresses or domainnames of the source database. Separate multiple values withcommas (,). For example: 192.168.0.1:8080,192.168.0.2:8080.

DatabaseUsername


DatabasePassword




NO TE






Table 5-105 Synchronization Object


FlowControl















Ignore and overwrite: Synchronization stability is prioritized, sotasks will not be interrupted as data conflicts occur.Report error: Data quality is prioritized. Any data conflicts are notallowed, so once a conflict occurs, the synchronization task failsand an error is reported. You need to manually find the cause ofthe fault. If the task is in the failed state for a long time, thestorage space may be used up and the task cannot be restored.


You can synchronize tables or databases based on the servicerequirements.If the synchronization objects in source and destination databaseshave different names, you can map the source object name to thedestination one. For details, see Mapping Object Names.












8



8

Rows perShard

Value range: 0 or 520,000 to 1,000,000,000● 0



520000





64

Step 6 On the Process Data page, select the columns to be processed.● If data processing is not required, click Next.● If you need to process columns, configure required rules by referring to

Processing Data.









NO TE



NO TE



----End





5.2.20 From GaussDB(for openGauss) Primary/Standby toKafka

This section uses real-time synchronization from GaussDB(for openGauss)primary/standby to Kafka as an example to describe how to use DRS to configurea real-time synchronization task.


Procedure
















Source DBEngine

Select GaussDB(for openGauss) Primary/Standby Edition.


Select Kafka.


Source DBInstance




SynchronizationMode

Select Incremental.










DB InstanceName


DatabaseUsername


DatabasePassword


NO TE






IP address or domain name of the destination database inthe IP address/Domain name:Port format. The port numberof the destination database ranges from 1 to 65534.You can enter up to 10 groups of IP addresses or domainnames of the source database. Separate multiple values withcommas (,). For example: 192.168.0.1:8080,192.168.0.2:8080.










TopicNameFormat

Topic name format. This parameter is available when TopicSynchronization Policy is set to Auto-generated topics.

Number ofPartitions

Topic name format. This parameter is available when TopicSynchronization Policy is set to Auto-generated topics.The number of partitions of a topic. Each topic can have multiplepartitions. More partitions can provide higher throughput butconsume more resources. Set the number of partitions based onthe actual situation of brokers.

Replication Factor

Topic name format. This parameter is available when TopicSynchronization Policy is set to Auto-generated topics.Number of copies of a topic. Each topic can have multiple copies,and the copies are placed on different brokers in a cluster. Thenumber of copies cannot exceed the number of brokers. Otherwise,the topic fails to be created.





The policy for synchronizing topics to the Kafka partitions.● If topics are synchronized to different partitions by hash value,

the performance on a single table query can be improved.● If topics are synchronized to partition 0, strong consistency can

be obtained but write performance is impacted.


DRS supports database-level and table-level synchronization. Youcan select data for synchronization based on your servicerequirements.The search function can help you quickly select the requireddatabase objects.






NO TE



NO TE



----End





5.2.21 From GaussDB(for openGauss) Primary/Standby toGaussDB(DWS)

This section uses real-time synchronization from GaussDB(for openGauss)primary/standby to GaussDB(DWS) as an example to describe how to use DRS toconfigure a real-time synchronization task.


Procedure
















Source DBEngine





Source DBInstance




SynchronizationMode

Available options: Full+Incremental, Full, and Incremental.Full+Incremental is used as an example.● Full+Incremental



● FullIn this mode, data is synchronized from the source to thedestination at a time.











DB InstanceName

The GaussDB(for openGauss) primary/standby instance thatyou selected during synchronization task creation and cannotbe changed.

DatabaseUsername


DatabasePassword


NO TE









IP address or domain name of the destination database. Theformat is IP address or domain name:Port number. The portnumber of the destination database ranges from 1 to 65534.You can enter up to 10 groups of IP addresses or domainnames of the source database. Separate multiple values withcommas (,). For example: 192.168.0.1:8080,192.168.0.2:8080.

DatabaseUsername


DatabasePassword


NO TE









DRS supports database-level and table-level synchronization. Youcan select data for synchronization based on your servicerequirements.● The search function can help you quickly select the required














8



8

Rows perShard

Value range: 0 or 520,000 to 1,000,000,000● 0



520000




Number of concurrent data replay threads.Incremental data is written to the destinationdatabase concurrently. The value ranges from1 to 64. A larger number of concurrentthreads brings higher pressure on thedestination database.

64









NO TE



NO TE



----End

5.2.22 From GaussDB(for openGauss) Primary/Standby toGaussDB(for openGauss) Distributed

This section uses real-time synchronization from GaussDB(for openGauss)primary/standby to GaussDB(for openGauss) distributed as an example todescribe how to use DRS to configure a real-time synchronization task.





Procedure
















Source DBEngine

Select primary/standby.




Source DBInstance







SynchronizationMode











DB InstanceName


DatabaseUsername


DatabasePassword


NO TE






IP address or domain name of the destination database inthe IP address/Domain name:Port format. The port of thedestination database. Range: 1 - 65534You can enter up to 10 groups of IP addresses or domainnames of the source database. Separate multiple values withcommas (,). Example: 192.168.0.1:8000,192.168.0.2:8000.

DatabaseUsername


DatabasePassword




NO TE








FlowControl
















8



8

Rows perShard

Value range: 0 or 520,000 to 1,000,000,000● 0



520000





64


Processing Data.









NO TE



NO TE



----End

5.2.23 From GaussDB(for openGauss) Primary/Standby toGaussDB(for openGauss) Primary/Standby

This section uses real-time synchronization from GaussDB(for openGauss)primary/standby to GaussDB(for openGauss) primary/standby as an example todescribe how to use DRS to configure a real-time synchronization task.






Procedure


















Source DBEngine





Source DBInstance




SynchronizationMode











DB InstanceName

The GaussDB(for openGauss) distributed instance selectedduring synchronization task creation. This parameter cannotbe changed.

DatabaseUsername


DatabasePassword


NO TE








IP address or domain name of the destination database inthe IP address/Domain name:Port format. The port numberof the destination database ranges from 1 to 65534.You can enter up to 10 groups of IP addresses or domainnames of the source database. Separate multiple values withcommas (,). Example: 192.168.0.1:8000,192.168.0.2:8000.

DatabaseUsername


DatabasePassword


NO TE








FlowControl
















8



8

Rows perShard

Value range: 0 or 520,000 to 1,000,000,000● 0



520000





64


Processing Data.










NO TE



NO TE



----End





5.2.24 From GaussDB(for MySQL) Primary/Standby to MySQLThis section uses GaussDB(for MySQL) primary/standby to MySQL synchronizationas an example to describe how to configure a synchronization task.





Procedure




























Source DBEngine






Select MySQL.


Source DBInstance

The GaussDB(for MySQL) primary/standby instance.



SynchronizationMode

● Full+Incremental.This synchronization mode allows you to synchronizedata in real time. After a full synchronization initializesthe destination database, an incremental synchronizationparses logs to ensure data consistency between thesource and destination databases.











DB InstanceName

The GaussDB(for MySQL) primary/standby instance selectedduring the replication instance creation and cannot bechanged.

DatabaseUsername


DatabasePassword


NO TE

The username and password of the source database are encrypted and stored in the systemand will be permanently deleted after the task is deleted.










DatabaseUsername


DatabasePassword


SSL Connection SSL encrypts the connections between the source anddestination databases. If SSL is enabled, upload the SSL CAroot certificate.

NO TE

The IP address, username, and password of the destination database are encrypted andstored in the system. After the task is deleted, the information is permanently deleted.












Ignore and overwrite: Synchronization stability is prioritized, sotasks will not be interrupted as data conflicts occur.Report error: Data quality is prioritized. Any data conflicts arenot allowed, so once a conflict occurs, the synchronization taskfails and an error is reported. You need to manually find thecause of the fault. If the task is in the failed state for a longtime, the storage space may be used up and the task cannot berestored.

Filter DROPDATABASE

To reduce the risk of data synchronization, DRS allows you tofilter and delete databases.● If you select Yes, the database deletion operation performed




Select whether to synchronize indexes based on the servicerequirements.






SynchronizeDDLs

You can select the DDL types for incremental synchronization asrequired. The DDL type depends on the application scenario.● One-to-one and one-to-many scenarios: If the DDL usage of

the source and destination databases must be consistent,high-risk DDLs must be synchronized. If you do not want ahigh-risk DDL to be performed in the destination, deselect thehigh-risk DDL to protect destination data. However, this maycause the synchronization to fail. However, filtering DDL maycause synchronization to fail, for example, column deletion.


Synchronization object






Step 5 On the Process Data page, set the filtering rules for data processing.● If you need to set data filtering, click Data Filtering and set related filtering

rules.● If you need to add additional columns, click Additional Columns and enter

the name of the column to be added and the operation type information.For details, see Processing Data.











NO TE



NO TE






----End

5.2.25 From GaussDB(for MySQL) Primary/Standby toGaussDB(DWS)

This section uses GaussDB(for MySQL) primary/standby to GaussDB(DWS) as anexample to describe how to configure a real-time synchronization task.







Procedure


























Source DBEngine








Source DBInstance

An available GaussDB(for MySQL) primary/standby instance.



SynchronizationMode












DB InstanceName


DatabaseUsername


DatabasePassword


NO TE

The username and password of the source database are encrypted and stored in the systemand will be permanently deleted after the task is deleted.










DatabaseUsername


DatabasePassword


NO TE

The IP address, username, and password of the destination database are encrypted andstored in the system. After the task is deleted, the information is permanently deleted.
















SynchronizeDDLs

You can select the DDL types for incremental synchronization asrequired. The DDL type depends on the application scenario.● One-to-one and one-to-many scenarios: If the DDL usage of

the source and destination databases must be consistent,high-risk DDLs must be synchronized. If you do not want ahigh-risk DDL to be performed in the destination, deselect thehigh-risk DDL to protect destination data. However, this maycause the synchronization to fail. However, filtering DDL maycause synchronization to fail, for example, column deletion.


Step 5 On the Data Processing page, select the table object to be processed, click Add inthe Operation column, enter the column name, type, and operation type, confirmthe information, and click Next.




CA UTION

● If you fill in a new column in serverName@database@table format, the newcolumn and the primary key of the source table form a composite primary key.






NO TE



NO TE










----End

5.2.26 From GaussDB(for MySQL) Primary/Standby to KafkaThis section describes how to use DRS to configure a synchronization task fromGaussDB(for MySQL) primary/standby to Kafka.





Procedure

















Source DBEngine



Select Kafka.


Source DBInstance

The source GaussDB(for MySQL) primary/standby instance.






SynchronizationMode











DB InstanceName


DatabaseUsername


DatabasePassword


NO TE
















TopicNameFormat

Topic name format. This parameter is available when TopicSynchronization Policy is set to Auto-generated topics.









DataFormat inKafka

Select the data format to be delivered from MySQL to Kafka.● Avro refers to binary encoded format.● JSON: JSON message format, which is easy to interpret but












NO TE







NO TE






----End

5.2.27 From GaussDB(for MySQL) Primary/Standby toElasticSearch

This section uses GaussDB(for MySQL) primary/standby to ElasticSearchsynchronization as an example to describe how to configure a synchronizationtask.


Procedure













Source DBEngine



Select CSS/ES.

Network Type Public network is used as an example. Available options:Public network, VPC, VPN or Direct Connect

Source DBInstance




SynchronizationMode











DB InstanceName


DatabaseUsername


DatabasePassword





NO TE







DatabaseUsername


DatabasePassword


NO TE









ShardConfiguration



Index Name ● Table NameThe index name created in the target Elasticsearch instance isthe same as the table name.






● When you select synchronization objects, the size of thedatabase table name and column name selected at a timecannot exceed 4 MB. If the number of synchronization objectsexceeds the limit, you can add synchronization objects inbatches by using the function of editing synchronizationobjects. For details, see Editing Synchronization Objects.










NO TE



NO TE






----End

5.2.28 From GaussDB(for MySQL) Primary/Standby to OracleThis section uses GaussDB(for MySQL) primary/standby to Oracle synchronizationas an example to describe how to configure a synchronization task.







Procedure














Source DBEngine



Select Oracle.


Source DBInstance




SynchronizationMode











DB InstanceName


DatabaseUsername


DatabasePassword


NO TE











DatabaseService Name


DatabaseUsername


DatabasePassword



● The maximum size of a single certificate file that can be uploadedis 500 KB.


NO TE









database objects.







NO TE



NO TE






----End






5.2.29 From PostgreSQL to GaussDB(for openGauss)Distributed

This section uses PostgreSQL to GaussDB(for openGauss) distributedsynchronization as an example to describe how to configure a synchronizationtask.


Procedure

















Source DBEngine

Select PostgreSQL.



Network Type The VPC network is used as an example.


A GaussDB(for openGauss) distributed instance.






SynchronizationMode

Full+IncrementalThis synchronization mode allows you to synchronize data inreal time. After a full synchronization initializes thedestination database, an incremental synchronization parseslogs to ensure data consistency between the source anddestination databases.FullThis synchronization mode is suitable for scenarios whereservice interruption is acceptable. Database objects anddata, including tables, views, and stored procedures, fromnon-system databases can be synchronized to thedestination all at once.




NO TE









SourceDatabase Type



Subnet A subnet provides dedicated network resources that areisolated from other networks, improving networksecurity. The subnet must be in the AZ where the sourcedatabase resides. You need to enable DHCP for creatingthe source database subnet.




DatabaseUsername


DatabasePassword







NO TE






SourceDatabase Type

Select an RDS DB instance.

DB InstanceName

Select the RDS DB instance to be migrated as the sourceDB instance.

DatabaseUsername

Enter the username of the source database.

DatabasePassword



Table 5-163 Destination database information


DB InstanceName

The GaussDB(for openGauss) distributed instance selectedduring migration task creation. This parameter cannot bechanged.




DatabaseUsername


DatabasePassword


NO TE

The username and password of the source and destination databases are encrypted andstored in the databases and the synchronization instance during the synchronization. Afterthe task is deleted, the username and password are permanently deleted.






DRS supports database- and table-level synchronization. You canselect data for synchronization based on your service requirements.● The search function can help you quickly select the required











NO TE



NO TE






----End

5.2.30 From PostgreSQL to PostgreSQLThis section uses synchronization from PostgreSQL to PostgreSQL as an exampleto describe how to configure a synchronization task.





Procedure
















Source DBEngine

Select PostgreSQL.


Select PostgreSQL.

Network Type Available options: VPC, Public network and VPN or DirectConnect. Public network is used as an example.


The RDS PostgreSQL DB instance.



SynchronizationMode

● Full+IncrementalThis synchronization mode allows you to synchronizedata in real time. After a full synchronization initializesthe destination database, an incremental synchronizationparses logs to ensure data consistency between thesource and destination databases.

● FullAll objects and data in non-system databases aresynchronized to the destination database at a time. Thismode is applicable to scenarios where serviceinterruption is acceptable.



Step 3 On the Configure Source and Destination Databases page, after thesynchronization instance is created, specify source and destination databaseinformation and click Test Connection for both the source and destinationdatabases to check whether they have been connected to the synchronization




instance. After the connection tests are successful, select the check box before theagreement and click Next.

NO TE




Table 5-167 Self-build on ECS - source database settings


SourceDatabase Type



Subnet A subnet provides dedicated network resources that areisolated from other networks, improving networksecurity. The subnet must be in the AZ where the sourcedatabase resides. You need to enable DHCP for creatingthe source database subnet.




DatabaseUsername


DatabasePassword








NO TE






SourceDatabase Type

Select an RDS DB instance.

DB InstanceName

Select the RDS PostgreSQL instance to be synchronized asthe source DB instance.

DatabaseUsername


DatabasePassword







DB InstanceName

The RDS PostgreSQL instance you selected when creating themigration task and cannot be changed.

DatabaseUsername


DatabasePassword


NO TE

The username and password of the source and destination databases are encrypted andstored in the databases and the synchronization instance during the synchronization. Afterthe task is deleted, the username and password are permanently deleted.

Step 4 On the Set Synchronization Task page, select the synchronization objects andaccounts and click Next.







You can customize the maximum migration speed.In addition, you can set the time range based on your servicerequirements. The traffic rate setting usually includes settingof a rate limiting time period and a traffic rate value. Flowcan be controlled all day or during specific time ranges. Thedefault value is All day. A maximum of three time rangescan be set, and they cannot overlap.The flow rate must be set based on the service scenario andcannot exceed 9,999 MB/s.


● NoThe synchronization speed is not limited and the outboundbandwidth of the source database is maximally used, whichcauses read consumption on the source databaseaccordingly. For example, if the outbound bandwidth of thesource database is 100 MB/s and 80% bandwidth is used,the I/O consumption on the source database is 80 MB/s.NOTE

– The flow control mode takes effect only in the fullsynchronization phase.






DRS uses primary key or unique key conflict policies to ensurethat tables with primary key or unique constraints in the sourcedatabase can be synchronized to the destination database asexpected.Select any of the following conflict policies:● Ignore




In the following scenarios, you can select Ignore or Overwrite.In other scenarios, you are advised to select Report error.● Data exists in the destination database.● Multiple source databases are synchronized to one

destination database.● Data in the destination database is updated manually.

Synchronize Available options: Index, Incremental DDLs, and Populatematerialized views during the full synchronization phasePopulate materialized views during the full synchronizationphase: This option takes effect only for materialized views thatwas populated in the source database. This operation affectsthe full synchronization performance. You perform thisoperation after the full synchronization is complete.


DRS supports database- and table-level synchronization. Youcan select data for synchronization based on your servicerequirements.● The search function can help you quickly select the required


databases have different names, you can map the sourceobject name to the destination one. For details, seeMapping Object Names.

SynchronizeAccount

During the synchronization, you can synchronize accountsbased on your service requirements.There are two types of accounts: accounts that can besynchronized and accounts that cannot be synchronized. Foraccounts that cannot be synchronized, you can view details inthe Remarks column and determine whether to synchronizeaccounts and permissions based on your service requirements.








NO TE



NO TE






----End






5.2.31 Incremental DDL Synchronization from PostgreSQL toPostgreSQL

This section describes how to perform real-time synchronization from PostgreSQLto RDS PostgreSQL. You can create triggers and functions in the source databaseto obtain the DDL information of the source database, and then synchronize DDLoperations to the destination database during the incremental synchronizationphase.

Prerequisites● The following DDL operations are supported: CREATE SCHEMA/TABLE (only

for database-level synchronization), DROP TABLE, and ALTER TABLE (includingADD COLUMN, DROP COLUMN, ALTER COLUMN, RENAME COLUMN, ADDCONSTRAINT, DROP CONSTRAINT and RENAME).

CA UTION

If data is inserted into a table, DRS does not synchronize the data to thedestination database.

● If the source and destination databases are of different versions, use SQLstatements that are compatible with both the source and destinationdatabases to perform DDL operations. For example, if the source database isPostgreSQL 11 and the destination database is PostgreSQL 12, run thefollowing statement to change the column type from char to int:alter table tablename alter column columnname type int USING columnname::int;

● Check whether a table named hwdrs_ddl_info, a function namedhwdrs_ddl_function(), and a trigger named hwdrs_ddl_event exist in thesource database in public mode. If they exist, delete them.

● During database-level synchronization, if a table without a primary key iscreated, run the following command to set the replication attribute of thetable without a primary key to full.alter table tablename replica identity full;

Procedure

Step 1 Connect to the database to be synchronized as a user who has permission tocreate event triggers.

Step 2 Run the following statements to create a table for storing DDL information:CREATE TABLE public.hwdrs_ddl_info( id bigserial primary key, ddl text COLLATE pg_catalog."default", username varchar(64), txid varchar(16), tag varchar(24), database varchar(64), schema varchar(64), client_address varchar(64), client_port integer, event_time timestamp);



Step 3 Run the following statements to create a function:CREATE OR REPLACE FUNCTION public.hwdrs_ddl_function() RETURNS event_trigger LANGUAGE plpgsql SECURITY DEFINERAS $BODY$ declare ddl text; declare real_num int; declare min_id int; declare max_num int := 50000;begin if (tg_tag = 'CREATE TABLE' or tg_tag = 'ALTER TABLE' or tg_tag = 'DROP TABLE' or tg_tag = 'CREATE SCHEMA') then select current_query() into ddl; insert into public.hwdrs_ddl_info(id, ddl, username, txid, tag, database, schema, client_address, client_port, event_time) values(default, ddl, current_user, cast(txid_current() as varchar(16)), tg_tag, current_database(), current_schema, inet_client_addr(), inet_client_port(), current_timestamp);

select count(id) into real_num from public.hwdrs_ddl_info; select min(id) into min_id from public.hwdrs_ddl_info;

if real_num > max_num then delete from public.hwdrs_ddl_info where id = min_id; end if; end if; end;$BODY$;

Step 4 Run the following statement to change the owner of the table created in Step 2to the user of the source database:ALTER TABLE public.hwdrs_ddl_info OWNER TO username;

Step 5 Run the following statement to change the owner of the function created in Step3 to the user of the source database:ALTER FUNCTION public.hwdrs_ddl_function() OWNER TO username;

Step 6 Run the following statement to create a DDL event trigger:CREATE EVENT TRIGGER hwdrs_ddl_event ON ddl_command_end EXECUTE PROCEDURE public.hwdrs_ddl_function();

Step 7 Run the following statement to set the created event trigger to enable:ALTER EVENT TRIGGER hwdrs_ddl_event ENABLE ALWAYS;

Step 8 Return to the DRS console and create a PostgreSQL to RDS PostgreSQLsynchronization task.

Step 9 After the synchronization task is complete, run the following statements to deletethe created tables, functions, and triggers.DROP EVENT trigger hwdrs_ddl_event;DROP FUNCTION public.hwdrs_ddl_function();DROP TABLE public.hwdrs_ddl_info;

----End

5.2.32 From DDS to MongoDBThis section uses DDS to MongoDB synchronization as an example to describehow to use DRS to configure an incremental synchronization task.




Procedure
















Source DBEngine

Select DDS.


Select MongoDB.


Source DBInstance

An available DDS instance



SynchronizationMode




Step 3 On the Configure Source and Destination Databases page, after thesynchronization instance is created, specify source and destination databaseinformation and click Test Connection for both the source and destinationdatabases to check whether they have been connected to the synchronizationinstance. After the connection tests are successful, click Next.







DB InstanceName

The DDS instance selected when you create the replicationinstance, which cannot be changed.

DatabaseUsername


DatabasePassword


NO TE








IP address or domain name of the destination database inthe IP address/Domain name:Port format. The port numberof the destination database ranges from 1 to 65534.You can enter up to 3 groups of IP addresses or domainnames of the source database. Separate multiple values withcommas (,). For example: 192.168.0.1:8080,192.168.0.2:8080.Ensure that the entered IP addresses or domain namesbelong to the same instance.NOTE

If multiple IP addresses or domain names are entered, the testconnection is successful as long as one IP address or domain name isaccessible. Therefore, you must ensure that the IP address or domainname is correct.


The name of the destination database.

DatabaseUsername


DatabasePassword





NO TE








Start Point The start position of the incremental synchronization. The formatis timestamp:incre. The source database logs are obtained fromthe start point (including the current start point).● If the source database is a single node or replica set instance,

run use local; db.oplog.rs.find(); to obtain the start position inthe oplog. Specify timestamp and incre based on the ts field inresult and the bsontimestamp format.

● If the source database is a cluster instance, convert the formatof the start position into timestamp and set incre to 1.


DRS supports database-level and table-level synchronization. Youcan select data for synchronization based on your servicerequirements.The search function can help you quickly select the requireddatabase objects.









NO TE



NO TE






----End

5.2.33 From DB2 to GaussDB(for openGauss) DistributedThis section uses the real-time synchronization from DB2 for LUW to GaussDB(foropenGauss) distributed as an example to describe how to configure a real-timesynchronization task.










Procedure














Source DBEngine

Select DB2.








SynchronizationMode

Available options: Full and Full+Incremental.


Step 3 On the Configure Source and Destination Databases page, specify source anddestination database information and click Test Connection for both the sourceand destination databases to check whether they have been connected to thesynchronization instance. After the connection tests are successful, click Next.








IP address or domain name of the source DB2 for LUWdatabase.

Port The port of the source database. Range: 1 – 65535

DatabaseUsername

The username for accessing the source DB2 for LUWdatabase.

DatabasePassword

The password for the source database username.

Database Name The name of the database to which the migration objectsbelong in the source DB2 for LUW.




NO TE

The IP address, username, and password of the source database are encrypted and stored inDRS and will be cleared after the task is deleted.




DB InstanceName

The GaussDB(for opnnGauss) distributed instance selectedduring synchronization task creation. This parameter cannotbe changed.




DatabaseUsername

The username for logging in to the destination database.

DatabasePassword

Password for the destination database username. Thedatabase username and password are encrypted and storedin the system and will be cleared after the task is deleted.

NO TE













Synchronizationobject

Select Tables or Databases as required.● If the synchronization objects in source and destination








NO TE



NO TE



----End

5.2.34 Kafka Message FormatData synchronized to the Kafka cluster is stored in Avro, JSON, and JSON-Cformats.





AvroFor details about the schema definition in Avro format, see record.rar. After datais synchronized to the Kafka cluster, parse data based on the definition of the Avroschema. For details about the data parsing, see drs-avro-read.rar.

JSONFor details about the JSON format, see Table 5-181.

Table 5-181 Parameters


mysqlType Field name and type in the source table.

id Sequence number of an event operation defined in DRS. Thevalue increases monotonically.

es The time when the record is generated in the source database.The value is a 13-bit Unix timestamp in milliseconds.

ts The time when the data is written to the target Kafka. Thevalue is a 13-bit Unix timestamp in milliseconds.

database Database name. For the Oracle database, set this parameter toschema.

table Table name.

type Operation type, such as DELETE, UPDATE, INSERT, and DDL.

isDdl Whether the operation is a DDL operation.

sql A DDL-defined SQL statement. The value is "".

sqlType JDBC type of the fields in the source table.

data The latest data, which is a JSON array. If the value of type isINSERT, the latest data is inserted. If the value of type isUPDATE, the latest data is updated.

old Old data. If the value of type is UPDATE, the data is old. If thevalue of type is DELETE, the data is deleted.

pkNames Primary key name.

{ "mysqlType":{ "c11":"binary", "c10":"varchar", "c13":"text", "c12":"varbinary", "c14":"blob", "c1":"varchar", "c2":"varbinary", "c3":"int",



https://res-static.hc-cdn.cn/cloudbu-site/intl/zh-cn/DRS/record.rar

https://res-static.hc-cdn.cn/cloudbu-site/intl/zh-cn/DRS/drs-avro-read.rar

"c4":"datetime", "c5":"timestamp", "c6":"char", "c7":"float", "c8":"double", "c9":"decimal", "id":"int" }, "id":27677, "es":1624614713000, "ts":1625058726990, "database":"test01", "table":"test ", "type":"UPDATE", "isDdl":false, "sql":"", "sqlType":{ "c11":-2, "c10":12, "c13":-1, "c12":-3, "c14":2004, "c1":12, "c2":-3, "c3":4, "c4":94, "c5":93, "c6":1, "c7":6, "c8":8, "c9":3, "id":4 }, "data":[ { "c11":"[]","c10": "HUAWEI CLOUD huaweicloud", "c13":"asfiajhfiaf939-0239uoituqorjoqirfoidjfqrniowejoiwqjroqwjrowqjojoiqgoiegnkjgoi23roiugouofdug9u90weurtg103", "c12":"[106, 103, 111, 106, 103, 111, 105, 100, 115, 106, 103, 111, 106, 111, 115, 111, 103, 57, 51, 52, 48, 57, 52, 51, 48, 57, 116, 106, 104, 114, 103, 106, 101, 119, 57, 116, 117, 48, 57, 51, 52, 48, 116, 101, 114, 111, 101, 106, 103, 57, 56, 51, 48, 52, 105, 101, 117, 114, 103, 57, 101, 119, 117, 114, 103, 48, 119, 101, 117, 116, 57, 114, 48, 52, 117, 48, 57, 53, 116, 117, 51, 48, 57, 50, 117, 116, 48, 57, 51, 117, 116, 48, 119, 57, 101]", "c14":"[106, 103, 111, 106, 103, 111, 105, 100, 115, 106, 103, 111, 106, 111, 115, 111, 103, 57, 51, 52, 48, 57, 52, 51, 48, 57, 116, 106, 104, 114, 103, 106, 101, 119, 57, 116, 117, 48, 57, 51, 52, 48, 116, 101, 114, 111, 101, 106, 103, 57, 56, 51, 48, 52, 105, 55, 57, 56, 52, 54, 53, 52, 54, 54, 54, 49, 52, 54, 53, 33, 64, 35, 36, 37, 94, 42, 40, 41, 95, 41, 43, 95, 43, 124, 125, 34, 63, 62, 58, 58, 101, 117, 114, 103, 57, 101, 119, 117, 114, 103, 48, 119, 101, 117, 116, 57, 114, 48, 52, 117, 48, 57, 53, 116, 117, 51, 48, 57, 50, 117, 116, 48, 57, 51, 117, 116, 48, 119, 57, 101]", "c1":"cf3f70a7-7565-44b0-ae3c-83bec549ea8e:104", "c2":"[]", "c3":"103", "c4":"2021-06-25 17:51:53", "c5":"1624614713.201", "c6":"!@#$%90weurtg103", "c7":"10357.0", "c8":"1.2510357E7", "c9":"9874510357", "id":"104" }



], "old":[ { "c11":"[]","c10": "HUAWEI CLOUD huaweicloud", "c13":"asfiajhfiaf939-0239", "c12":"[106, 103, 111, 106, 103, 111, 105, 100, 115, 106, 103, 111, 106, 111, 115, 111, 103, 57, 51, 52, 48, 57, 52, 51, 48, 57, 116, 106, 104, 114, 103, 106, 101, 119, 57, 116, 117, 48, 57, 51, 52, 48, 116, 101, 114, 111, 101, 106, 103, 57, 56, 51, 48, 52, 105, 101, 117, 114, 103, 57, 101, 119, 117, 114, 103, 48, 119, 101, 117, 116, 57, 114, 48, 52, 117, 48, 57, 53, 116, 117, 51, 48, 57, 50, 117, 116, 48, 57, 51, 117, 116, 48, 119, 57, 101]", "c14":"[106, 103, 111, 106, 103, 111, 105, 100, 115, 106, 103, 111, 106, 111, 115, 111, 103, 57, 51, 52, 48, 57, 52, 51, 48, 57, 116, 106, 104, 114, 103, 106, 101, 119, 57, 116, 117, 48, 57, 51, 52, 48, 116, 101, 114, 111, 101, 106, 103, 57, 56, 51, 48, 52, 105, 55, 57, 56, 52, 54, 53, 52, 54, 54, 54, 49, 52, 54, 53, 33, 64, 35, 36, 37, 94, 42, 40, 41, 95, 41, 43, 95, 43, 124, 125, 34, 63, 62, 58, 58, 101, 117, 114, 103, 57, 101, 119, 117, 114, 103, 48, 119, 101, 117, 116, 57, 114, 48, 52, 117, 48, 57, 53, 116, 117, 51, 48, 57, 50, 117, 116, 48, 57, 51, 117, 116, 48, 119, 57, 101]", "c1":"cf3f70a7-7565-44b0-ae3c-83bec549ea8e:104", "c2":"[]", "c3":"103", "c4":"2021-06-25 17:51:53", "c5":"1624614713.201", "c6":"!@#$%90weurtg103", "c7":"10357.0", "c8":"1.2510357E7", "c9":"9874510357", "id":"103" } ], "pkNames":[ "id" ]}

JSON-C

JSON-C is similar to JSON. The difference lies in the delete operation. JSON data isstored in old, and JSON-C is stored in data. Data of the timestamp type isconverted into a character string in the format of yyyy-mm-dd hh:mm:ss.

For details, see Table 5-182.

Table 5-182 JSON-C parameter description


mysqlType Field name and type in the source table

id Sequence number of an event operation defined in DRS. Thevalue increases monotonically.

es The time when the record is generated in the source database.The value is a 13-bit Unix timestamp in milliseconds.

ts The time when the data is written to the target Kafka. Thevalue is a 13-bit Unix timestamp in milliseconds.

database Database name. For the Oracle database, set this parameter toschema.




table Table name

type Operation type, such as DELETE, UPDATE, INSERT, and DDL.

isDdl Whether the operation is a DDL operation.

sql A DDL-defined SQL statement. The value is "".

sqlType JDBC type of the fields in the source table

data Latest data, which is a JSON array. If type is set to INSERT, thisparameter indicates the latest inserted data. If type is set toUPDATE, this parameter indicates the latest updated data. Iftype is set to DELETE, this parameter indicates the deleteddata.

old Old data. If type is set to UPDATE, the value indicates the databefore update. If type is set to INSERT, the value is null.

pkNames Primary key name

Common escape characters in JSON data

Table 5-183 Escape Character

Character Escape character

< \u003d

> \u003e

& \u0026

= \u003d

' \u0027

5.2.35 Forcibly Stopping Synchronization from GaussDB(foropenGauss) Distributed

This section describes how to clear the streaming replication slots of the sourceGaussDB(for openGauss) distributed database after the incremental or full+incremental synchronization task is forcibly stopped.

Prerequisites

Common users do not have the permission to perform the execute directoperation. To delete streaming replication slots, contact GaussDB(for openGauss)O&M personnel.



Procedure

Step 1 Log in to each primary DN node of GaussDB(for openGauss) distributed instanceas the user used when you tested the connectivity between the DRS instance andthe GaussDB(for openGauss) distributed instance.

Step 2 Run the following statement to query the streaming replication slot name of thedatabase object selected for the synchronization task:select slot_name from pg_replication_slots where database = 'database';

NO TICE

In the preceding command, database indicates the database selected in thesynchronization task.

Step 3 Run the following statement to delete the streaming replication slot:select * from pg_drop_replication_slot('slot_name');

NO TICE

In the preceding command, slot_name indicates the name of the streamingreplication slot queried in Step 2.

Step 4 Run the following statement to check whether the streaming replication slot issuccessfully deleted:select slot_name from pg_replication_slots where database = 'database';

If the query result is empty, the streaming replication slot is deleted.

Step 5 Repeat the preceding operations to ensure that the streaming replication slot oneach primary DN is deleted.

----End

5.2.36 Forcibly Stopping Synchronization from GaussDB(foropenGauss) Primary/Standby

This section describes how to clear the streaming replication slots of the sourceGaussDB(for openGauss) primary/standby database after the synchronization taskis forcibly stopped.

PrerequisitesCommon users do not have the permission to perform the execute directoperation. To delete streaming replication slots, contact GaussDB(for openGauss)O&M personnel.

Procedure

Step 1 Log in to the GaussDB(for openGauss) primary/standby instance as the user usedwhen you tested connectivity between the DRS instance and the GaussDB(foropenGauss) primary/standby instance.



Step 2 Run the following statement to query the streaming replication slot name of thedatabase object selected for the synchronization task:select slot_name from pg_replication_slots where database = 'database';

NO TICE



NO TICE


Step 4 Run the following statement to check whether the streaming replication slot issuccessfully deleted:select slot_name from pg_replication_slots where database = 'database';


----End

5.2.37 Forcibly Stopping Synchronization from PostgreSQLThis section describes how to clear the logical replication slot of the sourcedatabase, how to synchronize sequence values, and how to reset the sequencevalues in the destination database when the source database cannot be connectedafter the PostgreSQL synchronization task is forcibly stopped.

Clearing the Logical Replication Slot of the Source Database

Step 1 Log in to the source database as the source database user used in thesynchronization task.

Step 2 Query the name of the streaming replication slot of the database object selectedin the synchronization task.select slot_name from pg_replication_slots where database = 'database';

NO TICE





NO TICE


Step 4 Run the following statement to check whether the streaming replication slot issuccessfully deleted:select slot_name from pg_replication_slots where slot_name = 'slot_name';


----End

Synchronizing Sequence ValuesIf sequence objects are not synchronized or the destination database isGaussDB(for openGauss), skip this section.

Step 1 Use a high-privilege account (with the USAGE permission for all sequences) toconnect to the source database and run the following statement:select 'SELECT pg_catalog.setval('||quote_literal(quote_ident(n.nspname)||'.'||quote_ident(c.relname))||', '||nextval(c.oid)||');' as sqls from pg_class c join pg_namespace n on c.relnamespace=n.oid where c.relkind = 'S' and n.nspname !~'^pg_' and n.nspname<>'information_schema' and not (c.relname='hwdrs_ddl_info_id_seq' and n.nspname='public') order by n.nspname, c.relname;

The query result is the SQL statement that needs to be executed in the destinationdatabase.

Step 2 Log in to the destination database as the destination database user used in thesynchronization task. and run the SQL statement queried in Step 1 in thedestination database.

Step 3 Run the following statement in the destination database to check the sequencevalue synchronization result:SELECT n.nspname, c.relname, nextval(c.oid) from pg_class c join pg_namespace n on c.relnamespace=n.oid where c.relkind = 'S' and n.nspname !~'^pg_' and n.nspname<>'information_schema' order by 1,2;

----End

Resetting Sequence Values in the Destination DatabaseIf the source database failed and cannot be connected, you can reset the sequencevalues related to automatic increment or decrement columns in the destinationdatabase. If the source database can be connected, skip this section.

Step 1 Log in to the destination database as the destination database user used in thesynchronization task.

Step 2 Run the following statement to query the SQL statement for resetting thesequence value corresponding to the sequence that uses nextval as the defaultvalue of the table column:set search_path to ''; select 'SELECT pg_catalog.setval('||quote_literal(quote_ident(s. sequence_schema)||'.'||quote_ident(s.sequence_name))||', (SELECT '||case when s.increment::int<0 then 'min(' else 'max(' end|| quote_ident(c.column_name)||')'||case when s.increment::int<0 then '-1' else '+1' end||' FROM '||quote_ident(c.table_schema)||'.'||quote_ident(c.table_name)||'));' as sqls from information_schema.columns c join information_schema.sequences s on (position(quote_literal (quote_ident(s.sequence_schema)||'.'||quote_ident(s.sequence_name))||'::regclass' in c.column_default) > 0) where c.data_type in ('bigint', 'int',



'integer', 'smallint', 'numeric', 'real', 'double precision', 'double') and c.column_default like 'nextval(%%' order by s.sequence_schema, s.sequence_name;


Step 3 If the source database version is earlier than 10.0, skip this step. If the sourcedatabase version is 10.0 or later, run the following statement in the destinationdatabase to query the SQL statement for resetting the sequence valuecorresponding to the additional column of the table identity column:set search_path to ''; select 'SELECT pg_catalog.setval('||quote_literal(seqname)||', (SELECT '||case when increment::int<0 then 'min(' else 'max(' end||colname||')'||case when increment::int<0 then '-1' else '+1' end||' FROM '||tablename||'));' as sqls from (select objid::regclass::text, refobjid::regclass::text, (pg_identify_object(refclassid,refobjid,refobjsubid)).identity, (pg_sequence_parameters(objid)).increment from pg_depend where deptype='i' and refobjsubid>0 and objid in (select c.oid from pg_class c join pg_namespace n on c.relnamespace=n.oid where c.relkind='S' and n.nspname !~ '^pg_' and n.nspname<>'information_schema')) p(seqname,tablename,colname,increment);


Step 4 Run the SQL statements queried in Step 2 and Step 3 in the destination database.

Step 5 Run the following statement in the destination database to check the sequencevalue synchronization result:SELECT n.nspname, c.relname, nextval(c.oid) from pg_class c join pg_namespace n on c.relnamespace=n.oid where c.relkind = 'S' and n.nspname !~'^pg_' and n.nspname<>'information_schema' order by 1,2;

----End

5.3 Task Management

5.3.1 Viewing Task DetailsView the information about the synchronization tasks and synchronizationinstances. This section describes how to view details about a synchronization taskyou have created.


ProcedureNO TE


Step 1 On the Data Synchronization Management page, click the targetsynchronization task name in the Task Name/ID column.

Step 2 On the displayed Basic Information page, view details about the migration task.

You can view information about the task, synchronization instance, andsynchronization.

----End



5.3.2 Modifying Task InformationAfter a data synchronization task is created, you can modify task information toidentify different tasks.


● Task name

● Description

● SMN topic

● Synchronization delay threshold

● Number of days when an abnormal task is stopped

● Task start time

Prerequisites


Procedure


Step 2 On the Basic Information tab, locate the information to be modified in the TaskInformation area.

● You can click to modify the task name, SMN topic, delay threshold, thetime to stop abnormal tasks, and description.

– To submit the change, click .

– To cancel the change, click .




Description The description consists of a maximum of 256characters and cannot contain the following specialcharacters: !<>&'\"

SMN Topic You can apply for a topic on the SMN console and adda subscription.For details, see Simple Message Notification UserGuide.


The delay ranges from 1s to 3600s.







The value must range from 14 to 100.

● You can modify the task start time only when the task is in the Pending start

status.In the Task Information area, click Modify in the Scheduled Start Timefield. On the displayed page, specify the scheduled start time and click OK.


----End

5.3.3 Modifying Synchronization InformationA data synchronization task may fail due to the change of the password of thesource or destination database. You need to rectify the information and then retrythe synchronization task on the DRS console.

You can modify the following synchronization information:

● Source database password● Destination database password

NO TE

After the preceding information is changed, the change takes effect immediately, andthe data in the destination database is not cleared.


Procedure


Step 2 On the Basic Information tab, click Modify Connection Details in theSynchronization Information area.

Step 3 In the displayed dialog box, change the passwords of the source and destinationdatabases and click OK.


----End

5.3.4 Editing Synchronization ObjectsThis section describes how to change synchronization objects in a synchronizationtask. After a real-time synchronization task is created, you can changesynchronization objects by adding or deleting databases and tables to besynchronized during the incremental synchronization.




Method 1

Step 1 On the Data Synchronization Management page, locate the targetsynchronization task and click Edit in the Operation column.

Figure 5-232 Editing synchronization objects

Step 2 On the Set Synchronization Task page, change the objects to be synchronizedand click Next.

Figure 5-233 Changing synchronization objects









NO TE


Step 4 In the synchronization task list on the Data Synchronization Management page,the current task status is Incremental synchronization, and a subtask in theModifying task status is generated. After the subtask change is complete,incremental synchronization is performed for the edited synchronization objects.

----End

Method 2

Step 1 On the Data Synchronization Management page, click the targetsynchronization task.

Step 2 On the displayed page, click the Synchronization Mapping tab and click Edit tothe right of the synchronization object.


----End

5.3.5 Importing Synchronization ObjectsReal-time synchronization supports the import of objects through files. After atask is created, you can import object files on the Set Synchronization Task page.



NO TE

● Only Windows Microsoft Excel 97-2003 (*.xls), 2007, and later (*.xlsx) files can beimported. The downloaded compressed package provides the templates of the twoversions.

● The file name can contain only spaces, letters, digits, hyphens (-), underscores (_), andparentheses.

● The object information in the template must be entered in theSchemaName.TableName format. The value is case-sensitive and cannot include anglebrackets (<>), periods (.), and double quotation marks ("). Objects that start or endwith a space are not supported.

● The task in the configuration supports table-level synchronization, database-levelsynchronization, or file import mode. Each time you switch to a new mode, the selectedor imported database objects are cleared, and you need to select or import them again.

● If you want to import a file for mapping, fill in the first and second columns of the filebased on the template. If the first two columns of a row are left blank, the row will beignored.

● For the task created using the file import mode, database-level and table-levelsynchronization are not supported after the task is started.

● If you edit a task, the imported file must contain information about all objects.Information about added or deleted objects cannot be imported.

● If you edit a task again, the objects that have been synchronized cannot be mappedagain. Ensure that the object names remain unchanged after the mapping.

● If you edit a task again, the exported object information is the synchronized objectinformation.

● If the verification fails after the file is uploaded, click View Failure Details to downloadthe error information.

Procedure

Step 1 On the Set Synchronization Task page, click Import object file in theSynchronization Object field.

Figure 5-235 Importing an object file

Step 2 Click Download Template.

Step 3 Download the template and enter information about the objects to be imported.

Step 4 Click Select File. In the displayed dialog box, select the edited template.

Step 5 Click Upload.

----End

5.3.6 Mapping Object NamesData synchronization allows you to synchronize objects (including databases,schemas and tables) in a sources database to the corresponding objects in adestination database. If the synchronization objects in source and destination



databases have different names, you can map the source object name to thedestination one. The object types that can be mapped include database, schema,and table. Only whitelisted users can use this function. To use this function, submita service ticket. In the upper right corner of the management console, chooseService Tickets > Create Service Ticket to submit a service ticket.

Object name mapping can be used only in the following scenarios:

● For the first time you select synchronization objects for a data synchronizationtask.

● For the first time you add or delete the synchronization object which is not ina mapping relationship.

NO TE

● If the destination DB is a type of PostgreSQL (for example, GaussDB(DWS), GaussDB(for openGauss), or PostgreSQL), the destination schema name cannot start with pg_.Otherwise, the migration fails.

● The following scenarios do not support schema mapping for tables of the smallserial,serial, and bigserial types:● GaussDB(for openGauss) primary/standby -> GaussDB(for openGauss) distributed● GaussDB(for openGauss) primary/standby->GaussDB(for openGauss) primary/

standby● GaussDB(for openGauss) distributed -> GaussDB(for openGauss) distributed

This section describes how to map objects when configuring a datasynchronization task. For details about the mapping relationship, see ViewingSynchronization Mapping Information.

Mapping DatabasesDuring real-time synchronization, if the names of source databases to besynchronized are different from those in the destination, you can map the sourcedatabase names to the destination ones. For example, when synchronizingdatabase A in the source database to database B in the destination database, youneed to map database name first.

Step 1 On the Set Synchronization Task page, select the database that needs to bemapped from the synchronization objects on the right area and click Edit.



Figure 5-236 Mapping databases

Step 2 Changing a database name

In the displayed dialog box, enter a new database name. The new database nameis the name of the database saved in the destination DB instance.

Figure 5-237 Changing a database name

Step 3 Check the result.

After the database name is changed, the database name before modification andthe new database name are displayed. The database mapping is complete.



Figure 5-238 Checking the result

----End

Mapping Schemas

A schema is a collection of database objects, including: tables, views, storedprocedures, and indexes.

During real-time synchronization, if the names of source schemas to besynchronized are different from those in the destination, you can map the sourceschema names to the destination ones. For example, you need to synchronizeschema A in the source database to schema B in the destination database.

Step 1 On the Set Synchronization Task page, select the schema that needs to bemapped from the synchronization objects on the right area and click Edit.

Figure 5-239 Mapping schemas

Step 2 Edit the schema name.



In the displayed dialog box, enter a new schema name which is the name to besaved in the destination database.

Figure 5-240 Edit Schema Name


After the schema name is changed, the schema name before modification and thenew schema name are displayed. The schema mapping is complete.


----End

Mapping Tables

During real-time synchronization, if the names of source tables to be synchronizedare different from those in the destination, you can map the source table namesto the destination ones. For example, when synchronizing table A in the sourcedatabase to table B in the destination database you need to map table namesfirst.

Step 1 On the Set Synchronization Task page, select the table that needs to be mappedfrom the synchronization objects on the right area and click Edit.



Figure 5-242 Table name mapping

Step 2 Change a table name.

In the displayed dialog box, enter a new table name. The new table name is thename of the table saved in the destination database.

Figure 5-243 Changing a table name


After the table name is changed, the table name before modification and the newtable name are displayed. The table mapping is complete.




----End

5.3.7 Viewing Synchronization Mapping InformationDuring real-time synchronization, the objects that can be mapped to thedestination include databases, schemas, tables, and columns (in data processing).After a mapping relationship between objects is established, you can view detailsabout the mapping.


Procedure


Step 2 On the displayed page, click the Synchronization Mapping tab to view themapping details.

Figure 5-245 Viewing mapping information

NO TE

When you select an object, the spaces before and after the object name are not displayed.If there are two or more consecutive spaces in the middle of the object name, only onespace is displayed.

Step 3 In the upper right corner, filter and search for the mapping relationships by objector column.

----End



5.3.8 Editing a Synchronization TaskThis section describes how to modify configuration information of asynchronization task, including information about the source and destinationdatabases. For synchronization tasks in the following statuses, you can edit andsubmit the tasks again.

● Creating● Configuration


Method 1

Step 1 In the task list on the Data Synchronization Management page, locate the targettask and click Edit in the Operation column.

Step 2 On the Configure Source and Destination Databases page, enter informationabout the source and destination databases and click Next.





NO TE

For details about the operations and precautions, see "Creating a Data SynchronizationTask" in the Getting Started with Data Replication Service.

----End

Method 2

Step 1 On the Data Synchronization Management page, click the targetsynchronization task.



----End

5.3.9 Resuming a Synchronization TaskA fault may occur during the synchronization due to external factors, such asinsufficient storage space. After the fault is rectified based on the synchronizationlog information, you can resume the synchronization.




You can resume synchronization tasks in any of the following statuses:

● Full synchronization failed● Pausing

NO TE

● If the full synchronization task fails due to non-network problems, the system willautomatically resume the task three times by default. If the failure persists, youcan resume the task manually.

● If the full synchronization fails due to network problems, the system willautomatically resume the task until the full synchronization is restored.

Prerequisites


Method 1

In the task list on the Data Synchronization Management page, locate the targettask and click Resume in the Operation column.

Method 2


Step 2 On the displayed page, click the Synchronization Progress tab, and click Resumein the upper left corner.

----End

5.3.10 Skipping Data and Resuming a Synchronization TaskData synchronization may be stopped due to certain reasons. After the problem isresolved, you can directly skip the data written to the source database during thepause and resume data transfer. Only the incremental synchronization tasks fromDDM to Oracle support this function.

Prerequisites● You have logged in to the DRS console.● The task is paused.

Procedure

In the task list on the Data Synchronization Management page, locate the targettask and click Jump Resume in the Operation column.

5.3.11 Pausing a Synchronization TaskDRS allows you to pause real-time synchronization tasks.

The following tasks can be paused during incremental synchronization:



● MySQL->MySQL● MySQL -> GaussDB(for MySQL) primary/standby● MySQL->GaussDB(DWS)● MySQL->CSS/ES● MySQL->Oracle● DDM->GaussDB(DWS)● DDM->Oracle● DDM->Kafka● Oracle->GaussDB(DWS)● Oracle->PostgreSQL● Oracle -> GaussDB(for MySQL) primary/standby● Oracle->RDS for MySQL● PostgreSQL->GaussDB(DWS)● GaussDB(for MySQL) Primary/Standby -> Kafka● GaussDB(for MySQL) Primary/Standby -> CSS/ES● GaussDB(for MySQL) Primary/Standby -> Oracle

In addition, the following tasks can be paused during full synchronization:

● MySQL->MySQL● MySQL -> GaussDB(for MySQL) primary/standby


Procedure

Step 1 In the task list on the Online Synchronization Management page, locate thetarget task and click Pause in the Operation column.


NO TE

● After the task is paused, the status of the task becomes Pausing.● After you select Pause log capturing, the DRS instance will no longer communicate

with the source and destination databases. If the pause duration is too long, the taskmay fail to be resumed because the logs required by the source database expire. It isrecommended that the pause duration be less than or equal to 24 hours.

----End

5.3.12 Resetting a Synchronization TaskFor synchronization from MySQL to GaussDB(for MySQL) primary/standby, MySQLto MySQL, Oracle to GaussDB(for MySQL) primary/standby, and Oracle to RDSMySQL, you can reset the synchronization process.

For synchronization tasks in the following statuses, if the synchronization fails, youcan reset the task.



● Paused● Incremental synchronization failed

NO TE

● For a many-to-one synchronization task, only the parent task can be reset.

● For a MySQL many-to-one synchronization task, only the subtask can be reset.

● The reset function does not clear the destination database. You can determine whetherto clear the destination database based on your requirements. After the task is reset, fullsynchronization is performed again. You do not need to configure the task again.


Method 1

Step 1 In the task list on the Data Synchronization Management page, locate the targettask and click Reset in the Operation column.

Step 2 In the displayed dialog box, check the synchronization task again.

NO TE

If a many-to-one synchronization task fails to be reset, click the name of the failed subtaskin the failure details to view the failure cause of the task.

Step 3 After the check is complete and the check success rate is 100%, click Start tosubmit the synchronization task again.

----End

Method 2


Step 2 On the displayed page, click the Synchronization Progress tab, and click Reset inthe upper left corner.


----End

5.3.13 Stopping a Synchronization TaskAfter the source database and services are migrated to the destination database,you can stop the synchronization task. To prevent data from being overwrittenafter the source database and services are migrated to the destination database,stop a synchronization task to achieve this goal.

You can stop a task in any of the following statuses:

● Creating● Configuration● Pending start



● Full synchronization● Incremental synchronization● Task stopping● Fault rectification

NO TICE

● You are advised to stop the task before performing other operations, such asdisconnecting the network between the source database and thesynchronization instance. Otherwise, an alarm indicating that the sourcedatabase cannot be connected will be generated.


● For a task in the Fault rectification state, it cannot be stopped if the fault isbeing rectified.

● After a task is stopped, it cannot be retried.

Procedure

Step 1 In the task list on the Data Synchronization Management page, locate the targettask and click Stop.


NO TE

Generally, stopping a task can ensure the integrity of special objects. In rare cases (forexample, network exceptions), a task may fail to be stopped. If a task fails to be stoppedmultiple times, you can select Forcibly stop task to reduce the wait time.

----End

5.3.14 Deleting a Synchronization TaskThis section describes how to delete a synchronization task that has beencompleted or has failed. Deleted tasks will no longer be displayed in the task list.Exercise caution when performing this operation.

Prerequisites


Method 1

Step 1 In the task list on the Data Synchronization Management page, locate the targettask and click Delete in the Operation column.


----End



Method 2

Step 1 In the task list on the Data Synchronization Management page, select the targettasks and click Delete in the upper left of the synchronization task list.

Figure 5-246 Deleting synchronization tasks

NO TE




----End

5.3.15 Cloning a Synchronization TaskIn the MySQL to MySQL real-time synchronization scenario, you can clone theconfiguration of an existing synchronization task in any of the following statuses:

● Starting

● Full synchronization

● Incremental synchronization

● Modifying task

● Paused

● Completed

NO TE

● When a task is cloned, the source and destination database passwords are not cloned.You need to enter the passwords again for the new task.

● When you clone a task, the advanced settings for data filtering are not cloned. You needto set the advanced settings for the cloned task again.

● Many-to-one task cloning is not supported.

● When you clone a task that is being changed, if the change information has been savedto the database, the clone task configuration is the same as the changed configuration.

● After a clone task is created, the EIP and private IP address of the new task are differentfrom those of the original task. You may need to configure the network to ensure thatthe new task can communicate with the source and destination databases.


● A synchronization task has been created.



Procedure

Step 1 On the Data Synchronization Management page, select the task to be clonedand click Clone in the Operation column.

Step 2 In the displayed dialog box, confirm the new task name and click OK.

Step 3 After the task is submitted and the task clone is complete, the task status changesto Configuration. You can click Edit in the Operation column, enter the sourceand destination database passwords again, and edit and start the task.

----End

5.3.16 Modifying the Flow Control Mode

You can choose whether to control the flow. DRS allows you to control thesynchronization speed in the following scenarios:

● MySQL->MySQL● MySQL->RDS for PostgreSQL● MySQL->GaussDB(DWS)● MySQL->CSS/ES● MySQL->Oracle● Oracle->MySQL● Oracle -> GaussDB(for MySQL) primary/standby● Oracle -> GaussDB(for MySQL) distributed● Oracle -> GaussDB(for openGauss) primary/standby● Oracle -> GaussDB(for openGauss) distributed● Oracle->GaussDB(DWS)● Oracle->DDM● Oracle->PostgreSQL● Oracle->Kafka● GaussDB(for MySQL) primary/standby -> Oracle● GaussDB(for openGauss) primary/standby -> Oracle● GaussDB(for openGauss) primary/standby -> GaussDB(for openGauss)

distributed● GaussDB(for openGauss) distributed -> Oracle● GaussDB(for openGauss) distributed -> GaussDB(for openGauss) distributed● PostgreSQL->RDS for PostgreSQL

NO TE

● The flow control mode takes effect only in the full synchronization phase.● After the traffic rate is modified in the incremental migration phase, the modification

takes effect when the task enters the full migration phase again. For example, if thetraffic rate is modified and a synchronization object is added to the task, themodification takes effect in the full synchronization phase of the task.

● Only whitelisted can use this function. To use this function, submit a service ticket. Inthe upper right corner of the management console, choose Service Tickets > CreateService Ticket to submit a service ticket.




● A synchronization task has been created.

Method 1

Step 1 In the Synchronization Information area on the Basic Information tab, clickModify next to the Flow Control field.



----End

Method 2

Step 1 In the task list on the Data Synchronization Management page, locate the targettask and choose More > Speed or Speed in the Operation column.

Figure 5-248 Task list





----End

5.3.17 Processing DataDRS processes synchronized objects and allows you to add rules for selectedobjects. Different processing rules are supported in different scenarios.

Adding Synchronization Timestamp

Step 1 On the Process Data page, select the table objects to be processed in the SelectSource Database Object.

Step 2 Click the Process Data area, click Add Rule, and enter the column name, type,and operation to be added.

NO TE

● The column to which the rule is to be added already exists in the table and cannot bethe primary key.

● You are advised to use columns whose data type is timestamp (TIMESTAMP) as rulecolumns.

Step 3 Click Next.

----End

Adding Additional Column

Step 1 On the Processing Data page, click Additional Columns, locate the database ortable to be processed, and click Add in the Operation column.



Figure 5-250 Additional columns

Step 2 In the displayed Add dialog box, specify the column name, operation type, andfield type. Click OK.

Figure 5-251 Operation types

NO TE

● In many-to-one mapping scenarios, additional columns for data processing are requiredto avoid data conflicts.

● The following operation types are supported:

– Default: Use the default value to fill in the new column.

– Use the create_time column and update_time column as an example to fill thenew column with the data creation time and data update time.

– Expression: indicates that you need to fill the new column with an expression.

– If you fill in the new column in serverName@database@table format, you needto enter a server name and then the database name and table name will beautomatically filled in.

– Value: Select a value, for example, synchronization time.

● You can apply the additional column information of the first editable table to alleditable tables in batches.

● During MySQL to GaussDB(for MySQL) primary/standby synchronization, if the numberof columns in a single table exceeds 500, the number of additional columns added tothe table may exceed the upper limit. As a result, the task fails.



Step 3 Click Next.

----End

Filtering DataAfter a data filtering rule is added, update the source database to ensure dataconsistency. For example:● The filter criteria are met after the update. You need to continue the

synchronization and perform the same update operation on the destinationdatabase. If no data is matched, the operation will be ignored, causing datainconsistency.

● The filter criteria are not met after the update. You need to continue thesynchronization and perform the same update operation on the destinationdatabase.

Step 1 On the Processing Data page, set Processing Type to Data filtering.

Figure 5-252 Filtering data

Step 2 In the Object area, select the table to be processed.

Step 3 In the Filtering Criteria area, enter the filter criteria (only the part after WHEREin the SQL statement, for example, id=1), and click Verify.

NO TE

● Each table has only one verification rule.● Up to 500 tables in the source Oracle database and 500 tables in the source MySQL

database can be filtered at a time.● The filter criteria cannot use the packet, function, variable, or constant of a specific DB

engine. It must comply with the general SQL standard.

Step 4 After the verification is successful, click Generate Processing Rule. The rule isdisplayed.

Step 5 Click Next.

----End



Advanced Settings for Data Filtering

If you need to query an association table, you can use the advanced settings ofdata processing.

Step 1 On the Processing Data page, set Processing Type to Data filtering.

Step 2 In the Object area, select the table to be processed.

Step 3 In the Filtering Criteria area, specify the filtering criteria, for example, id1 in(select id from db1.tab1 where id >=3 and id <10), and click Verify.

NO TE

● Each table has only one verification rule.

● Up to 500 tables in the source Oracle database and 500 tables in the source MySQLdatabase can be filtered at a time.

● The filter criteria cannot use the packet, function, variable, or constant of a specific DBengine. It must comply with the general SQL standard.

Step 4 After the verification is successful, click Generate Processing Rule. The rule isdisplayed.

Step 5 In the Advanced Settings area, specify the configuration condition and rule forthe association table to help you filter data.

Figure 5-253 Advanced settings

1. In the Configuration Condition area, enter the association table informationentered in Step 3.



Database Name, Table Name, Column Name, Primary Key, Index, andFilter Criteria are mandatory. If the table does not have an index, enter itsprimary key.Filter Criteria is the filter condition of the association table informationentered in Step 3.

2. Then, click Verify.3. After the verification is successful, click Generate Configuration Rule. The

rule is displayed in the Configuration Rule area.To filter data in multiple association tables, repeat Step 5.

NO TE

Configuration rules can be deleted.

Step 6 Click Next.

----End

Processing Columns

Step 1 On the Process Data page, select Processing Columns.

Step 2 In the Object area, select the objects to be processed.

Figure 5-254 Processing Columns

Step 3 Click Edit to the right of the selected object.

Step 4 In the Edit Column dialog box, select the columns to be mapped and enter newcolumn names.



Figure 5-255 Edit Column

NO TE

● You can query or filter columns or create new column names.● After the column name is edited, the column name of the destination database is

changed to the new name.● The new column name cannot be the same as the original column name or an existing

column name.● The column name in the synchronized table cannot be modified.● Only the selected columns can be synchronized.● Partitioned tables do not support column mapping in MySQL to MySQL and MySQL to

GaussDB(for MySQL) primary/standby synchronization.● The GaussDB(for openGauss) partition key cannot be filtered.

Step 5 Click Confirm.

Step 6 Click Next.

----End

Viewing Data Filtering Results

Step 1 In the task list, click the task to be processed.

Step 2 Click the Process Data tab to view data filtering records. Click in the upperright corner to refresh the record list.

----End

View Column Processing

Step 1 On the task management page, click the target task name in the Task Name/IDcolumn.

Step 2 In the navigation pane on the left, choose Synchronization Mapping. In theupper right corner, and select Columns to view column mapping records. Click in the upper right corner to refresh the record list.



Figure 5-256 Viewing column mappings

----End

5.3.18 Batch OperationsDRS supports batch operation, making it easy for you to manage tasks. You canperform the following batch operations for real-time synchronization tasks:

● Delete● Stop● Pause● Resume● Configure Exception Notification

Procedure

Step 1 On the Data Synchronization Management page, select the tasks to be changed.



----End

5.3.19 Tag Management

Scenarios

Tag Management Service (TMS) enables you to use tags on the managementconsole to manage resources. TMS works with other cloud services to managetags. TMS manages tags globally, and other cloud services manage their own tags.● You are advised to set predefined tags on the TMS console.● A tag consists of a key and value. You can add only one value for each key.● Each DB instance can have up to 10 tags.

Adding a Tag










----End

Editing a Tag




----End

Delete a Tag





----End



5.3.20 Diagnosis of Abnormal RecordsDuring the synchronization, data may become abnormal due to conflicts, dataprocessing, heterogeneous conversion, and object missing. You can view abnormaldata on the Abnormal Records tab to locate the fault.

NO TE

Only synchronization from DDM to Oracle, MySQL to GaussDB(DWS), MySQL toGaussDB(for openGauss), Oracle to RDS MySQL, Oracle to GaussDB(for MySQL), andMySQL to PostgreSQL supports this function.

Procedure


Step 2 On the Abnormal Records tab, filter abnormal data, including statements anddescription, by time range.

----End



6 Data Subscription

6.1 Introduction to SDK APIsSDK defines multiple types of class objects. This section describes the APIdefinitions of these class objects.

● SubscribeContext

Table 6-1 SubscribeContext

Function Name Description

setDomainName(String domainName)

Specifies the account name.The account name for creating required subscriptiontasks.

setPassword(Stringpassword)

Specifies the account password.The password corresponding to the account name.

setIp(String ip) Specifies the IP address of the subscription instance.Set this parameter to the IP address located on theBasic Information page of the target subscriptiontask.

setUserId(StringuserId)

Specifies the user ID.You can obtain the user ID from My Credential onthe management console.

● ClusterClient

Data Replication ServiceUser Guide 6 Data Subscription


Table 6-2 ClusterClient


voidaddClusterListen-er(ClusterListenervar1)

Adds downstream listeners. A listener can subscribeto incremental data only after being added toClusterClient.The ClusterListener arg0 parameter is an object ofthe ClusterListener arg0 class.

void start() Starts the SDK client to subscribe to incrementaldata.

void stop() Stop subscribing to incremental data.

● ClusterListener

Table 6-3 ClusterListener


voidnotify(List<ClusterMessage> var1)

Defines the consumption of incremental data. Whenreceiving data, the SDK informs ClusterListner ofconsuming data using notify. For example, theconsumption mode in SDK Template indicates thesubscription data displayed on the screen.The input parameter type of this function is List<ClusterMessage> in which ClusterMessage is thestructure object of the subscription data storage. Fordetails, see Table 6-4.

● ClusterMessage

Each ClusterMessage stores the data records of an RDS transaction, and eachrecord is stored using Record.

Table 6-4 ClusterMessage


Record getRecord() Obtains a change record from ClusterMessage. Thechange record indicates each record in the RDSbinlog file, such as begin, commit, update, andinsert.

● Record

Record indicates each record in the RDS binlog file, such as begin, commit,and update.



Table 6-5 Record


StringgetAttribute(finalString key)

Obtains the main attribute values in Record. If theinput parameter is an attribute name, the value ofthis attribute is returned.Table 6-6 lists the attribute names and values thatcan be obtained by invoking this function.

Type getOpt() Obtains the statement type of a record, includinginsert, delete, update, replace, ddl, begin, commit,and heartbeat.

StringgetCheckpoint()

Obtains the checkpoint of the change record in thebinlog. The returned value is in the followingformat: binlog_offset@binlog_fid.binlog_offset indicates the offset of the changerecord in the binlog file, and binlog_fid indicatesthe numeric suffix of the binlog file. For example, ifthe binlog file name is mysql-bin.00092, the valueof binlog_fid is 92.

int getFieldCount() Obtains the number of Fields in the change record.

List <Field>getFieldList()

The data type of the returned value of this functionis List <Field>.List <Field> contains the definitions of all fields ofthe change record and the image values before andafter the change. For details about the definition ofField, see Table 6-7.

Table 6-6 Attribute information

key Description

record_id Specifies the record ID. The ID number does notascend during the subscription process.

instance Specifies the DB instance connection address of therecord. The format is ip:port.

source_type Specifies the DB engine type of the record. Thecurrent DB engine is MySQL.

source_category Specifies the record type. The current value isfull_recorded.

timestamp Specifies the time when the record is written to thebinlog. It is also the time when the SQL statement isexecuted in RDS.



key Description

checkpoint Specifies the binlog file checkpoint of the record.The format is :file_offset@file_name. Theparameter file_name, indicate the numeric suffix ofthe binlog file.

record_type Specifies the operation type of the record. Thevalues include: insert, update, delete, replace, ddl,begin, commit, and heartbeat.

db Specifies the database name updated in the record.

table_name Specifies the table name updated in the record.

record_recording Specifies the record code.

● Field

The Field class defines the attributes of each field, such as the code, type,field name, field value, and whether the field is a primary key. Table 6-7describes the API of each Field class.

Table 6-7 Field


String getEncoding() Obtains the encoding format of the field value.

StringgetFieldname()

Obtains the name of this field.

Type getType() Obtains the data type of the field. For details, seethe field type definition.

ByteStringgetValue()

Obtains the value of this field. The returned type isByteString. If the value is null, NULL is returned.

Boolean isPrimary() Checks whether the field is the primary key columnof the table. If yes, True is returned. Otherwise,False is returned.

6.2 SDK Operation InstructionsThe data subscription function caches data changes of key services in thedatabase and provides a unified SDK API for downstream services to subscribe to,obtain, and consume.

Before using the SDK, create a data subscription task on the DRS console.

After a subscription task is created, you can use an SDK to subscribe toincremental data in the subscription task in real time. The following lists theconstraints:




1. DRS only provides SDK JAVA version. For details, see SDK Download Address.2. One subscription channel can be consumed by only one SDK. If multiple SDKs

are connected to one data subscription channel, only one SDK process canobtain the data change information. If multiple downstream SDKs mustsubscribe to the same RDS instance, you need to create a data subscriptiontask for each SDK.

3. A downstream SDK cannot subscribe to and consume multiple subscriptiontasks.

4. After data subscription is successful, new data can be retained for a maximumof three days if the data is not consumed in time.

NO TICE

The SDK JAVA version provided by DRS supports the development environment ofJDK 1.6 or later. JDK 1.8 is recommended.

Network TypeCurrently, only VPCs are supported.

SDK Working PrinciplesData consumption and message confirmation are two asynchronous threadsstarted based on the transaction sequence. The two threads are independent ofeach other and comply with the causal sequence. The received messages invokethe notify function registered by users in sequence. The SDK ensures that eachmessage is pushed only once.

Importing SDK JAR PackageThe SDK JAR package can be directly imported only through the library. Currently,the Maven central repository is not supported.

<dependency><groupId>com.huawei.hwclouds</groupId><artifactId>drs-subscribe-sdk</artifactId><version>1.0</version></dependency>

Configuring ParametersDuring data subscription, some parameters affect the speed and interval forobtaining data.

Before starting the SDK, you can set the following parameters in thesubscribe.properties configuration file as required:

#Initial delay for obtaining the subscription dataMESSAGE_DELAY_TIME = 1500000#Interval for obtaining the subscription dataMESSAGE_PERIOD_TIME = 2000000#Notify the user that the subscription data initial delayNOTIFY_DELAY_TIME = 2000



#Notify the user of the subscription data intervalNOTIFY_PERIOD_TIME = 1000#Initial delay of the ACK messages from the serverACK_DELAY_TIME = 3000#Interval between the ACK messages from the serverACK_PERIOD_TIME = 5000

NO TE

● The preceding parameter values are set by default. You can also customize parametervalues based on the site requirements.

● The unit of the time mentioned above is microsecond.

Confirmation Mechanism

The SDK uses the automatic batch confirmation mechanism. The client programdoes not need to invoke the confirmation function and can be confirmedrepeatedly.

For example: the client receives five batches of messages, and the server onlyconfirms the first, the second, and the fifth batch, respectively. Messages areconfirmed in sequence. Therefore, it indicates that the client has consumed allmessages in the first to fifth batch. If the client program is suspended, theconsumption checkpoint starts from the fifth batch.

SDK Templateimport com.huawei.hwclouds.drs.context.SubscribeContext;import com.huawei.hwclouds.drs.message.ClusterMessage;import com.huawei.hwclouds.drs.subscribe.ClusterListener;import com.huawei.hwclouds.drs.subscribe.DefaultSubscribeClient;import com.huawei.hwclouds.drs.subscribe.SubscribeClient;import java.util.List;public class MainClass {public static void main(String[] args) throws Exception {SubscribeContext context = new SubscribeContext();//Set a Username of the current cloud account.context.setDomainName("username");//Set the Password of the current cloud account.context.setPassword("userpassword");//Set the IP address of the subscription instance on the Data Subscription Management page.context.setIp("SubscribeChannelIp");//Specify the user ID.context.setUserId("userId");SubscribeClient client =DefaultSubscribeClient.getSubscribeClient(context);ClusterListener clusterListener = new ClusterListener() {@Override//Client consumption behavior defined in notifypublic void notify(List<ClusterMessage> var1) throws Exception {for (ClusterMessage message : var1) {System.out.println("Message is " + message.toString());}}};client.addClusterListener(clusterListener);client.start();}}



6.3 SDK Download AddressTable 6-8 SDK download address

ReleaseDate

SDK Download Address Description

2019-01-19

drs-subscribe-sdk-1.0-jar-with-dependencies.jar

This issue is the first official release.

6.4 Viewing Task DetailsThis section describes how to view details about a subscription task, includinginformation about the task and subscription source.


ProcedureNO TE


Step 1 On the Data Subscription Management page, click the target subscription taskname in the Name/ID column.

Step 2 On the displayed Basic Information tab, view details about the subscription task.

You can view information about the task, subscription instance, and subscriptionsource.

----End

6.5 Editing Subscription Task InformationAfter a data subscription task is created, you can edit task information to identifydifferent tasks.


● Task name● Description● SMN topic




https://res-static.hc-cdn.cn/cloudbu-site/intl/zh-cn/DRS/drs-subscribe-sdk-1.0-jar-with-dependencies.jar

https://res-static.hc-cdn.cn/cloudbu-site/intl/zh-cn/DRS/drs-subscribe-sdk-1.0-jar-with-dependencies.jar

Procedure

Step 1 On the Data Subscription Management page, click the target subscription task.

Step 2 On the Basic Information page, click next to the information to modify.

● To submit the change, click .

● To cancel the change, click .

Table 6-9 Subscription task information



Description The description consists of a maximum of 256 charactersand cannot contain special characters !=<>'&"

SMN Topic You can apply for a topic on the SMN console and add asubscription.For details, see Simple Message Notification User Guide.


----End

6.6 Editing a Subscription TaskThis section describes how to modify configuration information of a subscriptiontask, including information about the source and destination databases. Forsubscription tasks in the following statuses, you can edit and submit the tasksagain.

● Configuration


Method 1

Step 1 In the task list on the Data Subscription Management page, locate the targettask and click Edit in the Operation column.

Step 2 On the Select Subscription Object page, enter the required information aboutthe objects to be modified and click Next.

Step 3 On the Confirm Task page, confirm that the configured information is correct,select the check box before the agreement, and click Submit to submit the task.

Step 4 After the task is submitted, view and manage it on the Data SubscriptionManagement page.






NO TE

After a subscription task is created, you can use an SDK to subscribe to incremental data inthe subscription task in real time. For details, see SDK Operation Instructions.

----End

6.7 Viewing Subscription InformationDRS allows you to view incremental subscription information (excluding view andstored procedure data) in a specified time range on the DRS console.

This section describes how to view the subscription information online and themeaning of each field in the data record.


● You have created a subscription task.

Procedure

Step 1 On the Data Subscription Management page, click the target subscription task.

Step 2 On the displayed page, click the Subscription Information tab.

By default, incremental subscription information of the last 5 minutes is displayedin the current list. To view the subscription information in a specified time range,you can select the time range in the upper right corner on the page, and the timerange must be within the subscription task time range.

Figure 6-1 Viewing subscription information

The data format of subscription information is the internal data format of the DRSservice. Table 6-10 describes the fields in the data record.





Table 6-10 Field description

Field Description

Service ID IP address and port of the RDS instance

DatabaseName

Name of the database where the statement is executed

Table Name Name of the table where the statement is executed

StatementType

The statement types are as follows: update, delete, insert,replace, begin, commit, ddl, and dml.

BinlogPosition

Location of the change record in the binlog file. The format isbinlog_file_offset@binlog_file_id. binlog_file_id indicates thesuffix of the binlog file name, and binlog_file_offset indicatesthe offset of the binlog record in the binlog file.

Time Time when the change record is written to the binlog file

To view details about a specified table in a specified database, click ViewSubscription Data.

Figure 6-2 Field description

For details, see Table 6-11.

Table 6-11 Field description

Field Description

Field Name Name of each field corresponding to the change record

Type Data type of each field corresponding to the change record

Code Character set code corresponding to the change record

Original Value The value of each field before the change There is no originalvalue for the insert operation.



Field Description

New Value The value of each field after the change There is no originalvalue for the delete operation.

NO TE

● The update operation has both the original and new values.

● If the operation type is DDL, only the field name, type, code, original value, and newvalue are available.

----End

6.8 Modifying Consumption Start TimeDRS allows you to modify the consumption start time at any time. Theconsumption start time must be within the subscription task time range. Once theconsumption start time is modified, the incremental data obtained by thedownstream SDK starts from the modified consumption start time.

Currently, the consumption point can be modified on the DRS managementconsole only and cannot be specified in SDK.

This section describes how to modify the consumption start time on the DRSmanagement console.


● You have created a subscription task.

Procedure

Step 1 Stop the SDK consumption process.

Before modifying a consumption start time, ensure that all SDK downstreambusiness processes connected to the subscription channel are stopped.

Step 2 On the Data Subscription Management page, locate the target subscription taskand click Modify in the Consumption Stat time column.

Figure 6-3 Modifying the consumption start time

Step 3 In the displayed dialog box, set the consumption start time and click OK.



Figure 6-4 Modifying the consumption start time

NO TE

The selected consumption start time must be within the time range of the subscriptiontask.

Step 4 Restart the SDK consumption process.

After the consumption start time is modified, restart the local SDK consumptionprocess. Then, the SDK starts to subscribe to incremental data from the modifiedconsumption start time.

----End

6.9 Modifying Subscription ObjectsThis section describes how to add or remove subscription objects in a subscriptiontask. After creating an instance, you can modify the subscription object andsubmit the subscription task again.

Prerequisites


Procedure

Step 1 On the Data Subscription Management page, locate the target subscription taskand click Modify Consumption Object in the Operation column.

Figure 6-5 Editing subscription objects



Step 2 On the Select Subscription Object page, change the subscription type and objectand click Next.

Figure 6-6 Modifying subscription objects

NO TE

During the process of editing a subscription object, the subscribed table cannot be deletedfrom the source database.


----End

6.10 Retrying a Subscription TaskThis section describes how to retry a failed synchronization task.

For synchronization tasks in the following statuses, if the synchronization fails, youcan retry the task.

● Full synchronization

● Incremental synchronization

If an incremental synchronization task fails, the system will automatically retry thetask three times by default. If the failure persists, you can manually retry the task.

Prerequisites


Method 1

In the task list on the Data Synchronization Management page, locate the targettask and click Retry in the Operation column.



Method 2


Step 2 On the displayed page, click the Synchronization Progress tab, and click Retry inthe upper left corner.

----End

6.11 Deleting a Subscription TaskThe task will no longer be displayed in the task list after being deleted. Exercisecaution when performing this operation.

Prerequisites


Method 1

Step 1 In the task list on the Data Subscription Management page, locate the targettask and click Delete in the Operation column.


----End

Method 2

Step 1 In the task list on the Data Subscription Management page, select the targettasks and click Delete in the upper left of the subscription task list.

Figure 6-7 Deleting subscription tasks

NO TE

You can select one or more tasks in a batch delete action.


----End



6.12 Batch OperationsTo facilitate task management, DRS supports batch operation. You can performthe following operations on data subscription tasks in batches:

● Delete● Configure Exception Notification

Procedure

Step 1 On the Data Subscription Management page, select the tasks to be changed.



----End

6.13 Tag Management


Adding a Tag

Step 1 On the Data Subscription Management page, click the target subscription taskname in the Task Name/ID column.









----End

Editing a Tag




----End

Delete a Tag





----End



7 Real-Time Disaster Recovery

7.1 Viewing DR DataThe data synchronization information is recorded during a disaster recovery. Youcan check the integrity of DR data after synchronization.

DRS allows you to view the initialization progress and of DR data health report onthe management console.

Prerequisites● You have logged in to the DRS console.● You have created a DR task.

ProcedureNO TE


Step 1 On the Disaster Recovery Management page, click the target DR task in theTask Name/ID column.

Step 2 On the Basic Information tab, click the Disaster Recovery Data tab.● Initialization Progress

Initialization Progress shows the historical data import progress during thedisaster recovery environment creation. After the historical data is imported,the initialization is complete, and data on this tab will not be updatedanymore.

Data Replication ServiceUser Guide 7 Real-Time Disaster Recovery


Figure 7-1 Initialization progress

● Data Health ReportsData Health Reports periodically shows the data comparison result betweenthe primary and disaster recovery instances, helping you review the datahealth status in the disaster recovery environment.

NO TE

– Data comparison is performed only for disaster recovery tasks.– Only the latest 30 health comparison reports are retained.

Figure 7-2 Data Health Reports

– Modify the comparison policy.Modifying the comparison policy does not affect the current healthcomparison task. The modification takes effect upon the nextcomparison.

▪ In the Health Comparison Policy area on the Data Health Reportstab, click Modify Comparison Policy.



Figure 7-3 Modify Comparison Policy

▪ On the Modify Comparison Policy page, set the requiredparameters.

○ Status: After the health comparison policy is disabled, the healthcomparison will not be performed, and historical health reportscan still be viewed.

○ Comparison Frequency: The comparison can be performedweekly or daily.

○ Comparison Time: When Comparison Frequency is set toWeekly, you can set one or more days from Monday to Sundayas the comparison time.

○ Time Zone: The default value is the local time zone.

○ Effective Time: Specifies the time period during which thecomparison policy takes effect. You are advised to perform thecomparison in off-peak hours. If the health comparison is notcomplete within the validity period, the health comparison isautomatically interrupted. You can still view the healthcomparison results of the completed task.

○ Comparison Type: Rows, accounts, and objects are compared bydefault.

▪ Click OK.

After the modification is successful, the new policy applies to thefollowing comparison tasks. You can cancel the ongoing tasks butthe health reports of the comparison tasks that have been completedcan still be viewed.

----End



7.2 Editing a DR TaskThis section describes how to edit configuration information of a DR task,including information about the service and DR databases. For DR tasks in thefollowing statuses, you can edit and submit the tasks again.

● Creating

● Configuration

Prerequisites


Method 1

Step 1 In the task list on the Disaster Recovery Management page, locate the targettask and click Edit in the Operation column.

Step 2 On the Configure Source and Destination Databases page, enter informationabout the service and DR databases and click Next.

Step 3 On the Check Task page, check the DR task.

● If any check fails, review the failure cause and rectify the fault. After the faultis rectified, click Check Again.

For details about how to handle check failures, see section Solutions toFailed Check Items in Data Replication Service User Guide.


● If the check is complete and the check success rate is 100%, go to theCompare Parameter page.





NO TE


Step 4 Compare the parameters.

The parameter comparison function helps you check the consistency of commonparameters and performance parameters between service and DR databases andshow inconsistent values. You can determine whether to use this function basedon service requirements. It mainly ensures that services are not affected after theDR task is completed.● This process is optional, so you can click Next to skip the comparison.● Compare common parameters:

– For common parameters, if the parameters in the service database aredifferent from those in the DR database, click Save Change to make theparameters of the DR database be the same as those in the servicedatabase.


– Performance parameter values in both the service and DR databases canbe the same or different.

▪ If you need to adjust the performance parameters, enter the value inthe Change to column and click Save Change.

▪ If you want to make the performance parameter values of the sourceand destination database be the same:

1) Click Use Source Database Value.DRS automatically makes the DR database values the same asthose of the service database.




NO TE

You can also manually enter the value as required.

2) Click Save Change.DRS changes the DR database parameter values based on yoursettings. After the modification, the comparison results areautomatically updated.Some parameters in the DR database cannot take effectimmediately, so the comparison result is temporarilyinconsistent. Restart the DR database before the DR task isstarted or after the DR task is completed. To minimize theimpact of database restart on your services, restart the DRdatabase at the scheduled time after the disaster recovery iscomplete.For details about parameter comparison, see Parameters forComparison in the Data Replication Service User Guide.

3) Click Next.



Starting a DR task may slightly affect the performance of the service and DRdatabases. You are advised to start a DR task during off-peak hours.

----End

Method 2








----End

7.3 Resuming a DR TaskA fault may occur during DR due to external factors, such as insufficient storagespace.

NO TE

● If the DR task fails due to non-network problems, the system will automatically resumethe task three times by default. If the failure persists, you can resume the task manually.

● If the DR task fails due to network problems, the system will automatically resume thetask until the task is restored.

● If a snapshot-based DR task fails, it cannot be resumed.

Prerequisites● You have logged in to the DRS console.● A failed DR task exists.

Method 1

In the task list on the Disaster Recovery Management page, locate the targettask and click Resume in the Operation column.

Method 2


Step 2 On the displayed page, click the Migration Progress tab, and click Resume in theupper left corner.

----End

7.4 Pausing a DR TaskYou can pause the DR tasks if they may cause buffer overflow or networkcongestion during peak hours.

Prerequisites● You have logged in to the DRS console.● The DR task is running properly.

Procedure

Step 1 In the task list on the Disaster Recovery Management page, locate the targettask and click Pause in the Operation column.




NO TE

● After the task is paused, the status of the task becomes Paused.

● After you select Pause log capturing, the DRS instance will no longer communicatewith the source and destination databases. If the pause duration is too long, the taskmay fail to be resumed because the logs required by the source database expire. It isrecommended that the pause duration be less than or equal to 24 hours.

● You can use the resumable transfer function to continue the DR task.

----End

7.5 Stopping a DR TaskWhen the DR task is complete or no longer needed, you can stop the DR task. Youcan stop a task in any of the following statuses:

● Creating● Configuration● Initializing● Disaster recovery in progress● Disaster recovery failed

NO TICE


● After a task is stopped, it cannot be reset.

Procedure

Step 1 In the task list on the Disaster Recovery Management page, locate the targettask and click Stop in the Operation column.


NO TE

Generally, stopping a task can ensure the integrity of special objects. In rare cases (forexample, network exceptions), a task may fail to be stopped. If a task fails to be stoppedmultiple times, you can select Forcibly stop task to reduce the wait time.

----End

7.6 Deleting a DR TaskYou can delete a DR task, when it is no longer needed Deleted tasks will no longerbe displayed in the task list. Exercise caution when performing this operation.



Prerequisites


Method 1

Step 1 In the task list on the Disaster Recovery Management page, locate the targettask and click Delete in the Operation column.


----End

Method 2

Step 1 In the task list on the Disaster Recovery Management page, select the targettasks and click Delete in the upper left of the DR task list.

Figure 7-7 Deleting DR tasks


----End

7.7 Resetting a DR TaskDuring the disaster recovery, the DR task may fail due to uncertain causes. Thissection describes how to reset the failed DR task.

You can reset the failed DR tasks in the following status:

● Initialization error● Disaster recovery failed

Prerequisites


Method 1

Step 1 In the task list on the Disaster Recovery Management page, locate the targettask and click Reset in the Operation column.

Step 2 In the displayed dialog box, check the DR task again.

Step 3 After the check is complete and the check success rate is 100%, click Start tosubmit the DR task again.

----End



Method 2

Step 1 On the Disaster Recovery Management page, click the target task in the TaskName/ID column.

Step 2 On the displayed page, click the Disaster Recovery Progress tab, and click Resetin the upper left corner.

Step 3 Perform Step 2 to Step 3.

----End

7.8 Viewing DR MetricsDRS monitors the DB instance performance and the migration progress. With themonitoring information, you can determine the link health status, data integrity,and data consistency. If both RPO and RTO are 0, data has been completelymigrated to the DR database. Then, you can determine whether to perform aswitchover.


Procedure


Step 2 On the Basic Information tab, click the Disaster Recovery Monitoring tab.● Recovery Point Objective (RPO) measures the consistency between the data in

the service database and the data in the DRS instance. When RPO is 0, all thedata in the service database has been migrated to the DRS instance.

● Recovery Time Objective (RTO) measures the amount of data beingtransmitted. When RTO is 0, all transactions on the DRS instance have beencompleted on the DR database.

● Lastest event time: It can be used as an auxiliary indicator for RPO analysis todetermine the actual RPO after a fault occurs. RPO = Service databasetimestamp – DRS receive timestamp

● Delay: Monitors the historical RPO and RTO, which helps predict the amountof lost data if a disaster occurs. You can pay attention to the following timeranges during which:– The RPO or RTO is high for a long time.– The RPO or RTO is consistently high or spiking high on a regular basis.

● Autonomy Management: Monitors the following DRS intelligent autonomycapabilities:– Number of times that DRS automatically resumes data transfer after a

network is disconnected– Number of times that DRS automatically overwrites old data with the

latest data when a data conflict occurs



● Performance: You can use performance monitoring to help diagnose thenetwork quality.

● Resource: You can use resource monitoring to help determine whether toscale up the DRS instance specifications.

Figure 7-8 DR monitoring

----End

7.9 Performing a Primary/Standby SwitchoverDRS supports primary/standby switchover for DR tasks. If both RPO and RTO are0, data has been completely migrated to the DR database. Then, you candetermine whether to perform a switchover.

● RPO measures the difference between the data in the service database andthe data in the DRS instance. When RPO is 0, all the data in the servicedatabase has been migrated to the DRS instance.

● RTO measures the amount of data being transmitted. When RTO is 0, alltransactions on the DRS instance have been completed on the DR database.


Procedure


Step 2 On the Basic Information tab, click the Disaster Recovery Monitoring tab.

Step 3 A primary/secondary switchover can be performed only when the task status isdisaster recovery in progress.

The DR relationship involves only one primary database. During a primary/secondary switchover, ensure that there is no data written to the database thatwill be the standby node, and no data will be written to the standby node in thefuture. The data of the standby node is synchronized only from the primary node.



Any other write operations will pollute the data in the standby database, dataconflicts occur in the DR center and cannot be resolved.● Method 1

Click Promote Current Cloud to promote the current instance to the servicedatabase. Click Demote Current Cloud to demote the current instance to thedisaster recovery database.

Figure 7-9 DR monitoring

● Method 2On Disaster Recovery Management page, select the task for which you wantto perform a primary/standby switchover and click Primary/StandbySwitchover in the upper left corner to switch over the service database to theDR database or switch over the DR database back to the service database.

----End

7.10 Modifying the Flow Control ModeDRS allows you to change the flow control mode for a task. Currently, onlydisaster recovery from MySQL to MySQL and MySQL to GaussDB(for MySQL)supports this function.

Prerequisites● You have logged in to the DRS console.● A disaster recovery task has been created and not started.

Method 1

Step 1 In the DR Information area on the Basic Information tab, click Modify next tothe Flow Control field.





----End

Method 2

Step 1 In the task list on the Disaster Recover Management page, locate the target taskand choose More > Speed or Speed in the Operation column.





----End

7.11 Batch OperationsDRS supports batch operation, making it easy for you to manage tasks. You canperform the following batch operations for real-time DR tasks:

● Delete

● Stop

● Pause

● Resume

● Primary/Standby Switchover

● Configure Exception Notification

Procedure

Step 1 On the Disaster Recovery Management page, select the tasks to be changed.



----End



7.12 Tag Management

Scenarios

Tag Management Service (TMS) enables you to use tags on the managementconsole to manage resources. TMS works with other cloud services to managetags. TMS manages tags globally, and other cloud services manage their own tags.● You are advised to set predefined tags on the TMS console.● A tag consists of a key and value. You can add only one value for each key.● Each DB instance can have up to 10 tags.

Adding a Tag








----End



Editing a Tag




----End

Delete a Tag





----End



8 Interconnecting with Cloud Eye

8.1 Supported Metrics

DescriptionThis section describes metrics reported by the Data Replication Service (DRS) toCloud Eye as well as their namespaces and dimensions. You can use APIs providedby Cloud Eye to query the metrics of the monitored object and alarms generatedfor DRS.

NamespaceSYS.DRS

DB Instance Monitoring MetricsTable 8-1 lists the DRS performance metrics.

Data Replication ServiceUser Guide 8 Interconnecting with Cloud Eye


Table 8-1 DRS performance metrics to be monitored

Metrics MetricsName

Description ValueRange

Monitored Object MonitoringInterval(RawData)

cpu_util CPUUsage

CPU usage of themonitored object

0-100%

Monitored object:ECSMonitored instancetype: replication,synchronization, andDR instances

1minute

mem_util MemoryUsage

Memory usage ofthe monitored object

0-100%


1minute

network_incoming_bytes_rate

NetworkInputThroughput

Incoming traffic inbytes per second

≥ 0bytes/s


1minute

network_outgoing_bytes_rate

NetworkOutputThroughput

Outgoing traffic inbytes per second

≥ 0bytes/s


1minute

disk_read_bytes_rate

DiskReadThroughput

Number of bytesread from the diskper second (bytes/second).

≥ 0bytes/s


1minute



Metrics MetricsName



disk_write_bytes_rate

DiskWriteThroughput

Number of byteswritten to the diskper second (bytes/second).

≥ 0bytes/s


1minute

disk_util StorageSpaceUsage

Storage space usageof the monitoredobject

0-100%


1minute

extract_bytes_rate

SourceDatabaseReadThroughput

Table data or WALbytes read from thesource database persecond

≥ 0bytes/s


1minute

extract_rows_rate

RowsReadfromSourceDatabase perSecond

Number of tabledata rows or WALrows read from thesource database persecond Unit: rows/s.

≥ 0row/s


1minute

extract_latency

SourceDatabaseWALExtractLag

Latency of extractingWAL from the sourcedatabase Unit: ms.

≥ms Monitored object:ECSMonitored instancetype: replication,synchronization, andDR instances

1minute



Metrics MetricsName



apply_bytes_rate

DestinationDatabaseWriteThroughput

Number of byteswritten to thedestination databaseper second.

≥ 0bytes/s


1minute

apply_rows_rate

RowsWritten intoDestinationDatabase perSecond

Number of rows thatare written to thedestination databaseper second Unit:rows/s.

≥ 0row/s


1minute

apply_transactions_rate

DMLTPS

Number of DMLtransactions writtento the destinationdatabase per second.

≥ 0transaction/s


1minute

apply_ddls_rate

DDLTPS

Number of DDLswritten to thedestination databaseper second.

≥ 0transaction/s


1minute

apply_latency

ReplicationDelay

Delay (inmilliseconds) of datasynchronization.

≥ 0ms


1minute



Metrics MetricsName



apply_average_execute_time

AverageTransactionExecutionTime

Average executiontime (RT = Executiontime + Commit time)of a transaction inthe destinationdatabase. The unit ismillisecond.

≥ 0ms


1minute

apply_average_commit_time

AverageTransactionCommit Time

Average committime (RT = Executiontime + Commit time)of a transaction inthe destinationdatabase. The unit isms.

≥ 0ms


1minute

apply_current_state

SynchronizationStatus

Data synchronizationstatus (0 or 10:abnormal; 1: idle; 2:DML; 3: DDL).

0 or10:abnormal1:idle2:DMLisexecuted.3:DDLisexecuted.


1minute

apply_thread_workers

SynchronizationThreads

Number of workingthreads for datasynchronization

≥ 0 Monitored object:ECSMonitored instancetype: replication,synchronization, andDR instances

1minute



Metrics MetricsName



apply_insert

NewDestinationDatabaseWriteVolume

Total number ofrows that have beenwritten to thedestination databasesince the start ofincrementalsynchronization


1minute

apply_update

UpdateDestinationDatabaseDefinitionQuantity

Total number ofrows that have beenupdated to thedestination databaseduring incrementalsynchronization


1minute

apply_delete

DeletedAmountfromtheDestinationDatabase

Total number ofrows that have beendeleted from thedestination databaseduring incrementalsynchronization


1minute

apply_insert_rate

Frequency ofAddingDestinationDatabaseData

Number of rows thatare added to thedestination databasein the last minute


1minute



Metrics MetricsName



apply_update_rate

DestinationDatabaseUpdateFrequency

Number of rows thatare updated to thedestination databasein the last minute


1minute

apply_delete_rate

Frequency ofDeletingDestinationDatabaseData

Number of rows thatare deleted from thedestination databasein the last minute


1minute

DimensionsKey Value

instance_id DRS instance ID

8.2 Setting Alarm Rules

ScenariosYou can set DRS alarm rules to customize the monitored objects and notificationpolicies and learn the DRS running status in a timely manner.

This section describes how to set DRS alarm rules, including the alarm rule name,service, dimension, monitoring scope, template, and whether to send anotification.



Procedure

Step 1 Log in to the management console.

Step 2 Under Management & Governance, click Cloud Eye.

Step 3 In the navigation pane on the left, choose Cloud Eye > Data Replication Service.

Figure 8-1 Choosing a monitored object

Step 4 Select the DB instance which you want to create an alarm rule for and clickCreate Alarm Rule in the Operation column.

Step 5 On the displayed page, set parameters as required.

Figure 8-2 Configuring alarm information

● Specify Name and Description.● Select Use template for Method. The template contains the following

common metrics: CPU usage, memory usage, and storage space usage.

● Click to enable alarm notification. The validity period is 24 hours bydefault. If the topics you required are not displayed in the drop-down list, clickCreate an SMN topic. Then, select Generated alarm and Cleared alarm forTrigger Condition.

NO TE

Cloud Eye sends notifications only within the validity period specified in the alarm rule.



Step 6 Click Create. The alarm rule is created.

For details about how to create alarm rules, see Creating an Alarm Rule in theCloud Eye User Guide.

----End

8.3 Viewing Monitoring Metrics

ScenariosCloud Eye monitors the running statuses of replication, synchronization, and DRinstances. You can obtain the monitoring metrics on the management console.Monitored data requires a period of time for transmission and display. The statusof the monitored object displayed on the Cloud Eye page is the status obtained 5to 10 minutes before. You can view the monitored data of a newly created DBinstance 5 to 10 minutes later.

PrerequisitesAn instance is running properly when in the following statuses:● Real-time migration: Full migration and Incremental migration● Real-time synchronization: Full synchronization and Incremental

synchronization● Real-time disaster recovery: Disaster recovery in progress

Viewing Metrics


Step 2 Click in the upper left corner and select a region and project.

Step 3 Choose Database > Data Replication Service. The Data Replication Servicepage is displayed.

Step 4 Take real-time migration as an example. On the Online Migration Managementpage, click the target migration task name in the Task Name/ID column.

Step 5 On the displayed page, click View Metric in the upper right corner of the page togo to the Cloud Eye console.

By default, the monitoring information about the DRS instance is displayed on thispage.

Step 6 View monitoring metrics of the instance.● On the Cloud Eye console, click the target DB instance name and click Select

Metric in the upper right corner. In the displayed dialog box, you can selectthe metrics to be displayed and sort them by dragging them at desiredlocations.

● You can sort graphs by dragging them based on service requirements.● Cloud Eye can monitor performance metrics from the last 1 hour, 3 hours, 12

hours, 1 day, 7 days, and 30 days.



https://support.huaweicloud.com/intl/en-us/usermanual-ces/en-us_topic_0084572213.html

Figure 8-3 Viewing monitoring metrics

----End



9 Interconnecting with CTS

9.1 Key Operations Recorded by CTSCloud Trace Service (CTS) provides records of operations on cloud serviceresources, enabling you to query, audit, and backtrack operations.

Table 9-1 DRS operations recorded by CTS

Operation Resource Type Trace Name

Creating a task job createJob

Editing a task job modifyJob

Deleting a task job deleteJob

Starting a task job startJob

Resuming a task job retryJob

9.2 Viewing TracesAfter CTS is enabled, CTS starts recording operations on cloud resources. The CTSmanagement console stores the last seven days of operation records.

This section describes how to query the operation records of the last seven dayson the CTS console.

Prerequisites

The CTS service has been enabled.

Procedure


Data Replication ServiceUser Guide 9 Interconnecting with CTS


Step 2 Click in the upper left corner of the page and select a region and project.

Step 3 Click Service List. Under Management & Governance, choose Cloud TraceService.

Step 4 Choose Trace List in the navigation pane on the left.

Step 5 Specify the filters used for querying traces. The following four filters are available:● Trace Source, Resource Type, and Search By

Select a filter from the drop-down list.When you select Trace name for Search By, you also need to select a specifictrace name.When you select Resource ID for Search By, you also need to select or entera specific resource ID.When you select Resource name for Search By, you also need to select orenter a specific resource name.

● Operator: Select a specific operator (a user rather than a tenant).● Trace Status: Available options include All trace statuses, normal, warning,

and incident. You can only select one of them.● Start time and end time: You can specify a time period for querying traces.

Step 6 Click on the left of the target record to extend its details.

Step 7 Click View Trace in the Operation column. A dialog box is displayed, on which thetrace structure details are displayed.

----End

Data Replication ServiceUser Guide 9 Interconnecting with CTS


10 Solutions to Failed Check Items

10.1 Disk Space

10.1.1 Checking Whether the Destination Database HasSufficient Storage Space

MySQL Migration

Table 10-1 Checking whether the destination database has sufficient storagespace

Check Item Whether the destination database has sufficient storagespace

Description Check whether the destination database has sufficientstorage space. If storage space is insufficient, the migrationwill fail.

Failure Causeand HandlingSuggestion

Failure cause: This item cannot be checked because thesource database fails to be connected.Handling suggestion: Check whether the source database isconnected.

Failure cause: Insufficient user permissionsHandling suggestion: Check whether the database userpermissions meet the migration requirements.

Data Replication ServiceUser Guide 10 Solutions to Failed Check Items


Failure cause: The destination database does not havesufficient storage space. The destination database musthave at least * GB of free space.Handling suggestion: Scale up or clean up the destinationdatabase storage space. If you clean up the storage space,you will obtain more space within 2 to 3 minutes.NOTE

It is recommended that the size of the destination database disk beset to the smaller value of the following two values:1. 2.5 times the size of the data to be migrated in the source

database.2. The size of the data to be migrated in the source database plus

200 GB.

Failure cause: An internal error occurs.Handling suggestion: Contact Huawei technical support.

PostgreSQL Migration









200 GB.




MongoDB Database Migration









200 GB.


10.1.2 Checking Whether the Destination Server HasSufficient Storage Space

Table 10-4 Checking whether the destination server has sufficient storage space

CheckItem

Whether the destination server has sufficient storage space

Description

If the destination server's storage space is insufficient, the migrationwill fail.



FailureCauseandHandlingSuggestion

Failure cause: The amount of data in the source database is greaterthan the remaining storage space of the destination server.Handling suggestion: Modify the synchronization object.

10.2 Database Parameters

10.2.1 Checking Whether the Source Database Binlog IsEnabled

MySQL Migration

Table 10-5 Checking whether the source database binlog is enabled

Check Item Whether the source database binlog is enabled

Description Check whether binlog is enabled for the source database.



Failure cause: Insufficient user permissionsHandling suggestion: Check whether the database userpermissions meet the migration requirements.NOTE

For details about the MySQL permissions and authorizationoperations required by DRS, see Which MySQL Permissions AreRequired for DRS?






Failure cause: The binlog function is disabled on the sourcedatabase.Handling suggestion:● If the source is an on-premises database, perform the

following operations to enable binlog.1. Run the following command to check whether binlog

is enabled:show variables like "log_bin"\G;

2. If binlog is disabled, add log-bin = mysql-binfollowed by [mysqld] in the MySQL configuration filemy.cnf or my.ini.

3. Restart the database.

● If the source database is a cloud RDS DB instance,contact technical support.

10.2.2 Checking Whether the Source Database Binlog Is Row-Based

MySQL Migration

Table 10-6 Checking whether the source database binlog is row-based

Check Item Whether the source database binlog is row-based

Description Check whether the source database binlog is row-based.






Failure cause: The source database binlog is not row-based.Handling suggestion:● If the source database is an on-premises database,

perform the following operations to change the binlogformat of the source database:Method 1: You can modify the my.cnf or my.iniconfiguration file and restart the database.binlog_format=row

Method 2: Stop all service connections.set global binlog_format='ROW'

Modify the my.cnf or my.ini configuration file.binlog_format=row

In the ROW format, the log growth rate increases, whichmay occupy more disk space.NOTE

The MySQL Global binlog_format parameter does not takeeffect for connected sessions. For details, see How Do I SetGlobal binlog_format=ROW to Take Effect Immediately?

● If the source database is an RDS DB instance on thecloud, change the binlog_format value of the sourcedatabase to ROW. After the change, restart thedatabase for the change to take effect.NOTE

The MySQL Global binlog_format parameter does not takeeffect for connected sessions. For details, see How Do I SetGlobal binlog_format=ROW to Take Effect Immediately?


10.2.3 Checking Whether the Binlog Retention Period Is Seton the Source Database

MySQL Migration

Table 10-7 Checking whether the binlog retention period is set on the sourcedatabase

Check Item Whether the binlog retention period is set on the sourcedatabase

Description Checking whether the binlog retention period is set on thesource database. You are advised to store the sourcedatabase binlog for a longer time, if the storage space issufficient.








Failure cause: The binlog retention period is not set on thesource database.Handling suggestion:Log in to the source database and run the following SQLstatement to set the retention period of binlog:call mysql.rds_set_configuration('binlog retention hours', n);

The value n indicates an integer from 1 to 168.

10.2.4 Checking Whether the Source and DestinationDatabase Character Sets Are Consistent

MySQL Migration

Table 10-8 Checking whether the source and destination database character setsare consistent

Check Item Whether the source and destination database character setsare consistent

Description Check whether the character sets of the servers hosting thesource and destination databases are consistent.



Failure cause: This item cannot be checked because thedestination database fails to be connected.Handling suggestion: Check whether the destinationdatabase is connected.




Failure cause: The character set of the source database isinconsistent with that of the destination database.Handling suggestion: Modify the character sets.Run commands to modify the self-created source database.1. Check whether source and destination database character

sets are consistent.show variables like "character_set_server"\G;

2. Modify the character set of the source database server.set character_set_server='utf8';


MySQL -> PostgreSQL Synchronization

Table 10-9 Checking whether the source and destination database character setsare consistent

Check Item Whether the source and destination database character setsare consistent

Description Check whether the character sets of the servers hosting thesource and destination databases are consistent.


Failure cause: The character set of the source database isinconsistent with that of the destination database.Handling suggestion: Change the character setcharacter_set_server of the source database to the same asthat of the destination database, or change the characterset server_encoding of the destination database to thesame as that of the source database.



10.2.5 Checking Whether the Source Database server_idMeets the Incremental Migration Requirements

MySQL

Table 10-10 Checking whether the source database server_id meets theincremental migration requirements

Check Item Whether the source database server_id meets theincremental migration requirements

Description Check whether the source database server_id meets theincremental migration requirements.


Failure cause: This item cannot be checked because thesource database failed to be connected.Handling suggestion: Check whether the source database isconnected.


Failure cause: The source database server_id does not meetthe incremental migration requirements.Handling suggestion:Run the following command to modify the server_id value:set global server_id=nThe value n indicates the source database server_id. If thesource database version is MySQL 5.6, the value n rangesfrom 2 to 4294967296. Otherwise, the value n ranges from1 to 4294967296.


10.2.6 Checking Whether the Source and DestinationDatabase Table Names Are Consistent in Case Sensitivity

MySQL Migration

Table 10-11 Checking whether the source and destination database table namesare consistent in case sensitivity

Check Item Whether the source and destination database table namesare consistent in case sensitivity



Description Check whether the source and destination database namesand table names are consistent in case sensitivity.




Failure cause: The lower_case_table_names values in thesource and destination databases must be the same.Handling suggestion:● If you are migrating data out of the cloud, change the

values of lower_case_table_names in the source anddestination databases to the same.You are advised to change the parameter value in anempty database. For example, if the destination RDS DBinstance is empty, run the following example commandto change the lower_case_table_names value to thesame as that in the source database: Sample command:set global lower_case_table_names=n;

In the preceding command, n indicates the parametervalue of the source database. After the modification,restart the database for the modification to take effect.

● If you are migrating data out of the cloud, perform thefollowing operations:If the destination database is a self-built database,modify the lower_case_table_names parameter of thedestination database. Add lower_case_table_names=nunder the [mysqld] tag in the MySQL configuration filemy.cnf. n indicates the value of parameter samelower_case_table_names of the source database. Thedatabase must be restarted to make the change takeeffect.If the destination database is a cloud database, checkwhether the lower_case_table_names parameter can bemodified. If not, contact Huawei technical support.

Failure cause: The lower_case_table_names parametervalue of the destination database is different from that ofthe source database, and the source database containsuppercase database and table names.Handling suggestion: Rectify the fault by referring to FAQs.

Failure cause: The database is unavailable.Handling suggestion: Contact Huawei technical support.





MySQL->MySQL, MySQL->Gauss(for MySQL) and Gauss(for MySQL) toMySQL Synchronization

Table 10-12 Checking whether the source and destination database table namesare consistent in case sensitivity

CheckItem

Whether the source and destination database table names areconsistent in case sensitivity

Description

The destination database is case insensitive. The names of the mappeddatabases and tables contain uppercase letters. If the destinationdatabase is case-insensitive, all uppercase letters are converted tolowercase letters for storage.


Failure cause: The destination database is case insensitive. Alluppercase letters are converted to lowercase letters for storage. Thenames of the mapped databases and tables contain uppercase letters.Handling suggestion: If the mapping relationship is correct, change thedatabase and table names that contain uppercase letters to lowercaseletters.

10.2.7 Checking Whether the Source Database GTID IsEnabled

MySQL

Table 10-13 Checking whether the source database GTID is enabled

Check Item Whether the source database GTID is enabled

Description The source database GTID must be enabled.



Item to BeConfirmed andHandlingSuggestion

Item to be confirmed: The source database GTID isdisabled. To recover faulty migration tasks and destinationdatabases more securely and efficiently, you are advised toenable GTID. Note that switching primary and standby DBinstances may lead to the failure of the migration task.Handling suggestion:● If the source database version is MySQL 5.5, ignore this

alarm.● If the source database version is MySQL 5.6 and later, set

the following parameters to enable GTID in the databaseconfiguration file. Then, restart the database for themodifications to take effect.gtid_mode = onlog_slave_updates = trueenforce_gtid_consistency = on

10.2.8 Checking Whether the Source Database ContainsObject Names with Non-ASCII Characters

MySQL

Table 10-14 Checking whether the source database contains object names withnon-ASCII characters

Check Item Whether the source database contains object names withnon-ASCII characters

Description If the source database contains object names with non-ASCII characters, the migration will fail.

Failure Cause andHandlingSuggestion

Failure cause: The source database cannot contain objectnames with non-ASCII characters.Handing suggestion: In the source database, change theobject names containing non-ASCII characters.

10.2.9 Checking Whether the Source and DestinationDatabase TIME_ZONE Values Are Consistent

MySQL

Table 10-15 Checking whether the TIME_ZONE values of the source anddestination databases are the same

Check Item Whether the TIME_ZONE values of the source anddestination databases are the same



Description The migration fails because the TIME_ZONE values of thesource and destination databases are different.


Failure cause: The TIME_ZONE or SYSTEM_TIME_ZONEvalues of the source and destination databases must be thesame.Handling suggestion: Change the TIME_ZONE value of thedestination database to the same as that of the sourcedatabase, or change the TIME_ZONE value of the sourcedatabase to the same as that of the destination database.

10.2.10 Checking Whether the COLLATION_SERVER Values ofthe Source and Destination Databases Are the Same

MySQL

Table 10-16 Checking whether the COLLATION_SERVER values of the source anddestination databases are the same

Check Item Whether the COLLATION_SERVER values of the source anddestination databases are the same

Description The migration fails because the COLLATION_SERVER valuesof the source and destination databases are different.


Failure cause: The COLLATION_SERVER values of thesource and destination databases must be the same.Handling suggestion: Change COLLATION_SERVER of thesource and destination databases to the same value.

10.2.11 Checking Whether the SERVER_UUID Values of theSource and Destination Databases Are the Same

MySQL Migration

Table 10-17 Checking whether the SERVER_UUID values of the source anddestination databases are the same

Check Item Whether the SERVER_UUID values of the source anddestination databases are the same

Description If the SERVER_UUID values of the source and destinationdatabases are the same, the migration fails.




Failure cause: The SERVER_UUID values of the source anddestination databases must be different.Handling suggestion: Check that the source and destinationdatabases are not the same MySQL database.

10.2.12 Checking Whether the SERVER_ID Values of theSource and Destination Databases Are Different

MySQL

Table 10-18 Checking whether the SERVER_ID values of the source anddestination databases are different

Check Item Whether the SERVER_ID values of the source anddestination databases are different

Description Check whether the SERVER_ID values of the source anddestination databases are different. If they are the same,the migration fails.


Failure cause: The SERVER_ID values of the source anddestination databases must be different.Handling suggestion: Change SERVER_ID of the source anddestination databases to different values.

10.2.13 Checking Whether the Source Database ContainsInvalid sql_mode Values

MySQL

Table 10-19 Checking whether the source database contains invalid sql_modevalues

Check Item Whether the source database contains invalid sql_modevalues

Description If the source database contains invalid sql_mode values,the migration will fail.


Failure cause: The sql_mode value of the source databasecannot be no_engine_substitution.Handling suggestion: Change sql_mode of the sourcedatabase to a proper value.



10.2.14 Checking Whether the SQL_MODE Values of theSource and Destination Databases Are the Same

MySQL

Table 10-20 Checking whether the SQL_MODE values of the source anddestination databases are the same

Check Item Whether the SQL_MODE values of the source anddestination databases are the same

Description Check whether the SQL_MODE values of source anddestination databases are the same. If they areinconsistent, the migration may fail.


● If you are migrating data to the cloud, perform thefollowing operations:Failure cause: The SQL_MODE values of the sourceand destination databases must be the same.Handling suggestion: Change the SQL_MODE valuesof the destination database to the same as those ofthe source database, Ensure that both the source anddestination databases do not have the forbiddenSQL_MODE values. For details, see ModifyingParameters. If MyISAM tables are to be migrated, theSQL_MODE values in the destination database cannotcontain NO_ENGINE_SUBSTITUTION.

● If you are migrating data out of the cloud, performthe following operations:Item to be confirmed: The SQL_MODE values of thesource and destination databases must be the same.Handling suggestions: Change the SQL_MODE valuesof the destination database to the same as those ofthe source database. Ensure that both the source anddestination databases do not have the forbiddenSQL_MODE values.

10.2.15 Checking Whether the sql_mode Value in theDestination Database Is Not NO_ENGINE_SUBSTITUTION

MySQL Migration and Synchronization

Table 10-21 Checking whether the sql_mode value in the destination database isnot NO_ENGINE_SUBSTITUTION

Check Item Whether the sql_mode value in the destination database isnot NO_ENGINE_SUBSTITUTION



https://support.huaweicloud.com/intl/en-us/usermanual-rds/rds_configuration.html


Description MyISAM tables are included in the migration objects. Thesql_mode value in the destination database cannot beNO_ENGINE_SUBSTITUTION.


Failure cause: The sql_mode value in the destinationdatabase is NO_ENGINE_SUBSTITUTION.Handling suggestion: In the destination database, setSQL_MODE to a value other thanNO_ENGINE_SUBSTITUTION. For details, see sectionModifying Parameters in the Relational Database ServiceUser Guide.

10.2.16 Checking Whether the innodb_strict_mode Values ofthe Source and Destination Databases Are the Same

MySQL Migration

Table 10-22 Checking whether the innodb_strict_mode values of the source anddestination databases are the same

Check Item Whether the innodb_strict_mode values of the sourceand destination databases are the same

Description Check whether the innodb_strict_mode values of sourceand destination databases are the same. If they areinconsistent, the migration may fail.


● If you are migrating data to the cloud, perform thefollowing operations:Failure cause: The innodb_strict_mode values of thesource and destination databases must be the same.Handling suggestion: Create a parameter group forthe destination database and changeinnodb_strict_mode to the same value as that of thesource database. For details, see the Creating aParameter Group section in the Relational DatabaseService User Guide.

● If you are migrating data out of the cloud, performthe following operations:Failure cause: The innodb_strict_mode values of thesource and destination databases must be the same.Handling suggestion: Change innodb_strict_mode ofthe destination database to the same value as that ofthe source database.




https://support.huaweicloud.com/intl/en-us/usermanual-rds/en-us_topic_parameter_group.html

https://support.huaweicloud.com/intl/en-us/usermanual-rds/en-us_topic_parameter_group.html

10.2.17 Checking Whether the max_connections Value of theDestination Database Is Large Enough

PostgreSQL

Table 10-23 Checking whether the max_connections value of the destinationdatabase is large enough

Check Item Whether the max_connections value of the destinationdatabase is large enough

Description If the max_connections value of the destination databaseis smaller than that of the source database, the migrationmay fail.


Failure cause: The max_connections value of thedestination database must be equal to or greater thanthat of the source database.Handling suggestion: Change themax_locks_per_transaction value of the source ordestination database to ensure that the value of thedestination database is equal to or greater than that ofthe source database. After the migration is complete,restore the parameter to its original value.

10.2.18 Checking Whether the max_worker_processes Value ofthe Destination Database Is Large Enough

PostgreSQL

Table 10-24 Checking whether the max_worker_processes value of the destinationdatabase is large enough

Check Item Whether the max_worker_processes value of thedestination database is large enough

Description If the max_worker_processes value of the destinationdatabase is smaller than that of the source database, themigration may fail.




Failure cause: The max_worker_processes value of thedestination database must be equal to or greater thanthat of the source database.Handling suggestion: Change themax_locks_per_transaction value of the source ordestination database to ensure that the value of thedestination database is equal to or greater than that ofthe source database. After the migration is complete,restore the parameter to its original value.

10.2.19 Checking Whether the max_prepared_transactionsValue of the Destination Database Is Large Enough

PostgreSQL

Table 10-25 Checking whether the max_prepared_transactions value of thedestination database is large enough

Check Item Whether the max_prepared_transactions value of thedestination database is large enough

Description If the max_prepared_transactions value of thedestination database is smaller than that of the sourcedatabase, the migration may fail.


Failure cause: The max_prepared_transactions value ofthe destination database must be equal to or greaterthan that of the source database.Handling suggestion: Change themax_locks_per_transaction value of the source ordestination database to ensure that the value of thedestination database is equal to or greater than that ofthe source database. After the migration is complete,restore the parameter to its original value.

10.2.20 Checking Whether the max_locks_per_transactionValue of the Destination Database Is Large Enough

PostgreSQL

Table 10-26 Checking whether the max_locks_per_transaction value of thedestination database is large enough

Check Item Whether the max_locks_per_transaction value of thedestination database is large enough



Description If the max_locks_per_transaction value of thedestination database is smaller than that of the sourcedatabase, the migration may fail.


Failure cause: The max_locks_per_transaction value ofthe destination database must be equal to or greaterthan that of the source database.Handling suggestion: Change themax_locks_per_transaction value of the source ordestination database to ensure that the value of thedestination database is equal to or greater than that ofthe source database. After the migration is complete,restore the parameter to its original value.

10.2.21 Checking Whether the max_wal_senders Value of theSource Database Is Correctly Configured

PostgreSQL

Table 10-27 Checking whether the max_wal_senders value of the source databaseis correctly configured

Check Item Whether the max_wal_senders value of the sourcedatabase is correctly configured

Description The max_wal_senders value of the source database mustbe greater than 0. Otherwise, the migration may fail.


Failure cause: The values of max_wal_senders of thesource database must be greater than 0.Handling suggestion: In the postgresql.confconfiguration file, set max_wal_senders to a valuegreater than 0 and restart the database for themodification to take effect.





10.2.22 Checking Whether the wal_level Value of the SourceDatabase Is Correctly Configured

PostgreSQL

Table 10-28 Checking whether the wal_level value of the source database iscorrectly configured

Check Item Whether the wal_level value of the source database iscorrectly configured

Description The migration fails because the wal_level value of thesource database is incorrect.


Failure cause: The wal_level value in the source databaseis incorrect.Handling suggestion: The wal_level value must behot_standby when the source database version isPostgreSQL 9.5 and must be replica when the sourcedatabase version is PostgreSQL 9.6. In the postgresql.confconfiguration file, change the wal_level valuecorrespondingly and restart the database for themodification to take effect.



10.2.23 Checking Whether the max_replication_slots Value ofthe Source Database Is Correctly Configured

PostgreSQL

Table 10-29 Checking whether the max_replication_slots value of the sourcedatabase is correctly configured

Check Item Whether the max_replication_slots value of the sourcedatabase is correctly configured

Description The max_replication_slots value of the source databasemust be greater than 0. Otherwise, the migration mayfail.




Failure cause: The values of max_replication_slots of thesource database must be greater than 0.Handling suggestion: In the postgresql.confconfiguration file, set max_replication_slots to a valuegreater than 0 and restart the database for themodification to take effect.



10.2.24 Checking Whether the hot_standby Value of theSource Database Is Correctly Configured

PostgreSQL

Table 10-30 Checking whether the hot_standby value of the source database iscorrectly configured

Check Item Whether the hot_standby value of the source database iscorrectly configured

Description The hot_standby value of the source database must beset to on. Otherwise, the migration may fail.


Failure cause: The hot_standby value of the sourcedatabase must be set to on.Handling suggestion: In the postgresql.confconfiguration file, set hot_standby to on and restart thedatabase for the modification to take effect.





10.2.25 Checking Whether the full_page_writes Value of theSource Database Is Correctly Configured

PostgreSQL

Table 10-31 Checking whether the full_page_writes value of the source databaseis correctly configured

Check Item Whether the full_page_writes value of the sourcedatabase is correctly configured

Description The full_page_writes value of the source database mustbe set to on. Otherwise, the migration may fail.


Failure cause: The full_page_writes value of the sourcedatabase must be set to on.Handling suggestion: In the postgresql.confconfiguration file, set full_page_writes to on and restartthe database for the modification to take effect.



10.2.26 Checking Whether the wal_keep_segments Value ofthe Source Database Is Correctly Configured

PostgreSQL

Table 10-32 Checking whether the wal_keep_segments value of the sourcedatabase is correctly configured

Check Item Whether the wal_keep_segments value of the sourcedatabase is correctly configured

Description The migration will fail if the wal_keep_segments valueof the source database is too small.


Failure cause: The wal_keep_segments value is too small.Handling suggestion: Set wal_keep_segments to a valuegreater than or equal to n (n = Source database size x5%/16). If the source database is busy, increase the valuen accordingly.



Failure cause: The wal_keep_segments parameter in thesource database cannot be checked because the sourcedatabase size failed to be obtained.Handling suggestion: Contact Huawei technical support.



10.2.27 Checking Whether the log_slave_updates Value of theSource Database Is Correctly Configured

MySQL Migration, Synchronization, and Disaster Recovery

Table 10-33 Checking whether the log_slave_updates value of the sourcedatabase is correctly configured

Check Item Whether the log_slave_updates value of the sourcedatabase is correctly configured

Description The migration will fail if the log_slave_updatesparameter of the source database is disabled.


Failure cause: The slave_updates_check parameter of thesource database must be enabled.Handling suggestion: In the MySQL configuration filemy.cnf, add the "log_slave_updates=1" line under[mysqld] and restart the database for the modification totake effect.

Failure cause: The source database is a standby databaseand the log_slave_updates value is OFF.Handling suggestion: On the source database, setlog_slave_updates to ON. Then, restart the database forthe modification to take effect.


Item to be confirmed: The source database is a standbydatabase and the log_slave_updates value is OFF.Handling suggestion: On the source database, setlog_slave_updates to ON. Then, restart the database forthe modification to take effect. If no switchover orfailover will occur, no operation is required.



10.2.28 Checking Whether the WAL_BLOCK_SIZE Value of theSource Database Is the Same As That of the DestinationDatabase

PostgreSQL

Table 10-34 Checking whether the WAL_BLOCK_SIZE value of the source databaseis the same as that of the destination database

Check Item Whether the WAL_BLOCK_SIZE value of the sourcedatabase is the same as that of the destination database

Description If the WAL_BLOCK_SIZE value of the source database is notthe same as that of the destination database, the migrationwill fail.


Failure cause: The WAL_BLOCK_SIZE value of the sourcedatabase must be the same as that of the destinationdatabase.Handling suggestion: The WAL_BLOCK_SIZE parameter isconfigured when the PostgreSQL database is installed usingthe source code. This parameter value cannot be changedafter being configured. Use another PostgreSQL databasethat has the same WAL_BLOCK_SIZE value as thedestination database or use the officially compiled binarypackage.

10.2.29 Checking Whether the BLOCK_SIZE Value of theSource Database Is the Same as That of the DestinationDatabase

PostgreSQL

Table 10-35 Checking whether the BLOCK_SIZE value of the source database isthe same as that of the destination database

Check Item Whether the BLOCK_SIZE value of the source database isthe same as that of the destination database

Description If the BLOCK_SIZE value of the source database is not thesame as that of the destination database, the migration willfail.




Failure cause: The BLOCK_SIZE value of the sourcedatabase must be the same as that of the destinationdatabase.Handling suggestion: Use another PostgreSQL databasethat has the same BLOCK_SIZE value as the destinationdatabase or use the officially compiled binary package.

10.2.30 Checking Whether the binlog_row_image Value isFULL

MySQL

Table 10-36 Checking whether the binlog_row_image value is FULL

Check Item Whether the binlog_row_image value is FULL

Description If the binlog_row_image value of the source database isnot FULL, the migration will fail.


Failure cause: The binlog_row_image value of the sourcedatabase is not FULL.Handling suggestion:● If the source database is an RDS DB instance on the

cloud, change binlog_row_image to FULL on the RDSconsole, and then restart the source database.

● If the source database is an on-premises database,perform the following steps:1. Log in to the server where the MySQL source

database is located.2. Manually change the value of binlog_row_image in

the my.cnf configuration file to FULL and save thefile.binlog_row_image=full

3. To ensure a successful task, restart the sourcedatabase during off-peak hours.



10.2.31 Checking Whether the Transaction Isolation Levels areConsistent

MySQL

Table 10-37 Checking whether the transaction isolation levels are consistent

CheckItem

Whether the transaction isolation levels are consistent

Description

Check whether the transaction isolation levels of the source anddestination databases are the same.


If you are migrating data to the cloud, perform the followingoperations:Failure cause: The transaction isolation levels of the source anddestination databases are different.Handling suggestion: Change the isolation level (tx_isolation ortransaction_isolation) of the destination database to be the same asthat of the source database.

10.2.32 Checking Whether the lc_monetary Values of theSource and Destination Databases Are the Same

PostgreSQL

Table 10-38 Checking whether the lc_monetary values of the source anddestination databases are the same

Check Item Whether the lc_monetary values of the source anddestination databases are the same

Description Check whether the lc_monetary values of the source anddestination databases are the same. If they are inconsistent,the migration fails.



Failure cause: This item cannot be checked because thedestination database failed to be connected.Handling suggestion: Check whether the destinationdatabase is connected.



Failure cause: The lc_monetary values of the source anddestination databases must be the same.Handling suggestion: Check whether the lc_monetaryvalues of the source and destination databases meet themigration requirements.



10.2.33 Checking Whether the Source Database ContainsTrigger Names with Non-ASCII Characters

MySQL

Table 10-39 Checking whether the source database contains trigger names withnon-ASCII characters

Check Item Whether the source database contains trigger names with non-ASCII characters

Description If the source database contains non-ASCII characters, themigration will fail.

Item to BeConfirmedandHandlingSuggestion

Item to be confirmed: The source database cannot contain viewnames with non-ASCII characters.Handling suggestion: To solve this problem, perform thefollowing steps:Method 1:Click Previous to return to the Select Migration Type page.Select a customized object and do not select the trigger namethat contains non-ASCII characters.Method 2: Change the trigger name.



10.2.34 Checking Whether the wal_level Value in the SourceDatabase Is Logical

PostgreSQL

Table 10-40 Checking whether the wal_level value in the source database islogical

Check Item Whether the wal_level value in the source database is logical

Description The wal_level value must be hot_standby when the sourcedatabase version is PostgreSQL 9.5, replica for PostgreSQL9.6, and logical for synchronization tasks.


Failure cause: The wal_level value in the source databasemust be logical.Handling suggestion: Change the wal_level value to logicalin the postgresql.conf configuration file and restart thedatabase for the change to take effect.

10.2.35 Checking Whether the wal_level Value in the SourceDatabase Is Logical

PostgreSQL

Table 10-41 Checking whether the wal_level value in the source database islogical

Check Item Whether the wal_level value in the source database is logical

Description The wal_level value must be hot_standby when the sourcedatabase version is PostgreSQL 9.5, replica for PostgreSQL9.6, and logical for synchronization tasks.


Failure cause: The wal_level value in the source databasemust be logical.Handling suggestion: Change the wal_level value to logicalin the postgresql.conf configuration file and restart thedatabase for the change to take effect.



10.2.36 Checking Whether the max_replication_slots Value ofthe Source Database Is Correct

PostgreSQL

Table 10-42 Checking whether the max_replication_slots value of the sourcedatabase is correct

Check Item Whether the max_replication_slots value of the sourcedatabase is correct

Description Check whether the value of max_replication_slots of thesource database is correct. If the value is incorrect, themigration fails.

Failure CauseandHandlingSuggestion

Failure cause: The max_replication_slots value of the sourcedatabase is incorrect.Handling suggestion: In the postgresql.conf configuration file,change max_replication_slots to a value greater than the usedreplication_slot value and restart the database for the changeto take effect.

10.2.37 Checking Whether the Source Database CollectionsContain More Than 10 Indexes

MongoDB Database

Table 10-43 Checking whether the source database collections contain more than10 indexes

Check Item Whether the source database collections contain more than10 indexes

Description If the number of indexes in the source database exceeds 10,the migration duration is affected.


Alarm cause: The source database has collections containingmore than 10 indexes, which are migrated slowly.Handling suggestion: The number of indexes affects themigration duration. Check whether all indexes need to bemigrated. If the index does not need to be migrated, deletethe index before starting the migration.Run the following command to delete the index:run the db.Collection name.dropIndex(Index name)



10.2.38 Checking Whether the Source Database CollectionsContain TTL Indexes

MongoDB Database

Table 10-44 Checking whether the source database collections contain TTLindexes

Check Item Whether the source database collections contain TTLindexes

Description Due to inconsistency of time zones and clocks betweensource and destination databases, migrating TTL indexes willcause data inconsistency.


Item to be confirmed: Due to inconsistency of time zonesand clocks between source and destination databases,migrating TTL indexes will cause data inconsistency.Handling suggestion: If data consistency is required, deleteTTL indexes. Alternatively, do not migrate the collectionscontaining TTL indexes.Run the following command to delete the index:run the db.Collection name.dropIndex(Index name)

10.2.39 Checking Whether log_bin_trust_function_creators IsSet to On in Both the Source and Destination Databases

MySQL

Table 10-45 Checking whether log_bin_trust_function_creators is set to on in boththe source and destination databases

CheckItem

Whether log_bin_trust_function_creators is set to on in both the sourceand destination databases

Description

During the out-of-cloud migration from MySQL to MySQL, thelog_bin_trust_function_creators value of the source database must bethe same as that of the destination database. If the source databasesupports user-defined functions (UDFs) but the destination databasedoes not, change the log_bin_trust_function_creators=off parameterof the destination database to log_bin_trust_function_creators=on. Ifthe parameters of the source and destination are different, themigration may fail.



Itemto BeConfirmedandHandlingSuggestion

Item to be confirmed: The destination database does not supportcustom functions.Handling suggestions: In the my.cnf file of the destination database,check whether log_bin_trust_function_creators=on exists. If it doesnot exist, add log_bin_trust_function_creators=on and restart thedatabase for the modification to take effect.

10.2.40 Checking Whether GTID Is Enabled for the SourceDatabase

MySQL

Table 10-46 Checking whether GTID is enabled for the source database

Check Item Whether GTID is enabled for the source database

Description During disaster recovery, GTID should be enabled for thesource database. Otherwise, the migration fails.


Failure cause: GTID is disabled for the source databaseHandling suggestion: In the configuration file of the sourcedatabase, set parameters as followings. Then, restart thesource database for the modifications to take effect.Parameters to be configured:gtid_mode = on;log_slave_updates = true; enforce_gtid_consistency = on;

10.2.41 Checking Whether GTID Is Enabled for the DestinationDatabase

MySQL Disaster Recovery

Table 10-47 Checking whether GTID is enabled for the destination database

Check Item Whether GTID is enabled for the destination database

Description During disaster recovery, GTID should be enabled for thedestination database. Otherwise, the migration fails.




Failure cause: GTID is disabled for the destination databaseHandling suggestion: Check that the destination databasebinlog is enabled. Modify the parameter settingsconfiguration file as follows to enable the destinationdatabase GTID, and then restart the databaseSample command:gtid_mode = on;log_slave_updates = true; enforce_gtid_consistency = on;

Sample command:log-bin = mysql-binbinlog_gtid_simple_recovery = on.

10.2.42 Checking Whether log_bin_trust_function_creators IsSet to On in the Destination Database

MySQL

Table 10-48 Checking whether log_bin_trust_function_creators is set to on in thedestination database

Check Item Whether log_bin_trust_function_creators is set to on in thedestination database

Description During the migration from RDS for MySQL to MySQL out ofthe cloud, the destination database does not support customfunctions.


Failure cause: The destination database does not supportcustom functions.Handling suggestions: In the my.cnf file of the destinationdatabase, check whetherlog_bin_trust_function_creators=on exists. If it does notexist, add log_bin_trust_function_creators=on and restartthe database for the modification to take effect.



10.2.43 Checking Whether the Values in the Source OracleDatabase Are Out of the Ranges of the MySQL Database

Oracle Migration

Table 10-49 Checking whether the values in the source Oracle database are out ofthe ranges of the MySQL database

Check Item Whether the values in the source Oracle database are out ofthe ranges of the MySQL database

Description The values of the following data types in the source Oracledatabase are out of the ranges of the MySQL database,causing the migration failure.


Alarm Information1. Ensure that the primary key or unique key column cannot

contain values of character string data types when you mapthe MySQL data types to the character data types in Oracle.Otherwise, data inconsistency or migration failure mayoccur.

2. Due to differences between Oracle and MySQL databases,the migration will fail if the values of the following datatypes in the source Oracle database are out of the ranges ofMySQL database: number, intl, float, double, date, andtimestamp.

Handling suggestion: Contact technical support.

10.2.44 Checking Whether the max_allowed_packet Value ofthe Destination Database Is too Small

MySQL

Table 10-50 Checking whether the max_allowed_packet value of the destinationdatabase is too small

Check Item Whether the max_allowed_packet value of the destinationdatabase is too small

Description A large amount of data cannot be written to thedestination database during the migration because themax_allowed_packet value is smaller than 100 MB. As aresult, the full migration failed.




Failure cause: The max_allowed_packet value of thedestination database is too small, which may cause datafails to be written during the migration.Handling suggestions: Set the max_allowed_packet valuegreater than 100 MB

10.2.45 Checking Whether the Source Database User Has thePermission to Parse Logs

Oracle -> MySQL Migration

Table 10-51 Checking whether the source database user has the permission toparse logs

CheckItem

Whether the source database user has the permission to parse logs

Description

If the source database user does not have the log parsing permission,the incremental migration will fail.


Failure cause: The source database user does not have theEXECUTE_CATALOG_ROLE role.Handling suggestion: Assign the required role to the user and performthe check again. Run the GRANT EXECUTE_CATALOG_ROLE TOUserName command to assign the role.

Failure cause: The source database user does not have the log parsingpermission.Handling suggestion: Assign the required role to the user and performthe check again. Run the GRANT LOGMINING TO UserNamecommand to grant the permission.

10.2.46 Checking Whether the ExpireLogsDays Value Is 0

MySQL Synchronization and Disaster Recovery

Table 10-52 Checking whether the expirelogsdays value is 0

CheckItem

Whether the expirelogsdays value is 0

Description

If the expire_logs_days value of the source database is set to 0, themigration may fail.




Failure cause: If expire_logs_days is set to 0 in the source database,operations such as startup and flush logs will trigger binlog clearanceand result in a migration failure.Handling suggestion: Set the binlog storage duration by running thefollowing command on the client: set global expire_logs_days=value(value indicates an integer greater than 0.)

10.2.47 Checking Whether the Source Database Character SetIs Supported

Oracle -> MySQL/Oracle -> PostgreSQL/Oracle-> GaussDB(for MySQL)Migration and Synchronization

Table 10-53 Checking whether the source database character set is supported

CheckItem

Whether the source database character set is supported

Description

The source database character set is not supported. A migration taskfrom Oracle only supports the following character sets: ZHS16GBK,AL32UTF8, UTF8, US7ASCII, and WE8MSWIN1252.


Failure cause: The source database character set is not supported.Handling suggestion: Change the source database character set, orselect a source database with supported character sets.

10.2.48 Checking Whether the Length Table and Field NamesIs Not Supported

DDM -> Oracle Synchronization

Table 10-54 Checking whether the length of table and field names is supported

CheckItem

Whether the length of table and field names is supported

Description

In synchronization tasks from DDM to Oracle, the lengths of table andfield names cannot exceed 30 characters.




Failure cause: There are tables or fields whose name lengths exceed 30characters in the source database.Handling suggestion: Handling suggestion: Change the lengths of thetable or field names fewer than 30 characters.

10.2.49 Checking Whether the Databases and Tables Exist

All Scenarios

Table 10-55 Checking whether the databases and tables exist

CheckItem

Whether the databases and tables exist

Description

There are databases and tables in the uploaded file that do not exist inthe source database. The synchronization fails.


Failure cause: Objects imported from files do not exist in the sourcedatabase.Handling suggestion: Remove these objects that do not exist andimport the file again.

10.2.50 Checking Whether the Supplemental Log Level of theSource Database Meets Requirements

Oracle Synchronization

Table 10-56 Checking whether the supplemental log level of the source databasemeets requirements

CheckItem

Whether the supplemental log level of the source database meetsrequirements

Description

The supplemental log level of the source Oracle database does notmeet requirements. The synchronization fails.




Failure cause: The supplemental logging level of the source Oracledatabase does not meet requirements.Handling suggestion: Perform any of the following operations in thesource database:● Enable all-level (database-level) supplemental logging: alter

database add supplemental log data (all) columns● Enable minimal-level supplemental logging: alter database add

supplemental log data. Then run the following command to enableall-level (table-level) supplemental logging for each to-be-synchronized table: alter table TABLE_NAME add supplementallog data(all) columns

10.2.51 Checking Whether the Length of the Source DatabaseObject Names Exceeds the Limit

MySQL to PostgreSQL and MySQL to GaussDB(DWS) Synchronization

Table 10-57 Checking whether the length of the source database object namesexceeds the limit

CheckItem

Whether the length of the source database object names exceeds thelimit

Description

The destination database object name can contain a maximum of 63characters. The length of source object names mapped to thedestination ones exceeds the upper limit.


Failure cause: The destination database object name can contain amaximum of 63 characters. The length of source object names mappedto the destination ones exceeds the upper limit.Handling suggestion:1. Deselect the objects whose name length exceeds the limit.2. If the objects are tables, change the table names to meet the

mapping conditions.

10.2.52 Checking the Replication Attribute of the Source Table

PostgreSQL to PostgreSQL Migration and Synchronization

Table 10-58 Checking the replication attribute of the source table

CheckItem

Whether the replication attribute of the source table without a primarykey is set to full.



Description

The replication attribute is not set to full for the tables withoutprimary keys.


Failure cause: The data recorded in the log of a table without aprimary key is incomplete. As a result, the update and deleteoperations on the table may fail to be synchronized and the data willbe inconsistent.Handling suggestion: Add a primary key to the table, do not migratetables without primary keys, or run the following statement to set thereplication attribute of tables without primary keys to full: alter tabletable_name replica identity full

10.2.53 Checking Whether session_replication_role of theDestination Database Is correctly Set


Table 10-59 Checking whether the session_replication_role value of thedestination database is correctly set

CheckItem

Whether the session_replication_role value of the destinationdatabase is correctly set.

Description

The session_replication_role parameter of the destination database isnot set to replica. Data synchronization may fail when the migratedtable has associated foreign key constraints or triggers.


Item to be confirmed: The session_replication_role parameter of thedestination database is not set to replica.Handling suggestion: Set session_replication_role of the destinationdatabase to replica. For an on-premises database, run the alterdatabase set session_replication_role to replica command as usersuperuser. For an RDS DB instance, modify the value ofsession_replication_role on the RDS console

10.2.54 Checking the Database Compatibility Type

MySQL -> GaussDB(DWS) Synchronization

Table 10-60 Checking the database compatibility type

CheckItem

Whether the database compatibility type is supported



Description

The destination database is read-only, and data cannot be written tothe destination database.


Failure cause: The migration of tables without primary keys does notsupport the ORA compatibility mode of GaussDB(DWS).Handling suggestion: Use the MySQL and Teradata compatibility modeof GaussDB(DWS) or add primary keys to tables that do not haveprimary keys.Run the following statement to add a primary key to the table:CREATE DATABASE mysql_compatible_db DBCOMPATIBILITY 'MYSQL';Or: CREATE DATABASE td_compatible_db DBCOMPATIBILITY 'TD';

10.2.55 Checking Whether the Collation of the DestinationDatabase Is Correct

Oracle->MySQL, Oracle->GaussDB(for MySQL), and Oracle->DDMSynchronization

Table 10-61 Checking whether the collation of the destination database is correct

CheckItem

Whether the collation of the destination database is correct

Description

The primary key or unique key in the destination database contains acollation ended in _ci. The collation ending in _ci is case insensitive, soan error indicating duplicate keys may be reported duringsynchronization and cause the synchronization to fail.


Failure cause: The destination database collation is not supported.Handling suggestion: Change the destination database collation to acase-sensitive collation (not ending with _ci).



10.2.56 Checking Whether the Source Database Has thePermission to Parse OGG Logs

Oracle -> GaussDB(for openGauss) Synchronization

Table 10-62 Checking whether the source database has the permission to parseOGG logs

CheckItem

Whether the source database has the permission to parse OGG logs

Description

To use XStream mode to read logs on the source database, enableENABLE_GOLDENGATE_REPLICATION on the source database.


Failure cause: XStream is not enabled on the source database.Handling suggestion: Check whether the database version supportsXStream. If yes, run the ALTER SYSTEM SETENABLE_GOLDENGATE_REPLICATION = TRUE SCOPE=BOTH commandin the source database to enable XStream.

10.2.57 Checking Whether the Index Name Is Supported

MySQL -> CSS/ES Synchronization

Table 10-63 Checking whether the index name is supported

CheckItem

Whether the index name is supported

Description

Check whether the index name complies with the specifications. Theindex name rules are as follows:● Uppercase letters are not allowed.● Cannot contain /*?"<,>|# and spaces.● Can contain colons (:).● Cannot start with a hyphen (-), underscore (_), or plus sign (+).● Cannot contain periods (.) or ellipsis (...).● Can contain up to 255 characters.




Failure cause: The index name is not supported.Handling suggestion: In the migration settings, select another table forsynchronization or change the index name for table mapping.

10.2.58 Checking Whether Tables Structures Are Consistent

MySQL -> CSS/ES Synchronization

Table 10-64 Checking whether tables structures are consistent

CheckItem

Whether tables structures are consistent

Description

Check whether the table structures at the source end and destinationare consistent.


Failure cause: The source table columns are not a subset of thedestination indexes.Handling suggestion: Return to the Set Synchronization Task page,select the tables that meet the requirements. Alternatively, createindexes required in the destination table.

10.2.59 Checking Whether Existing Data Meets theConstraints


Table 10-65 Checking whether existing data meets the constraints

CheckItem

Whether existing data meets the constraints

Description

The constraint type of the source database table does not checkwhether existing data meets constraints. Some data in the source tablemay not meet the constraints, and the destination database may notsupport the constraint types. As a result, data transmission fails or datais lost because the data written to the destination database fails theconstraint check.




Item to be confirmed: Some check item constraints are not met.Handling suggestion: Ensure that all data in the corresponding tablemeets the current constraints. If any data does not meet theconstraints, consider not configuring constraints in the destination(contact DRS online support to skip the table structure consistencycheck), or process the source data to ensure that the data meets theconstraints.

10.2.60 Checking the Additional Column of the DestinationDatabase

MySQL to GaussDB(for MySQL) Synchronization

Table 10-66 Checking the additional column of the destination database

CheckItem

Additional column check

Description

Check whether the additional column is added to the additionalcolumn list of the destination database. If no additional column isadded, the incremental synchronization task fails.


Failure cause: Some columns are missing in the additional columnprocessing table in the destination database.Handling suggestion: Add the missing additional columns to thedestination database tables. Reference statement:ALTER TABLE ` database `.` table ` ADD COLUMN ` column_name `column_definition;

10.2.61 Checking Whether Implicit Primary Key Check IsEnabled for the Primary and Standby Databases


Table 10-67 Checking whether implicit primary key check is enabled for theprimary and standby databases

CheckItem

Whether implicit primary key check is enabled for the primary andstandby databases

Description

Check whether create_default_primary_key is enabled for the sourceor destination database.




Item to be confirmed: The create_default_primary_key parameter ofthe source or destination database is enabled. As a result, the primary/standby switchover may fail or data may be inconsistent. You areadvised to disable create_default_primary_key. If this parameter isdisabled, the task may still fail after a primary/standby switchover. Thepossible cause is that a table without a primary key is created whenthis parameter is enabled.Handling suggestion: This parameter was discarded, but in some DBinstances of earlier versions, this parameter may be enabled. As aresult, an error may occur during the primary/standby switchover,which may cause the task to fail or data inconsistency, you are advisedto disable this parameter or ensure that the source database does notcontain tables that do not have primary keys.

10.3 DB Instance Statuses

10.3.1 Checking Whether the Destination Database IsInvolved in Another Migration Task

MySQL

Table 10-68 Checking whether the destination database is involved in anothermigration task

Check Item Whether the destination database is involved in anothermigration task

Description Check whether the destination database is being used inanother migration task. If more than one migration taskuses the same destination database, the migration may fail.


Failure cause: The destination RDS DB instance is being usedin another migration task.Handling suggestion: Wait for the migration task tocomplete. You can also stop or delete an unused migrationtask.

PostgreSQL

Table 10-69 Checking whether the destination database is involved in anothermigration task

Check Item Whether the destination database is involved in anothermigration task



Description Check whether the destination database is being used inanother migration task. If more than one migration task usesthe same destination database, the migration may fail.


Failure cause: The destination RDS DB instance is being usedin another migration task.Handling suggestion: Wait for the migration task tocomplete. You can also stop or delete an unused migrationtask.

10.3.2 Checking Whether the Destination DB Instance IsEmpty

PostgreSQL

Table 10-70 Checking whether the destination DB instance is empty

Check Item Whether the destination DB instance is empty

Description The destination DB instance must be empty.



Failure cause: The destination DB instance must be empty.Handling suggestion: Check that the destination DBinstance is empty.



10.3.3 Checking Whether the Destination Database Has aRead Replica

MySQL

Table 10-71 Checking whether the destination database has a read replica

Check Item Whether the destination database has a read replica



Description Check whether the destination database has read replicas.If the destination database has read replicas, theincremental migration may fail.


Failure cause: In an incremental migration, the destinationdatabase cannot have read replicas.Handling suggestion: Delete the read replicas from thedestination database. After the migration is complete,create read replicas.

10.3.4 Checking Whether the Destination Database Is Read-Only

MySQL Migration, Synchronization, and Backward DR

Table 10-72 Checking whether the destination database is read-only

CheckItem

Whether the destination database is read-only

Description

The destination database is read-only, and data cannot be written tothe destination database.


Failure cause: The destination database is read-only.Handling suggestion: Run the following commands to change thedestination database to read/write and then, restart the database.Sample commands:set global read_only=0;set global super_read_only=0;

10.3.5 Checking Whether the Source Database Is Empty

MongoDB Database

Table 10-73 Checking whether the source database is empty

Check Item Whether the source database is empty

Description The source database cannot be empty.





Failure cause: The source database cannot be empty.Handling suggestion: Create a non-empty database on thesource database.


10.3.6 Checking Whether the Source and DestinationDatabases Are of the Same Type

MongoDB Database

Table 10-74 Checking whether the source and destination databases are of thesame type

Check Item Whether the source and destination databases are of thesame type

Description Check whether the source and destination databases areof the same type. If they are of different types, themigration fails.


Failure cause: The destination database is a cluster butthe source database is a replica set.Handling suggestion: Change the type of the source ordestination database.

Failure cause: The destination database is a replica setbut the source database is a cluster.Handling suggestion: Change the type of the source ordestination database.

10.3.7 Checking Whether the Destination Database Exists

MySQL > PostgreSQL

Table 10-75 Checking whether the destination database exists

Check Item Whether the destination database exists



Description Databases and schemas cannot be migrated. You need tomanually create databases and schemas on the destinationdatabase. Otherwise, the migration will fail.


Failure cause: Databases cannot be migrated from MySQL toPostgreSQL.Handling suggestion: In the destination database, manuallycreate databases and schemas with the same names as thoseof the source database.

Failure cause: The objects to be synchronized already exist inthe destination database.Handling suggestions: Delete the tables to be synchronizedfrom the destination database or select the tables that donot exist in the destination database for synchronization.

MySQL -> GaussDB(for openGauss) Synchronization

Table 10-76 Checking whether destination database contains the configureddatabase

CheckItem

Whether the destination database cannot contain the configureddatabase.

Description

In the MySQL to GaussDB(for openGauss) synchronization scenario,the mapped database must exist in the destination database.Otherwise, the synchronization fails.


Failure cause: The destination database does not contain theconfigured database.Handling suggestion: Before the synchronization, manually create amapped database in the destination database.

10.3.8 Checking Whether the Destination DB Instance IsAvailable

Table 10-77 Checking whether the destination DB instance is available

CheckItem

Whether the destination DB instance is available

Description

Check whether the primary instance and read replicas are available inthe destination database. If not, the migration fails.




Failure cause: The destination DB instance is not available.Handling suggestion: Repair the destination DB instance.

Failure cause: Read replicas in the destination database are abnormal.Handling suggestion: Repair the abnormal read replicas in thedestination database.

Failure cause: The RDS service is abnormal. Try again later.Handling suggestion: Try again later.

10.3.9 Checking Whether the Destination Database Is Empty

MySQL

Table 10-78 Checking whether the destination database is empty

Check Item Whether the destination database is empty

Description Check whether the destination database is empty. If thedestination database is not empty, disaster recovery will fail.

FailureCause andHandlingSuggestion

Failure cause: The destination database is not empty.Handling suggestion: Delete all the user-created databases fromthe destination database.

10.4 Database User Permissions

10.4.1 Checking Whether the Source Database User HasSufficient Permissions

MySQL Migration

Table 10-79 Checking whether the source database user has sufficient permissions

Check Item Whether the source database user has sufficient permissions



Description The source database user must have sufficient permissions.● In a full migration, the source database user must have

the SELECT, SHOW VIEW, and EVENT permissions.● In an incremental migration, the source database user

must have the following permissions: SELECT, SHOWVIEW, EVENT, LOCK TABLES, REPLICATION SLAVE, andREPLICATION CLIENT.

If the permissions are insufficient, the migration will fail.


Failure cause: In a full migration, the source database usermust have the SELECT, SHOW VIEW, and EVENTpermissions.Handling suggestions: Grant the source database user thecorresponding permissions.

Failure cause: In an incremental migration, the sourcedatabase user must have the following permissions: SELECT,SHOW VIEW, EVENT, LOCK TABLES, REPLICATION SLAVE,REPLICATION CLIENT, In the DR scenario, the followingpermissions are required: CREATE, ALTER, DROP, DELETE,INSERT, UPDATE, and INDEX.Handling suggestions: Grant the source database user thecorresponding permissions.

Failure cause: Insufficient user permissionsHandling suggestion: Check whether the database userpermissions meet the migration requirements.NOTE

For details about the MySQL permissions and authorizationoperations required by DRS, see Which MySQL Permissions AreRequired for DRS?





Description The source database user must have sufficient permissions.● In a full migration, the source database user must have

the SELECT, REFERENCES, TRIGGER, EXECUTE, and USAGEpermissions.

● In an incremental migration, the source database usermust have the SUPERUSER or REPLICATION permission.

If the permissions are insufficient, the migration will fail.








Failure cause: In a full migration, the source database usermust have the SELECT, REFERENCES, TRIGGER, EXECUTE, andUSAGE permissions.Handling suggestion: Change or authorize the migrationaccount.

Failure cause: The replication permission is not configured inpg_hba.conf for the replication instance and database user.Handling suggestion:Grant the replication permission to the user.Add the following to pg_hba.conf, and restart the databasefor the modification to take effect:host replication XXX(dbuser) 0.0.0.0/0 passwordAfter the migration is complete, delete this record and restartthe database again.

Failure cause: The max_wal_senders value in the sourcedatabase is too small.Handling suggestion: In the postgresql.conf file, change themax_wal_senders value to a larger one, such as increasing itby 5 or 10.




Item to be confirmed: The source database contains objectsthat can only be created by a superuser. The destination useris not a superuser, so the objects will be ignored.Handling suggestion: Use a superuser of the destinationdatabase or confirm that these objects can be ignored.






Description Check whether the source database user permissions meetthe migration requirements. If the permissions areinsufficient, the migration will fail.



Failure cause: The source database user must have the readpermission on admin and local databases.Handling suggestion: Check whether the source databaseuser permissions meet the migration requirements.


Oracle Migration





Failure cause: The source database user does not havesufficient permissions.Handling suggestion: Grant the CREATE SESSION, SELECTANY TRANSACTION, SELECT ANY TABLE, and SELECT ANYDICTIONARY permissions to the user and perform the checkagain.NOTE

If the destination database is PostgreSQL, the SELECT ANYSEQUENCE permission is also required.








Failure cause: The source database user does not havesufficient permissions. During the incrementalsynchronization, the SELECT permission onINFORMATION_SCHEMA is required.Handling suggestions: Grant the source database user thecorresponding permissions.Run the following command:grant select on [dbname];

10.4.2 Checking Whether the Destination Database User HasSufficient Permissions

MySQL Migration

Table 10-84 Checking whether the destination database user has sufficientpermissions

Check Item Whether the destination database user has sufficientpermissions

Description Check whether the destination database user permissionsmeet the migration requirements. If the permissions areinsufficient, the migration will fail.


Failure cause: The destination database user must have thefollowing permissions: SELECT, CREATE, DROP, DELETE,INSERT, UPDATE, INDEX, EVENT, CREATE VIEW, CREATEROUTINE, TRIGGER, and WITH GRANT OPTION. If thedestination database version is in the range from 8.0.14 to8.0.18, the SESSION_VARIABLES_ADMIN permission isrequired.Handling suggestion: Check whether the destinationdatabase user permissions meet the migrationrequirements.


















Oracle -> MySQL/Oracle -> GaussDB(for MySQL) Synchronization







Failure cause: The destination database user must have thefollowing permissions: SELECT, CREATE, DROP, DELETE,INSERT, UPDATE, INDEX, EVENT, RELOAD, CREATE VIEW,CREATE ROUTINE, TRIGGER, and ALTER.Handling suggestion: Check whether the destinationdatabase user permissions meet the migration requirements.

Oracle -> PostgreSQL Synchronization





Failure cause: The destination database user does not havesufficient permissions.Handling suggestions: Run the following command to grantthe permissions of creating databases and tables on thedestination database. Then, perform the check again.ALTER ROLE targetUser WITH CREATEDB;

In the preceding command, targetUser indicates the currentuser of the destination database.




Description Check whether the destination database user permissionsmeet the requirements for MySQL to PostgreSQLsynchronization. If the permissions are insufficient, thesynchronization will fail.




Failure cause: Some tables in the destination database donot have the INSERT, SELECT, UPDATE, and DELETEpermissions.Handling suggestion: Add the required permissions for thetables and try again.Example command:GRANT INSERT,SELECT,UPDATE, DELETE ON db_name.table_name TO 'user'@'host';

PostgreSQL > PostgreSQL Synchronization



Description Check whether the destination database user permissionsmeet the requirements for PostgreSQL to PostgreSQLsynchronization. If the permissions are insufficient, thesynchronization will fail.


Failure cause: The destination database user must have theCREATEDB permission.Handling suggestion: Grant the destination database userthe CREATEDB permission.ALTER ROLE role_name WITH CREATEDB;



CheckItem

Whether the destination database user has sufficient permissions

Description

Check whether the destination database user permissions meet themigration requirements. If the permissions are insufficient, the disasterrecovery will fail.


Failure cause: The source database user must have the GRANTpermission.Handling suggestion: Grant user the required permission.GRANT SELECT, CREATE, DROP, DELETE, INSERT, UPDATE, SHOW VIEW, EVENT, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'u1' WITH GRANT OPTION;





CheckItem

Whether the destination database user has sufficient permissions

Description

Check whether the destination database user permissions meet therequirements for DDM to Oracle synchronization. If the permissions areinsufficient, the synchronization will fail.


Failure cause: The destination database user does not have sufficientpermissions.Handling suggestion: Use an account with the DBA permission, orgrant required permissions to the user.

GaussDB(for openGauss) as the Destination


CheckItem

Whether the source database user has sufficient permissions

Description

Check whether the source database user permissions meet themigration requirements.


Failure cause: The source database user does not have sufficientpermissions. The user needs the select permission for the schema.Handling suggestion: Grant the missing permissions to the objectowner or system administrator.



10.4.3 Checking Whether the Source Database Account IsAvailable

PostgreSQL

Table 10-94 Checking whether the source database account is available

Check Item Whether the source database account is available

Description Check whether the source database account meets themigration requirements.





Failure cause: The source database account does not exist.Handling suggestion: Create an account for the sourcedatabase.

Failure cause: The source database contains forbiddendatabase accounts.Handling suggestion: Delete the forbidden accounts fromthe source database and retry the migration task.

10.4.4 Checking Whether the Destination Database AccountHas Required Permissions to Migrate Definer

MySQL Migration

Table 10-95 Checking Whether the Destination Database Account Has RequiredPermissions to Migrate Definer

Check Item Checking whether the destination database account hasrequired permissions to migrate Definer

Description To migrate Definers to the cloud, the source database usermust have the all privileges permission.




Failure cause: The permission of the specified destinationdatabase account is insufficient.Handling suggestions: Migrate all Definers to the specifieddestination database account. Alternatively, do not migrateDefiners to the specified destination database account andrun the following command to grant the destination databaseaccount the all privileges permission.Example command:grant all privileges on *.* to 'user' @' host'

Failure cause: The specified source database user does nothave required permissions.Handling suggestion:1. When configuring the destination database, select Migrate

Definer to User to ensure that Definers of all the objectsare under the specified user.

2. Retain the Definer settings and run the followingcommand to grant the all privileges permission to thesource database user.Example command:grant all privileges on *.* to 'user' @' host'

10.5 Database Versions

10.5.1 Checking Whether the Source Database Version IsSupported

MySQL Migration

Table 10-96 Checking whether the source database version is supported

Check Item Whether the source database version is supported

Description Check whether the source database version is MySQL 5.5.x,MySQL 5.6.x, MySQL 8.0.x, and MySQL 5.7.x.


Failure cause: The source database version is not supported.Handling suggestion: Export data and then import itfollowing the instructions provided in the Migrating MySQLData Using mysqldump section in the Relational DatabaseService User Guide.




https://support.huaweicloud.com/intl/en-us/usermanual-rds/rds_migration_mysql.html







Description Check whether the source database version is PostgreSQL9.4, PostgreSQL 9.5, PostgreSQL 9.6, PostgreSQL 10.0,PostgreSQL 11.0, PostgreSQL 12.0, PostgreSQL EnhancedEdition, and PostgreSQL 13.0.



Failure cause: The source database version is not supported.Handling suggestion: Check whether the source databaseversion is supported. Currently, only PostgreSQL 9.4,PostgreSQL 9.5, PostgreSQL 9.6, PostgreSQL 10.0,PostgreSQL 11.0, PostgreSQL 12.0, PostgreSQL EnhancedEdition, and PostgreSQL 13.0. are supported.



PostgreSQL to GaussDB(DWS) Synchronization

Table 10-98 Checking Whether the Source Database Version Is Supported

CheckItem

Whether the source database version is supported

Description

Check whether the source database version is PostgreSQL 9.4,PostgreSQL 9.5, PostgreSQL 9.6, PostgreSQL 10.0, PostgreSQL 11.0,PostgreSQL 12.0, and PostgreSQL 13.0..




Failure cause: This item cannot be checked because the sourcedatabase fails to be connected.Handling suggestion: Check whether the source database is connected.

Failure cause: The source database version is not supported.Handling suggestion: Check whether the source database version issupported. Currently, only PostgreSQL 9.4, PostgreSQL 9.5, PostgreSQL9.6, PostgreSQL 10.0, PostgreSQL 11.0, and PostgreSQL 12.0, andPostgreSQL 13.0. are supported.

Failure cause: Insufficient user permissionsHandling suggestion: Check whether the database user permissionsmeet the migration requirements.





Description Currently, only MongoDB 3.4.x and MongoDB 4.0.x aresupported.


Failure cause: The source database version is not supported.Handling suggestion: Check whether the source databaseversion is supported. Currently, only MongoDB 3.4.x andMongoDB 4.0.x are supported.




Table 10-100 Checking whether source database version is supported


Description Check whether the source database version is Oracle 10g,11g, 12c, 18c, or 19c.




Failure cause: The source database version is not supported.Handling suggestion: Check whether the source databaseversion is supported. Currently, only Oracle 10g, 11g, 12c,18c, and 19c are supported.

Oracle -> PostgreSQL Migration

Table 10-101 Checking whether source database version is supported


Description Check whether the source database version is Oracle 10g,11g, 12c, or 18c.


Failure cause: The source database version is not supported.Handling suggestion: Check whether the source databaseversion is supported. Currently, only Oracle 10g, 11g, 12c,or 18c are supported.




Description Check whether the source database version meets therequirements for synchronization from MySQL toPostgreSQL.


Failure cause: The source database version is not supported.Handling suggestion: Check whether the source databaseversion is supported. Currently, only MySQL 5.5, 5.6, 5.7,and 8.0 are supported.

10.5.2 Checking Whether the Destination Database Version IsSupported

MySQL Migration

Table 10-103 Checking whether the destination database version is supported

Check Item Whether the destination database version is supported



Description Check whether the destination database version is MySQL5.6.x, MySQL 8.0.x, or MySQL 5.7.x.


Failure cause: The destination database version is notsupported.Handling suggestion: Export data and then import itfollowing the instructions provided in the Migrating MySQLData Using mysqldump section in the Relational DatabaseService User Guide.




PostgreSQL Migration and Synchronization



Description Check whether the destination database version isPostgreSQL 9.4, PostgreSQL 9.5, PostgreSQL 9.6,PostgreSQL 10.0, PostgreSQL 11.0, PostgreSQL 12.0,PostgreSQL Enhanced Edition, and PostgreSQL 13.0.


Failure cause: This item cannot be checked because thedestination database fails to be connected.Handling suggestion: Check whether the source database isconnected.

Failure cause: The destination database version is notsupported.Handling suggestion: Check whether the destinationdatabase version is supported. Currently, only PostgreSQL9.4, PostgreSQL 9.5, PostgreSQL 9.6, PostgreSQL 10.0,PostgreSQL 11.0, PostgreSQL 12.0, PostgreSQL EnhancedEdition, and PostgreSQL 13.0. are supported.










Description Currently, only MongoDB 3.2.x, 3.4.x, and 4.0.x aresupported.


Failure cause: The destination database version is notsupported.Handling suggestion: Check whether the destinationdatabase version is supported. Currently, only MongoDB3.2.x, 3.4.x, and 4.0.x are supported.






Description Check whether the destination database version meets themigration requirements.


Failure cause: The destination database version is notsupported.Handling suggestion: Check whether the destinationdatabase version is supported. Currently, only MySQL 5.6.xand MySQL 5.7.x are supported.



Oracle -> RDS PostgreSQL Migration



Description Check whether the destination database version meets themigration requirements.


Failure cause: The destination database version is notsupported.Handling suggestion: Check whether the destinationdatabase version is supported. Currently, only PostgreSQLEnhanced Edition is supported.




Description Check whether the destination database version meets therequirements for synchronization from MySQL toPostgreSQL.


Failure cause: The destination database version is notsupported.Handling suggestion: Check whether the destinationdatabase version is supported. Currently, only PostgreSQL10.x is supported.

10.5.3 Checking Whether the Migration Is from an EarlierDatabase Version to the Same or a Later Version

MySQL Migration

Table 10-109 Checking whether the migration is from an earlier database versionto the same or a later version

Check Item Whether the migration is from an earlier database versionto the same or a later version

Description Check whether the source database version is earlier than orthe same as the destination database version.






Failure cause: The source database version is not supported.Handling suggestion: Check whether the source databaseversion is supported. Currently, only MySQL 5.5.x, MySQL5.6.x, MySQL 8.0.x, and MySQL 5.7.x are supported.

Failure cause: The destination database version is notsupported.Handling suggestion: Check whether the destinationdatabase version is supported. Currently, only MySQL 5.6.x,MySQL 8.0.x, and MySQL 5.7.x are supported.



Failure cause: The destination database version must be thesame as or later than the source database version.Handling suggestion: Ensure the source database version isearlier than or the same as the destination databaseversion.

PostgreSQL Migration and Synchronization



Description Check whether the source database version is earlier thanor the same as the destination database version.







Failure cause: The source database version is not supported.Handling suggestion: Check whether the source databaseversion is supported. Currently, only PostgreSQL 9.4,PostgreSQL 9.5, PostgreSQL 9.6, PostgreSQL 10.0,PostgreSQL 11.0, PostgreSQL 12.0, and PostgreSQLEnhanced Edition are supported.

Failure cause: The destination database version is notsupported.Handling suggestion: Check whether the destinationdatabase version is supported. Currently, only PostgreSQL9.4, PostgreSQL 9.5, PostgreSQL 9.6, PostgreSQL 10.0,PostgreSQL 11.0, PostgreSQL 12.0, and PostgreSQLEnhanced Edition are supported.

Failure cause: The major versions of the source anddestination databases must be the same and the minorversion of the source database must be less than or equalto that of the destination database.Handling suggestion: Ensure the source database version isearlier than or the same as the destination databaseversion.

Failure cause: If the source database is an RDS PostgreSQLEnhanced Edition instance, the destination database canonly be an RDS PostgreSQL Enhanced Edition instance.Handling suggestion: Select RDS PostgreSQL EnhancedEdition instance as the destination database.


Failure cause: The destination database version and sourcedatabase version do not meet the requirements of theselected migration mode.Handling suggestion: Check whether the versions of thedestination database and source database meet themigration mode requirements.






Description Check whether the source database version is earlier than orthe same as the destination database version.


Failure cause: The versions of the source and destinationdatabases are inconsistent or do not meet the versionrequirements.Handling suggestion: The versions of the source anddestination databases must be the same and be 5.6, , 5.7, or8.0. Select the databases whose versions meet the versionrequirements.


Table 10-112 Checking Whether the Source Database Version Is Supported

CheckItem

Whether the migration is from an earlier database version to the sameor a later version

Description

Check whether the source database version is earlier than or the sameas the destination database version. The destination database versioncan be 4.0.x or later. The migration must be performed from an olderdatabase version to the same or a newer version Check whether thefeatures of the newer version are used in the source database. If thenew features are not supported in the destination database, thesynchronization may fail.


Item to be confirmed: The versions of the source and destinationdatabases are different.Potential problem: The source database version is 4.4.5 and thedestination database version is 4.0.3, which does not comply with themigration version requirements. If the source database supportsfeatures of the newer version but the destination database does not,the synchronization may fail.

Failure cause: The destination database version does not meet therequirements.Handling suggestion: Select version 4.0.x for the destination databasebecause the source database version is later than 4.0.x and thedestination database version is 3.4.x.



10.5.4 Checking Whether the MongoDB Instance TypeMatches the Migration Mode

MongoDB Database

Table 10-113 Checking whether the MongoDB instance type matches themigration mode

Check Item Whether the MongoDB instance type matches the migrationmode

Description Check whether the MongoDB instance type matches themigration mode. If not, the migration fails.


Failure cause: Incremental migration is supported only whenthe source database is a replica set instance.Handling suggestion: Use the replica set as the sourcedatabase for incremental migration.

Item to be confirmed: The migration type is incrementalmigration, but the destination DB instance type is unknown.Handling suggestion: Check whether the destination DBinstance type is replica set or sharded cluster.

10.5.5 Checking Whether the Plugin Versions of theDestination Database Are Later Than Those of the SourceDatabase

PostgreSQL

Table 10-114 Checking Whether the plugin versions of the destination databaseare later than those of the source database

Check Item Whether the plugin versions of the destination database arelater than those of the source database

Description Check whether the plugin versions of the destination databaseare earlier than those of the source database. The migration willfail if the plugin versions of the destination database are earlierthan those of the source database.


Failure cause: The plugin versions of the destination databaseare earlier than those of the source database.Handling suggestions: Contact RDS O&M personnel to upgradethe plugin versions of the destination database.



10.6 Network

10.6.1 Checking Whether the Source Database Is Connected

MySQL Migration

Table 10-115 Checking whether the source database is connected

Check Item Whether the source database is connected

Description Check the connectivity and accuracy of the IP address, portnumber, username, and password of the source database.


Failure cause: The connection fails.Handling suggestion: See network preparations in the DataReplication Service Best Practices.

Failure cause: Incorrect username or passwordHandling suggestion: Check whether the input usernameand password for the connection test are correct.

Failure cause: The database account does not allow remoteconnections.Handling suggestion:Run the following command to create a user that allowsremote connections. After the migration, delete this user.CREATE USER 'Account' @ '%' IDENTIFIED BY 'Password'

Failure cause: The SSL CA root certificate is invalid.Handling suggestion: Upload a valid SSL CA certificate.

Failure cause: No SSL CA root certificate exists.Handling suggestion: Contact Huawei technical support.









Failure cause: The IP address is inaccessible.Handling suggestion: See network preparations in the DataReplication Service Best Practices.


Failure cause: The database account does not allow remoteconnections.Handling suggestion:Configure the remote connection permission for the user inthe pg_hba.conf file.Open pg_hba.conf, add the following, and restart thedatabase for the modification to take effect:host all xxx(dbuser) 0.0.0.0/0 password

After the migration is complete, delete this record andrestart the database again.

Failure cause: Failed to connect to the database.Handling suggestion:The listen_addresses parameter value or port number inthe postgres.conf file is incorrect.In the postgres.conf file, set the listen_addresses value to'*' or set the port number to the correct value. Then, restartthe database for the modification to take effect.


Failure cause: The user does not have the login permission.Handling suggestion:Run the following command to grant the login permissionto the user:alter role xxx(dbuser) login

Failure cause: The postgres database does not exist in thesource database.Handling suggestion: Create a postgres database.









Failure cause: The username, password, or authenticationdatabase of the source database is incorrect.Handling suggestion: Check that the input username,password, and authentication database for the connectiontest are correct.



Failure cause: SSL connection parameters are notconfigured.Handling suggestion: Contact Huawei technical support.

Failure cause: The source database cannot connect to theport of the replication instance.Handling suggestion: Modify the firewall, security group, orACL configurations of the source and destination databasesto enable the source database to connect to the port of thereplication instance.

10.6.2 Checking Whether the Destination Database IsConnected


Table 10-118 Checking whether the destination database is connected

Check Item Whether the destination database is connected

Description Check the connectivity and accuracy of the IP address, portnumber, username, and password of the destinationdatabase.






Failure cause: The database account does not allow remoteconnections.Handling suggestion:Run the following command to create a user that allowsremote connections. After the migration, delete this user.CREATE USER 'Account' @ '%' IDENTIFIED BY 'Password'







Failure cause: The IP address is inaccessible.Handling suggestion: See network preparations in the DataReplication Service Best Practices.


Failure cause: The database account does not allow remoteconnections.Handling suggestion:Grant the remote connection permission for the user in thepg_hba.conf file because the replication instance and userare not configured in the pg_hba.conf configuration file.Add the following to the pg_hba.conf configuration file.After the migration is complete, delete this record andrestart the database for the modification to take effect.host all xxx(dbuser) 0.0.0.0/0 password



Failure cause: Failed to connect to the database. The failuremay be caused by the incorrect listen_addresses parametervalue or port number in postgres.conf.Handling suggestion: In the postgres.conf file, setlisten_addresses to "*" or set the port number to thecorrect value. Then, restart the database for themodification to take effect.


Failure cause: The user does not have the login permission.Handling suggestion:Run the following command to grant the login permissionto the user:alter role xxx(dbuser) login

Failure cause: The postgres database does not exist in thesource database.Handling suggestion: Create a postgres database.










Failure cause: SSL connection parameters are notconfigured.Handling suggestion: Contact Huawei technical support.



GaussDB(for openGauss) Synchronization


CheckItem

Whether the destination database is connected

Description

Check the connectivity and accuracy of the IP address, port number,username, and password of the destination database.


Failure cause: Incorrect username or passwordHandling suggestion: Check whether the input username and passwordfor the connection test are correct.

Failure cause: The database account does not allow remoteconnections.Handling suggestion:Run the following command to create a user that allows remoteconnections. After the migration, delete this user.CREATE USER 'Account' @ '%' IDENTIFIED BY 'Password'


10.6.3 Checking Whether the Destination Database CanConnect to the Source Database


Table 10-122 Checking whether the destination database can connect to thesource database

Check Item Whether the destination database can connect to the sourcedatabase

Description Check whether the destination database can connect to thesource database.


Failure cause: The destination database fails to connect tothe source database.Handling suggestion: See network preparations in the DataReplication Service Best Practices.

10.7 Database Objects



10.7.1 Checking Whether the Source Database Contains aMyISAM Table

MySQL

Table 10-123 Checking whether the source database contains a MyISAM table

Check Item Whether the source database contains a MyISAM table

Description If the source database contains a MyISAM table, themigration will fail.


Item to be confirmed: The source database containsMyISAM tables that are not supported by the destinationdatabase, which may cause the migration to fail.Handling suggestion: Convert the tables in the sourcedatabase to InnoDB tables and try again. Alternatively,contact technical support.

10.7.2 Checking Whether the Source Database ContainsUnsupported Table Field Types

Oracle Migration and Synchronization

Table 10-124 Checking whether the source database contains unsupported tablefield types

Check Item Whether the source database contains unsupported table fieldtypes

Description Unsupported table field types are as follows: BFILE, XMLType,SDO_GEOMETRY, TIMESTAMP (x), INTERVAL DAY TOSECOND (x), and UROWID. The source database containsunsupported table field types, resulting in migration failures.NOTE

X indicates the precision. Currently, TIMESTAMP and INTERVAL DAYTO SECOND do not support the column type with precision between 7to 9.


Failure cause: The source database contains unsupportedtable field types.Handling suggestion: Delete the columns containing theunsupported field types. Alternatively, do not migrate thetables containing the unsupported table field types.




Table 10-125 Checking whether the source database contains unsupported tablefield types

Check Item Whether the source database contains unsupported table fieldtypes

Description The following table fields types are not supported: geometry,point, lineString, polygon, geometrycollection, multipoint,multilinestring, and multipolygon. The source databasecontains unsupported table field types, resulting in migrationfailures.


Failure cause: The source database contains unsupported tablefield types.Handling suggestion: Delete the columns containing theunsupported field types. Alternatively, do not migrate thetables containing the unsupported table field types.

10.7.3 Checking Whether the Source Database Is Available

Oracle to GaussDB(for openGauss) Synchronization

Table 10-126 Checking whether the synchronization object exists in the sourcedatabase

CheckItem

Whether the synchronization object exists in the source database

Description

If the selected synchronization object does not exist in the sourcedatabase, the check fails.


Failure cause: The objects to be synchronized do not exist in the sourcedatabase.Handling suggestion: Deselect the objects to be synchronized.

MySQL > PostgreSQL

Table 10-127 Checking whether the source database is available

Check Item Whether the source database is available



Description In the pre-check phase, the source database is disconnectedwhen the synchronization object check is performed. As a result,the migration fails.


Failure cause: The source database is unavailable.Handling suggestions: Check that the source database isconnected and try again later.

10.7.4 Checking Whether the Source Database Contains theFunctions or Stored Procedures that the Source Database UserIs Not Authorized to Migrate

MySQL

Table 10-128 Checking whether the source database contains the functions orstored procedures that the source database user is not authorized to migrate

Check Item Whether the source database contains the functions or storedprocedures that the source database user is not authorized tomigrate.

Description The source database contains the functions or storedprocedures that the source database user is not authorized tomigrate.


Failure cause: The source database user does not have thepermission to migrate functions and stored procedures.Handling suggestion: Ensure that the source database user hasthe highest-level right.

10.7.5 Checking Whether Objects with the Same Names Existin the Source Database


Table 10-129 Checking whether objects with the same names exist in the sourcedatabase

CheckItem

Whether objects with the same names exist in the source database

Description

Failure cause: The source databases selected are not mapped to thesame database, or tables with same names exist in the selecteddatabases.




Failure cause: PostgreSQL does not support synchronization of multipledatabases, or objects have the same names in the source databases.Handling suggestion: Select one database for migration, or map theselected databases to the same database and ensure that the object inthe databases have unique names.

10.7.6 Checking Whether the Source Database ContainsUnlogged Tables

PostgreSQL as the Source

Table 10-130 Checking whether the source database contains unlogged tables

CheckItem

Whether the source database contains unlogged tables

Description

Check whether the source database contains unlogged tables. If yes,the synchronization fails.


Item to be confirmed: The source database contains unlogged tablesand modifications to these tables are not recorded in logs. As a result,incremental data of unlogged tables cannot be synchronized.Handling suggestions: Check whether incremental data of theunlogged tables needs to be synchronized. If yes, run the followingcommand to change the unlogged tables to logged: ALTER TABLETABLE_NAME SET LOGGED."

10.7.7 Checking Whether the Names of Views to Be MigratedAre the Same

Oracle Migration and Synchronization

Table 10-131 Checking whether the source database meets integrity constraints

Check Item Whether the source database meets constraint integrity

Description Check the constraint integrity of the source database. If thecheck result does not meet the migration requirements, themigration fails.




Failure cause: Tables to be migrated are dependent but thereferenced tables are not to be migrated.Handling suggestion: Select the referenced tables in themigration object list.

Failure cause: Views that cannot be migrated are selected inthe migration object list.Handling suggestions: Check all objects which the viewsreference and select them for migration.

Failure cause: The names of the views to be migrated are thesame except for letter cases.Handling suggestions: Change the view names or do notmigrate these views.

Failure cause: Source database constraint names are thesame except for letter cases.Handling suggestions: Change the constraint names or donot migrate the constraints whose names are the sameexcept for letter cases.

10.7.8 Checking Whether the _Id Fields in the Collection ofthe Source Database Have Indexes

MongoDB Database

Table 10-132 Checking whether the _id fields in the collections of the sourcedatabase have indexes

Check Item Whether the _id fields in the collections of the sourcedatabase have indexes

Description Check whether the _id fields in the collections of the sourcedatabase have indexes. If yes, the migration fails.


Failure cause: The _id fields in the collections of the sourcedatabase must have indexes.Handling suggestion: Run the db.Collectionname.ensureIndex({_id: 1}) command to add an index. Ifthe index fails to be added and the system displays amessage indicating that the _id value already exists, thecollection cannot be migrated.



10.7.9 Checking Whether the Index Length of the SourceDatabase Exceeds the Limit

Oracle -> MySQL/Oracle -> GaussDB(for MySQL) Migration andSynchronization

Table 10-133 Checking whether the index length of the source database exceedsthe limit

CheckItem

Whether the index length of the source database exceeds the limit

Description

The migration fails because the index length of the source databaseexceeds the column length limit of the destination database.


Failure cause: There are indexes in the source database exceed thecolumn length limit of the destination database.Handling suggestion: 1. Delete the tables from the migration object. 2.Modify the index length.

MySQL Migration, Synchronization, and Disaster Recovery

Table 10-134 Checking whether the index length of the source database exceedsthe column length limit

CheckItem

Whether the index length of the source database exceeds the limit

Description

The migration fails because the index length of the source databaseexceeds the column length limit of the destination database.


Failure cause: There are indexes in the source database exceed thecolumn length limit of the destination database.Handling suggestion: Set innodb_large_prefix of the destinationdatabase to ON, or return to the previous step and select the table tobe migrated again.



10.7.10 Checking Whether the Source Database Tables UseStorage Engines Not Supported by the Destination Database


Table 10-135 Checking whether the source database tables use storage enginesnot supported by the destination database

Check Item Whether the source database tables use storage engines notsupported by the destination database

Description Check whether the source database tables use storageengines not supported by the destination database. If yes,the migration fails.


Failure cause: The source database tables use the storageengines that are not supported by the destination database.Handling suggestion: Go back to the previous page anddeselect the tables that use the storage engines notsupported by the destination database.

10.7.11 Checking Whether the Database Names Mapped tothe Destination DB Instance Contain Unsupported Characters

MySQL

Table 10-136 Checking whether the database names mapped to the destinationdatabase contain unsupported characters.

CheckItem

Whether the database names mapped to the destination DB instancecontain unsupported characters.

Description

The following characters are not supported in the database namesmapped to the destination DB instance: .<>\'


Failure cause: The database names mapped to the destination DBinstance contain unsupported characters.Handling suggestion: Go back to the object selection page and changethe source database names to be mapped to the destination DBinstance.



10.7.12 Checking Whether the Source Database TablesContain Primary Keys

MySQL Migration and Disaster Recovery

Table 10-137 Checking whether the source database tables contain primary keys

Check Item Whether the source database tables contain primary keys

Description If tables to be migrated in the source database do not containprimary keys, the migration may fail.


Item to be confirmed: The tables to be migrated in the sourcedatabase do not contain primary keys.Handling suggestion: Create a primary key for the table. If thetable does not have a primary key to uniquely identify everyrow and the network connection is unstable, the data in thedestination database may be inconsistent with that in thesource database.

MySQL Synchronization

Table 10-138 Checking whether the source database tables contain primary keys

Check Item Whether the source database tables contain primary keys

Description If tables to be synchronized in the source database do notcontain primary keys, the synchronization may fail.

Failure CauseandHandlingSuggestion

Failure cause: The tables to be synchronized in the sourcedatabase do not contain primary keys.Handling suggestion: Create primary keys for the tables toimprove performance.

Failure cause: In a many-to-one task, tables with no primarykey that have the same name as those in the destinationdatabase are not allowed in the source database.Handling suggestion: Modify tables without primary keys,delete tables with no primary key from the destinationdatabase, or do not migrate tables without primary keys.


Item to be confirmed: The tables to be synchronized in thesource database do not contain primary keys.Handling suggestion: Create a primary key for the table. If thetable does not have a primary key to uniquely identify everyrow and the network connection is unstable, the data in thedestination database may be inconsistent with that in thesource database.



10.7.13 Checking Whether the Source Database ContainsTriggers or Events

MySQL Migration

Table 10-139 Checking whether the source database contains triggers or events

Check Item Whether the source database contains triggers or events

Description To prevent unexpected operations on the destination databaseautomatically triggered by triggers or events, this task startsthe trigger or event migration only after you stop the task. Ifyou close or disconnect the source database connection duringthe task running, triggers or events are not migrated.


Item to be confirmed: The source database contains triggers orevents.Handling suggestion: Stop the task first and then disconnectthe network to ensure the completeness of the migration.

10.7.14 Checking Whether the Source Database ReferencedRoles Pass the Check

MongoDB Database

Table 10-140 Checking whether the source database referenced roles pass thecheck

CheckItem

Whether the source database referenced roles pass the check

Description

If the roles referenced by accounts to be migrated are not migrated tothe destination database, the migration may fail.


Failure cause: The databases referenced by source database roles donot exist in the destination database, and are not displayed in theobject selection list.Handling suggestion: Select the databases referenced by roles formigration or do not migrate the roles.

Failure cause: The roles referenced by source database roles do notexist in the destination database, and are not displayed in the roleselection list.Handling suggestion: Select the referenced roles or do not migrate theroles that fail the check.



10.7.15 Checking Whether the Source Database ReferencedAccounts Pass the Check

MongoDB Database

Table 10-141 Checking whether the source database referenced accounts pass thecheck

CheckItem

Whether the source database referenced accounts pass the check

Description

If the roles referenced by accounts to be migrated are not migrated tothe destination database, the migration may fail.


Failure cause: The databases referenced by source database account donot exist in the destination database, and are not displayed in theobject selection list.Handling suggestion: Select the roles referenced by accounts formigration or do not migrate the accounts.

Failure cause: The databases referenced by source database account donot exist in the destination database, and are not displayed in theobject selection list.Handling suggestion: Select the databases referenced by accounts formigration or do not migrate the accounts.

10.7.16 Checking Database Mapping Objects

MySQL -> MySQL

Table 10-142 Checking database mapping objects

CheckItem

Whether the database mapping objects are supported

Description

Database mapping does not support views or stored procedures. If thesource database contains views or stored procedures, thesynchronization may fail.


Failure cause: Database mapping does not support views or storedprocedures.Handling suggestions: Cancel the mapping of databases containingviews or stored procedures, or delete the views or stored proceduresfrom the databases.



10.7.17 Checking Whether Associated Objects Are Selected

PostgreSQL to RDS PostgreSQL Migration and Synchronization, andPostgreSQL to GaussDB(DWS) Synchronization

Table 10-143 Checking whether associated objects are selected

CheckItem

Whether the associated objects are selected

Description

The associated objects must be selected for migration. Otherwise, themigration may fail.


Failure cause: Tables referenced by the foreign key in the table to bemigrated are not selected for migration.Handling suggestion: Select the associated objects.

Failure cause: The selected objects contain views associated with sometables or views that are not selected for migration.Handling suggestion: Select the associated objects.

Failure cause: The tables associated with the child tables to bemigrated are not selected for migration.Handling suggestion: Select the associated objects.

10.7.18 Checking Whether the Specified Objects Exist In theDestination Database

PostgreSQL to RDS PostgreSQL Migration and Synchronization, andPostgreSQL to GaussDB(DWS) Synchronization

Table 10-144 Checking whether the specified migration objects exist in thedestination database.

CheckItem

Whether the specified migration objects exist in the destinationdatabase.

Description

The objects with the same names as the source objects cannot exist inthe destination database. Otherwise, the migration may fail.


Failure cause: The objects to be synchronized exist in the destinationdatabase.Handling suggestion: Delete the objects with the same names as thesource objects and perform the verification again.



10.7.19 Checking Whether the Source Table Contains ColumnTypes that Cannot Be Used as Distribution Keys


Table 10-145 Checking whether the source table contains column types thatcannot be used as distribution keys

CheckItem

Whether the source table contains column types that cannot be usedas distribution keys

Description

The source table cannot contain column types used as distributionkeys. Otherwise, the synchronization may fail.


Failure cause: The source table contains column types that cannot beused as distribution keys.Handling suggestion: Select another table that can be migrated.

10.7.20 Checking Whether the Source Table ContainsUnsupported Table Field Types


Table 10-146 Checking whether the source table contains unsupported table fieldtypes

CheckItem

Whether the source table contains unsupported table field types

Description

The source tables cannot contain unsupported field types. Otherwise,the synchronization fails.


Failure cause: The source database table contains unsupported tablefield types.Handling suggestion: Select another table that can be migrated.



10.8 Database Configuration Items

10.8.1 Checking Whether the Source Database Name Is Valid

MySQL Migration

Table 10-147 Checking whether the source database name is valid

Check Item Whether the source database name is valid

Description The source database name cannot contain invalidcharacters. It must contain 1 to 64 characters, includingonly lowercase letters, digits, hyphens (-), and underscores(_).If the source database name contains any invalid character,the migration fails.


Failure cause: This item cannot be checked because thesource database fails to be connected.Handling suggestion: Check whether the source databaseis connected.

Failure cause: The source database name cannot containinvalid characters. It must contain 1 to 64 characters,including only lowercase letters, digits, hyphens (-), andunderscores (_).Handling suggestion: Change the source database namesthat contain unsupported characters or go back to theprevious page and select the databases that do not containunsupported characters.




Description If the source database name contains invalid characters,the migration fails.

Failure cause: The source database names cannot containthe following special characters: .<>'Handling suggestion: Change the source database namesthat contain unsupported characters or go back to theprevious page and select the databases that do notcontain unsupported characters.



Oracle Migration



Description The source database names cannot contain non-ASCIIcharacters or special characters .><\`|,?'!"If the source database name contains invalid characters,the migration fails.

Failure cause: The source database names containunsupported characters.Handling suggestion: Change the source database namesthat contain unsupported characters or go back to theprevious page and select the databases that do notcontain unsupported characters.

10.8.2 Checking Whether the Source Database Table Name IsValid

MySQL Migration

Table 10-150 Checking whether the source database table name is valid

Check Item Whether the source database table name is valid

Description If the source database table name contains invalidcharacter, the migration fails.


Failure cause: The source database table names containunsupported characters, non-ASCII characters, or thefollowing characters: ></\Handling suggestion: To solve this problem, perform thefollowing steps:Click Previous to return to the Select Migration Typepage. Select a customized object and do not select thetable that contains unsupported characters.Method 2: Change the table name.






Description The source database names contain the followingunsupported characters: '" .


Failure cause: The source database names containunsupported characters.Handling suggestion: Run the following command tochange the source database names that containunsupported characters:alter table old_name rename to new_name;

Oracle Migration



Description The source database names cannot contain non-ASCIIcharacters or special characters .><\`|,?'!" If the table nameor view name of the source database contains any invalidcharacter, the migration fails.


Failure cause: The table name or view name of the sourcedatabase contains unsupported characters.Handling suggestion:● Run the following command to change the table name

that contains unsupported characters:alter table old_name rename to new_name;

● Run the following command to change the view namethat contains unsupported characters:rename old_view_name to new_view_name;

10.8.3 Checking Whether the Source Database View Name IsValid

MySQL

Table 10-153 Checking whether the source database contains view names withnon-ASCII characters

Check Item Whether the source database contains view names withnon-ASCII characters

Description If the source database contains non-ASCII characters, themigration will fail.




Failure cause: The source database view names containunsupported characters, non-ASCII characters, or thefollowing characters: ></\Handling suggestion: To solve this problem, perform thefollowing steps:Method 1:Click Previous to return to the Select Migration Type page.Select a customized object and do not select the view namethat contains unsupported characters.Method 2: Change the view name.

10.8.4 Checking Whether the Source Database CollectionName Is Valid

MongoDB Database

Table 10-154 Checking whether the source database collection name is valid

Check Item Whether the source database collection name is valid

Description The source database collection names cannot containslashes (/) or backslashes (\).

Failure cause: The source database collection names cannotcontain the following characters: ,<>Handling suggestion: Modify the source database collectionnames that contain invalid characters or go back to theSelect Migration Type page and select the collections thatdo not contain invalid characters.

10.8.5 Checking Whether the Shard Key Can Be Obtainedfrom the Source Database


Table 10-155 Checking whether the shard keys can be obtained from the sourcedatabase

Check Item Whether the shard keys can be obtained from the sourcedatabase





Item to be confirmed: The source database is a replica setbut the shard keys have not been configured in thedestination database.Handling suggestion: If the destination database cannotobtain the shard keys of the source database, the data inthe source database will be migrated to the primary shardnode of the sharded cluster in the destination database. Tofully utilize the read/write performance, storage capability,and high availability of the cluster, see FAQs.

Item to be confirmed: The source database type isunknown, and the shard keys have not been configured inthe destination database.Handling suggestion: If the destination database cannotobtain the shard keys of the source database, the data inthe source database will be migrated to the primary shardnode of the sharded cluster in the destination database. Tofully utilize the read/write performance, storage capability,and high availability of the cluster, see FAQs.

Item to be confirmed: The source database containscollections that do not have shard keys configured.Handling suggestion: If the destination database cannotobtain the shard keys of the source database, the data inthe source database will be migrated to the primary shardnode of the sharded cluster in the destination database. Tofully utilize the read/write performance, storage capability,and high availability of the cluster, see FAQs.

10.8.6 Checking Whether the Source Database Schema NameIs Valid

PostgreSQL

Table 10-156 Checking whether the source database schema name is valid

Check Item Whether the source database schema name is valid

Description The source database schema names contain the followingunsupported characters: '" .


Failure cause: The source database schema names containunsupported characters.Handling suggestion: Run the following command tochange the source database schema names that containunsupported characters:alter schema old_name rename to new_name;






10.8.7 Checking Whether the Maximum Number of Chunks inthe Destination Database Is Sufficient

MongoDB Database

Table 10-157 Checking whether the maximum number of chunks in thedestination database is sufficient

Check Item Whether the maximum number of chunks in thedestination database is sufficient

Description The maximum number of chunks in the destinationdatabase is insufficient to support sharding and splitting ofthe source database. If the maximum number of chunks isreached, chunks are not split and the write performance isnegatively affected.


Item to be confirmed: The maximum number of chunks inthe destination database is insufficient to support shardingand splitting of the source database. If the maximumnumber of chunks is reached, chunks are not split and thewrite performance is negatively affected.Handling suggestion: Select a destination DB instance ofhigher specifications.

10.8.8 Checking Whether Archive Logs Are Enabled on theSource Oracle Database


Table 10-158 Checking whether archive logs are enabled on the source Oracledatabase

Check Item Whether archive logs are enabled on the source Oracle database

Description During incremental migration from Oracle to MySQL, archivelogs must be enabled on the source Oracle database.


Failure cause: Archive logs are not enabled on the source Oracledatabase.Handling suggestion: Run the alter database archivelogcommand to enable archive logs on the source Oracle database.



10.8.9 Checking Whether Supplemental Logging of the SourceOracle Database Meets Requirements

Oracle -> MySQL/Oracle -> PostgreSQL/Oracle -> GaussDB(for MySQL)/Oracle -> GaussDB Migration and Synchronization

Table 10-159 Checking whether supplemental logging of the source oracledatabase meets requirements

CheckItem

Whether supplemental logging of the source Oracle database meetsrequirements

Description

The supplemental logging of the source Oracle database must meetrequirements. Otherwise, the migration or synchronization fails.


Failure cause: The supplemental logging level of the source Oracledatabase does not meet requirements.Handling suggestion: Perform any of the following operations in thesource database:● Enable all supplemental logging at the database level: alter

database add supplemental log data (all) columns● Enable primary key and unique key supplemental logging: alter

database add supplemental log data (primary key,unique)columns

● Enable minimal supplemental logging: alter database addsupplemental log data; then run the following command to enableall, primary key, or unique key supplemental logging at the tablelevel for each to-be-synchronized table: alter table TABLE_NAMEadd supplemental log data(all) columns

10.9 Conflicts

10.9.1 Checking Whether the Names of the Source andDestination Databases Are the Same

MySQL Migration

Table 10-160 Checking whether the names of the source and destinationdatabases are the same

Check Item Whether the names of the source and destination databasesare the same

Description Check whether the names of the source and destinationdatabases are the same.







Handling suggestion:● If you are migrating data to the cloud, determine

whether to delete the databases with the same names asthe source databases or specify a new destination DBinstance based on site requirements.

● If you are migrating data out of the cloud, determinewhether to use the original destination database orspecify a new destination DB instance based on siterequirements.

Failure cause: During an incremental migration, the sourceand destination databases cannot have the same names.Handling suggestion: Determine whether to retain thesedatabases in the destination RDS DB instance or specifyanother destination RDS DB instance.


Oracle -> MySQL/Oracle -> GaussDB(for MySQL) Migration andSynchronization



Description Check whether the source and destination databases havethe same names to prevent existing databases from beingoverwritten. If the source and destination databases havethe same name, the migration cannot be performed.




Failure cause: Source database names are the same exceptfor letter cases.Handling suggestion: Change table names or do not migratethe tables with the same names.

Failure cause: Source database names are the same exceptfor letter cases.Handling suggestion: Select only one database among thedatabases whose names are the same except for lettercases.

Failure cause: The source and destination databases cannothave the same names.Handling suggestion: Determine whether to retain thesedatabases in the destination RDS DB instance or specifyanother destination RDS DB instance.

Oracle -> MySQL/Oracle -> GaussDB(for MySQL) Synchronization

Table 10-162 Checking Whether the Names of the Source and DestinationDatabases Are the Same


Description The mapping names of the tables to be synchronized in thesource databases are the same as the names of thedestination database tables.


Failure cause: The names of the tables to be synchronizedare already mapped to the destination database.Handling suggestion: Select other tables to migrate orchange the mapping names of the tables to besynchronized.




Description The migration fails when the names of the source anddestination databases are different.




Failure cause: The source and destination databases musthave the same names, except that the destination databasemust use only lowercase letters.Handling suggestion: Create a database with name inlowercase letters in the destination database.

Failure cause: The names of the objects to be migrated arethe same except for letter cases.Handling suggestion: Select only one database among thedatabases whose names are the same except for letter cases.

Failure cause: The names of the tables to be migrated arethe same except for letter cases.Handling suggestion: Change table names or do not migratethe tables with the same names.

Failure cause: The names of the tables to be migrated arethe same as those in the destination database and use onlylowercase letters.Handling suggestion: Change table names or do not migratethe tables with the same names.

Oracle -> GaussDB T Migration



Description The migration fails when the names of the source anddestination databases are different.


Failure cause: Some tables cannot be migrated becausetables with the same names already exist in the destinationdatabase.Handling suggestion: Select the tables that do not containsame table names or rename these tables. Commandexample: alter table old_name rename to new_name

Failure cause: Some databases or users cannot be migratedbecause the destination databases do not have thedatabases or users with the same name.Handling suggestion: Create these databases or users beforethe migration, or do not migrate these databases or users.






Description Check whether the source and destination databases havethe same names to prevent existing databases from beingoverwritten. If the source and destination databases have thesame name, the migration cannot be performed.


Failure cause: The destination database names cannot be thesame.Handling suggestion: Change the destination databasenames to prevent the database from being overwritten.



CheckItem

Whether the names of the source and destination databases are thesame

Description

Check whether the source and destination databases have the samenames to prevent existing databases from being overwritten. If thesource and destination databases have the same name, the migrationcannot be performed.


Failure cause: The destination database names cannot be the same.Handling suggestion: Change the destination database names toprevent the database from being overwritten.






Description Before synchronization from DDM to Oracle, databases orusers with the same names must be created in thedestination database.


Failure cause: Some databases cannot be synchronizedbecause the databases with the same names do not exist inthe destination databases.Handling suggestion: Create these database or users in thedestination databases or do not migrate these databases.

10.9.2 Checking Whether the Same View Names Exist in Boththe Source and Destination Databases

MongoDB -> DDS

Table 10-168 Checking whether the same view names exist in both the sourceand destination databases

Check Item Whether the same view names exist in both the source anddestination databases

Description Check whether the source and destination databases havethe same view names to prevent existing views from beingoverwritten. If view of the same name exists in thedestination database, the migration cannot be performed.


Failure cause: The same view names exist in both the sourceand destination databases.Handling suggestions: Delete the destination database viewsthat have the same names as those in the source database.Alternatively, do not migrate the views with the samenames.

10.9.3 Checking Whether the Destination Database Contains aNon-Empty Collection with the Same Name As the SourceDatabase

MongoDB Database

Table 10-169 Checking whether the destination database contains a non-emptycollection with the same name as the source database

Check Item Whether the destination database contains a non-emptycollection with the same name as the source database



Description Check whether the source and destination databases havethe same non-empty collections to prevent existingdatabases from being overwritten. If the source anddestination databases have the same collections, themigration cannot be performed.




Failure cause: The same non-empty collections exist in boththe source and destination databases.Handling suggestion: Determine whether to delete thesame non-empty collections from the destination DBinstance or specify a new destination DB instance.


10.9.4 Checking Whether Destination Database Contains theSame Table Names As the Synchronization Objects

MySQL > MySQL

Table 10-170 Checking whether destination database contains the same tablenames as the synchronization objects

Check Item Whether destination database contains the same tablenames as the synchronization objects. (table name conflicts)

Description If the source and destination databases have tables with thesame names, the existing tables may be overwritten. If thetables with the same name have the same structures, thetable names do not conflict. If table of the same name existsin the destination database, the migration cannot beperformed.


Failure cause: The source and destination database tablescannot have the same names.Handling suggestions: Check whether the tables with thesame names need to be retained. If yes, select another objectfor synchronization. If no, delete the tables with the samenames.



Failure cause: The destination database contains the sametable names as those of the synchronization objects.Handling suggestions: Check whether the tables with thesame names need to be retained. If yes, select another objectfor synchronization. If no, delete the tables with the samenames.

Failure cause: Both the source and destination databases areRDS DB instance and do not have mapped databases.Handling suggestion: Create mappings for the databases thatare not mapped.

10.9.5 Checking Whether the Destination Database ContainsObjects with the Same Name As Those in the SourceDatabase


Table 10-171 Checking whether the destination database contains objects withthe same name as those in the source database

Check Item Whether destination database contains objects with the samename as those in the source database

Description The destination database contains objects with the samename as those in the source database. If a table of the samename exists in the destination database, the migration cannotbe performed.


Failure cause: The source and destination database tablescannot have the same names.Handling suggestions: Check whether the tables with thesame names need to be retained. If yes, select another objectfor synchronization. If no, delete the tables with the samenames.

Failure cause: The destination database contains the sametable names as those of the synchronization objects.Handling suggestions: Check whether the tables with thesame names need to be retained. If yes, select another objectfor synchronization. If no, delete the tables with the samenames.




Table 10-172 Checking whether the destination database contains objects withthe same name as those in the source database

CheckItem

Whether the destination database contains objects with the samename as those in the source database

Description

The destination database contains objects with the same name asthose in the source database. If the same object names exist, themigration cannot be performed.


Failure cause: The destination database contains objects with the samename as those in the source database.Handling suggestions: Check whether the objects with the same namesneed to be retained. If yes, select another object for migration. If no,delete the objects with the same names.

PostgreSQL to PostgreSQL Table-Level Migration and Synchronization

Table 10-173 Checking whether destination database contains objects with thesame name as those in the source database

CheckItem

Whether destination database contains objects with the same name asthose in the source database

Description

The destination database contains objects with the same name asthose in the source database If the same object names exist, themigration cannot be performed.


Failure cause: The destination database contains objects with the samename as those in the source database.Handling suggestions: Check whether the objects with the same namesneed to be retained. If yes, select another object for migration. If no,delete the objects with the same names.



10.9.6 Checking Whether Collections in Both the Source andDestination Databases Are Not Capped

MongoDB Database

Table 10-174 Checking whether collections in both the source and destinationdatabases are not capped

Check Item Whether collections in both the source and destinationdatabases are not capped

Description Check whether collections in both the source anddestination databases are not capped. If not, the migrationfails.


Failure cause: the destination database has a collectionwhose name is the same as that of the capped collection ofthe source database.Handling suggestion: To ensure data consistency, you candelete the collection in the destination database with thesame name as the capped collection in the source database.Alternatively, you can choose not to migrate the cappedcollection that will contradict with that in the destinationdatabase.

Failure cause: The collections to be migrated are cappedcollections and already exist in the destination database.Handling suggestion: To ensure data consistency, you candelete the collection in the destination database with thesame name as the capped collection in the source database.Alternatively, you can choose not to migrate the cappedcollection that will contradict with that in the destinationdatabase.

10.10 SSL Connections

10.10.1 Checking Whether the SSL Connection Is CorrectlyConfigured

MySQL

Table 10-175 Checking whether the SSL connection is correctly configured

Check Item Whether the SSL connection is correctly configured

Description Check whether the SSL connection is correctly configuredfor the source database.







Item to be confirmed: The source database user must havethe REQUIRE SSL permission when using the SSLconnection.Handling suggestion: This alarm does not affect themigration process. If you require the SSL connection, youare advised to grant the REQUIRE SSL permission to thesource database user.

Item to be confirmed: The destination database user musthave the REQUIRE SSL permission when using the SSLconnection.Handling suggestion: This alarm does not affect themigration process. If you require the SSL connection, youare advised to grant the REQUIRE SSL permission to thedestination database user.

Failure cause: The source database user has the REQUIRESSL permission but did not upload the encryptioncertificate. The SSL connection cannot be used.Handling suggestion: On the Configure Source andDestination Databases page, enable the SSL connectionand upload the certificate, or change the source databaseuser.

Failure cause: The destination database user has theREQUIRE SSL permission but did not upload the encryptioncertificate. The SSL connection cannot be used.Handling suggestion: On the Configure Source andDestination Databases page, enable the SSL connectionand upload the certificate, or change the destinationdatabase user.

Item to be confirmed: Currently, the SSL connection is notenabled. DRS must ensure that the source database accountallows non-SSL connections to the source database.Handling suggestion: Manually check whether the sourcedatabase account allows non-SSL connections, or try toperform a migration. (By default, the source databaseaccount allows non-SSL connections.)




Failure cause: The SSL connection is enabled for the sourcedatabase but no certificate has been uploaded.Handling suggestion: On the Configure Source andDestination Databases page, upload a certificate or disablethe SSL connection for the source database.

MongoDB Database

Table 10-176 Checking whether the SSL connection is enabled for the sourcedatabase

Check Item Whether the SSL connection is enabled for the sourcedatabase

Description Check whether the SSL connection is enabled for the sourcedatabase.


Failure cause: SSL is enabled for the source database but nocertificate has been uploaded.Handling suggestion: Upload a certificate on the ConfigureSource and Destination Databases page, or disable SSLfor the source database.

10.10.2 Checking Whether the SSL Connection Is Enabled forthe Source Database

PostgreSQL

Table 10-177 Checking whether the SSL connection is enabled for the sourcedatabase

Check Item Whether the SSL connection is enabled for the sourcedatabase

Description Check whether the SSL connection is enabled for the sourcedatabase.


Failure cause: The source database SSL connection isdisabled.Handling suggestion: In the postgresql.conf file, setssl_ca_file to the directory of an SSL root CA certificate andset ssl to on to enable the SSL connection. Then, restart thedatabase for the modifications to take effect.



10.10.3 Checking Whether the SSL Certificate of the SourceDatabase Exists

MySQL > MySQL

Table 10-178 Checking whether the SSL certificate of the source database exists

Check Item Whether the SSL certificate of the source database exists

Description Check whether the SSL certificate type of the sourcedatabase is correct during MySQL to MySQLsynchronization. Otherwise, the synchronization fails.


Failure cause: The source database uses SSL to encryptconnections but the SSL certificate does not exist.Handing suggestion: On the Configure Source andDestination Databases page, enable SSL connection forthe source database and upload an encryption certificatethat contains only one beginning tag BEGIN CERTIFICATEand one end tag END CERTIFICATE.

Failure cause: The SSL certificate type of the sourcedatabase is not supported.Handing suggestion: On the Configure Source andDestination Databases page, enable SSL connection forthe source database and upload an encryption certificatethat contains only one beginning tag BEGIN CERTIFICATEand one end tag END CERTIFICATE.

10.10.4 Checking Whether the SSL Certificate of theDestination Database Exists

MySQL

Table 10-179 Checking whether the SSL certificate of the destination databaseexists

Check Item Whether the SSL certificate of the destination databaseexists

Description Check whether the SSL certificate type of the destinationdatabase is correct during migration. Otherwise, themigration fails.




Failure cause: The SSL certificate of the destination databasedoes not exist.Handing suggestion: On the Configure Source andDestination Databases page, enable SSL connection for thedestination database and upload an encryption certificatethat contains only one beginning tag BEGIN CERTIFICATEand one end tag END CERTIFICATE.

Failure cause: The SSL certificate type of the destinationdatabase is not supported.Handing suggestion: On the Configure Source andDestination Databases page, enable SSL connection for thedestination database and upload an encryption certificatethat contains only one beginning tag BEGIN CERTIFICATEand one end tag END CERTIFICATE.

10.10.5 Checking Whether Both the Source and DestinationDatabases Use SSL

MongoDB Database

Table 10-180 Checking whether both the source and destination databases useSSL to encrypt connections

Check Item Whether both the source and destination databases use SSLto encrypt connections

Description Check whether both the source and destination databasesuse SSL to encrypt connections.


Failure cause: Both the source and destination databasesuse SSL to encrypt connections.Handling suggestion: When migrating data to the cloud,disable SSL on the destination database. When migratingdata out of the cloud, disable SSL on the source database.To disable SSL, go to the DDS basic information page.

10.11 Object Dependencies



10.11.1 Checking Whether the Objects Referenced by ViewsAre Selected for Migration

MongoDB -> DDS

Table 10-181 Checking whether the objects referenced by views are selected formigration

Check Item Whether the objects referenced by views are selected formigration

Description The views and referenced objects should be migratedtogether. Otherwise, the migration fails.


Failure cause: The views to be migrated have dependencieson the objects that are not to be migrated.Handling suggestion: Select the referenced objects in themigration object list. Alternatively, do not migrate thedependent views.

10.11.2 Checking Whether Referenced Tables Are Selected forMigration


Table 10-182 Checking whether the tables referenced by the foreign key in thetable to be migrated are selected for migration.

Check Item Whether the tables referenced by the foreign key in the tableto be migrated are selected for migration.

Description The tables referenced by the foreign key in the table to bemigrated are not selected for migration.


Failure cause: Tables referenced by the foreign key in thetable to be migrated are not selected for migration.Handling suggestion: Select the referenced tables.

10.12 Source Database Information



10.12.1 Checking Whether the Shards and Mongos Are in theSame Cluster

MongoDB Database

Table 10-183 Checking whether the shards and mongos are in the same cluster

Check Item Whether the shards and mongos are in the same cluster

Description If the shards and mongos are not in the same cluster, themigration will fail.


Failure cause: The shards are in different clusters frommongos.Handling suggestion: On the connection test page, enter theshards which are in the same cluster as the mongos.

10.12.2 Checking Whether the Balancers of the SourceDatabase Is Enabled

MongoDB Database

Table 10-184 Checking whether the balancers of the source database is enabled

Check Item Whether the balancers of the source database are enabled

Description If the source database contains the collections whosebalancers are enabled, the migration will fail.


Failure cause: Balancers are enabled for the collections in thesource database.Handling suggestions: Disable balancers for the collections.

10.12.3 Checking Whether the Source and DestinationDatabase Types Match


Table 10-185 Checking whether the source and destination database types match

CheckItem

Whether the source and destination database types match



Description

If the source database type does not match the destination databasetype, the migration task will fail.


Failure cause: The source and destination database types do not match.Handling suggestion: If the source DB instance type is cluster, ensurethat the object type corresponding to the input IP address and port ofthe source database cluster is mongos, the source shard database typeis replica set, and the destination database type is cluster.



11 Troubleshooting

11.1 Backup Migration Failed Because Backup FilesCannot Be Found

ScenariosWhen you migrate full backups from self-built OBS buckets to clouds, thefollowing error message is displayed: restore:null.

Possible CausesThe possible causes are as follows:

● Backup files are deleted after you submit a backup migration task.● When you upload backup files to a self-built OBS bucket, you select Archive

for Storage Class. OBS archive storage offers cloud storage for rarely accesseddata. An archive file uploaded for the first time is in the Not restored status.As a result, a Microsoft SQL Server DB instance cannot download the file.

SolutionsBased on the previous analysis, solutions are provided as follows:

Solution 1If the migration fails because you delete the backup files, you can upload thedeleted backup files again to a self-built OBS bucket and select Standard forStorage Class. For details, see the Uploading a File or Folder section in theObject Storage Service Console Operation Guide.

Solution 2● If the migration failed because the storage class of your backup files is

Archive, perform the following steps. If the size of backup files is small,upload the backup files again to an OBS bucket and select Standard forStorage Class.

Data Replication ServiceUser Guide 11 Troubleshooting


https://support.huaweicloud.com/intl/en-us/clientogw-obs/obs_03_0024.html

For details, see the Uploading a File or Folder section in the Object StorageService Console Operation Guide.

Figure 11-1 Uploading a file

● If the backup files are large in size, log in to the OBS console and click thebucket to which the backup files are uploaded. On the displayed page, chooseObjects in the navigation pane on the left. On the Objects page, select theobject to be restored and click Restore above the file list. After the status ofthe backup files becomes Restored, submit an offline migration task again.For details, see the Restoring an Archive File on OBS section in the ObjectStorage Service Console Operation Guide.

11.2 Backup Migration Failed Because a BackupDatabase Cannot Be Found in the Backup Files

Scenarios

When you migrate full backups from self-built OBS buckets to clouds, the systemdisplays an error message indicating that the migration failed because the sourcedatabase cannot be found in the backup files.

Figure 11-2 Backup migration

Possible Cause

The name of a .bak backup file uploaded to a self-built OBS bucket is too long.



https://support.huaweicloud.com/intl/en-us/clientogw-obs/obs_03_0024.html

https://support.huaweicloud.com/intl/en-us/usermanual-obs/obs_03_0320.html

SolutionBased on the previous analysis, a solution is provided as follows:

Step 1 Check the name of the .bak backup file uploaded to a self-built OBS bucket byreferring to the Before You Apply section in the Data Replication Service QuickStart.

Step 2 Change the name of the backup file in the local database and upload the file to aself-built OBS bucket again.

----End



https://support.huaweicloud.com/intl/en-us/qs-drs/drs_offline_migration.html

A Change History

ReleasedOn

Description

2021-11-30 This issue is the thirty-fifth official release, which incorporatesthe following changes:● Supported real-time synchronization from GaussDB(for

openGauss) primary/standby to GaussDB(DWS).● Supported real-time synchronization from GaussDB(for

MySQL) primary/standby to MySQL.● Supported real-time synchronization from GaussDB(for

MySQL) primary/standby to GaussDB(DWS).● Supported real-time synchronization from DB2 for LUW to

GaussDB(for openGauss) primary/standby.● Supported real-time synchronization from DB2 for LUW to

GaussDB(for openGauss) distributed.● Supported re-editing and suspending real-time

synchronization from PostgreSQL to GaussDB (DWS).● Supported real-time synchronization from GaussDB(for

openGauss) distributed to GaussDB(DWS) in full+incrementalmode.

● Supported adding field types to additional columns duringMySQL to GaussDB(for MySQL) primary/standby dataprocessing.

Changed the following content:● The following scenarios are in the open beta test phase.

– Real-time synchronization from PostgreSQL toGaussDB(DWS)

– Real-time synchronization from DDM to MongoDB– Real-time synchronization from GaussDB(for openGauss)

primary/standby to Oracle– Real-time synchronization from GaussDB(for openGauss)

primary/standby to Kafka

Data Replication ServiceUser Guide A Change History


ReleasedOn

Description

– Real-time synchronization from GaussDB(for openGauss)primary/standby to GaussDB(for openGauss) distributed

– Real-time synchronization from GaussDB(for openGauss)primary/standby to GaussDB(for openGauss) primary/standby

– Real-time synchronization from GaussDB(for openGauss)distributed to MySQL

– Real-time synchronization from GaussDB(for MySQL)primary/standby to Kafka

– Real-time synchronization from GaussDB(for MySQL)primary/standby to Oracle

– Real-time synchronization from GaussDB(for MySQL)primary/standby to CSS/ES

– Real-time synchronization from self-built MySQL to CSS/ES– Real-time DR from MySQL to GaussDB(for MySQL)

primary/standby– Real-time DR from DDM-to-DDM.



ReleasedOn

Description

2021-09-30 This issue is the thirty-fourth official release, which incorporatesthe following changes:● Added the description of the product architecture and

principles.● Supported real-time synchronization from DDM to DDM.● Supported real-time synchronization from MySQL to Oracle.● Supported real-time synchronization from GaussDB(for

MySQL) primary/standby to Oracle.● Supported real-time synchronization from GaussDB(for

MySQL) primary/standby to Oracle.● Supported real-time incremental synchronization of MongoDB

out of the cloud.● Supported real-time synchronization from self-built MySQL to

Elasticsearch.● Supported object-level and row-level comparisons during

MySQL to GaussDB(for openGauss) distributed real-timesynchronization

● Supported DDL filtering in the MySQL to MySQL, MySQL toGaussDB(for MySQL), MySQL to GaussDB(DWS), and MySQLto PostgreSQL synchronization scenarios.

● Supported task cloning for MySQL real-time synchronization.● Added account migration progress statistics to the progress

details in real-time migration and real-time disaster recoveryscenarios.

Changed the following content:● The following scenarios meet the commercial user standard.

– Real-time synchronization from Oracle to DDM– Real-time synchronization from Oracle to PostgreSQL– Real-time synchronization from DDM to Kafka– Real-time synchronization from DDM to GaussDB(DWS)– Real-time synchronization from Oracle to PostgreSQL– Single-active DRS from GaussDB(for MySQL) primary/

standby to GaussDB(for MySQL) primary/standby



ReleasedOn

Description

2021-08-30 This issue is the thirty-third official release, which incorporatesthe following changes:● Supported real-time synchronization from MySQL to

ElasticSearch.● Supported real-time synchronization from GaussDB(for

openGauss) primary/standby to GaussDB(for openGauss)primary/standby.

● Supported real-time synchronization for PostgreSQL 13.● Supported JSON-C message format in MySQL to Kafka

synchronization scenario.● Supported migration of permissions and accounts in MySQL

to GaussDB(for MySQL) primary/standby migration scenario.● Supported exporting data comparison results.Changed the following content:● The following scenarios are in the open beta test phase.

– MySQL-> GaussDB(for openGauss) distributed– Oracle -> GaussDB(for openGauss) distributed– GaussDB(for openGauss) distributed -> Oracle– GaussDB(for openGauss) distributed -> GaussDB(DWS)– GaussDB(for openGauss) distributed -> Kafka– GaussDB(for openGauss) distributed -> GaussDB(for

openGauss) distributed● DRS real-time migration does not support the following

scenarios. If necessary, you can use the real-timesynchronization instead.– Oracle->MySQL– Oracle->PostgreSQL– Oracle -> GaussDB(for MySQL) primary/standby

● Supported selecting DRS task exception notifications from theSMN topic.



ReleasedOn

Description

2021-08-03 This issue is the thirty-first official release, which incorporates thefollowing changes:● Supported out-of-cloud synchronization from GaussDB(for

MySQL) primary/standby to Kafka.● Supported real-time synchronization from DDM to MySQL.● Supported real-time synchronization from PostgreSQL to

GaussDB(for openGauss) distributed in the cloud.● Supported real-time synchronization from PostgreSQL to

GaussDB(for openGauss) primary/standby in the cloud.● Supported filtering out the DELETE operation during out-of-

cloud synchronization from MySQL to Kafka.● Supported column processing for real-time synchronization

from MySQL to MySQL.● Supported real-time migration from MySQL to GaussDB(for

MySQL) primary/standby. The destination database can be setto Read/Write or Read-only.

● Supported user and permission synchronization and usercomparison during PostgreSQL to PostgreSQL real-timesynchronization.

Changed the following content:● Supported commercial use of Oracle to GaussDB(DWS)

synchronization.

2021-07-05 This issue is the thirty-first official release, which incorporates thefollowing changes:● Supported out-of-cloud synchronization from DDM to Kafka.● Supported flow control for MySQL to GaussDB(DWS)

synchronization tasks.● Added permissions, allowing users to perform all operations

except deleting DB instances.Changed the following content:● Charged fees for data transmission through a public network.● Adjusted fees for migrating databases out of the cloud.● Supported the commercial use of the following scenarios:

– Real-time synchronization from DDM to RDS for MySQL– Real-time synchronization from MySQL to RDS for

PostgreSQL– Real-time synchronization from MySQL to GaussDB(for

MySQL) primary/standby



ReleasedOn

Description

2021-05-31 This issue is the thirtieth official release, which incorporates thefollowing changes:● Supported real-time migration from MySQL to DDM and from

MySQL schema and logic table to DDM in VPN and DirectConnect networks.

● Supported tables without primary keys synchronized fromMySQL to GaussDB(DWS).

● Supported synchronization of some DDL operations duringincremental synchronization from MySQL to GaussDB(DWS).

● Supported synchronization of some DDL operations duringincremental synchronization from PostgreSQL to PostgreSQL.

Changed the following content:● Supported selecting DRS task exception notifications from the

SMN topic.

2021-04-30 This issue is the twenty-ninth official release, which incorporatesthe following changes:● Supported the following real-time synchronization scenarios:

– From Oracle to DDM.– From DDM to GaussDB(DWS)– From GaussDB(for openGauss) distributed to

GaussDB(DWS)● Supported real-time DR from DDM to DDM.Changed the following content:● Supported the commercial use of the following scenarios:

– Real-time migration from MySQL to DDM– Real-time migration from MySQL to GaussDB(for MySQL)– Real-time migration from Oracle to RDS MySQL– Real-time migration from Oracle to GaussDB(for MySQL)– Real-time migration from MySQL schema and logic table

to DDM– Real-time synchronization from the MySQL to GaussDB(for

MySQL) primary/standby– Real-time synchronization from Oracle to GaussDB(for

MySQL) primary/standby– Real-time synchronization from MySQL to GaussDB(DWS)– Real-time synchronization from Oracle to RDS MySQL.



ReleasedOn

Description

2021-03-30 This issue is the twenty-eighth official release, whichincorporates the following changes:● Supported real-time synchronization from Oracle to

GaussDB(for openGauss) distributed.● Supported real-time synchronization from MySQL and to

GaussDB(for MySQL) primary/standby.● Supported real-time synchronization from PostgreSQL to

GaussDB(DWS).● Supported incremental synchronization of MySQL databases.● Supported the pausing and resetting some synchronization

task.

2021-01-30 This issue is the twenty-seventeenth official release, whichincorporates the following changes:● Supported real-time import, editing, and processing of files

synchronized from Oracle to GaussDB(DWS).● Supported the real-time disaster recovery (DR) of

GaussDB(for MySQL) primary/standby.● Supported exporting task information on the real-time

disaster recovery page.

2020-12-30 This issue is the twenty-sixth official release, which incorporatesthe following changes:● Supported real-time synchronization from MySQL to

GaussDB(DWS).

2020-11-30 This issue is the twenty-fifth official release, which incorporatesthe following changes:● Supported editing and mapping objects for MySQL to

GaussDB(for openGauss) synchronization tasks.● Supported searching objects when the user selects objects.● Supported setting the number of days after which an

abnormal task can be automatically stopped.

2020-10-31 This issue is the twenty-fourth official release, which incorporatesthe following changes:● Added a description about delay in the migration,

synchronization, and DR scenarios.● Supported TTL settings at the row level in disaster recovery

from Cassandra to GaussDB(for Cassandra).Changed the following content:● Deleted the description of real-time migration of Microsoft

SQL Server databases.



ReleasedOn

Description

2020-09-30 This issue is the twenty-third official release, which incorporatesthe following changes:● Optimized the minimum permissions of the destination

database in the MySQL to GaussDB(for openGauss)synchronization scenario.

● Supported incremental startup of the GaussDB(foropenGauss) to MySQL synchronization task.

● Added constraints on the migration of PostgreSQL.● Added the description on the DR monitoring page, and the

connection needs to be reset after the RDS DB instance ispromoted to the primary DB instance.

2020-08-31 This issue is the twenty-second official release, whichincorporates the following changes:● Supported skipping data and pausing the synchronization

from DDM to Oracle.● Allowed users to specify the subnet where the instance resides

when creating a migration, synchronization, or DR task.Changed the following content:● Changed "online migration" to "real-time migration".● Changed "data synchronization" to "real-time

synchronization".● Changed "multi-active DR" to "real-time DR".

2020-07-31 This issue is the twenty-first official release, which incorporatesthe following changes:● Supported disaster recovery from Cassandra to GaussDB(for

Cassandra) for the first time.● Supported MySQL multi-table row filtering during

synchronization.● Allowed different users under the same tenant to manage

their own DRS tasks, and the tasks are invisible to each other.

2020-04-30 This issue is the twentieth official release, which incorporates thefollowing changes:● Supported exception diagnosis for heterogeneous migration

and synchronization.● Supported resumable uploads by creating a synchronization

task during Oracle to Kafka synchronization.



ReleasedOn

Description

2020-03-31 This issue is the nineteenth official release, which incorporatesthe following changes:● Supported disaster recovery from MySQL to GaussDB(for

MySQL) for the first time.● Supported DDM to Oracle synchronization for the first time.● Supported MySQL to PostgreSQL synchronization over public

networks.● Provided the task pausing function.● Supported MySQL to GaussDB(DWS) synchronization for the

first time.

2020-02-29 This issue is the eighteenth official release, which incorporatesthe following changes:● Supported pagination and querying for data synchronization.● Added the flow control mode for disaster recovery.● Supported forward and backward DR in multi-active DR.● Supported the change of the flow control mode after the task

is started.● Supported resetting passwords.● Disabled migration between self-built databases.

2020-01-30 This issue is the seventeenth official release, which incorporatesthe following changes:● Supported MySQL 8.0 for the first time.● Provided the quick comparison function. Users can directly

create a comparison task in the task list.● Supported alarm reporting for DR tasks.● Supported forcing tasks to stop.

2019-12-30 This issue is the sixteenth official release, which incorporates thefollowing changes:● Provided migration progress details so that the user can

monitor the migration progress.● Supported batch primary/standby switchover in disaster

recovery scenarios.● Added an entry that allows users to directly access the data

comparison page from the task list.● Supported migrations between on-premises MySQL

databases.



ReleasedOn

Description

2019-11-30 This issue is the fifteenth official release, which incorporates thefollowing changes:● Supported renaming databases during Microsoft SQL Server

backup and restoration.● Supported disaster recovery between RDS DB instances or

between self-built databases and RDS DB instances.● Supported selecting the current cloud as the active during

disaster recovery.● Supported the Oracle RAC cluster for incremental migration

between Oracle and MySQL.● Supported synchronizing MySQL out of the cloud.

2019-10-30 This issue is the fourteenth official release, which incorporatesthe following changes:● Supported partial migration of database accounts.● Supported checking backup files during backup migration.● Supported tag management.● Supported online multi-active DR.

2019-09-30 This issue is the thirteenth official release, which incorporates thefollowing changes:● Supported incremental migration from Oracle to MySQL

databases.● Supported full migration of triggers and events of PostgreSQL

databases.● Supported automatic reconnection and resumable data

transfer when network faults occur during full migration ofMySQL databases.

● Supported compute resources selection in the valuecomparison function of MySQL.

● Generated fees for MySQL migration and synchronization.● Supported user comparison for the MySQL migration process.



ReleasedOn

Description

2019-08-30 This issue is the twelfth official release, which incorporates thefollowing changes:● Supported the overwrite policy when conflicts occur during

MySQL synchronization.● Supported controlling the database replication rate in the VPN

and dedicate connect scenarios.● Supported migration of Definer for MySQL.● Supported migration of account permissions for MongoDB

databases.● Supported configuring multiple IP addresses for MongoDB

cluster databases.● Supported hyphens (-) in Microsoft SQL Server database

names.

2019-07-30 This issue is the eleventh official release, which incorporates thefollowing changes:● Supported the snapshot mode for MySQL full migration.● Canceled the retry function and supported the reset and

resume functions for MySQL database migration andsynchronization.

● Supported migrating and resetting account passwords.

2019-06-30 This issue is the tenth official release, which incorporates thefollowing changes:● Supported migrating DDS databases out of the cloud.● Canceled the binding of an EIP to the destination database

when migrating data to the cloud through a public network.● Supported resetting traffic flow during the migration or

synchronization of MySQL databases.

2019-05-30 This issue is the ninth official release, which incorporates thefollowing changes:● Supported full migration from Oracle to MySQL databases.● Optimized the parameter comparison function.

2019-04-30 This issue is the eighth official release, which incorporates thefollowing changes:● Supported full migration from Oracle to PostgreSQL

databases.● Supported VPN and Direct Connect in synchronization and

out-of-cloud migration scenarios.



ReleasedOn

Description

2019-03-30 This issue is the seventh official release, which incorporates thefollowing changes:● Supported online migration between DDS single-node

instances.● Displayed full migration progress by phase.● Supported viewing subscription data online.● Modified the consumption start time.● Supported modifying subscription objects.

2019-02-28 This issue is the sixth official release, which incorporates thefollowing changes:● Supported synchronization between PostgreSQL Enhanced

Editions through a VPC.● Supported online migration speed limitation for MySQL.● Supported migration of MySQL Finance Edition instances.● Supported filtering DROP DATABASE in MySQL to MySQL

synchronization.● Displayed mapping information in the synchronization

scenario.● Supported one-click confirmation of remarks.

2019-01-30 This issue is the fifth official release, which incorporates thefollowing changes:● Supported database alias in full backup migration and the

restoration of all databases.● Supported the migration of cluster instances of Enhanced

Edition.● Supported beta version of sending MySQL data subscription

information to the Kafka queue.

2019-01-19 This issue is the fourth official release, which incorporates thefollowing changes:● Supported editing the MySQL to MySQL synchronization task.● Supported MySQL to PostgreSQL synchronization.● Visualized data conflicts in data synchronization scenarios.● Supported table mapping for MySQL to PostgreSQL

synchronization.



ReleasedOn

Description

2018-12-30 This issue is the third official release, which incorporates thefollowing changes:● Supported parameter comparison for MySQL migration.● Supported incremental migrations from MongoDB replica sets

to clusters.● Optimized the synchronization mode and object.● Supported HUAWEI CLOUD Dedicated Computing Cluster

(DCC).

2018-11-30 This issue is the second official release, which incorporates thefollowing changes:● Supported the migration of MySQL database accounts.● Supported data synchronization.● Classified check items.● Supported selecting multiple .bak files during backup

migration.● Supported deleting tasks in batches.

2018-10-31 This issue is the first official release.



User Guide - Huawei Cloud

Documents

Transcript of User Guide - Huawei Cloud