鹅厂造了一座「桥」！腾讯云让主机搬家~
|
前些日子，我们曝光了一个鹅厂隐藏业务——主机搬家。 很多客户不禁要问了，主机迁移都能那么丝滑了，数据库是不是也安排一下？ 作为承载业务交易数据的核心软件，数据库的迁移让无数运维闻风丧胆。 究其原因，主要有四点：
无论多大数据量，迁移过程中一个数据的错漏，就会导致重大损失。如果是金融场景，损失更是惨重......（不敢想象一下自己的余额突然少了一个0） 二，数据库与业务系统深度绑定。
三，不同数据库有不同的数据结构和语法，迁移过程极其复杂。 同样是数字，在Oracle中，可以用NUMBER来定义大部分数字。但到了MySQL中，数字会被细分为整数、小数等不同类型存放。不同数据库还有自己特定的查询和操作语法。 过去搬个数据库，动辄要改造千万级别的数据，堪比愚公移山。 四，数据库迁移对时间要求极为严苛。
一路走来，鹅厂也深知数据库迁移的痛。于是，我的同事们结合这些痛点，打造了一座数据库迁移的「大桥」。 桥上拥有多个设施完备、功能齐全的站点。有的负责数据改造、有的负责数据传输，还有的进行一致性校验等。 把迁移的内容运上桥，经过不同站点时，各项改造工程便开始有条不紊地进行了。 为了匹配不同客户的需求，我的同事还为这座桥打造了两种产品部署形态，公有云环境下的DTS和私有云部署的DBbridge。 搬家前，鹅厂的工程师们会先摸清楚旧数据库的情况——是哪种数据库？有多少表、库、数据？现有应用和新数据库是否适配，要不要进行代码修改和数据类型调整？ 盘点清楚， 一切便可以交给工具了。 不同于过去那种愚公移山式的搬家，DTS和DBbridge把数据库分两部分迁移——数据结构和数据。
这些年和数据库斗智斗勇，我的同事对不同数据库的结构、语法和特性早已是信手拈来。
为了尽快传输数据，鹅厂工程师还针对不同数据库特性，匹配对应的传输方式。 工具还会对数据做预判，针对源端和目标端的冲突数据，采用对应处理策略，让传输更加丝滑高效。 最重要的是，使用这套工具，业务不用停机。
那么数据在迁移时产生的新数据，怎么处理呢？
这就要说到日志的作用了。
在数据库中，每一步操作都会被记录在日志中。迁移过程中，新增加的数据，都会通过日志解析后在新数据库回放，一条也不会放过。
为了保证应用在新数据库的表现，我的同事们还给新数据库设置了各种KPI和压测——
应用查询不够快，改写！
时延不够短，优化！
服务器压力指标过高，调优！ ......
实际上，在鹅厂，无论主机迁移，数据库迁移，还是存储迁移，都集成到了统一迁移服务平台MSP中。
MSP就像全能的搬家管家，集合了各种好用的搬迁工具。
腾讯搬家，欢迎试用！ |
全部评论
暂无评论
有话要说