If your existing simple application server is about to expire and you have created another simple application server, you can perform the operations described in this topic to migrate the website data in the existing server to the new server.

Background information

When your simple application server is about to expire and web applications are deployed on the server, we recommend that you use one of the following methods to maintain the running state of the web applications:
  • Renew the server in a timely manner. For more information, see Renew a server.
  • Create a custom image from the server before the server expires and use the custom image to create a simple application server to migrate the web applications to the new server. For more information, see Overview.

If you create a simple application server to replace the server that is about to expire to maintain the running state of the web applications, you can perform the operations described in this topic to migrate data to the new server.

The following section describes the simple application servers and data migration tools used in this topic:
  • Simple application servers:

    In this topic, the name of the simple application server that is about to expire is Server A, and the name of the new simple application server is Server B. Take note of the following items:

    • The image used by Server A is the LAMP 7.4 application image, and the Mantis Bug Tracker (MantisBT) system is deployed in the /data/wwwroot/default website root directory of Server A by default.
      Note For more information about how to deploy the MantisBT system on Linux, Apache, MySQL, and PHP (LAMP) servers, see Deploy MantisBT.
    • No limit applies to the image used by Server B, but a logon password must be set. For more information, see Manage the password of a server.
  • Data migration tools:
    • scp command: This command is used to remotely copy files by using the SSH protocol. The web applications deployed on Server A are copied to Server B by running the scp command.
    • Alibaba Cloud Data Transmission Service (DTS): Data stored in the databases of web applications deployed on Server A is migrated to the databases of Server B by using DTS. For more information about DTS, see What is DTS?

In this topic, the MantisBT system deployed on Server A is migrated to Server B. Data is fully migrated, and the system runs normally.

Preparations and precautions

Before you migrate data, make sure that the following preparations are made:
  • Create snapshots to back up data.

    We recommend that you create snapshots for both the server that is about to expire and the new server. If data exceptions occur due to migration failures on the servers, use snapshots to roll back the data stored on the disks of the servers. For more information, see Create a snapshot.

  • Check the network.

    Make sure that simple application servers can access the Internet. If you want to migrate data across regions in different countries, the network environment may not be stable and you may experience low migration speeds.

  • Check the authorized applications on the servers.

    Simple application servers in different regions reside in different virtual private clouds (VPCs). If you migrate data across regions, the hardware devices of the servers at the underlying layer may change, and the application licenses bound to the hardware may become invalid. You must check the authorized applications.

Before you migrate data, take note of the following items:
  • The runtime environment in each server must be of the same version.
    Some websites have high version requirements for the server runtime environment. If the versions of the runtime environment before and after the migration are different, the websites cannot run normally. We recommend that you use images of the same version for the two servers.
    Note Scenarios for building websites are complex and diverse. During the migration process, you must manually configure the new server based on the actual business requirements to ensure that the configurations of the new server are the same as those of the server that is about to expire. For example, if you customize some applications such as NGINX and Apache on the server that is about to expire, you must manually configure these applications on the new server.
  • The public IP address changes after data is migrated from the server that is about to expire to the new server.

    Different simple application servers have different public IP addresses. If you bind a domain name for the server that is about to expire, you must bind and resolve the domain name for the new server after data is migrated.

Step 1: Check the operating system of Server B

Simple Application Server provides an extensive range of images for use. You must check whether the image used by Server B is the same as that used by Server A.
  • If the images are the same, skip the step.
  • If the images are different, reset Server B to ensure that Server B uses the same image as Server A. In this topic, the image used by Server A is the LAMP 7.4 application image. You must also reset the image used by Server B to the LAMP 7.4 application image. For more information about how to reset a simple application server, see Reset a simple application server.

Step 2: Configure Server A and Server B

Before you migrate data stored in a database by using DTS, complete the following configurations on both Server A and Server B:

  1. Configure firewalls.
    Before you migrate data stored in a database, you must allow traffic on the specific ports on the firewalls of the two servers. ApsaraDB RDS for MySQL databases are installed on both Server A and Server B. By default, port 3306 is used to connect to MySQL. You must allow traffic on port 3306 on the firewalls of both Server A and Server B. For more information, see Add a firewall rule.
  2. Configure MySQL.
    When you migrate data stored in a database, users in MySQL databases must have remote connection permissions. Set a user in the MySQL database for remote connection on both Server A and Server B.
    1. Log on to a simple application server.
    2. Run the following command to switch to the root user:
      sudo su root
    3. Log on to a MySQL database.
      Environment variables are not configured on LAMP servers. Therefore, you must go to the /bin directory in the MySQL installation path to run commands.
      1. Run the following command to go to the /bin directory in the MySQL installation path:
        cd /usr/local/mysql/bin
      2. Run the following command to log on to the MySQL database:
        ./mysql -uroot -p
      3. Enter the password of the MySQL root user in the Enter password: command line.

        You can obtain MySQL logon passwords on LAMP servers in the Simple Application Server console. For more information, see Manage applications on a server created from an application image.

        Note When you enter a password, no command output is returned to maximize data security. You need only to enter the correct password and then press the Enter key.
    4. Run the following command to use the MySQL database:
      use mysql;
    5. Run the following command to create a user in the database for remote connection.
      In this example, create a user named testUser and set the password to Test123.
      Note The password is for demonstration only. You must set a password and keep the password secure to mitigate the risk of data exceptions due to password leaks.
      create user 'testUser'@'%' IDENTIFIED BY 'Test123';
    6. Run the following commands in sequence to grant the remote connection permissions to the testUser user.
      1. Grant the remote connection permissions.
        grant all privileges on *.* to 'testUser'@'%' with grant option;
      2. Make the configuration immediately take effect.
        flush privileges;
    7. Run the following command to exit MySQL:
      \q;

Step 3: View the website data information on Server A

  1. View the database and tables in MySQL where data of the MantisBT system is located.
    1. Run the following command to switch to the bugtracker database:
      use bugtracker;
    2. Run the following command to view the table information related to the MantisBT system:
      show tables;
      The following figure shows some queried table information. show tables
  2. On your computer, access Public IP address of Server A/index.php by using a browser to view data in the current MantisBT system.
    mantis-ATake note of the following items:
    • ① indicates the created test-01 test project.
    • ② indicates the created test111 test issue.

Step 4: Run the scp command to copy web applications

  1. Check the information of Server B.
    When you run the scp command to copy web applications, you must specify the public IP address and the path for storing files of the intended server. Therefore, you must check the following information of Server B:
    • Public IP address.

      For information about how to view the public IP address, see View the card of a server on the Servers page.

    • Website root directory.

      In this example, the website root directory of Server B is /data/wwwroot/default.

  2. Log on to Server A.
  3. Run the following command to switch to the root user:
    sudo su root
  4. Run the following scp command to migrate web applications deployed on Server A to Server B:
    scp -r /data/wwwroot/default/* root@<Public IP address of Server B>:/data/wwwroot/default/
    The following section describes the scp command:
    • -r indicates a recursive copy of the entire directory. If you want to copy a single file, delete -r.
    • /data/wwwroot/default/* indicates all files (/*) in the folder where the web applications are located on Server A.
    • root@<Public IP address of Server B> indicates that Server B is logged on by using SSH.
    • /data/wwwroot/default/ indicates the website root directory of Server B.
  5. Enter the logon password of Server B in the root@<Public IP address of Server B>'s password: command line.
    Note When you enter a password, no command output is returned to maximize data security. You need only to enter the correct password and then press the Enter key.
    When you run the scp command to remotely copy files, data transmission is encrypted and the transmission speed is limited. Wait until the files are copied.

Step 5: View the copied web applications of Server B

  1. Log on to Server B.
  2. Run the following command to switch to the root user:
    sudo su root
  3. Run the following command to go to the website root directory:
    cd /data/wwwroot/default
  4. Run the following command to view file information:
    ls
    You can view file information related to the MantisBT system, as shown in the following figure. mantisbt
  5. On your computer, access <Public IP address of Server B>/index.php by using a browser.

    The #1049: Unknown database 'bugtracker' message is prompted.

    The error occurs because data stored in the database where the MantisBT system is located is not migrated. You must migrate data stored in the database where the MantisBT system is located.

Step 6: Migrate data in the database by using DTS

  1. Log on to the DTS console.
  2. In the left-side navigation pane, click Data Migration. In the upper-right corner of the page, click Create Migration Task.
  3. Configure the data migration task.
    Take note of the following items:
    • Task Name: Specify a name for the task. Example: test-swas-01.
    • Source Database (information of Server A):
      Parameter Example
      Instance Type User-Created Database with Public IP Address.
      Instance Region The region where Server A is located. Example: China (Hangzhou).
      Database Type MySQL.
      Hostname or IP Address The public IP address of Server A.
      Port Number 3306.
      Database Account testUser.
      Database Password Test123.
      Note The password is for demonstration only. You must set a password and keep the password secure to mitigate the risk of data exceptions due to password leaks.
    • Destination Database (information of Server B):
      Parameter Example
      Instance Type User-Created Database with Public IP Address.
      Instance Region The region where Server B is located. Example: China (Hangzhou).
      Database Type MySQL.
      Hostname or IP Address The public IP address of Server B.
      Port Number 3306.
      Database Account testUser.
      Database Password Test123.
      Note The password is for demonstration only. You must set a password and keep the password secure to mitigate the risk of data exceptions due to password leaks.
  4. After all parameters are specified, click Test Connectivity to check the connectivity between DTS and the MySQL databases on the two servers.
    The following figure shows that the MySQL databases on the two servers are connected. Test connectivity
  5. In the lower-right corner of the page, click Set Whitelist and Next. In the Grant DTS Server Access Permission dialog box, click Next.
  6. In the Available section, click bugtracker and click the Icon 1 icon.
    Leave other parameters at the default settings.
  7. In the lower-right corner of the page, click Precheck.
    Wait until the precheck is complete.
    After the precheck is complete, click Next.
  8. In the Confirm Settings dialog box, select Data Transmission Service (Pay-as-you-go) Service Terms and click Buy and Start.
    In this example, you are not charged for migrating data by using DTS. However, when you migrate data by using DTS in actual scenarios, you are charged based on your operations, and the actual pricing is displayed on the page. For more information about the billing of DTS, see Pricing.
    After you start the data migration task, wait until data is migrated.

Step 7: Verify migration results

  1. Log on to Server B.
  2. Run the following command to switch to the root user:
    sudo su root
  3. Log on to the MySQL database.
    Environment variables are not configured on LAMP servers. Therefore, you must go to the /bin directory in the MySQL installation path to run commands.
    1. Run the following command to go to the /bin directory in the MySQL installation path:
      cd /usr/local/mysql/bin
    2. Run the following command to log on to the MySQL database:
      ./mysql -uroot -p
    3. Enter the password of the MySQL root user in the Enter password: command line.

      You can obtain MySQL logon passwords on LAMP servers in the Simple Application Server console. For more information, see Manage applications on a server created from an application image.

      Note When you enter a password, no command output is returned to maximize data security. You need only to enter the correct password and then press the Enter key.
  4. Modify the logon password of the root user in the database.
    When the MantisBT system is installed on Server A, the configured logon password for the database is the password of the MySQL root user on Server A. Therefore, the password information of the MySQL root user must be the same on both Server A and Server B.
    1. Run the following command to switch to MySQL:
      use mysql
    2. Run the following command to change the password of the root user:
      UPDATE user SET authentication_string=PASSWORD('<Logon password of the database on Server A>') where USER='root';
    3. Run the following command to make the configurations immediately take effect:
      flush privileges;
  5. Run the following command to switch to bugtracker:
    use bugtracker
  6. Run the following command to view the table information related to the MantisBT system:
    show tables;
    The following figure shows some queried table information. The table information of Server B is the same as that of Server A. show tables
  7. On your computer, access <Public IP address of Server B>/index.php by using a browser.
    The following figure shows that the website information is displayed normally. No error message appears. mantis-AThe system information of Server B is the same as that of Server A.
    • ① indicates the created test-01 test project.
    • ② indicates the created test111 test issue.

What to do next

The public IP address changes because data is migrated from Server A to Server B. If you bind and resolve a domain name to Server A, you must bind and resolve the domain name to Server B after data is migrated. For more information, see Bind and resolve domain names.