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

前言

最近写了很多数据库相关的文章，大家基本上对数据库也有了很多的了解，数据库本身有所了解了，我们是不是应该回归业务本身呢？

大家去了解过自己企业数据库的部署方式么？是怎么部署的，又是部署在哪里的？部署过程中可能会出现的问题有哪些？

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

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

但是我敢打赌，大家现在所在的企业，大概率都是使用了各种云服务厂商的服务部署方式，那就引入了今天的第一个思考。

为什么数据库要上云呢？

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

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

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的一个背景和技术，主要是希望跟大家跟我一起做一次完整数据迁移，一起去探讨技术背后的场景，以及场景背后我们应该有技术思考。

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

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

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

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