不以规矩不成方圆：Digital Ocean也删除了他们的数据库

上周（2017-04-05），位于纽约的云服务商 Digital Ocean 遭遇了一次长达4小时56分钟的停机事故，事故的原因竟然是：主数据库被删除了（primary database had been deleted）。

我曾经开过一个玩笑说：没有删除过数据库的DBA，职业生涯是不完整的。现在看起来，又有人因此而完整了。

对于我们来说，需要本着科学的态度，学习并且引以为警示，做到防患于未然。

Digital Ocean 公布了整个故障的根本原因（Root Cause）：

The root cause of this incident was a engineer-driven configuration error. A process performing automated testing was misconfigured using production credentials.

故障的根本原因在于工程师的配置错误，一个自动执行的测试流程使用了错误提供的生产环境认证配置。

这个根本原因翻译过来就是：由于配置错误，本应指向测试环境的任务被指向了生产环境，测试任务包含的环境初始化过程删除了主生产数据库。

幸运的是，Digital Ocean 公司实现了 DBA 守则的第一条：有效的备份重于一切。

他们在发现故障后三分钟发现了数据库被删除，随后在7分钟内启动恢复任务，时间线非常清晰：

T0.03 - 10:27 EDT - Verified that production database had been deleted on master

T3.07 - 13:31 EDT - Recovery of master completed; copy of backups to replicas ongoing

我在前一段总结了 数据库安全的16条军规，其中的几条正是基于类似的惨痛教训总结而来的，我筛选几条和大家分享：

备份重于一切

我曾经在总结的DBA四大守则的第一条就指出，『备份重于一切』，有了有效的备份，即使遭遇灾难，也可以从容应对，对于重要的生产环境，适当建立备库进行数据保护，查询分担，也会减少生产库的风险；

唯一会让DBA们从梦中惊醒的就是:没有备份! 所以对于数据库运维来说，第一重要的是做好备份!有备方能无患!

限制登录工具

明确限制不同工具的使用场景，明确规定工具的准确来源，或者通过堡垒机等来限制数据库访问。对于工具也可以做出明确规则和限制，如限制仅能通过SQL Developer访问生产，PL/SQL Developer工具仅能访问测试环境，以减少安全风险甚至误操作风险；

测试和生产隔离

互通就意味着同时可以访问，也就可能带来很多意想不到的安全风险，企业应当将测试环境和生产环境部署于不可互通，或者不可同时访问的网络环境中，避免因为错误连接而发生的数据库灾难。 分离部署一方面可以降低误操作的可能性，也可以屏蔽一些无关的访问可能，从而从网络链路上保证数据安全；

密码差异设置

有些测试环境或者非产品环境是利用产品环境恢复得到的，DBA在建立了测试环境后，就没有修改数据库用户的登录密码;经常性的，DBA也习惯在所有环境中设置通用的密码;这些习惯为系统带来了很多风险和不确定性。 我们建议用户在不同环境中采用不同的密码设置，这是因为一方面产品环境和测试环境面对的访问用户不同，密码设置相同则意味着产品环境的安全性完全得不到保障;另一方面，DBA登录到不同的数据库需要使用不同的密码，这进一步减低了DBA在错误的环境下执行命令的可能性。

这样的例子已经屡见不鲜了，近期的就有：

五重备份无一有效，还有哪些 rm -rf 和GitLab类似的忧伤？

如何检查和发现数据库的隐含风险呢？你可以通过云和恩墨的免费智能巡检平台 - Bethune 来进行全面诊断和检查。

Bethune （ https://bethune.enmotech.com ）为你的数据库发现潜在问题，早日消除安全隐患！

祝愿大家的 DBA 生涯都能够平安圆满！

文章转自数据和云公众号，原文链接

openGauss/GaussDB200 《FusionInsight LibrA: Huawei’s Enterprise Cloud Data Analytics Platform》 Huawei FusionInsight LibrA (FI-MPPDB)是OLAP系统，从《openGauss数据库核心技术》这本书上的描述看LibrA就是GaussDB200，从openGauss的代码上看，openGauss的OLAP特性也是来自这个产品。