Skip to content
文档
数据迁移
关于数据迁移插件

关于数据迁移插件

Chat2DB 支持将数据库对象（如表、视图等）从一个数据库或模式传输到另一个数据库或模式，无论是位于同一服务器还是不同服务器上。这一功能提供了灵活性和便捷性，便于进行数据迁移、同步或备份恢复等操作。 DBMotion 插件，是 Chat2DB 插件库中的一个插件，该插件提供了数据迁移、同步、校验等功能，支持将对象从一个数据库/模式传输到另一个数据库/模式，目标数据库和/或模式可以与源位于同一服务器上，也可以位于另一台服务器上。。

DBMotion

基本介绍

数据传输服务DBMotion是一款轻量、绿色的数据库迁移、同步、校验工具。支持国产化数据迁移、支持容灾演练、支持两地三中心和异地多活；源库无感知、简单易集成、丝滑高性能。助您在多云之间随心迁移、自由容灾。

功能介绍

已支持的数据库

DBMotion插件 v1.0.0 支持 MySQL to MySQL的对象迁移、全量数据迁移、增量同步；目前支持 5.6、5.7、8.0 三个版本的同版本迁移或向高版本迁移。

待支持的数据库

下面是已经实现支持，待集成进DBMotion插件的数据库类型

PostgreSQL to PostgreSQL 的对象迁移， 全量数据迁移，增量同步（暂不支持DDL和双向同步)。 目前支持 9.6 以上版本的同版本迁移或向高版本迁移。

MongoDB to MongoDB 的对象迁移、全量数据迁移、增量同步；目前支持 MongoDB 3.6 以上版本的同版本迁移或向高版本迁移。

openGauss to openGauss 的对象迁移、全量数据迁移、增量同步；支持 5.0.0 以上版本的单向和双向同步。

GaussDB to GaussDB 的对象迁移、全量数据迁移、增量同步；支持 503.1 以上版本的同版本迁移或向高版本迁移。

Oracle to GaussDB 的全量数据迁移和增量同步。

PostgreSQL/GaussDB/openGauss to Kafka 的全量数据迁移，增量订阅。

应用场景

一、机房内、云上云下数据库迁移

DBMotion支持Docker线下版和云上版本，用户可以下载线下版本在自己机房内做数据库迁移操作。 也可以直接使用云上的SAAS版来进行云上迁移或者跨云迁移，支持云上迁移到云下，云下迁移到云上，支持对RDS的到ECS或者线下机房的容灾同步。

二、国产化数据库迁移

通过可视化透明迁移工具将非国产数据库迁移到国产数据库，海外云迁移到国产云。 支持表、索引等结构也支持存储过程、自定义函数等代码的转换；通过内置专家经验和最佳实践保证业务高效、透明、安全的进行全量和增量同步数据，可实现零停机迁移；支持对象和数据的校验，兜底数据一致性；支持反向同步，随时可回滚。

三、异地多活数据同步

支持MySQL和openGauss的双向同步，有效的避免循环复制，支持覆盖、忽略和报错三种冲突解决策略。支持两地三中心/异地多活架构，支持容灾演练。

优势特点

  • 零停机：整个迁移过程中不需要业务停机，对源库不加任何锁。源库在迁移过程中可以做各种DDL操作

  • 方便直观：采用可视化操作，点点鼠标就可以完成数据的迁移和校验

  • 并发高性能：对象、全量、增量、校验过程全部采用多线程并发，同步性能能到达40M/s

  • 安全高效：支持SSL连接，保证传输数据安全

  • 稳定可靠：支持断点续传，源端断开自动重连，目标端失败自动重试

  • 预检查：正式迁移前提前预检查，预先发现迁移过程中可能出现的问题

  • 数据校验：迁移后支持数据校验，为数据切换保驾护航

  • 双向同步：主动避免循环复制，支持冲突策略处理

  • 对象映射/where条件过滤：支持源库和目标库的对象名映射，支持同步时忽略部分敏感数据

资费

Chat2DB Pro 会员可以享受限时福利，都可以免费获得 20G 迁移流量 🎁

使用限制

1. 带宽限制

源库到DBMotion和DBMotion到目标库的网络带宽会限制迁移的速度。如果任何一端的网络带宽较差都会导致迁移性能下降，达不到规格标称的迁移速度。

2. 数据库性能限制

源库或者目标库的性能会导致DBMotion迁移性能的下降。源库性能差会导致DBMotion取数据慢，目标库性能差会导致DBMotion存数据慢。

3. MySQL binlog格式问题

binlog需要使用ROW格式，来保证DBMotion能正确解析出数据的修改，以便增量同步到目标端 DDL变更时，建议使用use db1;alter table tb1类似的方式，而不是使用alter table db2.tb1的方式，避免DBMotion误判数据库导致判断这个变更是否要过滤时出错。

4. 源库对象选择无法区分全选一个节点还是全选当前所有子节点

界面上选择一个schema下所有表时，无法区分是勾选了界面上显示的所有表，还是勾选了整个schema。目前按照勾选整个schema来同步，也就是说，这个schema下当前所有的表和后面创建的表全部都会同步到目标端。

5. 对象依赖层数过多仍然会报错

DBMotion目前会处理对象依赖层数在10层以内的。也就是说view v10依赖于v9，v9依赖于v8，... v2依赖于v1的情况，DBMotion会自动处理，但是大于10层的依赖可能会报错。

6. 对象迁移到全量迁移过程中创建的表无法同步

用户选择了迁移整个schema(db1)，但是在对象迁移到全量迁移的这段时间间隔内创建了一个表db1.tb1。由于对象迁移的时候db1.tb1还没有，对象迁移不会把db1.tb1的表结构迁移过去，所以全量迁移的时候会报错说表结构不存在。

7. 其他

Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8mb4_0900_ai_ci,IMPLICIT) for operation '=' MySQL 8.0默认使用utf8mb4_0900_ai_ci的Collation作为utf8mb4的校对规则，跟5.6和5.7的utf8mb4_general_ci默认值不一样，如果有view使用convert(tt.ID using utf8mb4 )可能会出现对象迁移时迁移到目标端报错，Illegal mix of collations，建议手工在目标库将view改成convert(tt.ID using utf8mb4 ) COLLATE utf8mb4_general_ci以绕过这个问题。
团队协作数据传输