MongoDB

事故背景​ 线上环境有一个MongoDB副本集，由于是部署在客户那边本地机房，客户误操作把部署副本集的另外2个节点的 VM 给删除了（并且VM已经无法恢复了）。所幸的是还有一个节点存活，登录节点后发现这个节点是 SECONDARY，所以可能会有一部分数据丢失，而且此时已经无法对应用提供读写服务。此时只能停服维护，并对集群进行恢复。 ​ 基于以上问题，下面对副本集恢复操作步鄹进行了记录。 处理思路 对mongodb数据进行备份（防止恢复集群时出现意外导致数据丢失）。 把仅存的 SECONDARY 节点提升为 PRIMARY，删除集群中另外2个不存活的节点，然后重新配置MongoDB副本集。 新部署2个MongoDB节点，并加入到集群中。 等待 PRIMARY 节点数据同步到另外2个新节点后，进行数据验证，结束生产环境维护。 注意： 由于原先的集群中只存有 SECONDARY 节点，PRIMARY 节点已经丢失，所以存在部署数据没同步到 SECONDARY 的可能。但由于PRIMARY节点的VM已经被删，这部分未同步的数据的丢失在所难免，想恢复这部分数据只能 ...

项目背景由于历史原因，我们有一个作数据同步的业务，生产环境中MongoDB使用的是单节点。但随着业务增长，考虑到这个同步业务的重要性，避免由于单节点故障造成业务停止，所以需要升级为副本集保证高可用。 副本集架构下面这架构图是这篇文章需要实现的MongoDB副本集高可用架构： 升级架构前注意事项在生产环境中，做单节点升级到集群前，一定要先备份好mongodb的所有数据，避免操作失误导致数据丢失。 并且在保证在升级期间不会有程序连接到MongoDB进行读写操作，建议停服务升级，且在凌晨业务低峰期，进行操作。 一、原单节点MongoDB配置信息IP: 192.168.30.207Port: 27017 1.1 原配置文件systemLog: destination: file logAppend: true path: /home/server/mongodb/logs/mongodb.logstorage: journal: enabled: true dbPath: /home/server/mongodb/data directoryPerDB: tru ...