[Read it in one article] – How Are the Solutions Based on DTS and v2v Different When Implementing Database Migration and Disaster Recovery?

Q1: Are the v2v Migration Product and DTS Exactly the Same in Terms of Functional Positioning and Usage Scenarios?

A: They are different. Generally speaking:

DTS is a dedicated replication and migration product for vertical database scenarios, and is more suitable for replication and migration disaster recovery of various stateful databases.

The v2v migration product is suitable for stateless virtual machine application migration, such as Java application services (open-api/web), Nginx, etc.

Q2: If a Customer Wants to Use v2v to Migrate/Copy the Database in a VM, Is this Solution Recommended?

A: Not recommended.

   Using v2v to migrate/copy the database in a VM is risky and difficult to verify in advance.

Q3: What Are the Specific Risks of Using v2v to Migrate/Copy the Database in the VM?

A: 1. v2v cannot achieve smooth hot migration, and usually requires dozens of minutes or even longer service downtime.

    DTS achieves a similar effect to master-slave replication, which can realize smooth migration and switching of databases.

2. The target database cannot be verified in advance for production traffic, and it is difficult to roll back if problems occur.

   v2v database migration cannot achieve grayscale production traffic on the target database in advance, and then fall back to the source database when problems occur. The operation is complicated and time-consuming.

   DTS uses database replication technology to open the target database to the outside world, making it easier for customers to perform grayscale verification and rollback before migration.

3. After v2v migration, the target database may fail to start.

   The design of DTS is based on database logical replication, which perfectly solves the database transaction commit/rollback consistency problem, including the node consistency problem in the distributed database.

Q4: When Migrating a Virtual Machine Database Dased on DTS or v2v, Is it Necessary to Copy the Entire Machine File?

A: v2v migration requires copying the entire machine files (data files, index files, archive logs, temporary tablespaces, etc.).

DTS only copies database tables and supports on-demand selection of libraries/tables/fields for copying, greatly improving copying efficiency and reducing IO and bandwidth usage.

  Taking a 400GB Oracle database as an example, DTS only needs to migrate about 50GB of data in the data table space.

Q5: What other Benefits Are there when Using DTS to Migrate and Copy Databases?

A: 1. The database version can be upgraded during the migration process

    Previously, it was MySQL 5.0. Due to poor query performance, the customer hoped to migrate to MySQL 8.3 to solve the above performance issues.

2. Enable cross-operating system migration

    The customer wants to migrate the database deployed in Windows to a Linux virtual machine. The customer wants to migrate the database in a Linux VM to a target database running on k8s.

3. Implement replication/migration without OS permissions, only database permissions

    The customer database runs on the RDS of cloud vendors such as Huawei/Alibaba Cloud, and DTS can still be smoothly migrated to ZStack RDS or VM self-built database.

Q6: Since DTS Has such Great Advantages in Database Scenarios, Can Customers Easily Try it Out?

A: We provide permanent free use of 2 replication tasks (only supported by the above 4 open source products: MySQL, PG, MongoDB, and Hive)

PS: The replication from one source database to one target database is called one task.

It is now available on the ZStack Cube application market! One-click unpacking, 2 minutes to run, 10 minutes to complete the replication of 2,000 tables!