前言
最近写了很多数据库相干的文章，大家基本上对数据库也有了很多的理解，数据库自身有所理解了，咱们是不是应该回归业务自身呢？
大家去理解过本人企业数据库的部署形式么？是怎么部署的，又是部署在哪里的？部署过程中可能会呈现的问题有哪些？
是主从？还是双主？有没有分库？大的表做了分表没？等等 … 部署形式大概率也都是分库的，表数量级超千万基本上都开始分表了，思考周全的企业，必定也有数据库的冷备，热备，灾备，以及异地容灾等等。
我还记得我大学做我的项目，学校就是买了很多物理机，咱们的我的项目和数据库都是部署在本人外部的服务器上的，那家伙一到夏天风我嗡嗡嗡的吹，烦死了，机房还很热。
然而我敢打赌，大家当初所在的企业，大概率都是应用了各种云服务厂商的服务部署形式，那就引入了明天的第一个思考。
为什么数据库要上云呢？
咱们公司的大多数服务以及数据库都是在对应的云服务厂商的，那问题就来了，为啥都要上云呢？
在思考这个问题的时候，我第一工夫想到了反证法，不上云的害处是啥？
-
老本
相较于传统服务器须要购买、租用的形式，云服务器采纳即用即免费的形式，缩小购买老本，灵便扩大的容量能够按本人需要来定，不必后期估计须要用多少。
我之前所在的电商流动团队，每次到了大促咱们就去租赁云服务厂商的流量机，等流动完结就还回去，真的就是老本最大化了，而且还是依据你的应用流量计费。
如果大家还是应用本人购买的服务器，那这个时候难道去长期洽购么？尽管我晓得百度就是在某年春节流动的时候洽购了 N 多物理机，然而性质不一样，他们是能最大化利用这些服务器的，他们甚至能够开发云服务本人做云服务厂商，实际上他们的确也这么做了。
-
性能
云服务器实现了硬件上的隔离以及宽带上的独享，不受到地区、流量等的限度，能够继续的进行业务交换，不会因中断影响成果。
如果大家还是应用物理机，那去运营商迁专线的带宽老本，还有物理机性能的问题也不肯定能更上。
因为当初老本问题，你们公司买了很多低配的服务器，然而忽然你们业务体量几何增长，怎么办？持续买高配的？显然不是很适合。这谁顶得住啊？
-
治理
云服务器能够实现近程同步治理，共享，各种业务的备份。传统服务器须要在某一网络区域内，有可能受到网络影响导致材料缺失。
下面我提到的冷备，热备，灾备其实咱们购买的服务器都能做的，然而放着一个不晓得什么时候能力用到的服务器在那，真的很节约。
而且也有他做不到的，比方灾备，如果你公司在震区，要是还用物理服务器，基本上等于他杀，发送自然灾害的时候寰球的用户都无法访问你，交给服务厂商就不一样了，他们选址很有考究的，并且在各个中央都建设本人的数据中心，保障了高可用。
-
平安
为了保障云平台的可靠性，云服务平台公司必定会投入大量的功夫，有一套牢靠的平安保障系统，平台使用者不用放心平台稳定性、安全性问题。
物理机一旦高权限的所有者使坏，基本上都是不可复原的劫难，尽管云服务也一样，然而正当应用，和适当的权限收敛，齐全能够做到更高级别的平安的。
微盟事件大家也晓得，如果提前做好各种全量，增量备份其实就没什么大问题的，再者就是权限收敛问题，我司在对应的数据库服务器上是禁用了 rm -rf、fdisk 以及 drop 这样的极其操作的。
所有数据库的查问更是本人的组件查问，连 update 都无奈操作（只能靠代码）。
如果还是应用物理机，就须要本人去保护，降级打补丁，很难保障不被黑客入侵，之前我就遇到过服务器补丁打迟了，导致被黑客攻击，劫持拿去挖矿了，而云服务厂商的平安零碎都是实时更新的。
小结：没有非凡状况，能用云产品就间接用云产品，因为云产品提供的不仅仅是产品能力，最要害的是关键时刻的容灾、应急和服务能力，这些能力，并不是所有公司都能残缺建设一套，甚至是很多公司想都想不到的。
到目前为止，尽管各大云厂商包含他们的产品，都还有这样那样的问题，然而 从体系上，云依然是最欠缺，最标准的，间接一点讲，比 99% 的公司做的都要好。
上云须要思考的问题
这里很有意思，我在写这个文章的时候，我司正在做局部业务上云，以及云迁徙这样的业务，这让我联想到了很多有意思的事件。
咱们当初是从某云迁徙到华为云，我想大家也会与这样的场景，然而这样迁徙会带来一些什么样的问题呢？不晓得大家思考过没？
其实从本地到云，或者从云到云，要思考的点估计是差多的，那我先抛出一些问题，看下这些问题华为云服务厂商是怎么解决的。
- 迁徙失败：数据迁徙失败怎么办
- 数据失落：怎么判断迁徙后数据是否残缺
- 业务中断：迁徙到一半遇到不可抗力怎么办
- 数据、传输加密：数据传输过程中怎么加密，避免被不法之徒中途获取数据
- 热切换：怎么做到不停服切换，以及数据源切换过程中的数据一致性
这些问题是咱们不得不思考的，大家是不是认为迁徙多简略，那我想问一下，如果是订单库呢？大一点的电商每一秒，甚至是每一毫秒都是有订单的，哪怕是凌晨，别问我为什么晓得咳咳。
那你必定不能停服去迁徙数据库，你须要一边迁徙一边承受新的数据，这个时候就须要一些技巧了，不晓得 redis 字典的 rehash 大家晓得么？
rehash
在须要扩容的时候，redis 会新建一个 hash 字典，这个时候老的进行接收数据，新数据放到新的字典，同时缓缓把老数据拿过去，其实这个思维，在数据库迁徙也是能够用的，然而数据库的操作，往往都是基于数据的，并不是都是增量。
那简略，做点取巧的操作也能够，那云厂商的曾经把我下面提到的所有问题都必定思考过了，我接触的是华为云，华为云应用了 DRS（Data Replication Service 数据复制服务）做数据库迁徙的事件，他怎么做的呢？
DRS：数据复制服务 (Data Replication Service，简称为 DRS) 是一种易用、稳固、高效，用于数据库在线迁徙和数据库实时同步的云服务。DRS 围绕云数据库，升高了数据库之间数据流通的复杂性，无效地帮忙您缩小数据传输的老本。
大家可能会好奇，为啥不本人去实现数据迁徙，要用他人的组件呢？其实车轮子这个，如果你没更好的思路你还是用他人写好的就好了，你能比得过业余团队的研发后果嘛？
不过技术背地的实现，解决的问题还是须要咱们去关怀的，不然 DRS 什么都帮咱们做了，咱们动动鼠标就解决了，你怎么失去播种呢？这才是明天探讨的重点。
我说一下用车轮的益处吧：降低成本，升高技术门槛、升高危险
- 人力老本工夫老本，都是很低廉的，如果一个现成的货色都帮咱们做了，咱们还去开发干嘛？再者，我置信大部分公司还是没专门的 DBA 的，然而车轮子在了，咱们开发也能去做迁徙这样的事件了，不是嘛？咱们传统技术迁库耗时耗力不说了，失败率是真的高，还有数据比照等等，很头疼，我之前东家数据库迁徙都是中午，搞一早晨，天黑都不肯定搞好了，要是没好，用户上线了，还的暂停。
不过即便是应用了工具，一个数据库残缺的迁徙流程却还是应该很谨严的，大家可能会纳闷再谨严能有多谨严？给你看个图你就晓得了：
华为云的 DRS 的在线迁徙怎么做的呢？
能够看到，迁徙图中是应用到了 VPN，这个的作用次要就是保住一个高速稳固的传输，以及传输数据的加密，万一你同步的过程被其余对手公司抓到，那？在文章前面，你能够看到华为云 DRS 是怎么做的网络安全，我做了一次残缺的迁徙实战，并且做了总结。
迁徙实战
他迁徙很简略，都有教程，我用过一遍，大抵步骤如下：
迁徙作为一个非凡期间，业务配合、人为配合是最要害的，局部操作肯定要躲避，比如说常见的：
- 不能将源数据库日志强制清理掉
- 不能将用于连贯源数据库的用户明码批改掉、或者删除掉
- 不能将表长时间锁定，导致内部都无奈查问该表
他在迁徙之前能够做一个迁徙预查看，从官网文档来看，都是对过往迁徙案例总结进去的查看步骤，能够让迁徙胜利有更好的保障，这点挺好能够在迁徙前夕找出问题所在，我也失败过，是因为环境问题，都给了很明确的批示。
大家不晓得思考过没，就是数据迁徙了，然而如果数据库的设置没迁徙那也是很麻烦的，如果一个迁徙工具可能做到把 DBA 设置的好的 User 权限迁徙了，以及咱们设置的各种触发器，数据库字符集设置都迁徙了，那才是我现实的一个迁徙工具，是的华为云 DRS 做了，这就是比拟优良的点了，真的省了很多功夫。
特地是对于数据库各种设置并没那么理解的开发来说，这性能的确是很福利了，而且还有性能参数，相似各种 buffer 大小，cache 大小等等他都能迁徙，甚至能够做到流控，还能够随时扭转流控就更优良了：
迁徙模式多样化，这是我筹备开始迁徙的第一感触，我下面提到过，如果不能增量迁徙将毫无意义，DRS 还是想到了，这让我感觉如同有点暖，说着说着我的眼角又潮湿了 …
因为大部分的场景咱们都是线上业务的不停服迁徙，在迁徙过程中，还是一直的有增量数据在涌入的，敖丙之前所经验过的数据库迁徙基本上也都是全量 + 增量的迁徙模式，全量的场景只存在外部零碎，或者离线数据等。
其实这里的技术外围就在于怎么去保障增量的数据也能保障不失落正确的迁徙，我猜是通过 binlog 同步的，我看了下他的文档，日志，果然被我猜对了。
DRS 是通过全量迁徙过程实现历史数据迁徙至指标数据库后，增量迁徙阶段通过捕抓日志，利用日志等技术，将源端和指标端数据库保持数据统一，这里的保持一致前面也会提到，他提供了残缺的数据比照性能。
迁徙过程很简略，进度齐全能够看到，数据的提早也能够很直观的看到：
迁徙完结之后，DRS 提供了数据比照，其实数据比照以前我做迁徙的时候，咱们都是通过比照数据库行数去做的，因为没这样的迁徙工具，我发现了很暖心的一点就是内容比照，这一点让我很惊喜，因为行数的比照还是不够谨严，批改的日志如果缺失行数的比照也是没用的。
img
img
期待比照实现，点击“查看比照报表”，能够理解比照详情，详情页面如图所示：
下面提到的网络安全问题，我也在 DRS 找到了答案，他们会应用特定的加密协议进行数据传输，还能够用特定的 VPN 挂载网络传输：
DRS 还做了迁徙监控，能够看到实时进度，让整个迁徙进度比拟可视化，两头的异样也高深莫测，说实话工具真的就是香，以前想都不敢想，咱们熬夜就惟恐一个环节出错，而且常常还是后知后觉的，可视化的流程会你对迁徙有一种掌控感。
迁徙实现：
从我开始迁徙到完结，整个流程其实不到 2 小时，这个放在以前是不敢想的，这波体验我是很称心的，让我一个开发就做到了以前 DBA 能力做的事件，说着说了旁边的 DBA 的眼角也潮湿了 ….
小结
整个体验我感觉是很不错的，我总结几个我感觉 DRS 独特的设计和应用场景：
- 迁徙限速，依据限定时间段设置迁徙速度下限
利用场景:
- 有些流量型 app，比方游戏厂商等客户，迁徙时源数据库的公网、VPN 不能打满（打满将影响其对外业务，或者影响共用 VPN 带宽）
- 有些业务负载较重，或着客户无奈承受 业务工夫应用程序因为迁徙带来额定负载
- 用户迁徙(权限、明码、definer)，残缺继承源权限体系
利用场景:
- 市面上的迁徙产品均不反对用户的迁徙，也就是说如果用户没有留神，或者不懂用户迁徙，那么迁徙后业务必然报错，DRS 提供了全套的用户权限继承设计，能够将权限、明码、definer 保留迁徙至指标数据库，确保迁徙后权限平安、业务稳固，能够让不相熟数据库的客户迁徙时，依然能够实现一场精密的、高质量的数据库迁徙。
- 参数比照，迁徙后业务稳固
利用场景:
- 市面上的迁徙产品均不反对参数的迁徙，而数据库参数不一样，这将间接导致业务程序 运行报错(举个简略例子 session 数迁徙后变小了)，DRS 选定了业务和性能强相干要害的参数，防止了这些参数后续因为没有继承源环境设置，而导致业务报错或性能降落，能够让不相熟数据库的客户迁徙时，依然能够实现一场精密的、高质量的数据库迁徙。
- 数据校对平台，割接好帮手
利用场景:
- 市面上的迁徙产品均不反对数据的比照，校对工作留给用户测，DRS 提供了丰盛的比照性能:
- 对象比照
- 数据级比照
- 比照可定时，可勾销
利用比照定时工作，能够抉择凌晨等业务低峰期 进行数据一致性比照，第二天能够查看数据比照后果，对于迁徙状况做到齐全把握。能够让不相熟数据库的客户迁徙时，依然能够实现一场精密的、高质量的数据库迁徙。
- 触发器、事件的迁徙
利用场景:
- 市面上的迁徙产品均不反对触发器、事件的迁徙，精通迁徙的用户关注这些细节，因 为触发器和事件也是数据库的一部分，触发器和事件存在要害的业务逻辑，这些对象 不反对迁徙，业务必然报错，甚至造成不可挽回的损失。
- 能够让不相熟数据库的客户迁徙时，依然能够实现一场精密的、高质量的数据库迁徙。
注：【局部图片起源网络 侵删】
总结
其实给大家介绍这样 DRS 的一个背景和技术，次要是心愿跟大家跟我一起做一次残缺数据迁徙，一起去探讨技术背地的场景，以及场景背地咱们应该有技术思考。
不过这次体验真的，让我不得不感叹技术的便捷性，以前数据库迁徙都是团队开发以及测试一个团队熬夜守着数据库迁徙，最初验证测试能力走的，所有人拖着疲乏的身躯看着升起的太阳，眼角都湿了 …
当初我本人看看教程动动手指就实现了一场大规模的数据库迁徙演练，在享受技术给我带来不便的同时，也让我对技术背地的具体实现和人生的意义陷入了深深的思考。
或者这就是技术的价值吧，或者这就是这么多工程师日日夜夜辛苦的意义吧，或者 …
我是敖丙，你晓得的越多，你不晓得的越多，咱们下期见！