公司数据库

未来几年，全球数据量将呈指数级增长。据IDC统计，到2020年，全球数据总量将达到44ZB，中国数据量将达到8060EB，占全球数据总量的18%。数据，已然对当下的商务、生活乃至方方面面都产生了深远的影响。可众所周知，各行各业数据生产的速度要远远大于数据消化的速度。数据分析处理的不及时，必然造成大量具有时效性数据的浪费，日积月累，这样的不匹配性会越来越严重。

如何消除这样的不匹配性？归根结底，我们需要一种能够对更大规模数据做到更实时更迅捷的分析工具。

顺势而生的GPU数据库

2015年，已经在甲骨文公司工作了6年的星爵意识到，传统的数据库系统需要革新了。传统CPU数据库的发展主要面临两大瓶颈，一是数据计算速度，二是数据访问速度。而负责算力的CPU，目前停留在数十核的规模，这已经接近它的物理极限了。数据库计算领域，是时候该添加新鲜血液了。

2013年，深度学习技术的崛起让人们看到了GPU的力量。在这之前，GPU的主要功能是图片渲染，通过模拟现实场景生成接近于真实景象的图片，主要被应用于游戏领域。而深度学习技术，使GPU“大规模并行计算”的能力得以展现，人们对它的认知终于不再是游戏机，GPU，也可以成为像CPU一样的服务器。而星爵，更是坚定的认为，GPU处理大数据已经成为一种趋势。各种深度学习的软件框架例如TensorFlow，需要运行在计算设备上，与CPU相比，GPU更能让其高效的工作，在性价比以及计算力上都有较大的优势。

没有犹豫，星爵离开甲骨文，回国创立了Zilliz，他要做人工智能时代的数据库系统。

星爵认为，在过去数十年间，人工智能因为CPU架构下计算能力的限制而裹足不前，OLAP数据库技术也因为同样的原因而发展缓慢。就像华岩资本合伙人黄志玮所认为的，我们需要一个基于众核处理器硬件加速的、面向人工智能的新一代OLAIP（On-Line Analytical and Intellegent Processing）数据库系统，而这正是Zilliz在研发的产品。

Zilliz使用众核处理器上的成千上万个处理核心进行超大规模并行数据处理，实现数据库操作的加速，同时提供数据库系统和人工智能计算框架之间的直接数据通道。Zilliz将人工智能处理引擎融合进数据库执行引擎，提供集数据存储、分析、管理、和人工智能处理与一身的OLAIP数据库系统。

星爵向亿欧介绍，Zilliz基于GPU的数据库系统可以比CPU数据库的性能提高100倍，可大范围的应用于金融、电信、互联网以及政府领域。

在商业模式上，Zilliz为各行业的头部客户和互联网公司提供了不同的方案。对于头部客户，Zilliz即可以为其提供私有部署，同时还有基于一体机的解决方案；对于互联网公司，尤其是那些将数据部署在云端的客户，Zilliz可以为其提供SaaS的方案，使用各大云厂商提供的GPU，在云端为客户提供服务，从而使客户无需采购GPU硬件设备便可以使用。

新技术的新“麻烦”

大多数人有这样一个疑问——

即便GPU数据库的使用性能和性价比，与原有系统相比更有优势，但是要让用户将存储在CPU服务器上的数据快速迁移到GPU服务器中，可行性有多大？

这关乎到Zilliz的未来，也是星爵自公司创立之初就在解决的问题。星爵表示，Zilliz并不是要替代原有的CPU方案，而是要在大规模数据的实时性分析方面开创一个新的蓝海市场。

人工智能时代下，数据量将会呈指数型增长。在这样的情况下，各行各业的业务想要得到更好的发展，实时数据分析能力以及实时数据驱动运营能力将是其核心的竞争力，因此，Zilliz产品的存在是有其合理性的。

Zilliz投资人云启资本执行董事陈昱表示，在大数据时代，企业需要一个更大、更快、更强的数据库，人工智能技术的加入，是一种对传统数据库的革新，使数据库产生了更高的效率，这无疑是当下各公司最迫切的需求。

另外，星爵希望将数据库软件做成一个标准件。作为一个底层的数据库软件，需要对外提供标准化的查询语言接口，理想状态应当是用户在接入新数据库的时候，其业务层面不发生改变。因此Zilliz通过产品化与标准化，为用户提供标准SQL接口以及各种ETL工具，从而降低用户在数据迁移过程中的成本，尽量做到“无感迁移”。对于用户来说，相当于更换了一个数据库的软件和引擎，但是其业务层并不会受到影响。

星爵还向亿欧透露，为了更加快速的在CPU处理器与GPU处理器之间进行数据交换，Zilliz与IBM合作生产了数据库一体机，使用NvLink技术，能够大大提升不同类型处理器芯片之间的数据传输速度。

资本认可，行业进入爆发期

目前世界范围内做OLAP GPU数据库加速的公司仅有4家：

星爵介绍，在这一领域，国外从2006年就已经开始有所研究，然而，当时的市场认知度不足，用户对于GPU还停留在游戏处理器的认知上，且高端GPU的市场存量较少，并没有基于GPU部署数据库系统的实力。另一方面，整个生态系统还处于早期的发展状态，各种相关工具及配套软件比较缺乏。基于以上两点原因，国外公司在这一方面并没有太多优势。

到2016年，市场认知才有所好转。从业人员开始意识到GPU也可以做与企业相关的工程（例如深度学习），同时，GPU服务器已经成为常态，各种GPU的生态体系也逐渐完善，种种原因使得2016年成为GPU数据库的元年，至此，资本市场逐渐认可这一领域，GPU数据库进入爆发期。

然而爆发并不意味着竞争，靖亚资本创始人郑靖伟向亿欧介绍，数据库这样底层技术的门槛很高，国内少有人研究。产品的研发与验证都需要一定时间，而对于一般的大型中型公司来说，更换数据库系统需要进行很多的测试来评估流程，一旦被验证，很难再次更换数据库系统提供商。

而2018年，将是GPU数据库在各行各业应用更为广泛的一年。

人生大起大落落落落落落，实在是太刺激了，下面这真是一个悲伤的故事。

那年公司 ERP 系统刚进行升级。

因为公司陆续上了 MES 和 PDM 系统。为了加快整个公司信息化平台的统一，请了个第三方公司来做中间接口。

然后故事开始了。

某一个晚上，第三方人员问我要 ERP 的 SA 密码。

我很警惕：“你要干嘛?”

“我测试一下中间表。”

“有没有写表的操作?”

“没有，只有读表的操作。”

于是我放心的给了 SA 密码。给了 VPN 权限通道。放她进来了。

十分钟后…..

她带着哭腔打电话来(是的，对方做测试的是个 93 年的萌妹子。)

“吴哥哥， 服务器中毒了 。。。。”

我当时还在逛果壳呢，一听她说我服务器中毒了，我表示无比淡定。还以大哥的经验教训了一顿她。

“叫你不要往我服务器传插件嘛，这次帮你解决一下，下次不准了哟。”

我认为是小 case 呢，不就中毒了嘛，系统往回滚一天就好了。

然后悲剧的事情就出现了，远程进不去，于是我就去机房本地登录，居然也进不去。

我不死心，强制重启，居然还是进不去。我的服务器系统就这样崩了。。。

好在那几天在做开发，系统没有启用，于是我和我的老板汇报了这个情况：

“老大，我们服务器系统崩了。”

“哦，那就搞好它让它别崩。” 果然是霸道总裁啊。

当时数据和应用服务器我都是分开跑的，所以应用服务器奔溃了，我觉得也没多大事，就重新做系统吧。于是我重新做了个系统，然后喊萌妹子上来搭平台。

“小刘啊，你可害惨我了，一个下午给你重做服务器系统了，我基础环境都配置好了，你上来搭平台吧。”

萌妹子那是无比的歉意啊，又是答应请我吃饭又是答应请我看电影的。我都想系统再崩溃一次了。

按理说这样应该是没问题了，就在我走出机房，在外面抽了根烟，45 度仰望了一下天空，联想了一下和萌妹子点个 9 分熟的牛排，在喝一口二锅头这样浪漫的晚餐的时候。电话来了。

来电话的是萌妹子的老板。

“小吴，我想找一下 information.db 和 mfmedia.db 这两个总表没找到，你给我找一下。”

我都蒙了，从来没人问过我这样的问题，难道她老板不是IT行业的。

“ 数据库文件都在目录树里啊 ，自己去找啊。”

“没有。”

于是我登上服务器一看，我傻了。 所有的表都空了，所有的表都静静的躺在那，但是里面都空了。。。

不可能啊，我数据库是放在另外一台服务器上的，怎么可能会没有了。

于是我问萌妹子：“XXX，你到底做了什么操作啊，为毛我数据库都没了。”

萌妹子说：“我啥也没干啊，只是按照步骤一路点 YES。”

我才想起来， 在第一次配置基础环境的时候，建账套会提示是否初始环境，如果点是了，数据库就会被初始化 ，然后这位萌妹子傻傻的点了是。

“你知道不知道你干了什么， 公司 06 年到现在所有的数据，财务的，供应链的，进销存的全部都在这台服务器里，200 多个 G 数据，因为你一个是，全没了 。”

萌妹子也吓蒙了，话都说不出来了。

没办法，我再给我老板打电话。

“老板，有个好消息，有个坏消息。”

“直接说坏的。” 我就喜欢我们老板这么直接。

“恩。。恩。。那个。。就是那个。ERP 的数据没了。”

“哦，那就找回来。” 老板还是那么的霸气。我特么都要爱上他了。

“老板，我想你没明白这个的严重性。ERP 数据没了，从 06 年开始的都没了，这意味着就算找回来，整理所有的表，排错也需要 3 天左右时间，到时候所有的生产都要暂时停止。如果找不回来，我们可能就要倒闭了。”

我忽然有种掌握天下苍生的感觉。。。

对面沉默了 5 秒后，爆吼了一句：“吴 XX，你给我滚到我办公室来!!”

中间和老板手握手谈心，被老板亲切慰问的细节跳过不表。

当时公司高层对数据安全还没有那么重视，之前预算做的项目，我已经做了备份的计划书，一直没被审批下来，现在估计悔得肠子都清了。

于是我开始漫长的 数据恢复之旅 。

我之前已经做了个本地备份的计划，每天晚上会备份一次。我把希望都放在了它身上。等我把备份的数据库附件上去，发现时间居然都是两个星期之前的。

而且还有一些新表都没有，我联系对方，对方告知研发人员两个星期前做测试的时候把备份计划关了。。。

我心里万头草泥马奔腾而过。

最后没有办法，把老服务器又翻了出来，翻出之前的老数据，开始转换。

期间老板给我短信：“数据恢复进行的怎么样了呢。”

“报告，正在稳步进行中，按照目前的状况，可恢复的可能性超过 90%。” 别问我 90% 怎么算出来的，我就是哄他才这样说的。

“唉，真是心急呀，睡都睡不着。小吴呀，当初要是听你的，上了备份该多好呀。” 现在知道后悔了，哼哼。

“老大别担心，我会搞定的。” 是的，作为一位负责的员工，我就是这么让老大心安。

“恩，那就交给你了哦，熬夜少抽点烟哦。” 哎呀，瞬间觉得我老大萌萌哒有没有。

这里花了我一个晚上加一个白天。

数据转换好了，还有一些时间差的数据没法找到。于是通知各个部门，找单据，开始往里面补单子，一条一条的按照业务流程补进去。

为了协同更方便，在会议室加设了几十台电脑集体办公。。。

在大家一片怨声载道中，三天时间，终于把数据恢复了过来。三天内我没离开机房超过 10 米，吃喝拉撒都在机房，不对，拉撒不在。

这件事情造成的后果：

1. 大部分员工放假三天，我加班三天三夜。

2. 本来很爱我的大部分员工因为单据事件，集体转为黑我恨我了。

3. 公司立马批了我的计划，冷备，热备，异地容灾，全部上全了。

4.我挥刀自宫，自己罚了自己，扣除了自己一个月工资。

5.老板到现在还是在怀疑请的那家公司已经被我们竞争对手收买，是故意来破坏我们的。

6.萌妹子拉黑了我。

这真是个悲伤的故事。

看完了这个悲伤的故事，我们要回归理性， MySQL 数据库误删除后怎么办?

在日常运维工作中，对于数据库的备份是至关重要的!数据库对于网站的重要性使得我们对 MySQL 数据库的管理不容有失!

然而是人总难免会犯错误，说不定哪天大脑短路了，误操作把数据库给删除了，怎么办?

下面，就 MySQL 数据库误删除后的恢复方案进行说明。

工作场景

MySQL 数据库每晚 12:00 自动完全备份。

某天早上上班，9 点的时候，一同事犯晕 drop 了一个数据库!

需要 紧急恢复 可 利用备份的数据文件以及增量的 binlog 文件进行数据恢复 。

数据恢复思路

利用全备的 SQL 文件中记录的 CHANGE MASTER 语句 ，binlog 文件及其位置点信息，找出 binlog 文件中增量的那部分。

用 MySQLbinlog 命令将上述的 binlog 文件导出为 SQL 文件，并剔除其中的 drop 语句。

通过全备文件和增量 binlog 文件的导出 SQL 文件，就可以恢复到完整的数据。

实例说明

首先，要 确保 MySQL 开启了 binlog 日志功能。 在 /etc/myf 文件里的 [mysqld] 区块添加，如下图，然后重启 MySQL 服务。

1.在 ops 库下创建一张表 customers

2.现在进行全备份

参数说明：

-B：指定数据库

-F：刷新日志

-R：备份存储过程等

-x：锁表

Cmaster-data：在备份语句里添加 CHANGE MASTER 语句以及 binlog 文件及位置点信息

3.再次插入数据

4.此时误操作，删除了 test 数据库

此时，全备之后到误操作时刻之间，用户写入的数据在 binlog 中，需要恢复出来!

5.查看全备之后新增的 binlog 文件

这是全备时刻的 binlog 文件位置，即 mysql-bin.000002 的 106 行，因此 在该文件之前的 binlog 文件中的数据都已经包含在这个全备的 SQL 文件中了。

6.移动 binlog 文件，并导出为 SQL 文件

剔除其中的 drop 语句，查看 MySQL 的数据存放目录，由下面可知是在 /var/lib/mysql 下，将 binlog 文件导出 SQL 文件，并 vim 编辑它删除其中的 drop 语句。

注意：在 恢复全备数据之前必须将该 binlog 文件移出，否则恢复过程中，会继续写入语句到 binlog，最终导致增量恢复数据部分变得比较混乱。

7.恢复数据

查看数据库，看看 ops 库在不在。

此时恢复了全备时刻的数据。接着，使用 002bin.sql 文件恢复全备时刻到删除数据库之间，新增的数据。

再次查看数据库，发现全备份到删除数据库之间的那部分数据也 恢复 了!!

以上就是 MySQL 数据库增量数据恢复的实例过程!

最后，总结几点：

本案例适用于人为 SQL 语句造成的误操作或者没有主从复制等的热备情况宕机时的修复。

恢复条件为 MySQL 要开启 binlog 日志功能，并且要全备和增量的所有数据。

恢复时建议对外停止更新，即禁止更新数据库。

先恢复全量，然后把全备时刻点以后的增量日志，按顺序恢复成 SQL 文件，然后把文件中有问题的 SQL 语句删除(也可通过时间和位置点)，再恢复到数据库。

来源：51CTO

计 算 机 世 界

C HINA C OMPUTER W ORLD

关 于 IT 产 业 和 产 业 IT 的 一 切