本文将介绍腾讯云TDSQL数据迁移的相关方案及之前的案例。内容将分为三部分：制定数据迁移方案、腾讯云数据库迁移工具功能介绍以及实践的迁移案例。

数据迁移

数据迁移对DBA人员并不陌生，它是指将数据通过一定技术手段从一个物理位置移动到另一个物理位置，以实现数据集中。今天我们将重点讨论从Oracle进行异构数据库迁移，即迁移到TDSQL数据库。一般来说，业务需求源于业务系统的升级迭代或者在功能化背景下将原有的Oracle数据库更换为TDSQL或其他数据库。在数据迁移方案上，这些需求基本通用，主要包括数据库版本升级迭代和数据迁移上云等。

我们在进行大量数据迁移工作后，总结了一些失败案例及原因。数据迁移并非简单的日常DBA工作，不能仅依赖一个简单的工具完成。对于异构数据库迁移，它本身就是一个系统性工程。

异构数据库迁移失败的原因

1. 两个数据库本身存在不同特点和特性，存在的非常细微化的差异，测试不充分的情况下很容易导致失败。例如，Oracle和其他数据库（如TDSQL、PG）在数据类型计算、字符集处理、空值逻辑等方面有所不同。此外，数据类型范围差异也容易被忽略，可能导致迁移失败。

2. 迁移方案可能过于粗糙，缺乏具体步骤和权限说明。异构数据库迁移涉及多个部门，如业务部门、测试部门、运维部门等，人员众多且可能存在沟通障碍。若缺乏统一管理和指挥，项目可能混乱失控。

3. 迁移工具选择问题。各家厂商使用自家工具或开源、第三方工具，可能导致数据库兼容性不佳或测试不充分。在大数据量情况下，功能或性能不满足可能导致迁移失败。

4. 人员分工问题。方案验证和实际迁移时人员可能变换，需明确测试方案细节，避免失败案例。

5.  其他情况，如停机窗口时间不足，紧张或意外导致迁移失败。

异构数据库方案设计的考虑点

首先，建立专业团队，特别是对数据库更了解、更专业的人员，如数据库DBA、数据迁移人员、数据库架构师以及业务负责人等，共同探讨迁移方案。其次，迁移方案需细致评估，充分考虑数据迁移、业务迁移、数据校验和回退方案等方面。此外，在数据迁移前进行数据备份，以便在迁移失败时应急回退。

关于停机窗口，由于客户对此较为谨慎，我们需要评估每个动作所需时间，并在规定时间内完成。在线迁移的时间可能较短，只能进行切换操作；若时间较长，则可以相对宽松处理。但由于生产业务的重要性，迁移基本需在半小时内完成，包括业务验证和数据校验等。

实施过程中，选择熟悉迁移过程且操作熟练的人员进行操作，以减少误会和时间浪费。迁移后，继续观察业务验证是否正常，切换后一周内业务运行情况，数据库性能变化以及高峰期、低谷期业务性能波动等，以确保迁移的顺利进行和成功实施。异构数据库迁移的整体方案可以分为迁移前、迁移中和迁移后三个阶段。在迁移前，我们需要组建专门的迁移团队并确定人员，同时进行原有应用DB架构、RPS、基本信息、涉及人员及组件的调研，并设计新的数据库TDSQL，实现分布式和高可用架构。

在方案规划阶段，我们需关注数据迁移方案、数据架构设计、应用适配等方面，并涉及到应用联调测试、回退应急等方案。确定方案后，我们将进行测试验证，这一般是通过在测试环境中进行几个UAT过程来完成。每个环节都要进行方案的测试和验证，主要是为了发现有没有新的问题。测试验证和部署的工作相对来说比较繁琐，我们在这里可能会使用大量的时间进行验证。

在方案制定可能需要一个月的时间，而测试验证的过程可能需要两三个月甚至更长。验证通过后，我们需要进行双轨试运行一段时间，然后再找一个停机窗口进行正式上线，完成整个迁移的过程。通过严密的规划和验证，我们可以确保异构数据库迁移的顺利进行和成功实施。

腾讯云数据库迁移工具

下面将介绍腾讯云数据库迁移工具，这些工具可以帮助我们完成整个迁移过程。目前，我们在私有云中有两个迁移工具：DBBridge和TMT。DBBridge是商业版本，定位为数据迁移平台，支持各种异构数据库的迁移、数据同步和数据订阅。这个工具是平台化版本，自带高可用性，可以部署在一台或多台机器上，最大节点上限为50个。它还具备高可用监控和权限管理，适用于企业长期数据同步的场景。TMT则是专门针对Oracle迁移到TDSQL的场景的一个工具，可以实现迁移评估和数据迁移，这是一个免费版本，主要目的是为了快速实现Oracle数据迁移到TDSQL的需求。目前，这两个工具都已经正式投入使用，其中DBBridge支持的数据库类型更多，包括商业的、自研的和开源数据库。

关于用户权限管理，DBBridge提供管理员和普通用户两种角色。管理员可对所有通道进行管理，而普通用户仅能管理自己名下的通道。此外，DBBridge还具备监控功能，可实时监测集群内各组件服务状态及通道任务状态。在数据源方面，该系统支持商业化数据库、TDSQL数据库以及外部实时数据流（如Kafka）等多种数据源。

为实现数据迁移，TMT提供以下功能：首先，对源端Oracle进行迁移评估，以确定迁移至目标数据库的可行性；其次，完成结构迁移，即将Oracle中的表、索引等对象迁移至目标端；然后，执行数据迁移，将数据从Oracle端抽取至目标端；最后，进行数据校验，确保数据迁移的准确性和完整性。整个迁移过程遵循标准化步骤，确保迁移过程的顺利进行。

我们对比TMT和DBBridge这两款工具，首先，TMT是一款免费且高度灵活的脚本化工具，类似于一个程序包，适用于Oracle至TDSQL数据库的迁移场景。而DBbridge则是一款商业化的产品，功能全面但相对较重，适用于需求较高的场景。在安装过程中，TMT无需安装，只需配置好相关文件即可直接使用，具有简单且灵活的优点。相反，DBbridge需要安装，基于图形化界面操作，可定制化程度较低。就产品功能而言，TMT具备基本的结构迁移、数据迁移和数据校验功能。而DBbridge功能更为丰富，包括数据订阅、操作过滤等功能，并支持多种订阅目标，如文件和其他组件。

在迁移效率方面，由于TMT具有较高的灵活性，因此其效率相对高于DBbridge。总之，这两款工具各有优缺点，用户可根据实际需求选择合适的工具进行数据库迁移。

DBbridge的功能

迁移评估功能

下面将重点介绍DBbridge的功能，首先从迁移评估开始。迁移评估旨在判断两个数据库之间的迁移可行性。主要通过从Oracle端获取对象源数据，对其进行解析，并根据源端和目标端的语法规则进行匹配。若匹配成功，表示迁移可行；反之，则不可行。

评估完成后，将生成一份评估报告。报告有两种形式：一是网页版HTML报告，采用图形化方式展示评估结果，包括评估对象、用户、不兼容原因等信息，以及具体的不兼容问题，如不支持的语法等。二是CSV格式报告，便于用户筛选关键信息并进行对比。此外，我们还提供转化后的目标库SQL文件生成功能，直接生成目标库语法的SQL文件，方便用户在目标库中执行。值得注意的是，在进行迁移评估时，用户只需在配置文件中明确目标类型和选择相应的规则模板，而无需目标库实际存在。这一特点使得评估过程更加灵活和高效。

结构迁移是将源数据库的表结构转换为对应的目标数据库表结构，主要依赖于转换规则。针对分布式目标库，DBbridge支持在界面上调整分布策略，如设置复制表或分布式表，并可为每个表单独设置。对于大量对象，还支持生成Excel格式文件以批量指定分布策略。Oracle支持约14种对象类型，包括存储过程、视图、函数和TBlink等常用对象。迁移失败时，系统会展示失败详情，用户可通过界面查看并进行相应的人工修改或调整。

全量数据迁移在结构迁移完成后进行，可将Oracle数据迁移至目标库。此迁移过程可在备库进行，而非仅限于主库。同时，支持按WHERE条件过滤迁移数据，利用Oracle闪回特性。用户可选择清空或不清空目标表数据，以避免误删除。

在实际生产环境中，通常需要控制迁移速度。DBbridge允许用户调整并发数量以及其他参数。若迁移失败，系统同样会展示失败详情，以便用户采取相应措施进行修改或调整。

迁移过程中的并发设置按分区进行，即按表分区进行单独抽取。需注意的是，Oracle的GBK字符集与常规GBK不同，应使用GB18030或UTF8进行兼容，以避免乱码或数据迁移失败问题。

增量迁移在全量迁移完成后进行，用于在生产业务不停机情况下进行数据追平。增量迁移的实现主要通过记录全量时的SCN位点，并在增量过程中解析Oracle归档或在线日志，判断SCN是否位于所需时间点之后。若是，则应用全量后的数据；若否，则丢弃。

在进行全量位点指定时，我们必须先完成全量同步，然后才能进行增量同步，增量同步作为一个独立功能存在。例如，我们可以根据最新数据进行同步，或者通过输入SCN号从特定时间点或SCN开始同步，这些操作都是支持的。此外，我们还可以选择同步类型，如仅同步DML或DDL。

对于其他数据库，它们支持过滤操作，但我们不支持TRUNCATE操作。如果Oracle源端定期执行数据清除操作，我们可以选择不同步这些操作，将其视为无效操作。任务启动后，我们可以在界面上查看同步延迟情况，它会显示当前数据同步的大致延迟时间。同时，下方会显示运行日志，当有数据同步时，会打印相应的日志。这是界面监控功能的一部分。如果需要与客户监控工具对接，我们将提供相应接口，将相关监控信息输入到客户监控工具的接口上，实现监控功能。

数据校验功能

数据校验功能有两种方式：内容校验和函数校验。内容校验包括仅进行计数（count）和全面校验表内所有内容。校验可以在在线或离线状态下进行。在线校验通常适用于业务无法停机的情况。进行在线校验时，需要指定数据范围，例如校验某个时间段之前的数据。在校验完成后，我们会根据主键对两边数据进行逐行校验，生成哈希值。如果首次校验发现部分数据不一致，我们将在一段时间后（可设置，默认为半小时）对这些不一致数据进行再次校验，以防止因延迟或其他原因导致的变更未被校验。我们可以设置反复校验的次数，默认值为3次。

我们还可以采用抽样校验方法，例如抽取5%的数据进行校验。抽样校验可以减少校验所需时间。在校验过程中，我们还可以针对WHERE条件进行校验，仅校验特定时间段或范围内的数据。请注意，在线校验会对系统资源产生一定占用。因此，在进行校验时，应尽量调小并发度或使用在较小数据量。在大规模数据量下进行校验可能对业务产生影响。

将数据库数据写入KAFKA消息体

此外，我们还提供将数据库数据写入中间件或类似KAFKA的消息体的功能。这种场景适用于客户需要对数据进行加工的情况。由于在生产环境中直接处理数据较为困难，因此通常先将数据库数据写入KAFKA，然后下游消费程序从KAFKA中提取数据并传输至大数据平台进行加工。DBbridge支持将数据写入KAFKA的功能，既可以对表级别进行传输，也可以对整个数据库进行传输，还可以针对单个表指定Topic或将多个表放入同一个Topic。此外，该功能还支持对DML和DDL进行过滤，确保在表结构发生变化时，下游也能感知到变化，并将DML的变化同步至KAFKA。需要注意的是，KAFKA的Topic上限一般为1024，因此建议控制Topic数量，避免过多的Topic导致维护难度增加。一般情况下，如果数据库不太重要，可以为一个库分配一个Topic；若要提高下游消费能力，可以进行适当分区，但分区数量建议不要超过8个，以免影响流量和系统稳定性。

DBbridge实践应用的案例

从ORACLE数据库到TDSQL的迁移

最后，本文将介绍一个关于DBbridge实践应用的案例——从ORACLE数据库到TDSQL的迁移。在这个案例中，Oracle作为核心业务系统，数据容量为5TB。整个迁移过程要求在线完成，在完成后进行数据校验。首先，我们通过DG库进行全量迁移，避免影响主库。全量迁移完成后，进行数据校验。其次，校验通过后，从全量记录的SCN开始增量同步。这种方法的优点是主库无需停机，全量迁移时间充分，只要保证全量期间主库归档一直保留，迁移时间就可以掌握。迁移完成后，搭建增量通道并保持持续运行，确保数据追平。

在实际业务切换前，先停止应用，确认两边数据正常同步且一致。接下来，通过进行数据应用层的校验，如对业务表进行count、sum数值操作或使用工具进行抽样校验。校验通过后，开始进行数据库切换，切换完成后停止同步通道。

如果客户希望有回退方案，即在完成从Oracle到TDSQL的切换后，再搭建一个从TDSQL到Oracle的反向通道进行数据反向同步。如果新数据库出现问题，我们可以迅速进行回切到原来的数据库。迁移过程包括从Oracle到TDSQL，再从TDSQL到Oracle的回流，整个过程在半小时内完成，尽管数据量大，但切换时间并不长，且过程平稳。

从MySQL到TDSQL的迁移

另一个案例是从MySQL到TDSQL的迁移。许多客户大量使用MySQL，其中涉及较多功能模块。尽管MySQL与TDSQL完全兼容，但由于分批迁移的需要，我们需要分阶段进行迁移工作，并确保数据的实时同步。迁移方案同样通过备库进行全量迁移，完成全量迁移后，继续在备库上进行增量同步。

按照模块分阶段进行迁移，根据业务规划分成多次进行数据库切换。此方案相对平滑，且校验效率高，因为MySQL与TDSQL同源且完全兼容。我们使用DBbridge的采样校验功能，仅对增量数据进行校验，例如全量迁移3月8日的数据，增量迁移时仅校验8日至9日的数据，或适当扩大范围，如一周内的数据。

数据归档功能

此外，TDSQL还支持关于数据归档的需求。实际上，DBbridge本身并未提供归档功能，而是利用其迁移和校验能力实现了一个定时归档任务。归档的主要目的是将数据写入历史库。我们的方案是将数据写入历史库的同时，使用DBbridge创建两个同步任务，生成一个数据文件并保存在本地，另一个任务写入目标库。完成写入后，需要进行数据校验，确保源数据与历史库数据一致，且数据源、目标库和数据文件生成的OK文件三者保持一致。

生成数据文件的目的是备份和快速回滚，以确保数据安全。在校验通过后，通过DBbridge的删除功能调用一个删除动作，将源端数据删除。删除后再进行一次校验，确保删除的数量与OK文件显示的数量一致，此时归档成功。整个归档任务巧妙地利用了DBbridge现有的功能实现。