#### **描述:**
### 根据技术反馈,上午有人误操作删除了线上mongodb表数据,用户已反馈到客服,现在需要给用户恢复数据。
#### 首先要确定被删除数据的数据库架构是什么模式
**1.1、单点:**
是否有备份,有备份情况下,启动一个实例将,将备份数据导入到新实例
查找新实例是否有被删除掉的数据,使用mongodump导出数据,再导入到源被删除数据实例,恢复数据。
详细见本章下边内容:2.2备份和 2.5恢复
单节点mongodb没有oplog的概念,如果没有备份,数据就会出现丢失,正式环境尽量使用复制集架构。
**1.2、复制集:**
1.2.1、可以采用延迟节点形式,一PRIMARY节点,两SECONDARY其中一个做延迟节点,
比如我们延迟节点延迟8小时,我们删除数据要在8小时内发现,并恢复(保证oplog不被覆盖情况下)
1.2.2、全量+增量:根据数据量和重要性,选择天全量备份+小时增量oplog备份,或者周全量备份+天增量oplog备份。
![](images/screenshot_1584070305356.png)
**1.3、分片集群**
分片集群也是由多个复制集组成,备份方式可以按照复制集备份策略
### 2、**复制集架构模拟误删除:**
我们采用全量备份+oplog增量备份方式
**2.1、我们插入1000条数据:for (var i=0;i<1000;i++){ db.user.save({"userid":i}) }**
```
[root@10-1-1-159 ~]# /data/mongodb3.6.9/bin/mongo 10.1.1.159:27020
rs02:PRIMARY> use jia_test
switched to db jia_test
rs02:PRIMARY> for (var i=0;i<1000;i++){ db.user.save({"userid":i}) }
rs02:PRIMARY> db.user.count()
1000
rs02:PRIMARY> db.user.find()
{ "_id" : ObjectId("5e69f820ce1bb2285a21a343"), "userid" : 0 }
{ "_id" : ObjectId("5e69f820ce1bb2285a21a344"), "userid" : 1 }
{ "_id" : ObjectId("5e69f820ce1bb2285a21a345"), "userid" : 2 }
{ "_id" : ObjectId("5e69f820ce1bb2285a21a346"), "userid" : 3 }
```
**2.2、我们做个全量备份:**
```
[root@10-1-1-159 ~]# /data/mongodb3.6.9/bin/mongodump -h 10.1.1.159:27020 -d jia_test -o /root/
2020-03-12T16:52:37.418+0800 writing jia_test.user to
2020-03-12T16:52:37.421+0800 done dumping jia_test.user (1000 documents)
```
**2.3、第一种情况:**
如果我们在备份后的几个小时进行删除操作,只要把数据导入到新的实例就能找回数据,这样太简单了。
前提是我们有备份才能恢复。
**2.4、我们继续第二种情况**
我们继续插入数据:
```
[root@10-1-1-159 ~]# /data/mongodb3.6.9/bin/mongo 10.1.1.159:27020
rs02:PRIMARY> use jia_test
rs02:PRIMARY> db.user.insert({"userid" :1000})
WriteResult({ "nInserted" : 1 })
rs02:PRIMARY> db.user.insert({"userid" :1001})
WriteResult({ "nInserted" : 1 })
rs02:PRIMARY> db.user.insert({"userid" :1002})
WriteResult({ "nInserted" : 1 })
rs02:PRIMARY> db.user.insert({"userid" :1003})
WriteResult({ "nInserted" : 1 })
rs02:PRIMARY> db.user.insert({"userid" :1004})
WriteResult({ "nInserted" : 1 })
rs02:PRIMARY> db.user.insert({"userid" :1005}) #1、我们又插入了三条数据
WriteResult({ "nInserted" : 1 })
rs02:PRIMARY> db.user.remove({"userid" :1003}) #2、我们删除了一条数据
WriteResult({ "nRemoved" : 1 })
rs02:PRIMARY> db.user.insert({"userid" :1006}) #3、我们又插入一条数据
WriteResult({ "nInserted" : 1 })
rs02:PRIMARY>
```
>## 我们来恢复"userid" :1003 的这条数据,我们需要恢复到删除前一刻,也就是恢复到执行db.user.remove({"userid" :1003})这个时间点之前。
**2.5、我们创建一个新的副本集实例,将全量备份导入**
```
[root@10-1-1-159 ~]# /data/mongodb3.6.9/bin/mongorestore -h 10.1.1.77:27010 -d jia_test /root/jia_test/
2020-03-12T17:03:27.054+0800 the --db and --collection args should only be used when restoring from a BSON file. Other uses are deprecated and will not exist in the future; use --nsInclude instead
2020-03-12T17:03:27.055+0800 building a list of collections to restore from /root/jia_test dir
2020-03-12T17:03:27.056+0800 reading metadata for jia_test.user from /root/jia_test/user.metadata.json
2020-03-12T17:03:27.074+0800 restoring jia_test.user from /root/jia_test/user.bson
2020-03-12T17:03:27.099+0800 no indexes to restore
2020-03-12T17:03:27.099+0800 finished restoring jia_test.user (1000 documents)
2020-03-12T17:03:27.099+0800 done
/data/mongodb3.6.9/bin/mongo 10.1.1.77:27010
rs02:PRIMARY> db.user.count()
1000
rs02:PRIMARY>
```
**2.6、导出oplog日志:**
```
### 首先我们查一下什么时间执行删除操作的、连上执行删除操作的数据实例
[root@10-1-1-159 ~]# /data/mongodb3.6.9/bin/mongo 10.1.1.159:27020
rs02:PRIMARY> use local
switched to db local
rs02:PRIMARY> db.oplog.rs.find({"op":"d","ns":"jia_test.user"}) #op是操作,d是删除,ns命名空间就是某个库的某个表,oplogs日志解释详见oplog介绍
{ "ts" : Timestamp(1584003536, 1), "t" : NumberLong(1), "h" : NumberLong("5476681688775461425"), "v" : 2, "op" : "d", "ns" : "jia_test.user", "ui" : UUID("2527737e-eeea-415b-95de-061b6615a23c"), "wall" : ISODate("2020-03-12T08:58:56.056Z"), "o" : { "_id" : ObjectId("5e69f9b02e42450b5489dd4f") } }
rs02:PRIMARY>
```
### 已知:我们全量备份时间:2020-03-12T16:52:37.421+0800 done dumping jia_test.user (1000 documents)
### 删除时间也知道了,我们需要把全量备份成功的时间,进行一下转换,我们拿到时间戳,
尽量在备份时间在提前十分钟,这样我们日志就不会出现缺失,导入重复会自动覆盖。
![](images/screenshot_1584004718333.png)
**我们拿到两个时间戳:**
>备份时间戳: 1584002557
>删除时间戳:"ts" : Timestamp(1584003536, 1)
### 导出删除数据实例的oplog日志(大于备份时间小于删除时间的这一段)
```
[root@10-1-1-159 ~]# /data/mongodb3.6.9/bin/mongodump -h 10.1.1.159:27020 -d local -c oplog.rs -q '{ts:{$gt:Timestamp(1584002557, 1),$lt: Timestamp(1584003536, 1)},"ns":{"$regex":"jia_test.user"}}' -o .
```
**2.7、oplog导入到新实例:**
```
[root@10-1-1-159 ~]# /data/mongodb3.6.9/bin/mongorestore -h 10.1.1.77:27010 –oplogReplay local/oplog.rs.bson
```
**2.8、连接新恢复实例查看:**
```
[root@10-1-1-77 ~]# /data/mongodb3.6.9/bin/mongo 10.1.1.77:27010
rs02:PRIMARY> use jia_test
switched to db jia_test
rs02:PRIMARY> db.user.count()
1006
rs02:PRIMARY> db.user.find({"userid":1003}) #查看1003数据存在
{ "_id" : ObjectId("5e69f9b02e42450b5489dd4f"), "userid" : 1003 }
rs02:PRIMARY> db.user.find({"userid":1006}) #查看1006数据不存在,因为这条数据是在删除之后插入的,我们恢复的时间点是删除之前的。
rs02:PRIMARY>
```
**2.9、老的实例查看:**
```
[root@10-1-1-159 ~]# /data/mongodb3.6.9/bin/mongo 10.1.1.159:27020
rs02:PRIMARY> use jia_test
switched to db jia_test
rs02:PRIMARY> db.user.count()
1006
rs02:PRIMARY> db.user.find({"userid" :1003}) #1003数据不存在
rs02:PRIMARY> db.user.find({"userid" :1006}) #1006数据存在,删除只要又写入的
{ "_id" : ObjectId("5e69f9d42e42450b5489dd52"), "userid" : 1006 }
rs02:PRIMARY>
```
**2.10 我们把新实例数据通过导出,导入到线上正式环境就可以了**
### 温馨提示:Mongodb正式业务,至少要使用复制集,不要单点,数据一定要有备份。
前段时间某公司删除数据导致损失好几亿,
### **数据不备份 运维两行泪**
- 献给乐于奉献的你
- 一、工作感悟
- 1.1 工作感悟
- 1.2 数据库工作总结
- 二、运维专题(非技术)
- 2.1 公有云运维
- 2.1.1 阿里云采坑记.md
- 三、运维专题(技术类)
- 3.1 Linux(操作系统)
- 3.1.1 常见工作总结
- 3.1.2 常见服务使用和部署
- 3.1.3 操作系统优化
- 3.1.4 常用命令(Centos8)
- 3.2 Docker & K8s(容器技术)
- 3.2.1 Docker
- 1. Docker
- 1-1 容器基础
- 1-2 部署和加速
- 1-3 常用命令
- 1-4 Dockerfile编写
- 1-5 容器网络
- 1-6 数据持久化
- 2. docker-compose
- 2-1 基础
- 3.2.2 kubernetes
- 1. 导读-请先看我
- 2. kubeadm部署集群
- 1-1 k8s-1.14-基于calico
- 1-2 k8s-1.17-基于flanne
- 3. 二进制部署集群
- 4. 日常工作及故障处理
- 4-1 常用命令
- 4-2 故障处理
- 3.2.3 依赖服务部署
- 1. Harbor(镜像仓库)
- 1-1 harbor-2.1.0(单节点)
- 3.3 CICD(持续集成/部署)
- 3.3.1 GitLab
- 1. 服务部署
- 1-1 Gitlab-CE-13.3.4(单节点)
- 2. Git基础
- 3.3.2 Ansible
- 1. 服务部署
- 1-2 ansible-2.5(pip部署)
- 3. ansible-playbook
- 3-1 基于Roles的Playbook
- 3-3 循环语法
- 3.3.3 Jnekins
- 1. Jenkins部署
- 1-1 Jenkins-2.65部署
- 1-2 Jenkins-2.249部署
- 2. Jenkins项目初始化
- 3. Jenkins集成
- 3-1 Jenkins-2.65集成Sonar
- 3.4 LB/HA(负载均衡,反向代理)
- 3.4.1 LVS+Keepalive
- 1. LVS为MySQL读提供负载均衡
- 3.4.2 Pacemaker(HA)
- 1. 常用命令(转)
- 3.5 Runtime(代码运行环境)
- 3.5.1 Tomcat(Web中间件)
- 1. Tomcat部署手册
- 1-1 Tomcat-7.0.76部署
- 2. Tomcat常用脚本
- 3.6 NoSQL(非关系型数据库)
- 3.6.1 redis(非关系数据库)
- 1. Redis 基础
- 2. Redis 4.0变化
- 3. Codis实现Redis的集群
- 4. Redis故障处理
- 5. redis安全第一步
- 6. Redis集群搭建
- 7. CacheCloud部署
- 3.6.1 Redis挑战
- 3.6.2 MongoDB(文档数据库)
- 1. Mongodb基础
- 1-1 Mongodb4.0新特性
- 1-2 支持多大数据量
- 2. Mongodb安装
- 2-1 Mac OS安装Mongodb
- 2-2 Yum安装Mongodb
- 2-3 二进制安装Mongodb
- 2-4 docker容器安装Mongodb
- 2-5 Mongodb 配置文件详解
- 2-6 Mongodb 生产安全清单
- 2-7 用户身份认证和授权
- 3. Mongodb副本集
- 3-1 副本集搭建
- 3-2 用户身份认证与授权
- 4. 日常维护工作
- 4-1 Mongodb磁盘回收
- 4-2 Mongodb备份恢复到任意时间点
- 4-3 Mongodb慢查询分析
- 4-4 Mongodb版本升级
- 4-5 Mongodb副本集成员状态
- 4-6 Mongodb备份恢复工具使用
- 4-7 Mongodb服务启动和停止
- 4-8 修改副本集成员oplog大小
- 4-9 Mongodb 副本集Oplog
- 3.7 MQ(消息队列)
- 3.7.1 Zookeeper(分布式协调系统)
- 1. ZooKeeper基础
- 2. ZooKeeper集群搭建
- 2-1 ZK-3.4.10部署
- 3.2 RabbitMQ(消息队列)
- 1. 服务部署
- 1-1 RabbitMQ-3.8部署
- 2. 常用命令
- 3.8 Monitor(数据收集,监控)
- 3.8.1 Zabbix(运维监控)
- 1. 服务部署
- 1-1 服务端部署
- 1-2 客户端部署
- 2. 监控服务
- 2-1 监控Apache
- 2-2 监控IIS
- 2-3 监控Ningx
- 2-4 监控Tomcat(6/7/8)
- 2-5 监控WebSphere 7
- 2-6 监控MySQL
- 2-7 监控Oracle
- 2-8 监控SQL Servre
- 2-9 监控Weblogic
- 2-10 监控Windows
- 2-11 自定义监控项
- 3. 告警推送
- 3-1 邮件告警
- 3-2 短信告警
- 3-3 告警推到Syslog
- 4. 日常工作
- 4-1 数据库优化(TokuDB)
- 4-2 数据库优化(分区表)
- 4-3 前端定制(Grafana)
- 5. 与Grafana结合
- 3.8.2 ELKBstack(日志收集展示)
- 1. 服务部署
- 1-1 ELK 5.5部署及配置
- 1-1-1 ELKBstack介绍
- 1-1-2 Elasticsearch部署
- 1-1-3 Logstash部署
- 1-1-4 Kibana部署
- 1-1-5 X-pack部署
- 1-1-6 Filebeat部署
- 2. ELK高级配置
- 1. Elasticsearch实战
- 2. Logstash实战
- 3. Filebeat实战
- 5. 引入队列
- 3.9 Virtualization(虚拟化)
- 3.10 Basic(基础服务)
- 3.10.1 Piwik-Matomo(用户行为分析)
- 1. Piwik前期分析
- 2. Piwik介绍和部署
- 2-1 Piwik-3.x版本(早期)
- 3. Piwik 功能配置
- 4. Piwik 模拟数据和压测
- 5. Piwik运转原理
- 6. Piwik数据库模式(一)
- 6-1 第一部分
- 6-2 第二部分
- 3.10.2 Cobbler(系统自动部署)
- 1. Cobbler 可以干什么?
- 2. Cobbler 基础原理
- 3. Cobbler 安装
- 3-1 Cobbler-2.8部署
- 4. Cobbler 基础配置
- 5. Cobbler 配置文件
- 6. 一键优化脚本
- 3.10.3 Rsync(数据同步服务)
- 1. Rsync基础
- 2. 案例:页面部署(服务端拉取)
- 3.10.4 NFS(共享存储)
- 1. NFS部署手册
- 2. 客户端NFS备份脚本
- 3.10.5 Grafana(可视化)
- 1. 安装(8.2.x)
- 3.11 Tools(软件工具)
- 3.11.1 基准测试
- 1. 基准测试方法论
- 2. 压测工具 - Siege
- 3. 压测工具 - http_load
- 3.12 DB(关系型数据库)
- 3.12.1 MySQL(关系数据库)
- 1. MySQL部署
- 1-1 MySQL-5.7部署
- 1-2 Percona-5.7 + TokuDB 部署
- 2. MySQL复制
- 2-1 MySQL异步复制
- 3. MySQL备份恢复
- 3-1 xtrabackup 备份恢复
- 4. MySQL 高可用
- 4-1 MHA(HA)
- 4-1-1 MHA 架构介绍和原理
- 4-1-2 MHA日常管理
- 4-1-3 MHA 自动Failover
- 4-1-4 MHA常用参数
- 4-1-5 MHA 报错
- 4-1-6 MHA相关配置文件和脚本
- 4-2 MyCAT
- 4-2-1 MyCAT 介绍和部署
- 4-1-3 MyCAT读写分离案例解析
- 5. MySQL 常用脚本
- 5-1 MySQL常用统计语句
- 5-2 MySQL性能分析脚本
- 6. MySQL 日常及故障处理
- 6-1 MySQL死锁排查
- 6-2 复制故障
- 6-3 MySQL 升级注意事项
- 6-3 MySQL授权
- 3.12.2 Oracle(关系数据库)
- 1. Oracle部署
- 1-1 Oracle11g单实例部署
- 1-2 Oracle12c单实例部署
- 2. Oracle常用脚本
- 3. Oracle 知识点
- 六、Ansible开源项目
- 6.1 项目初始化手册
- 6.1.1 Ansible错误处理
- 6.1.2 一种预先判断是否操作的方法
- 6.2 System初始化
- 6.3 Nginx/Tnginx部署
- 6.4 Python部署
- 6.5 PHP部署
- 6.6 MySQL部署
- 6.7 Docker部署
- 6.8 Haproxy部署
- 6.9 Redis部署
- 1. 变量和tags信息
- 3. Redis主从部署
- 4. Redis集群部署
- 5. 清理数据
- 6.10 Software软件部署
- 6.11 Zabbix部署
- 6.12 Elastic部署
- 6.13 Tomcat
- 6.14 Kafka部署
- 6.15 Zookeeper部署
- 6.16 Etcd集群部署
- 6.17 M3DB部署
- 6.18 Pormetheus部署
- 七、学习资源推荐
- 八、从瞎搞到放弃
- 8.1 CodeQL(语义代码分析引擎)
- 8.1.1 背景及计划
- 8.1.2 CodeQL概述
- 8.1.3 简单部署和使用
- 8.1.4 后续
- 8.2 dbdeployer(轻松部署MySQL)
- 归档笔记
- 三、常用服务部署(迁移中)
- 3.4 Nginx & PHP(Web服务)
- 3.4.1 Nginx(Web)
- 1. Nginx基础和部署
- 2. Nginx 我的一些思考
- 3. Nginx(Web)配置
- 4. Nginx(Proxy)配置
- 5. Nginx日常管理
- 3.4.3 PHP
- 1. PHP 7.1 部署
- 2. PHP5.6 部署
- 4. PHP原理
- 5. PHP 常用模块
- 二、运维项目实战(迁移中)
- 2.1 标准化 & 工具化项目
- 2.1.1 系统部署和优化
- 2.1.5 全网日志收集展示平台项目
- 1. 项目需求
- 2. 整体方案规划
- 3. 日志收集配置
- 4. 消息缓冲队列
- 5. 日志处理转发
- 6. 日志数据展示(待补充)
- 7. ELK安全配置(上)
- 8. ELK安全配置(下)
- 9. 项目总结
- 2.2 高性能Web项目
- 2.2.1 网站需求(完善中)