曝光，鹅厂造了一座「桥」！

前些日子，我们曝光了一个鹅厂隐藏业务——主机搬家。

很多客户不禁要问了，主机迁移都能那么丝滑了，数据库是不是也安排一下？

作为承载业务交易数据的核心软件，数据库的迁移让无数运维闻风丧胆。

究其原因，主要有四点：

一，数据库迁移对准确性要求极高。

无论多大数据量，迁移过程中一个数据的错漏，就会导致重大损失。如果是金融场景，损失更是惨重......（不敢想象一下自己的余额突然少了一个0）

二，数据库与业务系统深度绑定。

万一迁移后应用系统水土不服，整个业务都会崩溃，后果不堪设想。

三，不同数据库有不同的数据结构和语法，迁移过程极其复杂。

同样是数字，在Oracle中，可以用NUMBER来定义大部分数字。但到了MySQL中，数字会被细分为整数、小数等不同类型存放。不同数据库还有自己特定的查询和操作语法。

（大概是这样👇）

过去搬个数据库，动辄要改造千万级别的数据，堪比愚公移山。

四，数据库迁移对时间要求极为严苛。

为了保障迁移成功，很多业务在自行迁移数据的过程中，业务往往会停机。如果耗时十天半个月，那业务怕也是要凉了。

一路走来，鹅厂也深知数据库迁移的痛。于是，我的同事们结合这些痛点，打造了一座数据库迁移的「大桥」。

桥上拥有多个设施完备、功能齐全的站点。有的负责数据改造、有的负责数据传输，还有的进行一致性校验等。

把迁移的内容运上桥，经过不同站点时，各项改造工程便开始有条不紊地进行了。

为了匹配不同客户的需求，我的同事还为这座桥打造了两种产品部署形态，公有云环境下的DTS和私有云部署的DBbridge。

搬家前，鹅厂的工程师们会先摸清楚旧数据库的情况——是哪种数据库？有多少表、库、数据？现有应用和新数据库是否适配，要不要进行代码修改和数据类型调整？

盘点清楚， 一切便可以交给工具了。

不同于过去那种愚公移山式的搬家，DTS和DBbridge把数据库分两部分迁移——数据结构和数据。

这些年和数据库斗智斗勇，我的同事对不同数据库的结构、语法和特性早已是信手拈来。

A数据库到B数据库该怎样转换，中间会踩到什么坑，都梳理出来沉淀在工具中。只需要选定源端目标端数据库，工具就可以将结构和数据同步过去。

为了尽快传输数据，鹅厂工程师还针对不同数据库特性，匹配对应的传输方式。

工具还会对数据做预判，针对源端和目标端的冲突数据，采用对应处理策略，让传输更加丝滑高效。

最重要的是，使用这套工具，业务不用停机。

那么数据在迁移时产生的新数据，怎么处理呢？

这就要说到日志的作用了。

在数据库中，每一步操作都会被记录在日志中。迁移过程中，新增加的数据，都会通过日志解析后在新数据库回放，一条也不会放过。

迁移完成后，迁移工具还会用各种姿势将新旧数据进行比对检查，高效验证迁移结果，给数据割接吃一颗定心丸。

为了保证应用在新数据库的表现，我的同事们还给新数据库设置了各种KPI和压测——

应用查询不够快，改写！

时延不够短，优化！

服务器压力指标过高，调优！

......

直到应用在新数据库上跑得又快又稳。

实际上，在鹅厂，无论主机迁移，数据库迁移，还是存储迁移，都集成到了统一迁移服务平台MSP中。

MSP就像全能的搬家管家，集合了各种好用的搬迁工具。

在搬家前，MSP会像一个贴心的管家一样，替你盘点家当。 只需点一下，无论你有几个主机、数据库、存储桶，从规格、类型、版本到内存、网络、操作系统，MSP都能盘点得一清二楚，省事又安全。

腾讯搬家，欢迎试用！👇

﹀

﹀

﹀

-- 更多精彩 --

腾讯云原生数据库 TDSQL-C 发布列存索引能力，大幅提升复杂查询性能

↓↓点击阅读原文，了解更多优惠