记一次Mongodb中admin数据库导致的事故

一次Mongodb事故：admin数据库出现问题，引发事故。

《一次惊心动魄的MongoDB admin数据库事故：教训与反思》

技术内容：

事故背景

近日，我在负责维护的一个MongoDB集群中，发生了一起由于admin数据库操作不当导致的事故，事故发生时，整个集群的可用性受到了严重影响，部分业务数据甚至出现了短暂丢失，经过紧急处理，最终成功恢复了业务，但此次事故给我留下了深刻的教训，以下是事故的详细经过。

事故经过

1、事故起因

在一个周五的下午，我接到一个需求，需要对MongoDB集群进行扩容操作，由于之前已经有过多次扩容经验，我对此项操作信心满满，在准备好相关资源后，我开始了扩容操作。

2、执行操作

我登录到MongoDB的admin数据库，准备执行添加节点的操作，由于之前一直使用的是MongoDB 3.4版本，而此次集群已经升级到了4.0版本，我对部分操作命令并不熟悉。

在添加节点时，我错误地使用了以下命令：

db.runCommand({addshard:"shardName/host:port"})

实际上，在MongoDB 4.0版本中，应该使用以下命令：

sh.addShard("shardName/host:port")

3、事故发生

在执行了错误的命令后，我并未立即发现异常，在几分钟后，业务方反馈数据库连接出现异常，部分业务数据无法访问。

4、问题排查

接到业务反馈后，我立即开始排查问题，通过查看MongoDB日志，发现以下错误信息：

Error: couldn't add shard since the specified host is already a member of the config server replica set

经分析，错误原因是我在执行addshard命令时，使用了已经存在于config server副本集的节点，这使得config server副本集的成员发生变更，从而导致整个集群出现异常。

5、事故处理

（1）立即停止错误的添加节点操作，避免事态进一步恶化。

（2）与业务方沟通，暂时切换到其他数据源，降低业务影响。

（3）联系MongoDB官方技术支持，寻求解决方案。

（4）根据官方建议，重新配置config server副本集，恢复集群。

（5）在确保集群稳定后，逐步将业务切换回MongoDB。

事故反思

1、事故原因

（1）对MongoDB版本升级后的操作不熟悉，导致执行了错误的命令。

（2）在执行重要操作前，未进行充分的测试。

（3）监控不到位，未能在第一时间发现异常。

2、教训与改进措施

（1）加强对MongoDB的学习，特别是版本升级后的新特性。

（2）在执行重要操作前，务必进行充分测试，避免因操作失误导致事故。

（3）完善监控体系，提高异常发现能力。

（4）建立应急预案，提高应对突发事故的能力。

此次MongoDB admin数据库事故，让我深刻认识到了自己在操作和监控方面的不足，通过反思和总结，我将不断提高自己的技能，确保类似事故不再发生，也希望我的经验教训能对其他MongoDB使用者有所启示，共同守护数据安全。