我们做迁移的目的是为了进行业务迁移，在进行数据迁移时，企业最怕的就是影响业务正常运作，进而影响到用户的正常使用，从这个角度出发，迁移至少要满足三个正确性才能进行业务的切换。
首先，我们应该保证函数、触发器、表结构、索引等全部 Database 对象能够完整地迁移到目标库，并且确保对象的运行逻辑和源库的一致性；其次，在数据迁移中，如果业务对停机时间窗口有要求，还要考虑全量+增量的在线迁移，保证业务不中断，同时对同步数据进行校验，保证数据迁移的准确性；最后，当对象和数据全部迁移成功后，要使用工具测试迁移后业务运行的正确性，一是确保业务在目标库的运行结果正确，二是确保目标库性能能够支撑住业务的负载。
以从 OpenTSDB 迁移至 TDengine 为例，我们首先需要将基于 OpenTSDB 的系统进行迁移涉及到的数据模式设计、系统规模估算、数据写入端改造，进行数据分流、应用适配工作；之后将两个系统并行运行一段时间，再将历史数据迁移到 TDengine 中。当然如果你的应用中有部分功能强依赖于上述 OpenTSDB 特性，同时又不希望停止使用，可以考虑保持原有的 OpenTSDB 系统运行，同时启动 TDengine 来提供主要的服务。
在具体操作上，你可以使用 TDengine 的官方迁移工具 taosAdapter 来帮助完成迁移，无需编写一行代码，就可以将基于 OpenTSDB 的应用快速、安全、可靠地迁移到 TDengine之上，显著降低迁移成本。
而从企业具体实践角度来说，睿信物联网制定的迁移方案也可以借鉴。为了能够平滑顺利地完成升级上线，不影响用户正常使用，睿信物联网将升级上线分为数据迁移、试运行、正式上线三阶段完成。
在数据迁移阶段，OpenTSDB 和 TDengine 并行运行，数据同时向两个 Database 写入，在此阶段，由于 OpenTSDB 有全量数据，查询请求全部交给它，同时启动数据迁移工具，将历史数据迁移到TDengine，待数据迁移完成，进入到试运行阶段，此时 TDengine 已经具备全量数据，查询请求全部切换到其上，观察两周左右时间没有问题就进入正式上线阶段，此时 OpenTSDB 停止运行，占用资源全部回收。
考虑到业务的快速长久发展，正确选择数据库至关重要。如果当前业务进度被数据库方案掣肘，企业能做的就是及时止损，尽快调研合适的数据库进行迁移，以保证业务的可持续发展。相信阅读完本篇文章你会解锁从 OpenTSDB 做数据迁移的正确姿势。
