- 文档首页
数据库传输服务
常见问题
常见通用问题
接入安全性与业务影响常见问题
接入安全性与业务影响常见问题
在接入数据库传输服务 DTS 前,您可能关心其对源库数据安全及业务运行的影响。本文是关于数据完整性、锁表机制及资源占用的核心解答:
不会。
- 只读操作: DTS 在源端仅执行 SELECT 读取操作,绝不会对源库数据进行写入、更新或删除。
- 数据安全: 迁移过程不会改变源库数据的任何内容,确保源端数据绝对安全。
不会。
- 无锁迁移: DTS 在全量迁移和增量同步的全生命周期中,均不会对源端数据库进行锁表。
- 业务透明: 源端的数据表始终保持正常的读写访问状态,业务感知度极低。
不会,反而有助于保障连续性。
- 实时同步: 增量迁移通过实时捕获并同步源端变更数据,允许业务在迁移期间继续在源端运行。
- 平滑切换: 您可以在业务低峰期进行最终切流,将停机切换时间缩短至分钟级,最大程度降低对业务的影响。
不建议/不可以。
- 风险提示: 请勿在全量执行期间强制手动终止任务,这极可能导致目标端数据不完整或状态异常。
- 正确操作: 如需终止,请等待全量阶段自动完成后,再执行停止操作。
全量阶段主要通过 SELECT 拉取数据,确实会带来一定的 I/O 和网络开销。为降低对核心业务的影响,建议采取以下措施:
- 错峰执行: 选择业务低峰期(如深夜)启动全量迁移任务。
- 限流控制: 在 DTS 配置中调整全量迁移速率,主动限制对源库的读取压力。
- 资源隔离: 确保源库拥有独立的连接数与带宽资源,避免与核心业务争抢极限带宽。
同步过程中,业务双写(同时向新老库写入)是否会影响增量同步及数据一致性?
业务双写(分批切流)方案本身是可行且安全的,不会破坏 DTS 的增量同步机制,但必须严格遵守操作规范以防止数据回滚覆盖。
- DTS 的增量同步是基于源端数据库(老库)的增量日志(如 Binlog)进行解析的。
- 原理: 只要源端持续产生变更,DTS 就能正常捕获并传输。
- 结果: 业务侧将部分流量切换到新库写入,不会导致 DTS 任务报错或中断,也不会导致源端产生的数据丢失。
- 在双写期间,新库可能同时存在“DTS 同步过来的老数据”和“业务直接写入的新数据”。DTS 遵循增量日志优先(基于时间顺序)的原则:
- 回放逻辑: DTS 同步数据时,会严格基于 Binlog 位点(Timestamp/LSN)进行回放。
- 覆盖场景: 如果 DTS 同步过来的操作时间戳晚于您在新库手动写入的时间,DTS 的数据会覆盖新库的数据;反之则不会。
- 这不是盲目的全量覆盖,而是严格的时间序回放,旨在保证最终状态与源端演进一致。
- 尽管双写可行,但错误的操作会导致严重的数据事故。请务必遵守以下规范:
- 一旦某个表或 Database 的业务流量完全切换至新库,切勿再向老库的对应表中写入数据。如果切流后老库仍有写入,DTS 会将这些过时或重复的数据再次同步到新库,极易造成新库数据被错误覆盖或主键冲突。
- 提前评估双写链路的幂等性(即多次写入同一数据结果一致)。
- 在切流过程中持续关注任务延迟、数据校验结果和目标端数据变化。
如何在同步过程中仅删除源端数据,而保留目标端数据?
可以实现。通过在任务配置中过滤 DELETE 操作,即可达成源端删除、目标端保留的效果,但这会打破两端数据的严格一致性。
- 在创建全量加增量同步任务时,进入配置同步对象的同步类型选择配置环节,取消勾选 DELETE 操作。
- 源端的 INSERT 和 UPDATE 操作仍会正常同步到目标端;但源端的 DELETE 操作将被 DTS 忽略,不会传递至目标端,从而实现目标端数据的保留。
- 此配置会改变源端与目标端之间的数据演进关系,导致目标端数据不再严格跟随源端删除行为。
- 数据差异:随着时间推移,目标端的数据量将多于源端(包含源端已删除的历史数据)。
- 一致性破坏:目标端不再是源端的实时镜像,无法用于需要严格一致性的场景。
适用于目标端需要长期保留历史数据、审计数据归档、目标端承担查询分析(OLAP)或加工任务,需要完整的历史记录。
在专有网络的迁移或同步任务中,为什么私有网络内会莫名出现多个以 dts_shuttle 开头的网卡?
在创建火山引擎专有网络数据迁移或同步任务的过程中,系统会默认在您选择的私有网络内创建数张网卡,网卡会默认挂载到您选择的子网上。网卡的名称格式为 dts_shuttle_********。
最近更新时间:2026.08.12 16:33:47