About Data Migration Plugin

Chat2DB supports transferring database objects (such as tables, views, etc.) from one database or schema to another, whether on the same server or on different servers. This feature provides flexibility and convenience for operations such as data migration, synchronization, or backup and recovery. DBMotion plug-in, a plug-in in the Chat2DB plug-in library, provides data migration, synchronization, verification and other functions, and supports transferring objects from one database/schema to another. The target database and/or schema can be on the same server as the source or on another server.

DBMotion

Basic Introduction

The data transfer service DBMotion is a lightweight, green database migration, synchronization, verification tool. It supports localized data migration, disaster recovery drills, two-site three-center and remote multi-site active-active; source database unaware, simple and easy to integrate, smooth and high performance. Help you migrate between multiple clouds and recover from disasters freely.

Function Introduction

Supported Databases

v1.0.0 DBMotion plugin supports object migration, full data migration, and incremental synchronization of MySQL to MySQL; currently supports migration of the same version or migration to a higher version of 5.6, 5.7, and 8.0.

Databases to be supported

The following are the database types that have been supported and are to be integrated into the DBMotion plugin

**Object migration, full data migration, and incremental synchronization of PostgreSQL to PostgreSQL (DDL and two-way synchronization are not supported yet). Currently, it supports the same version migration or migration to higher versions of versions above 9.6.

MySQL to Clickhouse object migration, full data migration, and incremental synchronization; supports MySQL versions 5.6, 5.7, 8.0 to Clickhouse 22 and later.

MongoDB to MongoDB object migration, full data migration, and incremental synchronization; currently supports the same version migration or migration to higher versions of MongoDB versions above 3.6.

openGauss to openGauss object migration, full data migration, and incremental synchronization; supports one-way and two-way synchronization of versions above 5.0.0.

GaussDB to GaussDB object migration, full data migration, and incremental synchronization; supports the same version migration or migration to higher versions of versions above 503.1.

Oracle to GaussDB full data migration and incremental synchronization.

SQL Server to SQL Server object migration, full data migration; currently supports mutual migration of the same version of 2017/2019.

Redis to Redis full data migration and incremental synchronization; currently supports migration of the same version or migration to a higher version of 5.0 and above.

MySQL to Kafka full data migration.

PostgreSQL/GaussDB/openGauss to Kafka full data migration, incremental subscription.

Application scenarios

1. Database migration in the computer room, on-cloud and off-cloud

DBMotion supports Docker offline version and cloud version. Users can download the offline version to perform database migration in their own computer room. You can also directly use the SAAS version on the cloud to migrate on the cloud or across clouds, support migration from on-cloud to off-cloud, and support disaster recovery synchronization of RDS to ECS or offline computer rooms.

2. Domestic database migration

Migrate non-domestic databases to domestic databases and overseas clouds to domestic clouds through visual transparent migration tools. Supports conversion of tables, indexes and other structures, as well as stored procedures, custom functions and other codes; through built-in expert experience and best practices, ensures efficient, transparent and secure full and incremental data synchronization, and can achieve zero downtime migration; supports object and data verification, guarantees data consistency; supports reverse synchronization and can be rolled back at any time.

3. Remote multi-active data synchronization

Supports two-way synchronization of MySQL and openGauss, effectively avoids circular replication, and supports three conflict resolution strategies: overwrite, ignore and error. Supports two-site three-center/remote multi-active architecture, and supports disaster recovery drills.

Advantages and features

Zero downtime: No business downtime is required during the entire migration process, and no locks are added to the source database. The source database can perform various DDL operations during the migration process
Convenient and intuitive: Using visual operations, you can complete data migration and verification with a few clicks of the mouse
Concurrency and high performance: Object, full, incremental, and verification processes all use multi-threaded concurrency, and the synchronization performance can reach 40M/s
Safe and efficient: Support SSL connection to ensure the security of transmitted data
Stable and reliable: Support breakpoint resumption, automatic reconnection when the source end is disconnected, and automatic retry when the target end fails
Pre-check: Pre-check in advance before the formal migration to find possible problems during the migration process in advance
Data verification: Support data verification after migration to escort data switching
Two-way synchronization: Actively avoid circular replication and support conflict strategy processing
Object mapping/where condition filtering: Support object name mapping of source and target databases, and support ignoring some sensitive data during synchronization

Price

DBMotion plugin is free for Chat2DB Pro members for a limited time.

Usage restrictions

1. Bandwidth restrictions

The network bandwidth from the source database to DBMotion and from DBMotion to the target database will limit the migration speed. If the network bandwidth on either end is poor, the migration performance will be reduced and the migration speed will not reach the specification.

2. Database performance restrictions

The performance of the source database or the target database will lead to a decline in the migration performance of DBMotion. Poor performance of the source database will cause DBMotion to retrieve data slowly, and poor performance of the target database will cause DBMotion to store data slowly.

3. MySQL binlog format issues

Binlog needs to use ROW format to ensure that DBMotion can correctly parse the data modification so that it can be incrementally synchronized to the target end. When DDL changes, it is recommended to use a method similar to use db1; alter table tb1 instead of using alter table db2.tb1 to avoid DBMotion misjudging the database and making errors when judging whether the change should be filtered.

4. The source database object selection cannot distinguish whether to select all nodes or all current child nodes

When selecting all tables under a schema on the interface, it cannot distinguish whether all tables displayed on the interface are checked or the entire schema is checked. Currently, synchronization is performed according to checking the entire schema, that is, all current tables under this schema and tables created later will all be synchronized to the target end.

5. Too many object dependency layers will still cause an error

DBMotion currently handles object dependency layers within 10 layers. That is to say, if view v10 depends on v9, v9 depends on v8, ... v2 depends on v1, DBMotion will automatically handle it, but dependencies greater than 10 layers may cause an error.

6. Tables created during object migration to full migration cannot be synchronized

The user selected to migrate the entire schema (db1), but a table db1.tb1 was created during the time interval between object migration and full migration. Since db1.tb1 does not exist when the object is migrated, the object migration will not migrate the table structure of db1.tb1, so an error will be reported during the full migration saying that the table structure does not exist.

7. Others

Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8mb4_0900_ai_ci,IMPLICIT) for operation '=' MySQL 8.0 uses utf8mb4_0900_ai_ci Collation as the collation rule for utf8mb4 by default, which is different from the default value of utf8mb4_general_ci in 5.6 and 5.7. If there is a view using convert(tt.ID using utf8mb4 ), an error may occur when migrating objects to the target end, indicating Illegal mix of collations. It is recommended to manually change the view to convert(tt.ID using utf8mb4 ) COLLATE utf8mb4_general_ci in the target database to bypass this problem.

Team Collaboration Data Transfer