Descripción:
De acuerdo con la información técnica, se trata de alguien borrar accidentalmente una línea de datos de la tabla, mongodb comentarios de los usuarios al servicio al cliente, y ahora necesita para restaurar los datos del usuario.
En primer esquema de base de determinar los datos que se suprime es qué modelo
1.1, un único punto:
¿Hay una copia de seguridad con situaciones de espera, iniciar una instancia, va a importar los datos de copia de seguridad a la nueva instancia
de encontrar una nueva instancia ha sido borrado de datos utilizando los datos de exportación mongodump, y luego importados en la fuente de instancias de datos eliminados y restaurar los datos.
Ver detalles más abajo en este capítulo: 2.2 2.5 Copia de seguridad y restauración de
un único nodo mongodb ningún concepto oplog, si no hay ninguna copia de seguridad, se perderán los datos, trate de usar el entorno formal de copiado arquitectura del conjunto.
1,2, conjunto de replicación:
1.2.1, puede tomar la forma de un nodo de retardo, un PRIMARIA nodo, SECUNDARIA dos de los cuales hacen un nodo de retardo,
tal como el nodo nos latencia retraso de ocho horas, se encontró que los datos se borran antes de 8 horas, y la recuperación (oplog garantía no cubierto por la minúscula)
1.2.2, la cantidad total + delta: la cantidad de datos y la importancia de seleccionar la cantidad de copias de seguridad incrementales horas de copia de seguridad + Vincent oplog, días o la cantidad completa de copia de seguridad incremental de copia de seguridad + oplog. 
1.3, la fragmentación de clúster
fragmento son un grupo compuesto de una pluralidad de juegos de copias, copia de seguridad se puede ajustar de acuerdo con la política de copia de seguridad
2. Copia de simulación arquitectura del conjunto de borrado accidental:
Usamos la copia de seguridad completa + oplog copia de seguridad incremental
2.1, insertamos 1000 Datos: for (var i = 0; i <1000; i ++) {db.user.save ({ "ID de usuario": 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, hacemos una copia de seguridad completa:
[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, el primer caso:
Si la operación de eliminación en unas pocas horas después de la copia de seguridad, siempre y cuando los datos importados a la nueva instancia será capaz de recuperar los datos, esto es demasiado simple.
La premisa es que tenemos una copia de seguridad para recuperarse.
2.4, que siguen el segundo caso
Seguimos inserción de datos:
[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>Vamos a restaurar el "ID de usuario": antes de este punto en el tiempo: ({1003 "ID de usuario"}) 1003 de estos datos, necesitamos un momento, que es, para restaurar eliminado antes de la recuperación de la ejecución db.user.remove.
2.5, se crea un nuevo conjunto de réplicas de ejemplo, la importación de copia de seguridad completa
[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 Exportación oplog registro:
### 首先我们查一下什么时间执行删除操作的、连上执行删除操作的数据实例
[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>Teniendo en cuenta: Se completa el tiempo de copia de seguridad: 2020-03-12T16: 52: 37.421 + 0.800 jia_test.user vertido hecho (1000 documentos)
del tiempo de eliminación también se sabe que necesitamos el tiempo entero como la copia de seguridad se ha realizado correctamente, lo fueron la conversión, se obtiene un sello de tiempo,
Prueba el tiempo de copia de seguridad en cuestión de minutos diez antes, no tendríamos los registros faltantes, duplicados de importación sobrescritos automáticamente. 
Tenemos dos marcas de tiempo:
marca de tiempo de copia de seguridad: 1584002557
marca de tiempo de eliminación: "TS": Marca de tiempo (1584003536 , 1)
Exportación de instancias de datos oplog registro suprimido (tiempo de supresión es mayor que el tiempo de copia de seguridad es menor que este período)
[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 en una nueva instancia:
[root@10-1-1-159 ~]# /data/mongodb3.6.9/bin/mongorestore -h 10.1.1.77:27010 –oplogReplay local/oplog.rs.bson2.8, conectar la nueva recuperación ejemplos véase:
[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, la instancia antigua de visión:
[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 colocamos una nueva instancia de los datos mediante la exportación, la importación en el entorno en línea puede ser un oficial
Consejos: MongoDB asuntos oficiales, al menos, utilizan un conjunto de replicación, no un solo punto, los datos deben ser respaldados.
Hace algún tiempo, una deleción empresa de datos que resultan en la pérdida de cientos de millones,