面试官：你经历过数据库迁移么？有哪些注意点和难点？

前言

最近写了不少数据库相关的文章，你们基本上对数据库也有了不少的了解，数据库自己有所了解了，咱们是否是应该回归业务自己呢？

你们去了解过本身企业数据库的部署方式么？是怎么部署的，又是部署在哪里的？部署过程当中可能会出现的问题有哪些？

是主从？仍是双主？有没有分库？大的表作了分表没？等等...部署方式大几率也都是分库的，表数量级超千万基本上都开始分表了，考虑周全的企业，确定也有数据库的冷备，热备，灾备，以及异地容灾等等。

我还记得我大学作项目，学校就是买了不少物理机，咱们的项目和数据库都是部署在本身内部的服务器上的，那家伙一到夏天风我嗡嗡嗡的吹，烦死了，机房还很热。

可是我敢打赌，你们如今所在的企业，大几率都是使用了各类云服务厂商的服务部署方式，那就引入了今天的第一个思考。

为何数据库要上云呢？

咱们公司的大多数服务以及数据库都是在对应的云服务厂商的，那问题就来了，为啥都要上云呢？

在思考这个问题的时候，我第一时间想到了反证法，不上云的坏处是啥？

1. 成本

相较于传统服务器须要购买、租用的方式，云服务器采用即用即收费的方式，减小购买成本，灵活扩展的容量能够按本身需求来定，不用前期估量须要用多少。

我以前所在的电商活动团队，每次到了大促咱们就去租赁云服务厂商的流量机，等活动结束就还回去，真的就是成本最大化了，并且仍是根据你的使用流量计费。

若是你们仍是使用本身购买的服务器，那这个时候难道去临时采购么？虽然我知道百度就是在某年春节活动的时候采购了N多物理机，可是性质不同，他们是能最大化利用这些服务器的，他们甚至能够开发云服务本身作云服务厂商，实际上他们确实也这么作了。

2. 性能

云服务器实现了硬件上的隔离以及宽带上的独享，不受到地域、流量等的限制，能够持续的进行业务交流，不会因中断影响效果。

若是你们仍是使用物理机，那去运营商迁专线的带宽成本，还有物理机性能的问题也不必定能更上。

因为如今成本问题，大家公司买了不少低配的服务器，可是忽然大家业务体量几何增加，怎么办？继续买高配的？显然不是很合适。这谁顶得住啊？

3. 管理

云服务器能够实现远程同步管理，共享，各类业务的备份。传统服务器须要在某一网络区域内，有可能受到网络影响致使资料缺失。

上面我提到的冷备，热备，灾备其实咱们购买的服务器都能作的，可是放着一个不知道何时才能用到的服务器在那，真的很浪费。

并且也有他作不到的，好比灾备，若是你公司在震区，要是还用物理服务器，基本上等于自杀，发送天然灾害的时候全球的用户都没法访问你，交给服务厂商就不同了，他们选址颇有讲究的，而且在各个地方都创建本身的数据中心，保证了高可用。

4. 安全

为了保证云平台的可靠性，云服务平台公司确定会投入大量的功夫，有一套可靠的安全保障系统，平台使用者没必要担忧平台稳定性、安全性问题。

物理机一旦高权限的全部者使坏，基本上都是不可恢复的灾难，虽然云服务也同样，可是合理使用，和适当的权限收敛，彻底能够作到更高级别的安全的。

微盟事件你们也知道，若是提早作好各类全量，增量备份其实就没什么大问题的，再者就是权限收敛问题，我司在对应的数据库服务器上是禁用了rm -rf 、fdisk以及drop这样的极端操做的。

全部数据库的查询更是本身的组件查询，连update都没法操做（只能靠代码）。

若是仍是使用物理机，就须要本身去维护，升级打补丁，很难保证不被黑客入侵，以前我就遇到过服务器补丁打迟了，致使被黑客攻击，劫持拿去挖矿了，而云服务厂商的安全系统都是实时更新的。

小结：没有特殊状况，能用云产品就直接用云产品，由于云产品提供的不只仅是产品能力，最关键的是关键时刻的容灾、应急和服务能力，这些能力，并非全部公司都能完整建设一套，甚至是不少公司想都想不到的。

到目前为止，虽然各大云厂商包括他们的产品，都还有这样那样的问题，可是从体系上，云仍然是最完善，最规范的，直接一点讲，比99%的公司作的都要好。

上云须要考虑的问题

这里颇有意思，我在写这个文章的时候，我司正在作部分业务上云，以及云迁移这样的业务，这让我联想到了不少有意思的事情。

咱们如今是从某云迁移到华为云，我想你们也会与这样的场景，可是这样迁移会带来一些什么样的问题呢？不知道你们思考过没？

其实从本地到云，或者从云到云，要思考的点估计是差多的，那我先抛出一些问题，看下这些问题华为云服务厂商是怎么解决的。

1. 迁移失败：数据迁移失败怎么办
2. 数据丢失：怎么判断迁移后数据是否完整
3. 业务中断：迁移到一半遇到不可抗力怎么办
4. 数据、传输加密：数据传输过程当中怎么加密，防止被不法之徒中途获取数据
5. 热切换：怎么作到不停服切换，以及数据源切换过程当中的数据一致性

这些问题是咱们不得不考虑的，你们是否是觉得迁移多简单，那我想问一下，假如是订单库呢？大一点的电商每一秒，甚至是每一毫秒都是有订单的，哪怕是凌晨，别问我为何知道咳咳。

那你确定不能停服去迁移数据库，你须要一边迁移一边接受新的数据，这个时候就须要一些技巧了，不知道redis字典的rehash你们知道么？

rehash

在须要扩容的时候，redis会新建一个hash字典，这个时候老的中止接收数据，新数据放到新的字典，同时慢慢把老数据拿过来，其实这个思想，在数据库迁移也是能够用的，可是数据库的操做，每每都是基于数据的，并非都是增量。

那简单，作点取巧的操做也能够，那云厂商的已经把我上面提到的全部问题都确定考虑过了，我接触的是华为云，华为云使用了DRS（Data Replication Service 数据复制服务）作数据库迁移的事情，他怎么作的呢？

DRS：数据复制服务(Data Replication Service，简称为 DRS)是一种易用、稳定、高效，用于数据库在线迁移和数据库实时同步的云服务。 DRS 围绕云数据库，下降了数据库之间数据流通的复杂性，有效地帮助您减小数据传输的成本。

你们可能会好奇，为啥不本身去实现数据迁移，要用别人的组件呢？其实车轮子这个，若是你没更好的思路你仍是用别人写好的就行了，你能比得过专业团队的研发结果嘛？

不过技术背后的实现，解决的问题仍是须要咱们去关心的，否则DRS什么都帮咱们作了，咱们动动鼠标就解决了，你怎么获得收获呢？这才是今天探讨的重点。

我说一下用车轮的好处吧：下降成本，下降技术门槛、下降风险

• 人力成本时间成本，都是很昂贵的，若是一个现成的东西都帮咱们作了，咱们还去开发干吗？再者，我相信大部分公司仍是没专门的DBA的，可是车轮子在了，咱们开发也能去作迁移这样的事情了，不是嘛？咱们传统技术迁库耗时耗力不说了，失败率是真的高，还有数据对比等等，很头疼，我以前东家数据库迁移都是半夜，搞一夜，天亮都不必定搞好了，要是没好，用户上线了，还的暂停。

不过即便是使用了工具，一个数据库完整的迁移流程却仍是应该很严谨的，你们可能会疑惑再严谨能有多严谨？给你看个图你就知道了：

华为云的DRS的在线迁移怎么作的呢？

能够看到，迁移图中是使用到了VP*，这个的做用主要就是保住一个高速稳定的传输，以及传输数据的加密，万一你同步的过程被其余对手公司抓到，那？在文章后面，你能够看到华为云DRS是怎么作的网络安全，我作了一次完整的迁移实战，而且作了总结。

迁移实战

他迁移很简单，都有教程，我用过一遍，大体步骤以下：

迁移做为一个特殊时期，业务配合、人为配合是最关键的，部分操做必定要规避，好比说常见的：

• 不能将源数据库日志强制清理掉
• 不能将用于链接源数据库的用户密码修改掉、或者删除掉
• 不能将表长时间锁定，致使外部都没法查询该表

他在迁移以前能够作一个迁移预检查，从官方文档来看，都是对过往迁移案例总结出来的检查步骤，可让迁移成功有更好的保障，这点挺好能够在迁移前夕找出问题所在，我也失败过，是由于环境问题，都给了很明确的指示。

你们不知道思考过没，就是数据迁移了，可是若是数据库的设置没迁移那也是很麻烦的，若是一个迁移工具可以作到把DBA设置的好的User权限迁移了，以及咱们设置的各类触发器，数据库字符集设置都迁移了，那才是我理想的一个迁移工具，是的华为云DRS作了，这就是比较优秀的点了，真的省了不少功夫。

特别是对于数据库各类设置并没那么了解的开发来讲，这功能确实是很福利了，并且还有性能参数，相似各类buffer大小，cache大小等等他都能迁移，甚至能够作到流控，还能够随时改变流控就更优秀了：

迁移模式多样化，这是我准备开始迁移的第一感觉，我上面提到过，若是不能增量迁移将毫无心义，DRS仍是想到了，这让我以为好像有点暖，说着说着个人眼角又湿润了...

由于大部分的场景咱们都是线上业务的不停服迁移，在迁移过程当中，仍是不断的有增量数据在涌入的，敖丙以前所经历过的数据库迁移基本上也都是全量+增量的迁移模式，全量的场景只存在内部系统，或者离线数据等。

其实这里的技术核心就在于怎么去保证增量的数据也能保证不丢失正确的迁移，我猜是经过binlog同步的，我看了下他的文档，日志，果真被我猜对了。

DRS是经过全量迁移过程完成历史数据迁移至目标数据库后，增量迁移阶段经过捕抓日志，应用日志等技术，将源端和目标端数据库保持数据一致，这里的保持一致后面也会提到，他提供了完整的数据对比功能。

迁移过程很简单，进度彻底能够看到，数据的延迟也能够很直观的看到：

迁移结束以后，DRS提供了数据对比，其实数据对比之前我作迁移的时候，咱们都是经过对比数据库行数去作的，由于没这样的迁移工具，我发现了很暖心的一点就是内容对比，这一点让我很惊喜，由于行数的对比仍是不够严谨，修改的日志若是缺失行数的对比也是没用的。

等待对比完成，点击“查看对比报表”，能够了解对比详情，详情页面如图所示：

上面提到的网络安全问题，我也在DRS找到了答案，他们会使用特定的加密协议进行数据传输，还能够用特定的VP*挂载网络传输：

DRS还作了迁移监控，能够看到实时进度，让整个迁移进度比较可视化，中间的异常也一目了然，说实话工具真的就是香，之前想都不敢想，咱们熬夜就生怕一个环节出错，并且常常仍是后知后觉的，可视化的流程会你对迁移有一种掌控感。

迁移完成：

从我开始迁移到结束，整个流程其实不到2小时，这个放在之前是不敢想的，这波体验我是很满意的，让我一个开发就作到了之前DBA才能作的事情，说着说了旁边的DBA的眼角也湿润了....

小结

整个体验我以为是很不错的，我总结几个我以为DRS独特的设计和使用场景：

1. 迁移限速，根据限定时间段设置迁移速度上限

应用场景:

• 有些流量型app，好比游戏厂商等客户， 迁移时源数据库的公网、VP不能打满（打满将影响其对外业务，或者影响共用VP 带宽）

• 有些业务负载较重，或着客户没法接受 业务时间应用程序由于迁移带来额外负载

2. 用户迁移(权限、密码、 definer)，完整继承源权限体系

应用场景:

• 市面上的迁移产品均不支持用户的迁移， 也就是说若是用户没有注意，或者不懂用户迁移，那么迁移后业务必然报错， DRS提供了全套的用户权限继承设计， 能够将权限、密码、definer保留迁移至目标数据库，确保迁移后权限安全、业务稳定，可让不熟悉数据库的客户迁移时，仍然能够完成一场精细的、高质量的数据库迁移。

3. 参数对比，迁移后业务稳定

应用场景:

• 市面上的迁移产品均不支持参数的迁移，而数据库参数不同，这将直接致使业务程序 运行报错(举个简单例子session数迁移后变小了)，DRS选定了业务和性能强相关关键的参数，避免了这些参数后续由于没有继承源环境设置，而致使业务报错或性能降低， 可让不熟悉数据库的客户迁移时，仍然能够完成一场精细的、高质量的数据库迁移。

4. 数据校对平台，割接好帮手

应用场景:

• 市面上的迁移产品均不支持数据的对比，校对工做留给用户测，DRS提供了丰富的对比功能:

• 对象对比

• 数据级对比

• 对比可定时，可取消

  利用对比定时任务，能够选择凌晨等业务低峰期 进行数据一致性对比，次日能够查看数据对比结果，对于迁移状况作到彻底掌握。 可让不熟悉数据库的客户迁移时，仍然能够完成一场精细的、高质量的数据库迁移。

5. 触发器、事件的迁移

应用场景:

• 市面上的迁移产品均不支持触发器、事件的迁移，精通迁移的用户关注这些细节，因 为触发器和事件也是数据库的一部分，触发器和事件存在关键的业务逻辑，这些对象 不支持迁移，业务必然报错，甚至形成不可挽回的损失。
• 可让不熟悉数据库的客户迁移时，仍然能够完成一场精细的、高质量的数据库迁移。

注：【部分图片来源网络 侵删】

总结

其实给你们介绍这样DRS的一个背景和技术，主要是但愿跟你们跟我一块儿作一次完整数据迁移，一块儿去探讨技术背后的场景，以及场景背后咱们应该有技术思考。

不过此次体验真的，让我不得不感慨技术的便捷性，之前数据库迁移都是团队开发以及测试一个团队熬夜守着数据库迁移，最后验证测试才能走的，全部人拖着疲惫的身躯看着升起的太阳，眼角都湿了...

如今我本身看看教程动动手指就完成了一场大规模的数据库迁移演练，在享受技术给我带来方便的同时，也让我对技术背后的具体实现和人生的意义陷入了深深的思考。

或许这就是技术的价值吧，或许这就是这么多工程师日日夜夜辛苦的意义吧，或许...

我是敖丙，你知道的越多，你不知道的越多，咱们下期见！