Best Practices - support.huaweicloud.comBest Practices Summary This document provides practices of...

Data Replication Service

Best Practices

Issue 06

Date 2019-10-30

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2020. 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://e.huawei.com

Issue 06 (2019-10-30) Copyright © Huawei Technologies Co., Ltd. i

https://e.huawei.com

Contents

1 Best Practices Summary.........................................................................................................1

2 Migrating Databases Across Cloud Platforms.................................................................. 22.1 MySQL Database Migration................................................................................................................................................ 22.2 Microsoft SQL Server Database Migration...................................................................................................................182.3 PostgreSQL Database Migration..................................................................................................................................... 272.4 MongoDB Database Migration........................................................................................................................................ 38

3 Migrating Local Databases to Cloud................................................................................ 523.1 MySQL Database Migration.............................................................................................................................................. 523.2 Microsoft SQL Server Database Migration...................................................................................................................673.3 PostgreSQL Database Migration..................................................................................................................................... 763.4 MongoDB Database Migration........................................................................................................................................ 86

4 Migrating Self-Built Databases on ECS to Cloud...........................................................994.1 MySQL Database Migration.............................................................................................................................................. 994.2 Microsoft SQL Server Database Migration................................................................................................................ 1144.3 PostgreSQL Database Migration................................................................................................................................... 1244.4 MongoDB Database Migration...................................................................................................................................... 135

5 Migrating Microsoft SQL Server Backup Data to RDS SQL Server DB Instance...1505.1 Overview................................................................................................................................................................................1505.2 Migration Preparations..................................................................................................................................................... 1515.3 Exporting Backup Files......................................................................................................................................................1535.4 Uploading Backup Files.................................................................................................................................................... 1595.5 Scenario 1: Full Backup Migration................................................................................................................................1605.6 Scenario 2: Full+Incremental Backup Migration......................................................................................................1645.7 Manual Configuration.......................................................................................................................................................176

A Change History....................................................................................................................184

Data Replication ServiceBest Practices Contents

Issue 06 (2019-10-30) Copyright © Huawei Technologies Co., Ltd. ii

1 Best Practices Summary

This document provides practices of Data Replication Service (DRS) in commonapplication scenarios for you to quickly migrate databases.

Table 1-1 DRS best practices

Best Practices Description

Migrating Databases AcrossCloud Platforms

This section describes how to migrate othercloud databases to the databases on thecurrent cloud and provides correspondingprocedures and guidance for migration ofdifferent DB engines.

Migrating Local Databases toCloud

This section describes how to migrate on-premises databases to the databases on thecurrent cloud and provides correspondingprocedures and guidance for migration ofdifferent DB engines.

Migrating Self-Built Databaseson ECS to Cloud

This section describes how to migrate self-built databases on ECS to the databases onthe current cloud and providescorresponding procedures and guidance formigration of different DB engines.

Migrating Microsoft SQL ServerBackup Data to RDS SQL ServerDB Instance

This section describes how to migrate on-premises databases to the databases on thecurrent cloud using backup files.

Data Replication ServiceBest Practices 1 Best Practices Summary

Issue 06 (2019-10-30) Copyright © Huawei Technologies Co., Ltd. 1

https://support.huaweicloud.com/en-us/bestpractice-drs/drs_01_0002.html









2 Migrating Databases Across CloudPlatforms

2.1 MySQL Database Migration

2.2 Microsoft SQL Server Database Migration

2.3 PostgreSQL Database Migration

2.4 MongoDB Database Migration

2.1 MySQL Database MigrationDRS helps you migrate MySQL databases from other cloud platform to the MySQLDB instances on the current cloud. With DRS, you can migrate databases onlinewith zero downtime and your services and databases can remain operationalduring migration.

This section describes how to use DRS to migrate other cloud MySQL databases tothe MySQL DB instances on the current cloud. Migration scenarios are as follows:

● Migrate other cloud MySQL databases to MySQL DB instances on the currentcloud.

● Migrate other cloud self-built MySQL databases to MySQL DB instances onthe current cloud.

Data Replication ServiceBest Practices 2 Migrating Databases Across Cloud Platforms


Architecture

Figure 2-1 Online migration of other cloud MySQL databases

Figure 2-2 Online migration of other cloud self-built MySQL databases



Migration Process

Figure 2-3 Migration process

Migration Suggestions (Important)● Database migration is closely related to the environment and manual

operations. To ensure smooth migration, you are advised to perform a drillbefore the migration to help you detect and resolve problems in advance. Fordetails about how to minimize the impact on the database, see the followingsuggestion.

● It is strongly recommended that you start a migration task at a specified timeduring off-peak hours. Keeping data in static can effectively improve themigration success rate and prevent the migration from affecting serviceperformance.

Notes on Migration (Important)

NO TICE

Before creating a migration task, read the migration notes carefully.

For details, see the Before You Start section in the Data Replication ServiceGetting Started.



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

Migration Preparations1. Permissions

Table 2-1 lists the source and destination database user permissions requiredin full and incremental migrations from other cloud MySQL databases to theMySQL DB instances on the current cloud.

Table 2-1 Migration permissions

User Full MigrationPermission

Incremental MigrationPermission

Source database user SELECT, SHOW VIEW,and EVENT

SELECT, SHOW VIEW,EVENT, LOCK TABLES,REPLICATION SLAVE,and REPLICATIONCLIENT

Destination databaseuser

SELECT, CREATE, ALTER,DROP, DELETE, INSERT,UPDATE, INDEX,EVENT, CREATE VIEW,CREATE ROUTINE,TRIGGER, and WITHGRANT OPTION.


– Source database permission settings:The source MySQL database account must have all the requiredpermissions listed in Table 2-1. If the permissions are insufficient, createan account that has all of the permissions on the source database.Currently, you can use DRS to migrate databases on Alibaba Cloud,Tencent Cloud, and Amazon Web Services.For example, if you want to migrate a MySQL database from AlibabaCloud to a MySQL database on the current cloud, you are advised tocreate a premier account with the highest-level permission on the sourcedatabase. Since creating the account may cause the database to reboot,perform this operation at a proper time. For details, see Create a premieraccount.

– Destination database permission settings:If the destination database is a MySQL database on the current cloud, theinitial account can be used.

2. Network settingsEnable public accessibility for the source database.– Source database network settings:

Enable public accessibility for the source database.For example, if you want to migrate a MySQL database from AlibabaCloud to the MySQL database on the current cloud, you need to apply foran Internet IP address for your source database. For details, see relateddocuments provided by Alibaba Cloud.



https://www.alibabacloud.com/help/doc-detail/26130.htm#top

https://www.alibabacloud.com/help/doc-detail/26130.htm#top

https://www.alibabacloud.com/help/doc-detail/26128.htm

https://www.alibabacloud.com/help/doc-detail/26128.htm

– Destination database network settings:

By default, the destination database and the DRS replication instance arein the same VPC and can communicate with each other. No furtherconfiguration is required.

3. Security rules

– Source database security group settings:

Add the EIP of the replication instance to the whitelist of the sourceMySQL DB instance to allow the access from the EIP.

For example, if you want to migrate a MySQL database from AlibabaCloud to a MySQL database on the current cloud, you need to set thesource database whitelist by referring to related documents provided byAlibaba Cloud.

Before configuring the whitelist for the source database, you need toobtain the EIP of the DRS replication instance. You can find the EIP on theConfigure Source and Destination Databases page after creating thereplication instance on the DRS console.

Figure 2-4 EIP of the replication instance

You can also add 0.0.0.0/0 to the source database whitelist to allow anyIP address to access the source database but you must ensure that theabove does not pose a risk to your services.

After the migration is complete, you can delete the configuration fromthe whitelist.

– Destination database security group settings:


4. Other

DRS supports migration of some parameters that are closely related toservices and performance. For details about the parameters, see Parametersfor Comparison. If you need to migrate other parameters, manually set thembased on the service requirements.

Migration Procedure

Step 1 Create a migration task.

1. Log in to the management console and choose Database > Data ReplicationService to go to the DRS console.

2. On the Online Migration Management page, click Create Migration Task.

3. On the Create Replication Instance page, configure information about thetask and replication instance. Then, click Next.



https://www.alibabacloud.com/help/doc-detail/43185.htm?spm=a2c63.p38356.b99.38.6d3e3badm0GLrK

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


Figure 2-5 Task information

Table 2-2 Task information

Parameter Description

Task Name Consists of 4 to 64 characters, starts with a letter, and cancontain only letters (case-insensitive), digits, hyphens (-),and underscores (_).

SendNotifications

If the function is enabled, DRS will send notifications tothe specified recipients based on the mobile numbers andemail addresses you entered. If an exception occurs on themigration task, the system will send a notification to thespecified recipients.NOTE

Recipients must handle exceptions within 48 hours of receiving anSMS message or email.




Synchronization DelayThreshold

Indicates a time difference (in seconds) of synchronizationbetween the source and destination database.If the synchronization delay exceeds the threshold youspecify, DRS will send notifications to the specifiedrecipients. The value ranges from 1 to 3,600. The unit issecond.NOTE

In the early stages of an incremental migration, thesynchronization delay is long because a large quantity of data isawaiting synchronization. In this case, no notifications will besent.

Description Consists of a maximum of 256 characters and cannotcontain the following special characters: !=<>&'"

Table 2-3 Replication instance information


Data Flow Select To the cloud.

Source DBEngine

Select MySQL.

Destination DBEngine

Select MySQL.

Network Type Select Public network. You are advised to enable theSSL connection, which may reduce the migrationperformance by 20% to 30% but ensures data security.

Destination DBInstance

Select the MySQL DB instance you have purchased.

DestinationDatabase Access

Select Read-only as an example:– Read-only

During the migration, the destination databasebecomes read-only. After the migration is complete, itbecomes readable and writable. This option isrecommended because it ensures the integrity andsuccess rate of data migration.

– Read/WriteDuring the migration, the destination database can bereadable and writable. However, the data in themigration may be modified when operations areperformed or applications are connected. It should benoted that programs, even without services, cangenerate data operations, which may cause dataconflicts, task faults, and upload failure. You canselect this option after fully understanding the risks.




Migration Type Select Full+Incremental as an example:– Full: This migration type is suitable for scenarios

where service interruption is permitted. It migrates allobjects and data in non-system databases to thedestination database at one time. The objects includetables, views, stored procedures, and triggers.NOTE

If you perform a full migration, you are advised to stopoperations on the source database. Otherwise, datagenerated in the source database during the migration willnot be synchronized to the destination 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.

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

4. On the Configure Source and Destination Databases page, wait until the

replication instance is created. Then, configure source database anddestination database information. You are advised to click Test Connection inthe Source Database and Destination Database areas to check that both thesource and destination databases are connected. Then, select the check boxbefore the agreement and click Next.



Figure 2-6 Configuring source and destination database information

Table 2-4 Source database information


IP Address orDomain Name

Enter the IP address or domain name of the sourcedatabase.

Port Enter an integer ranging from 1 to 65535, whichindicates the port number of the source database.

DatabaseUsername

Enter the username of the source database.

DatabasePassword

Enter the password of the source database username.

SSL Connection To improve data security during a migration on a publicnetwork, you are advised to enable the SSL connectionto encrypt migration links and upload a CA certificate.

Table 2-5 Destination database information


DB InstanceName

The RDS MySQL DB instance you have selected duringthe replication instance creation is displayed by defaultand cannot be changed.




DatabaseUsername

Indicates the username for accessing the destinationMySQL DB instance.

DatabasePassword

Enter the password of the destination databaseusername.

Migrate Definerto User

– YesThe Definers of all source database objects will bemigrated to the user. Other users do not havepermissions on database objects unless these usersare authorized. For details on authorization, see HowDo I Maintain the Original Service User PermissionSystem After Definer Is Forcibly Converted DuringMySQL Migration? in the Data Replication ServiceFAQs.

– 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.

5. On the Set Task page, select a migration type and migration objects.

Figure 2-7 Migration objects



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




Table 2-6 Migration types and objects-public network


Flow Control You can choose whether or not to control the flow.– Control: You can custom the maximum migration speed.

In addition, you can set the time range based on yourservice requirements. 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 9999 Mbit/s.

– Not control: The migration speed is not limited and theoutbound bandwidth of the source database ismaximally used, which causes read consumption on thesource database accordingly. For example, if theoutbound bandwidth of the source database is 100Mbit/s and 80% bandwidth is used, the I/O consumptionon the source database is 80 Mbit/s.NOTE

▪ The flow control mode takes effect during a full migrationonly.

▪ Only users in the whitelist can use the flow control mode.You can apply for this function by submitting a serviceticket.

Filter DROPDATABASE

During data synchronization, executing DROP DATABASEon the source database may affect the datasynchronization capability. To reduce the risk of datasynchronization, DDL supports filtering DROP DATABASE.Currently, the database deletion operation can be filteredby default.– If this check box is selected, the database deletion

operation performed by the user on the source databaseis not synchronized during data synchronization.

– If this check box is deselected, related operations aresynchronized to the destination database during datasynchronization.

NOTEDROP DATABASE cannot be filtered for stored procedures.




MigrateAccount

During a database migration, accounts need to bemigrated separately.Accounts to be migrated can be classified into thefollowing types: accounts that can be migrated completely,accounts whose permissions need to be reduced, andaccounts that cannot be migrated. You can choose whetheror not to migrate the accounts as required.– Yes

If you choose to migrate accounts, see sectionMigrating Accounts in the Data Replication ServiceUser Guide to migrate database users, permissions, andpasswords.

– NoDuring the migration, accounts and permissions are notmigrated.

MigrateObject

All database objects can be migrated. After the objects aremigrated to the destination DB instance, the object namesremain the same as those in the source database andcannot be modified.You can migrate all objects or specified objects based onyour service requirements.– All: Migrates all objects in the source database to the

destination database.– Self-defined: Migrates self-defined objects to the

destination database.NOTE

If you choose not to migrate all of the databases, the migrationmay fail because the objects, such as stored procedures and views,in the database to be migrated may have dependencies on otherobjects that are not migrated. To prevent migration failure, you areadvised to migrate all of the databases.

6. On the Check Task page, check the migration task.

– If any check item fails, check the failure cause and rectify the fault. Afterthe fault is rectified, click Check Again.For details about how to handle check item failures, see the CheckingWhether the Source Database Is Connected section in the DataReplication Service User Guide.

– If all check items are successful, click Next.




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


Figure 2-8 Task Check

You can proceed to the next step only when all check items are successful. If anyalarms are generated, view and confirm the alarm details first before proceeding tothe next step.

7. Compare the parameters.The parameter comparison function helps you check the consistency ofcommon parameters and performance parameters between source anddestination databases and show inconsistent values. You can determinewhether to use this function based on service requirements. It mainly ensuresthat services are not affected after a migration is 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 areinconsistent, click Change to change the destination database values tobe the same as those of the source database.

Figure 2-9 Modifying common parameters



Performance parameter values in both the source and destination can bethe same or different.

▪ If you need to change the performance parameter values that areconsistent in the comparison results to different values, locate thetarget parameter, enter the values in the Change to column, andclick Change in the upper left corner.

▪ If you want to make the source and destination database values thesame:1) Click Use Source Database Value.

The system automatically makes the destination database valuesthe same as those of the source database.

Figure 2-10 One-click modification

You can also manually enter parameter values.

2) Click Save Change.The system changes the parameter values based on yoursettings for the destination database values. After themodification, the comparison results are automatically updated.

Figure 2-11 Performance parameters



Some parameters in the destination database cannot take effectimmediately. You need to restart the system for the modificationto take effect. The comparison result is inconsistent. In addition,restart the destination database before the migration task isstarted or after the migration task is completed. To minimize theimpact of database restart on your services, restart thedestination database at the scheduled time after the migrationis complete.For details about parameter comparison, see Parameters forComparison in the Data Replication Service User Guide.

3) Click Next.8. On the Confirm Task page, specify Start Time and click Next.

You are advised to start a migration task during off-peak hours ifencountering the following situations. If you have to migrate data duringpeak hours, you can select Yes for Flow Control to control the migrationspeed.

Figure 2-12 Confirming the task

9. After the task is submitted, go back to the Online Migration Managementpage to view the task status.

Step 2 Manage the migration task.

The migration task contains two phases: full migration and incremental migration.You can manage them in different phases.● Full migration

– Viewing the migration progress: You can click the target full migrationtask. On the Migration Progress tab, view the migration progress. Whenthe progress reaches 100%, the full migration is complete.

– Viewing migration details: In the migration details, you can view themigration progress of a specific object. If the number of objects is thesame as that of migrated objects, the migration is complete. You canview the migration progress of each object in details. Currently, thisfunction is available only to whitelisted users. You can submit a serviceticket to apply for this function.





● Incremental migration

– View the synchronization delay. After the full migration is complete, theincremental migration starts. On the Online Migration Managementpage, click the target migration task. On the displayed page, clickMigration Progress to view the synchronization delay of the incrementalmigration. When the synchronization delay is 0s, the destination databaseis synchronized with the source database in real time. You can also viewthe data consistency on the Migration Comparison tab.

Figure 2-13 Viewing the synchronization delay

– View the migration comparison results. On the Online MigrationManagement page, click the target migration task. On the displayedpage, click Migration Comparison and perform a migration comparisonin accordance to the following guidelines, helping you determine a propertime for migration to minimize service downtime.

Figure 2-14 Migration comparison process

For details, see the Comparing Migration Items section in the DataReplication Service User Guide.

Step 3 Start the cutover.

You are advised to start the cutover process during off-peak hours. Before thecutover, ensure that at least one complete data comparison is performed duringoff-peak hours. You can start a comparison at a specified time point during off-peak hours to obtain more specific comparison results. Due to slight timedifference and continuous operations on data, inconsistent comparison resultsmay be generated, reducing the reliability and validity of the results.

1. Interrupt services first. If the workload is not heavy, you may do not need tointerrupt the services.

2. Run the following statement on the source database and check whether anynew session executes SQL statements within 1 to 5 minutes. If not, the servicehas been stopped.show processlist



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

The process list queried by the preceding statement includes the connection of theDRS replication instance. If no additional session executes SQL statements, the servicehas been stopped.

3. On the Migration Progress page, view the synchronization delay. When thedelay is 0s and remains stable for a period, you can perform a data-levelcomparison between the source and destination databases. For details aboutthe time required, refer to the comparison results of the previous comparison.– If there is enough time, compare all objects.– If there is not enough time, use the data-level comparison to compare

the tables that are frequently used and that contain key business data orinconsistent data.

4. Determine a proper time to cut the services over to the destination database.After services are restored and available, the migration is complete.

Step 4 Stop or delete the migration task.

1. Stop the migration task. After databases and services are migrated to thedestination database, to prevent operations on the source database frombeing synchronized to the destination database to overwrite data, you canstop the migration task. This operation only deletes the replication instance,and the migration task is still displayed in the task list. You can view or deletethe task. You will not be charged for the migration task after the task isstopped.

2. Delete the migration task. After the migration task is complete, you candelete it. After the migration task is deleted, it will not be displayed in thetask list.

----End

2.2 Microsoft SQL Server Database MigrationDRS supports data migration from other cloud Microsoft SQL Server databases tothe Microsoft SQL Server DB instances on the current cloud. With DRS, you canmigrate databases online with zero downtime and your services and databasescan remain operational during migration.

This section describes how to use DRS to migrate other cloud Microsoft SQLServer databases to the Microsoft SQL Server DB instances on the current cloud.Migration scenarios are as follows:

● Migrate other cloud Microsoft SQL Server databases to the Microsoft SQLServer DB instances on the current cloud.

● Migrate other cloud self-built Microsoft SQL Server databases to the MicrosoftSQL Server DB instances on the current cloud.



Architecture

Figure 2-15 Full migration of other cloud Microsoft SQL Server databases

Figure 2-16 Full migration of other cloud self-built Microsoft SQL Serverdatabases



Migration Process





NO TICE




Table 2-7 lists the source and destination database user permissions requiredin full and incremental migrations from Microsoft SQL Server databases onother clouds to Microsoft SQL Server DB instances on the current cloud.







Source database user Must have thedb_owner permission.

Unsupported


Must have either of thefollowing permissions:dbcreator and CREATEANY DATABASE.

Unsupported

– Source database permission settings:The source Microsoft SQL Server database account must have all therequired permissions listed in Table 2-7. If the permissions areinsufficient, create an account that has all of the permissions on thesource database.

– Destination database permission settings:If the destination database is a Microsoft SQL Server database on thecurrent cloud, the initial account can be used.

2. Network settings– Source database network settings:

▪ Enable public accessibility for the source database.

▪ Ensure that the bandwidth is sufficient because a migration willoccupy large amounts of network bandwidth.

– Destination database network settings:Ensure that the destination Microsoft SQL Server instance is available andaccessible.

3. Security rules– Source database security group settings:

Add the EIPs of the replication instance to the whitelist of the source SQLServer DB instance.For example, if you want to migrate an Alibaba Cloud SQL Serverdatabase to a SQL Server database on the current cloud, you need to setthe source database whitelist by referring to Configure a whitelist.Before setting the network whitelist, you need to obtain the EIP of thereplication instance.After the replication instance is created, you can obtain its EIP from theConfigure Source and Destination Databases page.

Figure 2-18 Obtaining the replication instance EIP



https://www.alibabacloud.com/help/doc-detail/54529.htm?spm=a2c63.l28256.b99.33.2ebb3a3e0qFKq7

You can also add 0.0.0.0/0 to the source database whitelist to allow anyIP address to access the source database but you must ensure that theabove does not pose a risk to your services.


– Destination database security group settings:


4. Other

You need to export statements of creating users and jobs first and manuallyadd the statements to the destination Microsoft SQL Server instance on thecurrent cloud because the Microsoft SQL Server user information andscheduled jobs will not be migrated.

Migration Procedure



2. On the Online Migration Management page, click Create Migration Task.

3. On the Create Replication Instance page, configure information about thetask and replication instance. Then, click Next.

Figure 2-19 Replication instance information






SendNotifications



Description Consists of a maximum of 256 characters and cannotcontain the following special characters: !=<>'&"




Source DBEngine

Select Microsoft SQL Server.



Network Type Select Public network. You are advised to enable the SSLconnection, which may reduce the migrationperformance by 20% to 30% but ensures data security.


Select a Microsoft SQL Server DB instance you havepurchased.

Migration Type – FullIt migrates all data at one time. If you perform a fullmigration, you are advised to stop operations on thesource database. Otherwise, data generated in thesource database during the migration will not besynchronized to the destination database.











DatabaseUsername


DatabasePassword


SSL Connection To improve data security during a migration on a publicnetwork, you are advised to enable the SSL connection toencrypt migration links and upload a CA certificate.



DB InstanceName

The RDS Microsoft SQL Server DB instance you haveselected during the replication instance creation isdisplayed by default and cannot be changed.

DatabaseUsername

Indicates the username for accessing the destinationMicrosoft SQL Server DB instance.




DatabasePassword




Table 2-12 Migration types and objects


MigrationObject

Only full migration is supported. After the objects aremigrated to the destination Microsoft SQL Serverinstance, the object names will remain the same as thoseof the source database on the RDS Microsoft SQL Serverinstance and cannot be modified.










7. On the Confirm Task page, specify Start Time, select the check box beforethe agreement, and click Next.


– 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. If you have to migrate data during peak hours, you can select Yes forFlow Control to control the migration speed.

8. The migration task is started after you submit it. You can go back to theOnline Migration Management page to view the task status.


After a migration task is started, all data is migrated. You can manage the task onthe management console.



● Full migration

View the migration progress. On the Online Migration Management page,click the target full migration task. On the displayed page, click MigrationProgress to view the full migration progress in percentage. When the progressreaches 100%, the full migration is complete.

Figure 2-24 Viewing the full migration progress

Migration comparison: For a full migration task, you can click the task nameand check whether the migration objects of the source and destinationdatabases are consistent on the Migration Comparison tab.




----End

2.3 PostgreSQL Database MigrationDRS supports data migration from other cloud databases to the PostgreSQL DBinstances on the current cloud. With DRS, you can migrate databases online withzero downtime and your services and databases can remain operational duringmigration.

This section describes how to use DRS to migrate other cloud databases to thePostgreSQL DB instances on the current cloud. Migration scenarios are as follows:

● Migrate other cloud PostgreSQL databases to PostgreSQL DB instances on thecurrent cloud.

● Migrate other cloud self-built PostgreSQL databases to PostgreSQL DBinstances on the current cloud.



Architecture

Figure 2-25 Online migration of other cloud PostgreSQL databases

Figure 2-26 Online migration of other cloud self-built PostgreSQL databases



Migration Process






NO TICE







Table 2-13 lists the source and destination database user permissionsrequired in full and incremental migrations from other cloud PostgreSQLdatabases to the PostgreSQL DB instances on the current cloud.




Source database user SELECT, REFERENCES,TRIGGER, EXECUTE,and USAGE.

SUPERUSER orREPLICATION


SELECT and CREATEDB SELECT

– Source database permission settings:The source MySQL database account must have all the requiredpermissions listed in Table 2-13. If the permissions are insufficient, createan account that has all of the permissions on the source database.Currently, you can use DRS to migrate databases on Alibaba Cloud,Tencent Cloud, and Amazon Web Services.For example, if you want to migrate a PostgreSQL database from AlibabaCloud to the current cloud, you can use the initial account of the sourcedatabase.

– Destination database permission settings:If the destination database is a PostgreSQL database on the currentcloud, the initial account can be used.


Enable public accessibility for the source database.For example, if you want to migrate a PostgreSQL database from AlibabaCloud to the current cloud, you need to apply for an Internet IP addressfor your source database. For details, see related documents provided byAlibaba Cloud.

– Destination database network settings:The destination database needs no further configuration.

3. Security rules– Source database security group settings:

Add the EIP of the replication instance to the whitelist of the sourcePostgreSQL DB instance to allow the access from the EIP.For example, if you want to migrate a PostgreSQL database from AlibabaCloud to the current cloud, you need to set the source database whitelist



https://www.alibabacloud.com/help/doc-detail/97738.htm?spm=a2c63.l28256.b99.67.971113c7p1kmTw

by referring to related documents provided by Alibaba Cloud. Beforesetting the network whitelist, you need to obtain the EIP of thereplication instance.After the replication instance is created, you can obtain its EIP from theConfigure Source and Destination Databases page.


You can also add 0.0.0.0/0 to the source database whitelist. Thisconfiguration allows any IP addresses to access the source database,which may be insecure.After the migration is complete, you can delete the rules.

– Destination database security group settings:By default, the destination database and the DRS replication instance arein the same VPC and can communicate with each other. No furtherconfiguration is required.

4. OtherYou need to export PostgreSQL user information first and manually add it tothe destination database because the user information will not be migrated.

Migration Procedure



2. On the Online Migration Management page, click Create Migration Task.3. On the Create Replication Instance page, configure information about the

task, recipient, and replication instance. Then, click Next.



https://www.alibabacloud.com/help/doc-detail/43187.htm?spm=a2c63.p38356.b99.72.512225bbhc4WwG





SendNotifications













Source DBEngine

Select PostgreSQL.


Select PostgreSQL.



Select a PostgreSQL DB instance you have purchased.

Migration Type – FullIt migrates all data at one time. If you perform a fullmigration, you are advised to stop operations on thesource database. Otherwise, data generated in thesource database during the migration will not besynchronized to the destination database.– Full+IncrementalAn incremental migration can keep data consistencyafter a full migration is complete.You can select Full+Incremental to enable the sourceand destination database services to remain accessibleduring the migration.


replication instance is created. Then, configure source database anddestination database information. You are advised to click Test Connection in



the Source Database and Destination Database areas to check that both thesource and destination databases are connected. Then, select the check boxbefore the agreement and click Next.






Port Enter an integer ranging from 1 to 65535, which indicatesthe port number of the source database.

DatabaseUsername


DatabasePassword







DB InstanceName

The RDS PostgreSQL DB instance you have selectedduring the replication instance creation is displayed bydefault and cannot be changed.

DatabaseUsername

Indicates the username for accessing the destinationPostgreSQL DB instance.

DatabasePassword


















Viewing the migration progress: You can click the target full migration task.On the Migration Progress tab, view the migration progress. When theprogress reaches 100%, the full migration is complete.

● Incremental migration– View the synchronization delay. After the full migration is complete, the

incremental migration starts. On the Online Migration Managementpage, click the target migration task. On the displayed page, clickMigration Progress to view the synchronization delay of the incrementalmigration. When the synchronization delay is 0s, the destination databaseis synchronized with the source database in real time. You can also viewthe data consistency on the Migration Comparison tab.










2. Run the following statement on the source database and check whether anynew session executes SQL statements within 1 to 5 minutes. If not, the servicehas been stopped.SELECT procpid, start, now() - start AS execute_time, current_query FROM (SELECT backendid, pg_stat_get_backend_pid(S.backendid) AS procpid, pg_stat_get_backend_activity_start(S.backendid) AS start, pg_stat_get_backend_activity(S.backendid) AS current_query FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS S) AS S ORDER BY start;


3. On the Migration Progress page, view the synchronization delay. When thedelay is 0s and remains stable for a period, you can perform a data-level




comparison between the source and destination databases. For details aboutthe time required, refer to the comparison results of the previous comparison.– If there is enough time, compare all objects.– If there is not enough time, use the data-level comparison to compare






----End

2.4 MongoDB Database MigrationDRS supports data migration from other cloud MongoDB databases to DocumentDatabase Service (DDS) DB instances. With DRS, you can migrate databasesonline with zero downtime and your services and databases can remainoperational during migration.

This section describes how to use DRS to migrate other cloud MongoDB databasesto DDS DB instances online. Migration scenarios are as follows:

● Migrate other cloud MongoDB databases to DDS DB instances.● Migrate other cloud self-built MongoDB databases to DDS DB instances.



Architecture

Figure 2-35 Online migration of other cloud MongoDB databases

Figure 2-36 Online migration of other cloud self-built MongoDB databases



Migration Process






NO TICE







Table 2-18 lists the source and destination database user permissionsrequired in full and incremental migrations from other cloud MongoDBdatabases to DDS DB instances.






Source database user ● Replica set: Thesource databaseaccount must havethereadAnyDatabasepermission on theadmin database,and the readpermission on thedatabase to bemigrated.

● Cluster: The sourcedatabase accountmust have thereadAnyDatabasepermission on theadmin database andthe read permissionon the configdatabase and thedatabase to bemigrated.

● Single node: Thesource databaseaccount must havethereadAnyDatabasepermission on theadmin database andthe read permissionon the database tobe migrated.

● Replica set: Thesource databaseaccount must thereadAnyDatabasepermission on theadmin database andhave the readpermission on thedatabase to bemigrated and thelocal database.

● Single node: Thesource databaseaccount must thereadAnyDatabasepermission on theadmin database andhave the readpermission on thedatabase to bemigrated and thelocal database.

● Cluster: The sourcedatabase accountthat connects to themongos node mustthereadAnyDatabasepermission on theadmin database andhave the readpermission on theconfig database andthe databases to bemigrated. Thesource databaseaccount thatconnects to theshard nodes mustthereadAnyDatabasepermission on theadmin database andhave the readpermission on thelocal database and





the databases to bemigrated.


The destination database account must have thereadAnyDatabase permission on the admindatabase and the readWrite permission on thedestination database.

– Source database permission settings:

The source MongoDB database account must have all the requiredpermissions listed in Table 2-18. If the permissions are insufficient, createan account that has all of the permissions on the source database.Currently, you can use DRS to migrate databases on Alibaba Cloud,Tencent Cloud, and Amazon Web Services.For example, if you want to migrate an Alibaba Cloud MongoDBdatabase to a DDS database, you can use the initial account of the sourcedatabase.

– Destination database permission settings:If the destination database is a DDS database, the initial account can beused.


Enable public accessibility for the source database.For example, if you want to migrate an Alibaba Cloud MongoDBdatabase to a DDS database, you need to apply for a public IP address foryour source database. For details, see related documents provided byAlibaba Cloud.

– Destination database network settings: No settings are required.3. Security rules

– Source database security group settings:Add the EIPs of the replication instance to the whitelist of the sourcedatabase.For example, if you want to migrate an Alibaba Cloud MongoDBdatabase to a DDS database, you need to set the source databasewhitelist by referring to related documents provided by Alibaba Cloud.Before setting the network whitelist, you need to obtain the EIP of thereplication instance.

▪ After the replication instance is created, you can obtain its EIP fromthe Configure Source and Destination Databases page.




https://www.alibabacloud.com/help/doc-detail/63981.htm?spm=a2c63.p38356.b99.22.450f37d12w93gW

https://www.alibabacloud.com/help/doc-detail/54529.htm?spm=a2c63.l28256.b99.17.52503a3efZ99t8

You can also add 0.0.0.0/0 to the source database whitelist. Thisconfiguration allows any IP addresses to access the source database,which may be insecure.After the migration is complete, you can delete the configuration fromthe whitelist.

– Destination database security group settings:By default, the destination database and the DRS replication instance arein the same VPC and can communicate with each other. No furtherconfiguration is required.

4. OtherYou need to export the user information of the MongoDB database first andmanually add it to the destination DDS DB instance because the userinformation will not be migrated.

Migration Procedure











SendNotifications










Source DBEngine

Select MongoDB database.


Select DDS.



Select a DDS DB instance you have purchased.








DatabaseUsername


DatabasePassword





DB InstanceName

The DDS DB instance you have selected during thereplication instance creation is displayed by default andcannot be changed.

DatabaseUsername

Enter the username for accessing the destination DDS DBinstance.

DatabasePassword

Enter the password for accessing the destination DDS DBinstance.







MigrationObject

Select the objects to be migrated. The objects can beeither databases or tables. After the objects are migratedto the destination DB instance, the object names remainthe same as those in the source database and cannot bemodified.


















2. Run the following statement on the source database and check whether anynew session executes SQL statements within 1 to 5 minutes. If not, the servicehas been stopped.db.currentOp()


3. On the Migration Progress page, view the synchronization delay. When thedelay is 0s and remains stable for a period, you can perform a data-levelcomparison between the source and destination databases. For details aboutthe time required, refer to the comparison results of the previous comparison.




– If there is enough time, compare all objects.– If there is not enough time, use the data-level comparison to compare






----End



3 Migrating Local Databases to Cloud





3.1 MySQL Database MigrationDRS supports data migration from local MySQL databases to the MySQL DBinstances on the current cloud. With DRS, you can migrate databases online withzero downtime and your services and databases can remain operational duringmigration.

This section describes how to use DRS to migrate local MySQL databases to RDSMySQL DB instances on the current cloud. The following network types aresupported:

● Virtual Private Network (VPN)● Public network

Architecture

Figure 3-1 VPN

Data Replication ServiceBest Practices 3 Migrating Local Databases to Cloud


Figure 3-2 Public network+SSL connection

Migration Process








NO TICE




Table 3-1 lists the source and destination database user permissions requiredin full and incremental migrations from local MySQL databases to the MySQLDB instances on the current cloud.









– Source database permission settings:The source database account must have all the required permissionslisted in Table 3-1. If the permissions are insufficient, create a user thathas all of the permissions on the source database.



You can migrate local MySQL databases to the MySQL databases on thecurrent cloud through a VPN or public network. Enable publicaccessibility or establish a VPN for local MySQL databases based on the




site requirements. You are advised to migrate data through a publicnetwork, which is more convenient and cost-effective.


▪ If the source database attempts to access the destination databasethrough a VPN, you need to enable the HUAWEI CLOUD VPN servicefirst so that the source database can communicate with thedestination RDS network.

▪ If the source database attempts to access the destination databasethrough a public network, you do not need to configure thedestination database.

3. Security rules

a. Source database security group settings:

▪ If the migration is performed over a public network, add the EIP ofthe DRS replication instance to the network whitelist of the sourceMySQL database to enable the source MySQL database tocommunicate with the current cloud. Before setting the networkwhitelist, you need to obtain the EIP of the replication instance.The IP address on the Configure Source and Destination Databasespage is the EIP of the replication instance.

Figure 3-4 EIP of the replication instance

▪ If the migration is performed over a VPN network, add the private IPaddress of the DRS replication instance to the network whitelist ofthe source MySQL database to enable the source MySQL database tocommunicate with the current cloud. The IP address on theConfigure Source and Destination Databases page is the private IPaddress of the replication instance.

After the migration is complete, you can delete the rules.b. Destination database security group settings:


4. OtherDRS supports migration of some parameters that are closely related toservices and performance. For details about the parameters, see Parametersfor Comparison. If you need to migrate other parameters, manually set thembased on the service requirements.

Migration ProcedureThe following describes how to use DRS to migrate a local MySQL database to anRDS MySQL DB instance online.








task and replication instance. Then, click Next.

Figure 3-5 Task information




SendNotifications













Source DBEngine

Select MySQL.


Select MySQL.



Select the MySQL DB instance you have purchased.



During the migration, the destination databasebecomes read-only. After the migration is complete, itbecomes readable and writable. This option isrecommended because it ensures the integrity andsuccess rate of data migration.

– Read/WriteDuring the migration, the destination database can bereadable and writable. However, the data in themigration may be modified when operations areperformed or applications are connected. It should benoted that programs, even without services, cangenerate data operations, which may cause dataconflicts, task faults, and upload failure. You canselect this option after fully understanding the risks.









DatabaseUsername


DatabasePassword


SSL Connection To improve data security during a migration on a publicnetwork, you are advised to enable the SSL connectionto encrypt migration links and upload a CA certificate.



DB InstanceName





DatabaseUsername

Indicates the username for accessing the destinationMySQL DB instance.

DatabasePassword



– YesThe Definers of all source database objects will bemigrated to the user. Other users do not havepermissions on database objects unless these usersare authorized. For details on authorization, see HowDo I Maintain the Original Service User PermissionSystem After Definer Is Forcibly Converted DuringMySQL Migration? in the Data Replication ServiceFAQs.










Table 3-6 Migration types and objects-public network


Flow Control You can choose whether or not to control the flow.– Control: You can custom the maximum migration speed.

In addition, you can set the time range based on yourservice requirements. 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 9999 Mbit/s.

– Not control: The migration speed is not limited and theoutbound bandwidth of the source database ismaximally used, which causes read consumption on thesource database accordingly. For example, if theoutbound bandwidth of the source database is 100Mbit/s and 80% bandwidth is used, the I/O consumptionon the source database is 80 Mbit/s.NOTE

▪ The flow control mode takes effect during a full migrationonly.

▪ Only users in the whitelist can use the flow control mode.You can apply for this function by submitting a serviceticket.

Filter DROPDATABASE

During data synchronization, executing DROP DATABASEon the source database may affect the datasynchronization capability. To reduce the risk of datasynchronization, DDL supports filtering DROP DATABASE.Currently, the database deletion operation can be filteredby default.– If this check box is selected, the database deletion

operation performed by the user on the source databaseis not synchronized during data synchronization.






MigrateAccount

During a database migration, accounts need to bemigrated separately.Accounts to be migrated can be classified into thefollowing types: accounts that can be migrated completely,accounts whose permissions need to be reduced, andaccounts that cannot be migrated. You can choose whetheror not to migrate the accounts as required.– Yes

If you choose to migrate accounts, see sectionMigrating Accounts in the Data Replication ServiceUser Guide to migrate database users, permissions, andpasswords.


MigrateObject

All database objects can be migrated. After the objects aremigrated to the destination DB instance, the object namesremain the same as those in the source database andcannot be modified.You can migrate all objects or specified objects based onyour service requirements.– All: Migrates all objects in the source database to the



If you choose not to migrate all of the databases, the migrationmay fail because the objects, such as stored procedures and views,in the database to be migrated may have dependencies on otherobjects that are not migrated. To prevent migration failure, you areadvised to migrate all of the databases.











▪ If you want to make the source and destination database values thesame:1) Click Use Source Database Value.

The system automatically makes the destination database valuesthe same as those of the source database.








3) Click Next.8. On the Confirm Task page, specify Start Time and click Next.

You are advised to start a migration task during off-peak hours ifencountering the following situations. If you have to migrate data duringpeak hours, you can select Yes for Flow Control to control the migrationspeed.











● Incremental migration

– View the synchronization delay. After the full migration is complete, theincremental migration starts. On the Online Migration Managementpage, click the target migration task. On the displayed page, clickMigration Progress to view the synchronization delay of the incrementalmigration. When the synchronization delay is 0s, the destination databaseis synchronized with the source database in real time. You can also viewthe data consistency on the Migration Comparison tab.



















----End

3.2 Microsoft SQL Server Database MigrationDRS supports data migration from local Microsoft SQL Server databases toMicrosoft SQL Server DB instances on the current cloud. With DRS, you canmigrate databases online with zero downtime and your services and databasescan remain operational during migration.

This section describes how to use DRS to migrate local Microsoft SQL Serverdatabases to Microsoft SQL Server DB instances on the current cloud. Thefollowing network types are supported:

● VPN● Public network



Architecture

Figure 3-15 VPN


Migration Process







NO TICE




Table 3-7 lists the source and destination database user permissions requiredin full and incremental migrations from Microsoft SQL Server databases onother clouds to Microsoft SQL Server DB instances on the current cloud.





Unsupported



Unsupported




You can migrate local Microsoft SQL Server databases to Microsoft SQLServer databases on the current cloud through a VPN or public network.




Enable public accessibility or establish a VPN for local Microsoft SQLServer databases based on the site requirements.If you migrate databases on a public network, pay attention to thefollowing:

▪ Ensure that the bandwidth is sufficient because a migration willoccupy large amounts of network bandwidth.



▪ If the source database attempts to access the destination databasethrough a public network, you need to ensure the destination DBinstance is available and accessible. No need to bind an EIP to thedestination DB instance.

3. Security rules


▪ If the migration is performed through a VPN network, you need toadd the private IP address of the DRS replication instance to thewhitelist of the source database to allow the private IP address toaccess to the source database.

▪ If the migration is performed through a public network, you need toadd the EIP of the DRS replication instance to the whitelist of thesource database to allow the EIP to access to the source database.

The IP address on the Configure Source and Destination Databases page is theEIP or private IP address of the replication instance.

b. Destination database security group settings:By default, the destination database and the DRS replication instance arein the same VPC and can communicate with each other. No furtherconfiguration is required.

4. OtherYou need to export statements of creating users and jobs first and manuallyadd the statements to the destination Microsoft SQL Server instance on thecurrent cloud because the Microsoft SQL Server user information andscheduled jobs will not be migrated.

Migration Procedure

The following describes how to use DRS to migrate a local Microsoft SQL Serverdatabase to a Microsoft SQL Server DB instance on the current cloud.






task and replication instance. Then, click Next.





SendNotifications









Source DBEngine




Network Type Select Public network. You are advised to enable the SSLconnection, which may reduce the migrationperformance by 20% to 30% but ensures data security.


Select a Microsoft SQL Server DB instance you havepurchased.

Migration Type – FullIt migrates all data at one time. If you perform a fullmigration, you are advised to stop operations on thesource database. Otherwise, data generated in thesource database during the migration will not besynchronized to the destination database.











DatabaseUsername


DatabasePassword





DB InstanceName

The RDS Microsoft SQL Server DB instance you haveselected during the replication instance creation isdisplayed by default and cannot be changed.

DatabaseUsername

Indicates the username for accessing the destinationMicrosoft SQL Server DB instance.

DatabasePassword








MigrationObject

















After a migration task is started, all data is migrated. You can manage the task onthe management console.● Full migration









----End

3.3 PostgreSQL Database MigrationDRS supports data migration from local MySQL databases to the PostgreSQL DBinstances on the current cloud. With DRS, you can migrate databases online withzero downtime and your services and databases can remain operational duringmigration.

This section describes how to configure the DRS to migrate the local PostgreSQLdatabase to the PostgreSQL database on the current cloud. The following networktypes are supported:


Architecture

Figure 3-24 VPN network




Migration Process








NO TICE




Table 3-13 lists the source and destination database user permissionsrequired in full and incremental migrations from local PostgreSQL databasesto the PostgreSQL DB instances on the current cloud.









– Destination database permission settings:If the destination database is a PostgreSQL database on the currentcloud, the initial account can be used.


You can migrate local PostgreSQL databases to RDS PostgreSQLdatabases on the current cloud through a VPN or public network. Enablepublic accessibility or establish a VPN for local PostgreSQL databasesbased on the site requirements. You are advised to migrate data througha public network, which is more secure.






▪ If the source database attempts to access the destination databasethrough a public network, you do not need to configure thedestination database.

3. Security rules


▪ If the migration is performed over a public network, add the EIP ofthe DRS replication instance to the whitelist of the sourcePostgreSQL database to enable the source database to communicatewith the current cloud.

▪ If the migration is performed over a VPN network, add the private IPaddress of the DRS replication instance to the network whitelist ofthe source database to enable the source database to communicatewith the destination database.

The IP address on the Configure Source and Destination Databases pageis the EIP or private IP address of the replication instance.

After the migration is complete, you can delete the rules.b. Destination database security group settings:


4. OtherYou need to export PostgreSQL user information first and manually add it tothe destination database because the user information will not be migrated.

Migration Procedure











SendNotifications













Source DBEngine

Select PostgreSQL.


Select PostgreSQL.
















DatabaseUsername


DatabasePassword







DB InstanceName


DatabaseUsername

Indicates the username for accessing the destinationPostgreSQL DB instance.

DatabasePassword


















----End

3.4 MongoDB Database MigrationDRS supports data migration from local MongoDB databases to DDS DB instances.With DRS, you can migrate databases online with zero downtime and yourservices and databases can remain operational during migration.

This section describes how to use DRS to migrate local MongoDB databases toDDS DB instances. The following network types are supported:


Architecture

Figure 3-33 VPN




Migration Process








NO TICE




Table 3-18 lists the source and destination database user permissionsrequired in full and incremental migrations from local MongoDB databases toDDS DB instances.












You can migrate local MongoDB databases to DDS databases onlinethrough a VPN or public network. Enable public accessibility or establisha VPN for local MongoDB databases based on the site requirements. Youare advised to migrate data through a public network, which is moresecure.


▪ If the source database accesses the destination database through aVPN, enable the VPN service first so that the source database cancommunicate with the destination DDS network.

▪ If you access the DDS DB instance through a public network, nonetwork settings are required.

3. Security rules

a. Source database network settings:

▪ If the migration is performed over a public network, add the EIPs ofthe replication instance to the whitelist of the source database.Before setting the network whitelist, you need to obtain the EIP ofthe replication instance.After the replication instance is created, you can obtain its EIP fromthe Configure Source and Destination Databases page.




You can also add 0.0.0.0/0 to the source database whitelist. Thisconfiguration allows any IP addresses to access the source database,which may be insecure.

▪ If the migration is performed over a VPN network, add the private IPaddress of the DRS replication instance to the whitelist of the sourcedatabase to enable the source database to communicate with thedestination database.


b. Destination database security group settings:By default, the destination database and the DRS replication instance arein the same VPC and can communicate with each other. No furtherconfiguration is required.

4. OtherYou need to export the user information of the MongoDB database first andmanually add it to the destination DDS DB instance because the userinformation will not be migrated.

Migration ProcedureThe following describes how to use DRS to migrate a local MongoDB database toa DDS DB instance online.











SendNotifications













Source DBEngine



Select DDS.
















DatabaseUsername


DatabasePassword







DB InstanceName

The DDS DB instance you have selected during thereplication instance creation is displayed by default andcannot be changed.

DatabaseUsername

Enter the username for accessing the destination DDS DBinstance.

DatabasePassword

Enter the password for accessing the destination DDS DBinstance.


Figure 3-39 Migration object


Parameter

Description

Migration Object

Select the objects to be migrated. The objects can be eitherdatabases or tables. After the objects are migrated to thedestination DB instance, the object names remain the same asthose in the source database and cannot be modified.


















You are advised to start the cutover process during off-peak hours. Before thecutover, ensure that at least one complete data comparison is performed duringoff-peak hours. You can start a comparison at a specified time point during off-peak hours to obtain more specific comparison results. Due to slight time




difference and continuous operations on data, inconsistent comparison resultsmay be generated, reducing the reliability and validity of the results.










----End



4 Migrating Self-Built Databases on ECSto Cloud





4.1 MySQL Database MigrationDRS supports data migration from self-built MySQL databases on ECS to theMySQL DB instances on the current cloud. With DRS, you can migrate databasesonline with zero downtime and your services and databases can remainoperational during migration.

This section describes how to use DRS to migrate self-built MySQL databases onECS to the MySQL DB instances on the current cloud. The following networkscenarios are supported:

● Source and destination databases are in the same VPC.● Source and destination databases are in different VPCs.

Data Replication ServiceBest Practices 4 Migrating Self-Built Databases on ECS to Cloud


Architecture

Figure 4-1 Source and destination databases in the same VPC

Figure 4-2 Source and destination databases in the same region and differentVPCs



Migration Process






NO TICE







Table 4-1 lists the source and destination database user permissions requiredin full and incremental migrations from self-built MySQL databases on ECS tothe MySQL DB instances on the current cloud.











2. Network settings– The source and destination databases must be in the same region.– The source and destination databases can be either in the same VPC or

different VPCs.

▪ If the source and destination databases are in the same VPC, thenetworks are interconnected by default.

▪ If the source and destination databases are in different VPCs, thesubnets of the source and destination databases are required to be indifferent CIDR blocks. You need to create a VPC peering connectionbetween the two VPCs. For details, see VPC Peering ConnectionCreation Procedure.

3. Security rules– In the same VPC, the network is connected by default. You do not need

to set a security group.



https://support.huaweicloud.com/en-us/usermanual-vpc/en-us_topic_0046655036.html


– In different VPCs, establish a VPC peering connection between the twoVPCs. You do not need to set a security group.

4. OtherDRS supports migration of some parameters that are closely related toservices and performance. For details about the parameters, see Parametersfor Comparison. If you need to migrate other parameters, manually set thembased on the service requirements.

Migration Procedure



2. On the Online Migration Management page, click Create Migration Task.3. On the Create Replication Instance page, specify the task name and

description, notification recipient information, and replication instanceinformation. Then, click Next.









SendNotifications










Source DBEngine

Select MySQL.


Select MySQL.

Network Type Select VPC.


Select an RDS MySQL DB instance you have purchased.






During the migration, the destination database isread-only. After the migration is complete, it becomesreadable and writable. This option insures theintegrity and success rate of data migration.

– Read/WriteDuring the migration, the destination database isreadable and writable. Do not modify the data beingmigrated. Otherwise, data conflicts will result inmigration failures.













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. For details onhow to create a VPC, see the Creating a VPC section inthe Virtual Private Cloud User Guide.

Subnet A subnet provides dedicated network resources that arelogically isolated from other networks, improving networksecurity. Subnets can take effect only in AZs. You need toenable the Dynamic Host Configuration Protocol (DHCP)for subnets where you plan to create the source database,and cannot disable the DHCP during creation. For detailson how to create a VPC, see the Creating a VPC sectionin the Virtual Private Cloud User Guide.









DatabaseUsername


DatabasePassword


SSL Connection You can enable the SSL connection to encrypt migrationlinks and upload an encrypted certificate.



DB InstanceName


DatabaseUsername

Enter the username of the destination database.

DatabasePassword



– YesThe Definers of all source database objects will bemigrated to the user. Other users do not havepermissions on 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? in the Data Replication ServiceFAQs.


5. On the Set Task page, select migration accounts and migration objects.

Figure 4-6 Migration Type








Parameter

Description

FilterDROPDATABASE

During data synchronization, executing DROP DATABASE onthe source database may affect the data synchronizationcapability. To reduce the risk of data synchronization, DDLsupports filtering DROP DATABASE.Currently, the database deletion operation can be filtered bydefault.– If this check box is selected, the database deletion operation

performed by the user on the source database is notsynchronized during data synchronization.



MigrateAccount

During a database migration, accounts need to be migratedseparately.Accounts to be migrated can be classified into the followingtypes: accounts that can be migrated completely, accountswhose permissions need to be reduced, and accounts thatcannot be migrated. You can choose whether or not to migratethe accounts as required.– Yes

During a database migration, accounts need to be migratedseparately.Accounts to be migrated can be classified into the followingtypes: accounts that can be migrated completely, accountswhose permissions need to be reduced, and accounts thatcannot be migrated. You can choose whether or not tomigrate the accounts as required.

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

▪ NoDuring the migration, accounts, permissions, andpasswords are not migrated.






Parameter

Description

MigrateObject

All database objects can be migrated. After the objects aremigrated to the destination DB instance, the object namesremain the same as those in the source database and cannotbe modified.You can migrate all objects or specified objects based on yourservice requirements.– All: Migrates all objects in the source database to the



If you choose not to migrate all of the databases, the migration mayfail because 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, you are advised tomigrate all of the databases.















▪ If you want to make the source and destination database values thesame:

1) Click Use Source Database Value.The system automatically makes the destination database valuesthe same as those of the source database.








3) Click Next.





8. On the Confirm Task page, specify Start Time, select the check box beforethe agreement, and click Next.You are advised to start a migration task during off-peak hours ifencountering the following situations. If you have to migrate data duringpeak hours, you can select Yes for Flow Control to control the migrationspeed.




















3. On the Migration Progress page, view the synchronization delay. When thedelay is 0s and remains stable for a period, you can perform a data-levelcomparison between the source and destination databases. For details aboutthe time required, refer to the comparison results of the previous comparison.– If there is enough time, compare all objects.




– If there is not enough time, use the data-level comparison to comparethe tables that are frequently used and that contain key business data orinconsistent data.





----End

4.2 Microsoft SQL Server Database MigrationDRS supports data migration from self-built Microsoft SQL Server databases onECS to the Microsoft SQL Server DB instances on the current cloud. With DRS, youcan migrate databases online with zero downtime and your services anddatabases can remain operational during migration.

This section describes how to use DRS to migrate self-built Microsoft SQL Serverdatabases on ECS to the Microsoft SQL Server DB instances on the current cloud.The following network scenarios are supported:




Architecture





Migration Process





NO TICE




Table 4-7 lists the source and destination database user permissions requiredin full and incremental migrations from self-built Microsoft SQL Serverdatabases on ECS to the Microsoft SQL Server DB instances on the currentcloud.








Unsupported



Unsupported



2. Network settings– The source and destination databases must be in the same region.– The source and destination databases can be either in the same VPC or

different VPCs.




to set a security group.– In different VPCs, establish a VPC peering connection between the two

VPCs. You do not need to set a security group.4. Other

You need to export statements of creating users and jobs first and manuallyadd the statements to the destination database because the Microsoft SQLServer user information and scheduled jobs will not be migrated.

Migration Procedure













SendNotifications









Source DBEngine






Select the Microsoft SQL Server DB instance you havecreated on the current cloud.

Migration Type – Full: This migration type is suitable for scenarioswhere service interruption is permitted. It migrates allobjects and data in non-system databases to thedestination database at one time. The objects includetables, views, stored procedures, and triggers.NOTE







By default, the selected VPC and subnet are those where RDS is located. If your sourcedatabase is not in the VPC, select the same VPC and subnet as those where RDS islocated.



SourceDatabase Type


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. For details onhow to create a VPC, see Creating a VPC.

Subnet A subnet provides dedicated network resources that arelogically isolated from other networks, improvingnetwork security. Subnets can take effect only in AZs. Youneed to enable the DHCP for subnets where you plan tocreate the source database, and cannot disable the DHCPduring creation. For details on how to create a VPC, seethe Creating a VPC section in the Virtual Private CloudUser Guide.









DatabaseUsername


DatabasePassword





DB InstanceName

The Microsoft SQL Server DB instance you have selectedduring the migration task creation is displayed by defaultand cannot be changed.

DatabaseUsername


DatabasePassword








MigrationObject

















After a migration task is started, all data is migrated. You can manage the task onthe management console.

● Full migration









----End

4.3 PostgreSQL Database MigrationDRS supports data migration from self-built PostgreSQL databases on ECS to thePostgreSQL DB instances on the current cloud. With DRS, you can migratedatabases online with zero downtime and your services and databases can remainoperational during migration.

This section describes how to use DRS to migrate self-built PostgreSQL databaseson ECS to the PostgreSQL DB instances on the current cloud. The followingnetwork scenarios are supported:




Architecture





Migration Process






NO TICE







Table 4-13 lists the source and destination database user permissionsrequired in full and incremental migrations from self-built PostgreSQLdatabases on ECS to the PostgreSQL DB instances on the current cloud.








– Source database permission settings:

The source database account must have all the required permissionslisted in Table 4-13. If the permissions are insufficient, create a user thathas all of the permissions on the source database.

– Destination database permission settings:

If the destination database is a PostgreSQL database on the currentcloud, the initial account can be used.

2. Network settings

– The source and destination databases must be in the same region.

– The source and destination databases can be either in the same VPC ordifferent VPCs.



3. Security rules

– In the same VPC, the network is connected by default. You do not needto set a security group.

– In different VPCs, establish a VPC peering connection between the twoVPCs. You do not need to set a security group.

4. Other

You need to export PostgreSQL user information first and manually add it tothe destination database because the user information will not be migrated.





Migration Procedure












SendNotifications










Source DBEngine

Select PostgreSQL.


Select PostgreSQL.











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








SourceDatabase Type


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. For details onhow to create a VPC, see the Creating a VPC section inthe Virtual Private Cloud User Guide.

Subnet A subnet provides dedicated network resources that arelogically isolated from other networks, improving networksecurity. Subnets can take effect only in AZs. You need toenable the DHCP for subnets where you plan to createthe source database, and cannot disable the DHCP duringcreation. For details on how to create a VPC, see theCreating a VPC section in the Virtual Private Cloud UserGuide.









DatabaseUsername


DatabasePassword





DB InstanceName


DatabaseUsername


DatabasePassword
















----End

4.4 MongoDB Database MigrationDRS supports data migration from self-built MongoDB databases on ECS to theDDS DB instances on the current cloud. With DRS, you can migrate databasesonline with zero downtime and your services and databases can remainoperational during migration.

This section describes how to use DRS to migrate self-built MongoDB databaseson ECS to DDS DB instances on the current cloud. The following network scenariosare supported:




Architecture





Migration Process






NO TICE







Table 4-18 lists the source and destination database user permissionsrequired in full and incremental migrations from local MongoDB databases toDDS DB instances.










2. Network settings– The source database and destination DDS DB instance must be in the

same region.– The source database and destination DDS DB instance can be either in

the same VPC or different VPCs.




to set a security group.– In different VPCs, establish a VPC peering connection between the two

VPCs. You do not need to set a security group.4. Other

You need to export the user information of the MongoDB database first andmanually add it to the destination DDS DB instance because the userinformation will not be migrated.

Migration Procedure













SendNotifications













Source DBEngine



Select DDS.











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








SourceDatabase Type

Select Non-DDS DB instance.

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. For details onhow to create a VPC, see Creating a VPC.





Subnet A subnet provides dedicated network resources that arelogically isolated from other networks, improving networksecurity. Subnets can take effect only in AZs. You need toenable the DHCP for subnets where you plan to createthe source database, and cannot disable the DHCP duringcreation. For details on how to create a VPC, see theCreating a VPC section in the Virtual Private Cloud UserGuide.




DatabaseUsername


DatabasePassword





DB InstanceName

The DDS DB instance you have selected during themigration task creation is displayed by default and cannotbe changed.

DatabaseUsername


DatabasePassword









MigrationObject

Select the objects to be migrated. The objects can beeither databases or tables. After the objects are migratedto the destination DB instance, the object names remainthe same as those in the source database and cannot bemodified.




















3. On the Migration Progress page, view the synchronization delay. When thedelay is 0s and remains stable for a period, you can perform a data-levelcomparison between the source and destination databases. For details aboutthe time required, refer to the comparison results of the previous comparison.




– If there is enough time, compare all objects.– If there is not enough time, use the data-level comparison to compare






----End



5 Migrating Microsoft SQL Server BackupData to RDS SQL Server DB Instance

5.1 Overview5.2 Migration Preparations5.3 Exporting Backup Files5.4 Uploading Backup Files5.5 Scenario 1: Full Backup Migration5.6 Scenario 2: Full+Incremental Backup Migration5.7 Manual Configuration

5.1 OverviewIt often becomes necessary to hide a real IP address of your database for the sakeof security. Migrating data through direct connections is an option, but costly. DRSsupports backup migration, which allows you to export data from your sourcedatabase for backup and upload the backup files to OBS. Then, you can restorethe backup files to the destination database to complete the migration. Using thismethod, data migration can be realized without exposing your source databases.

DRS supports full migration and full+incremental migration.

Scenario 1: Full Backup MigrationIn this scenario, you need to stop services, upload the exported full backup file ofthe Microsoft SQL Server database to OBS, and then restore the backup data tothe destination database.

Figure 5-1 Full migration

Data Replication ServiceBest Practices

5 Migrating Microsoft SQL Server Backup Data toRDS SQL Server DB Instance


Scenario 2: Full+Incremental Backup MigrationIn this scenario, data is migrated continuously. After a full backup and restorationis complete, you can perform incremental migrations for several times to minimizeservice interruption. A complete restoration process involves restoring severalincremental backup files. The destination DB instance will not be available untilthe last backup file is restored. You can determine whether the selected backupfile is the last one.

Figure 5-2 Full+incremental migration

5.2 Migration PreparationsThis section describes how to prepare for backup and migration. Before using DRS,ensure that you have completed the required preparations.

Preparing for Backup FilesFor details, see the Before You Start section in the Data Replication ServiceGetting Started.

Configuring Database Restoration Mode● No configuration is required during a full backup restoration.● During full and incremental backup migration, the recovery mode must be set

to Full. The procedure is as follows:Method 1: Log in to the local database center using Microsoft SQL ServerManagement Studio. Right-click the database to be migrated and chooseProperties from the shortcut menu. In the dialog box that is displayed, clickOptions, and select Full for Recovery mode.




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

Figure 5-3 Recovery mode

Method 2: Run the following SQL commands to set the restoration mode:USE master; ALTER DATABASE database_name SET RECOVERY FULL;

Destination Database Storage Space

The available storage space of the destination database should be at least 1.5times larger than the total storage space of the database to be restored.

Migration Duration Reference

A complete backup and migration process consists of the following phases:

Figure 5-4 Migration diagram

Table 5-1 Backup migration

Phase Name Description

① Export the backupfiles.

The time required for generating databasebackup files depends on the configurationof the source database. You need toestimate the time based on theconfiguration of the source database.

② Upload the backupfile to OBS.

OBS does not limit the upload anddownload speed. If you access OBS througha public network, the upload and downloadspeed is restricted by the public networkbandwidth. For example, if the bandwidthof the public network is 10 MB/s and thenetwork is not affected by other factors, theupload rate is 10 MB/s.




Phase Name Description

③ Download the backupfile to the destinationRDS SQL Serverthrough DRS.

Generally, the download speed is 100 MB/sor 300 GB/h.

④ Restore the backupfiles to thedestination database.

Generally, the recovery speed is about 5GB/min or 300 GB/h.

TotalDuration

Total time consumption = phase ① time consumption + phase ②time consumption + phase ③ time consumption + phase ④ timeconsumptionService downtime = Service suspension -> Last incremental backup -> Uploading to OBS -> Creating a DRS task for restoration

The following uses an example to describe the time required for backing up andmigrating data. You can estimate the migration time in advance. The actual timerequired depends on the network and database configurations on the client. Thetime listed in the following table is for reference only.

Example

Table 5-2 Backup migration example

Phase Name Backup File Size(GB)

Time Required (h)

① Export the backup files. 283 5.5

② Upload the backup fileto OBS.

283 8.95

③ Download the backupfile by through DRS.

283 0.61

④ Restore the backup filesto the destinationdatabase.

283 2.24

Total Duration 17.3

5.3 Exporting Backup FilesThis section describes how to export the full backup files and incremental backupfiles of a database.

Step 1 Check the parameter settings of the local database.




This operation is mandatory for full and incremental migration. If you only perform the fullmigration, skip this step.

The database has log truncation and shrinking configurations. Therefore, beforeexporting full backup files, you must set the database recovery model to Full untilthe entire database and services are migrated to the DB instance on the currentcloud.

1. Log in to the local database center through Microsoft SQL ServerManagement Studio.

2. Right-click the database to be migrated and choose Properties from theshortcut menu. In the displayed dialog box, select Options from the left list.

3. Select Full for Recovery model. Then, click OK.

Figure 5-5 Configuring the recovery model

Step 2 (Optional) Set backup file compression parameter.

If the bandwidth of your local data center is low and uploading data to OBSBrowser takes a long time, you are advised to configure the backup filecompression parameters.

1. Log in to the database center through Microsoft SQL Server ManagementStudio as the database administrator.

2. In Object Explorer, right-click the server and choose Properties.3. Click Database Settings.4. In the Backup and restore area, select Compress backup.

This setting determines the server-level default setting for compressionbackup, as detailed below:– If Compress backup is not selected, the new backup will not be

compressed by default.– If Compress backup is selected, the new backup file is compressed by

default.




Figure 5-6 Configuring compression parameter

Step 3 Export the full backup file.


2. Right-click the database whose data needs to be exported and choose Tasks >Back Up.




Figure 5-7 Back Up

3. Set Backup type to Full, click Add, and enter the path to which the backupfile is exported. The file name extension must be .bak.




Figure 5-8 Setting the full backup file

● It is recommended that the backup file name be the same as the database name (casesensitive), and the suffix .bak be added to the backup file name.

● You are advised to back up all the databases in a .bak file or a few .bak files. Thisreduces the frequency of uploading and restoring the database.

Step 4 Export the incremental backup file.


2. Right-click the database whose data needs to be exported and choose Tasks >Back Up.




Figure 5-9 Back Up

3. Select Transaction Log for Backup type, click Add, and enter the path towhich the backup file is exported. The suffix is .bak.




Figure 5-10 Setting the incremental backup file

● It is recommended that the backup file name be the same as the database name (casesensitive), with the time stamp and .bak suffix. For example: [Database name] _Incr_[Timestamp] .bak.

● You are advised to back up all the databases in a .bak file or a few .bak files. Thisreduces the frequency of uploading and restoring the database. For example, you canback up the A, B, and C databases to a .bak file, and then compress, upload, and restorethe three databases in a batch. This helps to improve the success rate of datarestoration.

----End

5.4 Uploading Backup FilesThis section describes how to upload backup files.

Step 1 Create an OBS bucket and upload the backup file to the OBS bucket.

● If the size of the file does not exceed 50 MB, select Standard for Storage Class andPublic Read for Bucket Policy on the OBS console.

● If you need to upload multiple files and the size of the files exceeds 50 MB, you need toinstall OBS Browserhttps://auth.huaweicloud.com/authui/login.html?service=https%3A%2F%2Fconsole-intl.huaweicloud.com%2Fconsole%2F#/login because itsupports resumable upload. For details, see Downloading OBS Browser.

You are advised to store backup files in independent OBS buckets in the same region todistinguish the backup files from other public files.

Before uploading the backup file, create access keys (AK and SK) in the OBS console. Fordetails, see Creating Access Keys (AK and SK).

When uploading backup files, select Standard for Storage Class.




https://storage.huaweicloud.com/obs

https://auth.huaweicloud.com/authui/login.html?service=https%3A%2F%2Fconsole-intl.huaweicloud.com%2Fconsole%2F#/login

https://auth.huaweicloud.com/authui/login.html?service=https%3A%2F%2Fconsole-intl.huaweicloud.com%2Fconsole%2F#/login

https://support.huaweicloud.com/en-us/clientogw-obs/en-us_topic_0045853783.html


1. For details about how to log in to OBS Browser, see Logging In to OBSBrowser.

2. For details about how to add an OBS bucket, see Adding a Bucket.3. For details about how to upload files to an OBS bucket, see Uploading a File

or Folder.

----End

5.5 Scenario 1: Full Backup MigrationIn this scenario, you need to stop services, upload the exported full backup file ofthe Microsoft SQL Server database to OBS, and then restore the backup data tothe destination database.

This section describes how to migrate a full backup.

Migration Diagram

Figure 5-11 Full migration






https://support.huaweicloud.com/en-us/clientogw-obs/obs_03_0022.html



Migration Process


Procedure

Step 1 Export the full backup file of the database. For details, see 5.3 Exporting BackupFiles.

Step 2 Upload files to an OBS bucket. For details, see 5.4 Uploading Backup Files.

Step 3 Log in to the DRS console.

Step 4 Click in the upper left corner and select a region and a project.

Step 5 Choose Service List > Database > Data Replication Service.

Step 6 In the navigation pane on the left, choose Backup Migration Management. Then,click Create Migration Task.

Step 7 Enter the information about the migration task and backup file, and click Next.




https://auth.huaweicloud.com/authui/login.action?locale=en-us#/login

Figure 5-13 Migration task information

Table 5-3 Migration task information


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

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

Database Type Select Microsoft SQL Server.

Backup File Source Select OBS bucket.

Bucket Name Select the bucket where the backup file is stored andthe full backup file.NOTE

● The backup file of the Microsoft SQL Server must be inthe .bak format. Multiple backup files can be selected atthe same time.

● The bucket name, backup file name, or path cannotcontain Chinese characters.

Step 8 On the Select Destination page, specify database information and click Next.




Figure 5-14 Full migration database information

Table 5-4 Microsoft SQL Server database information


Destination RDSDB InstanceName

Select a destination RDS DB instance. If no RDS DB instanceis available, you can buy one by referring to the Buy a DBInstance section in the Relational Database Service GettingStarted.

Backup Type Select Full.Full: indicates full backup files.NOTE

To migrate databases at a time, you need to stop services first andupload full backups for restoration.

Last Backup File Select Yes if you perform a one-time full migration.

Overwrite Data You can determine whether to overwrite data in thedestination database during the restoration if thedestination DB instance contains a database with the samename as the backup database.NOTE

If you select this option, the destination databases with the samenames as the backup databases will be overwritten. Exercise cautionwhen performing this operation.

Perform Pre-verification

Specifies whether to perform pre-verification on the backupmigration task. The default value is Yes.● Yes: To ensure successful migration and identify potential

problems in advance, verify the validity, integrity,continuity, and version compatibility of backup filesbefore restoration.

● No: If pre-verification is not performed, the migrationspeed is faster, but you need to check the validity,integrity, continuity, and version compatibility of backupfiles on your own.




https://support.huaweicloud.com/en-us/qs-rds/en-us_topic_0053089697.html



Restore Database You can restore all or some of databases.● All: Restores all databases in the backup file. You do not

need to enter the names of the databases to be restored.By default, all databases in the backup file are restored.

● Custom: Restore specified databases from the backupfile. You need to enter the names of the databases to berestored.The databases to be restored must be consistent withthose for which the full or incremental backups arecreated.

Step 9 On the Confirm Task page, check the configuration details, read and agree to theagreement, and click Next.

Step 10 In the task list on the Backup Migration Management page, check whether thetask is in the Restoring status. If the migration is successful, the task statusbecomes Successful.

----End

5.6 Scenario 2: Full+Incremental Backup MigrationIn this scenario, data is migrated continuously. After a full backup and restorationis complete, you can perform incremental migrations for several times to minimizeservice interruption. A complete restoration process involves restoring severalincremental backup files. The destination DB instance will not be available untilthe last backup file is restored. You can determine whether the selected backupfile is the last one.

This section uses a full+incremental migration as an example to describe how toperform a migration while minimizing service interruption.




Migration Diagram

Figure 5-15 Full+incremental migration

Migration Process

Figure 5-16 Flowchart

First Full Migration

Step 1 Export the full backup file of the database. For details, see 5.3 Exporting BackupFiles.






Step 4 Click in the upper left corner and select a region and a project.

Step 5 Choose Service List > Database > Data Replication Service.



Figure 5-17 Migration task information







Bucket Name Select the bucket where the backup file is stored andthe full backup file.NOTE

● The backup file of the Microsoft SQL Server must be inthe .bak format. Multiple backup files can be selected atthe same time.

● The bucket name, backup file name, or path cannotcontain Chinese characters.





https://console.huaweicloud.com/drs

Figure 5-18 Full migration database information




Select a destination RDS DB instance. If no RDS DB instanceis available, you can buy one by referring to the Buy a DBInstance section in the Relational Database Service GettingStarted.

Backup Type Select Full.Full: indicates full backup files.

Last Backup File A complete restoration process involves restoring severalincremental backup files. The destination DB instance willnot be available until the last backup file is restored. Youcan determine whether the selected backup file is the lastone. Select Yes in either of the following scenarios:● Perform a one-time full migration.● The selected backup file is the last one to be restored.Select No in the scenario where you continue to restoredatabases using incremental backup files after a full backuprestoration is performed. In this case, the destinationdatabase is in the restoring state and cannot be read orwritten.

Overwrite Data You can determine whether to overwrite data in thedestination database during the restoration if thedestination DB instance contains a database with the samename as the backup database.NOTE

If you select this option, the destination databases with the samenames as the backup databases will be overwritten. Exercise cautionwhen performing this operation.













● Custom: Restore specified databases from the backupfile. You need to enter the names of the databases to berestored.The databases to be restored must be consistent withthose for which the full or incremental backups arecreated.



----End

First Incremental Migration

Step 1 Export the first incremental backup file of the database. For details, see 5.3Exporting Backup Files.








Figure 5-19 Incremental backup







Bucket Name Select the bucket where the backup file is stored andthe first incremental backup file.NOTE

The backup file of the Microsoft SQL Server must be inthe .bak format. Multiple backup files can be selected at thesame time.





Figure 5-20 Incremental migration database information




Select a destination RDS DB instance.The destination RDS DB instance must be the same as theDB instance selected during full backup and restoration.

Backup Type Select Incremental.Incremental: indicates log backup files.

Last Backup File A complete restoration process involves restoring severalincremental backup files. The destination DB instance willnot be available until the last backup file is restored. Youcan determine whether the selected backup file is the lastone. Select Yes in either of the following scenarios:● Perform a one-time full migration.● The selected backup file is the last one to be restored.Select No if the incremental backup is performed for thefirst time. In this case, the destination database is in therestoring state and cannot be read or written.











● Custom: Restore specified databases from the backupfile. You need to enter the names of the databases to berestored.



----End

Second Incremental MigrationTo minimize the service interruption caused by migration, you need to back up,upload, and restore transaction logs before service migration. These operationswill restore historical data to the destination database, which greatly reduces thetime for uploading and restoring the last transaction log backup during themigration.

Step 1 Before service migration, export new incremental backup files. For details, see 5.3Exporting Backup Files.

Step 2 Perform Step 2 to Step 4.









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



Bucket Name Select the bucket where the backup file is stored andthe new incremental backup file.NOTE







Select a destination RDS DB instance. The destination RDSDB instance must be the same as the DB instance selectedduring full backup and restoration.






Last Backup File A complete restoration process involves restoring severalincremental backup files. The destination DB instance willnot be available until the last backup file is restored. Youcan determine whether the selected backup file is the lastone. Select Yes in either of the following scenarios:● Perform a one-time full migration.● The selected backup file is the last one to be restored.Select No if the incremental backup is performed beforemigration. In this case, the destination database is in therestoring state and cannot be read or written.










----End

Checking Database TransactionsBefore service migration, stop services and ensure that no unfinished transactionexists in the database. Otherwise, data may be lost during migration.

Step 1 Run the following statement to check whether the IP addresses of the servicesystem are disconnected:select * from sys.dm_exec_connections;

● If yes, all service system IP addresses are disconnected and the lastincremental backup can be migrated.




● If no, go to Step 2.

Step 2 If an IP address is not disconnected, run the following statement to query thesessions that are not closed:select * from sys.dm_exec_sessions;

Run the following statement to view the transactions that are being executed:

select * from sys.dm_tran_session_transactions;

If the query result contains unclosed sessions and transactions that are beingexecuted, go to Step 3.

Step 3 The last incremental backup can be migrated only after the transaction iscomplete, the session is closed, and the service system is disconnected.

----End

Last Incremental Migration

After several incremental migrations, the two databases are almost consistent.During the transaction checks, services are stopped and no data will be generated.Then, you need to perform the last incremental migration to ensure the dataconsistency.

Step 1 Export the new incremental backup file of the database. For details, see 5.3Exporting Backup Files.

Step 2 Perform Step 2 to Step 4.













Bucket Name Select the bucket where the backup file is stored andthe new incremental backup file.NOTE







Select a destination RDS DB instance. The destination RDSDB instance must be the same as the DB instance selectedduring full backup and restoration.


Last Backup File Select Yes because it is the last incremental migration afterservices are stopped.














----End

5.7 Manual Configuration

Scenarios

After data is migrated from the local host or VMs to the RDS SQL Server DBinstance on the current cloud through DRS, the Login accounts, database links,Agent Jobs, and key configurations of the source database also need to besynchronized to the destination database.

Login Account

Login account is an instance-level account of Microsoft SQL Server and is used tomanage user server and database permissions. Generally, a user has multiple suchaccounts. After the user is migrated to the RDS SQL Server DB instance, you needto manually create corresponding Login accounts on the DB instance. Thefollowing describes how to create a Login account with the same name andpassword as those of your local Login account on the RDS SQL Server DB instanceand grant permissions to the account.




Step 1 Execute the following script to obtain the script for creating a Local account onyour local instance. The obtained script can be directly executed on the destinationDB instance to create a Login account with the same name and password.SELECT 'IF (SUSER_ID('+QUOTENAME(SP.name,'''')+') IS NULL) BEGIN CREATE LOGIN ' +QUOTENAME(SP.name)+CASEWHEN SP.type_desc = 'SQL_LOGIN' THEN ' WITH PASSWORD = ' +CONVERT(NVARCHAR(MAX),SL.password_hash,1)+ ' HASHED,SID=' +CONVERT(NVARCHAR(MAX),SP.SID,1)+',CHECK_EXPIRATION = '+ CASE WHEN SL.is_expiration_checked = 1 THEN 'ON' ELSE 'OFF' END +', CHECK_POLICY = ' +CASE WHEN SL.is_policy_checked = 1 THEN 'ON,' ELSE 'OFF,' ENDELSE ' FROM WINDOWS WITH'END+' DEFAULT_DATABASE=[' +SP.default_database_name+ '], DEFAULT_LANGUAGE=[' +SP.default_language_name+ '] END;' as CreateLoginFROM sys.server_principals AS SP LEFT JOIN sys.sql_logins AS SLON SP.principal_id = SL.principal_idWHERE SP.type ='S'AND SP.name NOT LIKE '##%##'AND SP.name NOT LIKE 'NT AUTHORITY%'AND SP.name NOT LIKE 'NT SERVICE%'AND SP.name NOT IN ('rdsadmin','rdsbackup','rdsuser','rdsmirror','public')

Step 2 Execute the script in Step 1:

Figure 5-25 Obtaining the script

Step 3 Copy and execute the script obtain in Step 2 on the destination instance. Thecreated Login account is the same as the original one.

Step 4 Map the newly created Login account to the database user permissions that havebeen migrated to the RDS SQL Server DB instance to ensure permissionconsistency.declare @DBName nvarchar(200)declare @Login_name nvarchar(200)declare @SQL nvarchar(MAX)set @Login_name = 'TestLogin7' //Enter the login name one by one.declare DBName_Cursor cursor forselect quotename(name)from sys.databases where database_id > 4 and state = 0and name not like '%$%'and name <> 'rdsadmin'open DBName_Cursorfetch next from DBName_Cursor into @DBNameWHILE @@FETCH_STATUS= 0beginSET @SQL=' USE '+ (@DBName)+ 'if exists(select top 1 1 from sys.sysusers where name = '''+ @Login_Name +''')beginALTER USER '+@Login_name+' with login = '+@Login_name+';end'




print @SQLEXEC (@SQL)fetch next from DBName_Cursor into @DBNameendclose DBName_Cursordeallocate DBName_Cursor

After the preceding script is executed, you can view the Login account with the same nameon the new instance, and the password and permission are the same as those on your localhost.

----End

Database LinkSQL Server allows you to create database links to interact with databases onexternal DB instances. Therefore you can query, synchronize, and comparedatabases of different types or on different DB instances. However, these linkscannot be automatically synchronized to the DB instance on cloud so you need tosynchronize them manually.

Step 1 Connect the local DB instance and cloud DB instance through Microsoft SQLServer Management Studio. Choose Server Objects > Linked Servers and locatethe DBLink of the current DB instance.

Figure 5-26 Viewing database links

Step 2 Select the linked server and press F7. The Object Explore page is displayed. Onthis page, you can quickly create a script.




Figure 5-27 Creating the script

Step 3 In the displayed window, view all the scripts for creating DBLinks of the current DBinstance. You only need to copy the scripts to the destination DB instance andchange the password on @rmtpassword.USE [master]GO /****** Object: LinkedServer [DRS_TEST_REMOTE] Script Date: 2019/5/25 17:51:50 ******/EXEC master.dbo.sp_addlinkedserver @server = N'DRS_TEST_REMOTE', @srvproduct=N'', @provider=N'SQLNCLI', @datasrc=N'DESKTOP-B18JH5T\SQLSERVER2016EE'/* For security reasons the linked server remote logins password is changed with ######## */EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'DRS_TEST_REMOTE',@useself=N'False',@locallogin=NULL,@rmtuser=N'sa',@rmtpassword='########'GO

The preceding script is an example. The created script may contain a large number ofdefault system configuration items. You need to retain only the following two key scriptsfor each DBLink. In addition, you need to enter the account and password again.

----End

Agent JOB

Agent Job is the agent service of Microsoft SQL Server. It helps you quickly createscheduled tasks on DB instances, perform routine O&M, and process data. Youneed to manually migrate local Job scripts.

Step 1 Connect the local DB instance and cloud DB instance through Microsoft SQLServer Management Studio. Choose SQL Server Agent > Jobs and locate all thejobs of the current DB instance.




Figure 5-28 Viewing Jobs

Step 2 Select a job and press F7. All jobs are displayed on the Object Explore page.Select all jobs and create a script in the new window.

Figure 5-29 Creating a script

Step 3 Copy the T-SQL script in the new window to the new DB instance, and thenmodify the following key items to ensure that the creation is successful.● Modify the owner account of each job.

Example:@owner_login_name=N'rdsuser'

● Modify the DB instance name of each job.Example:@server=N' DB instance IP address'@server_name = N'DB instance IP address'




The owner account of the new job is very important. On the RDS SQL Server DB instance,only the owner of the job can view the job of the DB instance. Therefore, it is recommendedthat all job owners use the same account to facilitate job management.

----End

Key ConfigurationAfter the database is restored to the RDS SQL Server DB instance, some localimportant configuration items need to be synchronized to keep service runningproperly.

1. tempdb: The file configuration of the temporary database needs to besynchronized.It is recommended that you set 8 temporary files and ensure that the files arestored in D:\RDSDBDATA\Temp\.Run the following script on the destination database to add the temporarydatabase file configuration:USE [master]GOALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb1', FILENAME = N'D:\RDSDBDATA\Temp\tempdb1.ndf' , SIZE = 65536KB , FILEGROWTH = 65536KB )GOALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb2', FILENAME = N'D:\RDSDBDATA\Temp\tempdb2.ndf' , SIZE = 65536KB , FILEGROWTH = 65536KB )GOALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb3', FILENAME = N'D:\RDSDBDATA\Temp\tempdb3.ndf' , SIZE = 65536KB , FILEGROWTH = 65536KB )GOALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb4', FILENAME = N'D:\RDSDBDATA\Temp\tempdb4.ndf' , SIZE = 65536KB , FILEGROWTH = 65536KB )GOALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb5', FILENAME = N'D:\RDSDBDATA\Temp\tempdb5.ndf' , SIZE = 65536KB , FILEGROWTH = 65536KB )GOALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb6', FILENAME = N'D:\RDSDBDATA\Temp\tempdb6.ndf' , SIZE = 65536KB , FILEGROWTH = 65536KB )GOALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb7', FILENAME = N'D:\RDSDBDATA\Temp\tempdb7.ndf' , SIZE = 65536KB , FILEGROWTH = 65536KB )GO




Figure 5-30 Checking temporary files

2. Database isolation level: Check whether the database isolation level isenabled on the source DB instance and synchronize the isolation level to theRDS SQL Server DB instance. There are two snapshot isolation parameters:– Is Read Committed Snapshot On– Allow Snapshot IsolationIf the database isolation level of the source DB instance is enabled, you canrun the following script on the destination database to enable the databaseisolation level:USE [DBName]GOALTER DATABASE [DBName] SET READ_COMMITTED_SNAPSHOT ON WITH NO_WAITGOALTER DATABASE [DBName] SET ALLOW_SNAPSHOT_ISOLATION ONGO

3. Max Degree of Parallelism: The maximum degree of parallelism is set to 0 bydefault on the RDS SQL Server instance. You can also set the value based onthe local settings to avoid exceptions in different service scenarios.In Object Explorer, right-click a local server and select Properties. Click theAdvanced node. In the Max Degree of Parallelism box, view the value of thelocal instance and change the max degree of parallelism value in theparameter group of the destination RDS SQL Server instance to the same.




Figure 5-31 Max Degree of Parallelism

Log in to the RDS console. On the Instance Management page, click thetarget DB instance name. Choose Parameters, search for the max degree ofparallelism parameter, and change its value.

Figure 5-32 max degree of parallelism

4. Check whether the database recovery model on the cloud is set to Full. If not,change the mode.

Right-click the database and choose Properties from the shortcut menu. Inthe displayed page, select Options. Then, verify that Recovery Model is set toFull. Ensure that the database is highly available and the backup policy isexecutable.

Figure 5-33 Checking the database recovery model

5. The backup information records the statistics of the source database. The oldinformation affects the SQL performance. After the migration, you are advisedto start the databases of all users and collect the statistics to ensure thestable performance of the new system.




A Change History

Date Description

2019-10-30 This issue is the sixth official release, which incorporates thefollowing changes:● Supported the migration of specified MySQL users.● Supported checking backup files during backup migration.

2019-07-30 This issue is the fifth official release, which incorporates thefollowing changes:● Added backup migration in 5 Migrating Microsoft SQL

Server Backup Data to RDS SQL Server DB Instance.● Supported unbinding EIP from destination databases during

online migration.

2018-09-30 This issue is the fourth official release, which incorporates thefollowing changes:● Added practices of PostgreSQL database migrations.● Supported setting a synchronization delay threshold.● Supported setting the source database type.

2018-08-31 This issue is the third official release, which incorporates thefollowing changes:● Displayed the remaining time of a migration task.● Supported object-level and data-level comparisons.● Supported full migration of MongoDB clusters.

2018-07-14 This issue is the second official release, which incorporates thefollowing changes:● Added the practice of MongoDB database migration.● Added practices of starting a migration task as scheduled.● Added practices of sending notifications to a specified

recipient.● Organized information of migration preparations based on

permissions, network, and security rules.

Data Replication ServiceBest Practices A Change History


Date Description

2018-05-31 This issue is the first official release.

Data Replication ServiceBest Practices A Change History


Best Practices - support.huaweicloud.comBest Practices Summary This document provides practices of...

Documents

Transcript of Best Practices - support.huaweicloud.comBest Practices Summary This document provides practices of...