我们如何意外地向自己的数据库宣战

一切都始于一个简单的任务：“嘿，我们来检查一下两个数据库在一段时间内是否有相同的数据！”听起来没什么问题，对吧？哦，我们当时是多么年轻和愚蠢啊。

我们团队做了一些研究（也就是谷歌搜索），找到了一个潜在的解决方案。就在这时，我们的资深队友，也就是所谓的 MongoDB 专家，挺身而出。我们这么称呼他，是因为他比我们其他人经验略丰富一些。

无论如何，他发现命令是一段神奇的代码，可以为集合生成哈希值

db.runCommand({ dbHash: 1, collections: [] }).md5  

他激动极了！兴奋极了！简直在椅子上蹦蹦跳跳！他的终极计划是什么？对两个数据库的每个集合运行这条命令，比较哈希值，如果不匹配，轰！检测到数据不一致！

首先，他在一个小型数据库上测试了它。它成功了。漂亮。完美。没有任何问题。于是，他自然而然地做了任何过度自信的工程师都会做的事情：

“让我们在拥有 2 亿条记录的实时数据库上尝试一下！”

我的朋友们，此刻一切都变得非常糟糕。

末日时刻

动图

起初，一切似乎都很好。他运行了命令。他等待。等待。等待。

然后他不耐烦了，心想：“嗯，也许我应该停止这个命令？”于是他尝试终止它。

情节转折：指挥部拒绝死亡。

几秒钟后，我们所有的数据库连接数飙升至 2900%。所有查询都停止了工作。应用程序崩溃了。用户可能正对着屏幕尖叫。

就在这时，混乱突然爆发。警报（在我们脑海里）响起。人们大喊大叫。我们的团队像好莱坞烂片里的黑客一样，疯狂地用谷歌搜索信息。

但无论我们怎么尝试，都无济于事。为了减少 MongoDB 的连接数，我们停止了一些不重要的服务，并尝试将连接数保持在尽可能低的水平。

我们一个看似无害的命令却彻底瘫痪了整个数据库。这就像往河里扔了一块小石头，却不知怎么地引发了海啸。

令人震惊的真相

最后，我们的MongoDB 专家（此时，他已经因为压力而老了 10 岁）决定阅读官方文档。在那里，像恶棍的阴谋一样隐藏着这样一句话：

The dbHash command locks the database and doesn’t allow any changes until it finishes.  

翻译：“哈哈，在我完成之前你们什么也做不了。祝你们好运，失败者们！”

此时，我们有两个选择：

1. 坐在那里希望奇迹发生。
2. 找到一种方法来强制唤醒我们可怜的、冻结的数据库。

幸运的是，我们的 DevOps 队友想到了一个主意。“我们来扩展数据库吧。这样就能强制重启，并终止卡住的命令！”

动图

我们用力地点点头，看着他登录 MongoDB Atlas，像打开坏炉子上的暖气一样增大数据库大小，然后按下神奇的按钮。

复活

接下来的五分钟，我们静静地坐在那里，看着屏幕，向数据库之神祈祷。

然后砰！数据库重启了！卡住的命令消失了！应用程序又恢复正常了！

我们欢呼雀跃，我们泪流满面。我们发誓，永远、永远、永远不再在实时数据库上运行随机命令。

经验教训：

尝试新事物前务必阅读说明书。除非你喜欢心脏病发作，否则最好不要在真实系统上测试实验想法。

最后，如果文章对你有帮助，请点赞👏并关注，谢谢！