MongoDB利用oplog恢复数据的方法

目录
  • 数据全备
  • 模拟故障
    • 写入数据
    • 模拟误操作
  • 恢复步骤
    • 备份oplog
    • 解析oplog
    • 将oplog备份和全备复制到standalone机
    • 查找误操作时间点
    • 进行数据恢复
    • 检查恢复结果

当我们对数据出现误操作的时候，可以利用oplog恢复数据。

使用前提：

  • 1、环境是副本集
  • 2、必须有全备
  • 2、全备后oplog没有被覆盖

数据全备

mongodump -h 172.16.254.133 --port 27017 -o /mongodb/backup/backup

模拟故障

写入数据

handong1:PRIMARY> for (var i = 1; i <= 100; i++) {
...    db.test.insert( { id : i , name: "handong" , name1:"handong", name2:"handong", name3:"handong"} )
... }
WriteResult({ "nInserted" : 1 })
handong1:PRIMARY>
handong1:PRIMARY> db.test.count()
100

模拟误操作

handong1:PRIMARY> db.test.remove({})
WriteResult({ "nRemoved" : 100 })
handong1:PRIMARY> db.test.count()
0

所有文档被误删除。

恢复步骤

备份oplog

mongodump -h 172.16.254.133 --port 27017 -d local -c oplog.rs -o /mongodb/backup
2021-04-30T18:32:29.077+0800	writing local.oplog.rs to /mongodb/backup/local/oplog.rs.bson
2021-04-30T18:32:32.039+0800	local.oplog.rs  7108
2021-04-30T18:32:35.038+0800	local.oplog.rs  17912
2021-04-30T18:32:38.041+0800	local.oplog.rs  28226
2021-04-30T18:32:41.039+0800	local.oplog.rs  38642
2021-04-30T18:32:44.042+0800	local.oplog.rs  50679
2021-04-30T18:32:47.040+0800	local.oplog.rs  64001
2021-04-30T18:32:50.040+0800	local.oplog.rs  77265
2021-04-30T18:32:53.038+0800	local.oplog.rs  89739
2021-04-30T18:32:56.038+0800	local.oplog.rs  102449
2021-04-30T18:32:57.697+0800	local.oplog.rs  132459
2021-04-30T18:32:57.697+0800	done dumping local.oplog.rs (132459 documents)

解析oplog

bsondump /mongodb/backup/local/oplog.rs.bson  > /mongodb/backup/local/local.log
2021-04-30T18:34:27.612+0800	132459 objects found

将oplog备份和全备复制到standalone机

scp -r backup/ 172.16.254.130:/mongodb/backup/

scp -r local/ 172.16.254.130:/mongodb/backup/backup

查找误操作时间点

通过查看解析完的日志local.log发现误操作的时间点在1619778429。

进行数据恢复

mongorestore -h 172.16.254.130 --port 27017 --oplogReplay --oplogLimit 1619778429:1 /mongodb/backup/backup
2021-04-30T19:00:11.099+0800	preparing collections to restore from
2021-04-30T19:00:11.100+0800	don't know what to do with file "/mongodb/backup/backup/local/111.log", skipping...
2021-04-30T19:00:11.100+0800	don't know what to do with file "/mongodb/backup/backup/local/local.log", skipping...
2021-04-30T19:00:11.116+0800	reading metadata for db4.rcmd_1_tag_li_liao from /mongodb/backup/backup/db4/rcmd_1_tag_li_liao.metadata.json
2021-04-30T19:00:11.117+0800	reading metadata for ycsb.usertable from /mongodb/backup/backup/ycsb/usertable.metadata.json
2021-04-30T19:00:11.119+0800	reading metadata for db3.db3 from /mongodb/backup/backup/db3/db3.metadata.json
2021-04-30T19:00:11.119+0800	reading metadata for ycsb1.usertable from /mongodb/backup/backup/ycsb1/usertable.metadata.json
2021-04-30T19:00:11.170+0800	restoring ycsb.usertable from /mongodb/backup/backup/ycsb/usertable.bson
2021-04-30T19:00:11.187+0800	restoring ycsb1.usertable from /mongodb/backup/backup/ycsb1/usertable.bson
2021-04-30T19:00:11.391+0800	restoring db4.rcmd_1_tag_li_liao from /mongodb/backup/backup/db4/rcmd_1_tag_li_liao.bson
2021-04-30T19:00:11.580+0800	restoring db3.db3 from /mongodb/backup/backup/db3/db3.bson
2021-04-30T19:00:11.661+0800	no indexes to restore
2021-04-30T19:00:11.661+0800	finished restoring db3.db3 (6 documents, 0 failures)
2021-04-30T19:00:11.662+0800	reading metadata for db5.test from /mongodb/backup/backup/db5/test.metadata.json
2021-04-30T19:00:12.545+0800	restoring db5.test from /mongodb/backup/backup/db5/test.bson
2021-04-30T19:00:12.548+0800	no indexes to restore
2021-04-30T19:00:12.548+0800	finished restoring db5.test (0 documents, 0 failures)
2021-04-30T19:00:12.548+0800	reading metadata for db4.db4 from /mongodb/backup/backup/db4/db4.metadata.json
2021-04-30T19:00:13.784+0800	no indexes to restore
2021-04-30T19:00:13.784+0800	finished restoring ycsb1.usertable (30370 documents, 0 failures)
2021-04-30T19:00:13.785+0800	reading metadata for db4.test1 from /mongodb/backup/backup/db4/test1.metadata.json
2021-04-30T19:00:14.099+0800	[###################.....]          ycsb.usertable  47.8MB/58.9MB  (81.2%)
2021-04-30T19:00:14.099+0800	[........................]  db4.rcmd_1_tag_li_liao  79.8MB/3.32GB   (2.3%)
2021-04-30T19:00:14.099+0800
2021-04-30T19:00:14.843+0800	[########################]  ycsb.usertable  58.9MB/58.9MB  (100.0%)
2021-04-30T19:00:14.843+0800	no indexes to restore
2021-04-30T19:00:14.843+0800	finished restoring ycsb.usertable (43458 documents, 0 failures)
2021-04-30T19:00:15.339+0800	restoring db4.db4 from /mongodb/backup/backup/db4/db4.bson
2021-04-30T19:00:17.077+0800	restoring db4.test1 from /mongodb/backup/backup/db4/test1.bson
2021-04-30T19:00:17.103+0800	[#.......................]  db4.rcmd_1_tag_li_liao  167MB/3.32GB  (4.9%)
2021-04-30T19:00:17.104+0800	[#.......................]                 db4.db4  8.11MB/137MB  (5.9%)
2021-04-30T19:00:17.104+0800	[........................]               db4.test1      0B/104MB  (0.0%)
2021-04-30T19:00:17.104+0800
2021-04-30T19:00:20.099+0800	[#.......................]  db4.rcmd_1_tag_li_liao  204MB/3.32GB   (6.0%)
2021-04-30T19:00:20.099+0800	[####....................]                 db4.db4  24.5MB/137MB  (18.0%)
2021-04-30T19:00:20.099+0800	[#.......................]               db4.test1  4.47MB/104MB   (4.3%)
2021-04-30T19:00:20.099+0800
2021-04-30T19:00:23.099+0800	[#.......................]  db4.rcmd_1_tag_li_liao  272MB/3.32GB   (8.0%)
2021-04-30T19:00:23.099+0800	[######..................]                 db4.db4  39.7MB/137MB  (29.1%)
2021-04-30T19:00:23.099+0800	[####....................]               db4.test1  20.1MB/104MB  (19.3%)
2021-04-30T19:00:23.099+0800
2021-04-30T19:00:26.102+0800	[##......................]  db4.rcmd_1_tag_li_liao  355MB/3.32GB  (10.4%)
2021-04-30T19:00:26.102+0800	[##########..............]                 db4.db4  58.0MB/137MB  (42.5%)
2021-04-30T19:00:26.102+0800	[########................]               db4.test1  38.1MB/104MB  (36.7%)
2021-04-30T19:00:26.102+0800
2021-04-30T19:00:29.098+0800	[##......................]  db4.rcmd_1_tag_li_liao  401MB/3.32GB  (11.8%)
2021-04-30T19:00:29.098+0800	[############............]                 db4.db4  73.1MB/137MB  (53.5%)
2021-04-30T19:00:29.098+0800	[###########.............]               db4.test1  51.8MB/104MB  (49.8%)
2021-04-30T19:00:29.098+0800
2021-04-30T19:00:32.097+0800	[###.....................]  db4.rcmd_1_tag_li_liao  494MB/3.32GB  (14.5%)
2021-04-30T19:00:32.097+0800	[###############.........]                 db4.db4  90.8MB/137MB  (66.5%)
2021-04-30T19:00:32.097+0800	[###############.........]               db4.test1  67.3MB/104MB  (64.7%)
2021-04-30T19:00:32.097+0800
2021-04-30T19:00:35.100+0800	[###.....................]  db4.rcmd_1_tag_li_liao  556MB/3.32GB  (16.3%)
2021-04-30T19:00:35.100+0800	[###################.....]                 db4.db4   110MB/137MB  (80.5%)
2021-04-30T19:00:35.100+0800	[###################.....]               db4.test1  86.1MB/104MB  (82.8%)
2021-04-30T19:00:35.100+0800
2021-04-30T19:00:38.097+0800	[####....................]  db4.rcmd_1_tag_li_liao  620MB/3.32GB  (18.2%)
2021-04-30T19:00:38.097+0800	[#####################...]                 db4.db4   124MB/137MB  (91.1%)
2021-04-30T19:00:38.097+0800	[#######################.]               db4.test1   101MB/104MB  (96.7%)
2021-04-30T19:00:38.097+0800
2021-04-30T19:00:39.023+0800	[########################]  db4.test1  104MB/104MB  (100.0%)
2021-04-30T19:00:39.023+0800	no indexes to restore
2021-04-30T19:00:39.023+0800	finished restoring db4.test1 (1000000 documents, 0 failures)
2021-04-30T19:00:40.386+0800	[########################]  db4.db4  137MB/137MB  (100.0%)
2021-04-30T19:00:40.386+0800	no indexes to restore
2021-04-30T19:00:40.386+0800	finished restoring db4.db4 (1313657 documents, 0 failures)
2021-04-30T19:00:41.097+0800	[####....................]  db4.rcmd_1_tag_li_liao  684MB/3.32GB  (20.1%)
2021-04-30T19:00:44.097+0800	[#####...................]  db4.rcmd_1_tag_li_liao  760MB/3.32GB  (22.3%)
2021-04-30T19:00:47.097+0800	[#####...................]  db4.rcmd_1_tag_li_liao  836MB/3.32GB  (24.6%)
2021-04-30T19:00:50.098+0800	[######..................]  db4.rcmd_1_tag_li_liao  906MB/3.32GB  (26.6%)
2021-04-30T19:00:53.098+0800	[#######.................]  db4.rcmd_1_tag_li_liao  994MB/3.32GB  (29.2%)
2021-04-30T19:00:56.098+0800	[#######.................]  db4.rcmd_1_tag_li_liao  1.03GB/3.32GB  (31.0%)
2021-04-30T19:00:59.098+0800	[########................]  db4.rcmd_1_tag_li_liao  1.11GB/3.32GB  (33.3%)
2021-04-30T19:01:02.097+0800	[########................]  db4.rcmd_1_tag_li_liao  1.18GB/3.32GB  (35.5%)
2021-04-30T19:01:05.101+0800	[#########...............]  db4.rcmd_1_tag_li_liao  1.26GB/3.32GB  (38.0%)
2021-04-30T19:01:08.097+0800	[#########...............]  db4.rcmd_1_tag_li_liao  1.32GB/3.32GB  (39.7%)
2021-04-30T19:01:11.100+0800	[#########...............]  db4.rcmd_1_tag_li_liao  1.37GB/3.32GB  (41.1%)
2021-04-30T19:01:14.098+0800	[##########..............]  db4.rcmd_1_tag_li_liao  1.43GB/3.32GB  (43.2%)
2021-04-30T19:01:17.097+0800	[##########..............]  db4.rcmd_1_tag_li_liao  1.50GB/3.32GB  (45.0%)
2021-04-30T19:01:20.098+0800	[###########.............]  db4.rcmd_1_tag_li_liao  1.54GB/3.32GB  (46.3%)
2021-04-30T19:01:23.098+0800	[###########.............]  db4.rcmd_1_tag_li_liao  1.58GB/3.32GB  (47.6%)
2021-04-30T19:01:26.098+0800	[###########.............]  db4.rcmd_1_tag_li_liao  1.64GB/3.32GB  (49.3%)
2021-04-30T19:01:29.097+0800	[############............]  db4.rcmd_1_tag_li_liao  1.71GB/3.32GB  (51.4%)
2021-04-30T19:01:32.097+0800	[############............]  db4.rcmd_1_tag_li_liao  1.77GB/3.32GB  (53.2%)
2021-04-30T19:01:35.098+0800	[#############...........]  db4.rcmd_1_tag_li_liao  1.85GB/3.32GB  (55.7%)
2021-04-30T19:01:38.097+0800	[#############...........]  db4.rcmd_1_tag_li_liao  1.90GB/3.32GB  (57.2%)
2021-04-30T19:01:41.097+0800	[##############..........]  db4.rcmd_1_tag_li_liao  1.98GB/3.32GB  (59.5%)
2021-04-30T19:01:44.827+0800	[##############..........]  db4.rcmd_1_tag_li_liao  2.00GB/3.32GB  (60.3%)
2021-04-30T19:01:47.097+0800	[##############..........]  db4.rcmd_1_tag_li_liao  2.05GB/3.32GB  (61.8%)
2021-04-30T19:01:50.098+0800	[###############.........]  db4.rcmd_1_tag_li_liao  2.12GB/3.32GB  (63.9%)
2021-04-30T19:01:53.097+0800	[###############.........]  db4.rcmd_1_tag_li_liao  2.19GB/3.32GB  (65.9%)
2021-04-30T19:01:56.097+0800	[################........]  db4.rcmd_1_tag_li_liao  2.26GB/3.32GB  (67.9%)
2021-04-30T19:01:59.099+0800	[################........]  db4.rcmd_1_tag_li_liao  2.32GB/3.32GB  (69.8%)
2021-04-30T19:02:02.098+0800	[#################.......]  db4.rcmd_1_tag_li_liao  2.39GB/3.32GB  (72.0%)
2021-04-30T19:02:05.097+0800	[#################.......]  db4.rcmd_1_tag_li_liao  2.47GB/3.32GB  (74.4%)
2021-04-30T19:02:08.097+0800	[##################......]  db4.rcmd_1_tag_li_liao  2.52GB/3.32GB  (76.0%)
2021-04-30T19:02:11.097+0800	[##################......]  db4.rcmd_1_tag_li_liao  2.59GB/3.32GB  (77.8%)
2021-04-30T19:02:14.097+0800	[###################.....]  db4.rcmd_1_tag_li_liao  2.66GB/3.32GB  (80.0%)
2021-04-30T19:02:17.097+0800	[###################.....]  db4.rcmd_1_tag_li_liao  2.72GB/3.32GB  (81.9%)
2021-04-30T19:02:20.097+0800	[####################....]  db4.rcmd_1_tag_li_liao  2.78GB/3.32GB  (83.7%)
2021-04-30T19:02:23.097+0800	[####################....]  db4.rcmd_1_tag_li_liao  2.85GB/3.32GB  (85.7%)
2021-04-30T19:02:26.098+0800	[#####################...]  db4.rcmd_1_tag_li_liao  2.94GB/3.32GB  (88.4%)
2021-04-30T19:02:29.097+0800	[#####################...]  db4.rcmd_1_tag_li_liao  3.00GB/3.32GB  (90.4%)
2021-04-30T19:02:32.097+0800	[######################..]  db4.rcmd_1_tag_li_liao  3.06GB/3.32GB  (92.1%)
2021-04-30T19:02:35.099+0800	[######################..]  db4.rcmd_1_tag_li_liao  3.12GB/3.32GB  (93.9%)
2021-04-30T19:02:38.097+0800	[######################..]  db4.rcmd_1_tag_li_liao  3.15GB/3.32GB  (95.0%)
2021-04-30T19:02:41.098+0800	[#######################.]  db4.rcmd_1_tag_li_liao  3.21GB/3.32GB  (96.7%)
2021-04-30T19:02:44.167+0800	[#######################.]  db4.rcmd_1_tag_li_liao  3.26GB/3.32GB  (98.0%)
2021-04-30T19:02:47.097+0800	[#######################.]  db4.rcmd_1_tag_li_liao  3.32GB/3.32GB  (99.9%)
2021-04-30T19:02:47.392+0800	[########################]  db4.rcmd_1_tag_li_liao  3.32GB/3.32GB  (100.0%)
2021-04-30T19:02:47.393+0800	no indexes to restore
2021-04-30T19:02:47.393+0800	finished restoring db4.rcmd_1_tag_li_liao (379143 documents, 0 failures)
2021-04-30T19:02:47.393+0800	restoring users from /mongodb/backup/backup/admin/system.users.bson
2021-04-30T19:02:50.655+0800	admin.tempusers  2.05KB
2021-04-30T19:02:50.655+0800	admin.tempusers  2.05KB
2021-04-30T19:02:51.905+0800	replaying oplog
2021-04-30T19:02:53.097+0800	oplog  483KB
2021-04-30T19:02:56.097+0800	oplog  20.2MB
2021-04-30T19:02:59.100+0800	oplog  36.9MB
2021-04-30T19:03:02.097+0800	oplog  50.1MB
2021-04-30T19:03:05.098+0800	oplog  69.0MB
2021-04-30T19:03:08.097+0800	oplog  90.6MB
2021-04-30T19:03:11.097+0800	oplog  124MB
2021-04-30T19:03:14.097+0800	oplog  159MB
2021-04-30T19:03:17.098+0800	oplog  185MB
2021-04-30T19:03:20.097+0800	oplog  219MB
2021-04-30T19:03:23.098+0800	oplog  256MB
2021-04-30T19:03:26.097+0800	oplog  290MB
2021-04-30T19:03:29.097+0800	oplog  323MB
2021-04-30T19:03:32.097+0800	oplog  357MB
2021-04-30T19:03:35.097+0800	oplog  391MB
2021-04-30T19:03:38.098+0800	oplog  427MB
2021-04-30T19:03:41.098+0800	oplog  464MB
2021-04-30T19:03:44.097+0800	oplog  501MB
2021-04-30T19:03:47.097+0800	oplog  544MB
2021-04-30T19:03:50.098+0800	oplog  580MB
2021-04-30T19:03:53.098+0800	oplog  619MB
2021-04-30T19:03:56.098+0800	oplog  650MB
2021-04-30T19:03:59.099+0800	oplog  687MB
2021-04-30T19:04:02.097+0800	oplog  722MB
2021-04-30T19:04:05.097+0800	oplog  758MB
2021-04-30T19:04:08.098+0800	oplog  795MB
2021-04-30T19:04:11.097+0800	oplog  826MB
2021-04-30T19:04:14.098+0800	oplog  858MB
2021-04-30T19:04:17.102+0800	oplog  893MB
2021-04-30T19:04:20.097+0800	oplog  929MB
2021-04-30T19:04:23.098+0800	oplog  968MB
2021-04-30T19:04:26.098+0800	oplog  1001MB
2021-04-30T19:04:29.097+0800	oplog  1002MB
2021-04-30T19:04:32.097+0800	oplog  1003MB
2021-04-30T19:04:35.097+0800	oplog  1004MB
2021-04-30T19:04:38.097+0800	oplog  1004MB
2021-04-30T19:04:38.597+0800	applied 130029 oplog entries
2021-04-30T19:04:38.597+0800	oplog  1005MB
2021-04-30T19:04:38.614+0800	2766634 document(s) restored successfully. 0 document(s) failed to restore.

检查恢复结果

> show dbs
admin   0.000GB
config  0.000GB
db3     0.000GB
db4     3.355GB
db5     0.000GB
local   0.000GB
ycsb    0.060GB
ycsb1   0.041GB
>
>
> use db5
switched to db db5
>
> db.test.count()
100

可以看到我们前期插入的100记录以及恢复成功。

到此这篇关于MongoDB利用oplog恢复数据介绍的文章就介绍到这了,更多相关oplog数据恢复内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！

赞 (0)

相关推荐

  • 利用MongoDB中oplog机制实现准实时数据的操作监控

    利用MongoDB中oplog机制实现准实时数据的操作监控

    前言 最近有一个需求是要实时获取到新插入到MongoDB的数据,而插入程序本身已经有一套处理逻辑,所以不方便直接在插入程序里写相关程序,传统的数据库大多自带这种触发器机制,但是Mongo没有相关的函数可以用(也可能我了解的太少了,求纠正),当然还有一点是需要python实现,于是收集整理了一个相应的实现方法. 一.引子 首先可以想到,这种需求其实很像数据库的主从备份机制,从数据库之所以能够同步主库是因为存在某些指标来做控制,我们知道MongoDB虽然没有现成触发器,但是它能够实现主从备份,所以我

  • 关于单台MongoDB实例开启Oplog的过程详解

    背景 随着数据的积累,MongoDB中的数据量越来越大,数据分析团队从数据库中抽取变化数据(假如依据栏位createdatetime,transdatetime),越来越困难.我们知道MongoDB的副本集有一个数据结构Oplog,里面存储了Primary节点的所有写操作(此处的写操作是指查询以外的操作,包含 更新.异常等).其实,数据的抽取完全可以从Oplog中抓取这些操作,然后去重放. oplog是local库下的一个固定集合,Secondary就是通过查看Primary 的oplog这个集

  • 剖析后OpLog订阅MongoDB的数据变更就没那么难了

    剖析后OpLog订阅MongoDB的数据变更就没那么难了

    目录 前言 oplog简介 解析oplog 代码 结语 前言 我们开源了一个订阅分发mysql的binlog的项目,一直用的非常好,忽然有天开发说能不能支持MongoDB的数据订阅呢,MongoDB的使用度也挺广泛的.安排.经过简单的了解后发现MongoDB也有类似binlog的机制,最终花了两天时间把功能完成,并统一抽象集成到binlog开源项目中,使用和binlog同一套订阅分发模型管理MongoDB数据源.整个过程非常顺利,比整mysql的binlog要简单的多了. oplog简介 先来聊

  • Mongodb的oplog详解

    Oplog 是 MongoDB 实现复制集的关键数据结构,在复制集中 Primary 对数据库操作之后就会产生一个 Oplog 文档保存在 local.oplog.rs 集合中,Secondary 成员会拉取 Primary 的 Oplog 并重放相同的操作,从而达到 Secondary 成员与 Primary 有一致的数据.实际上复制集中每一个成员都会保存 Oplog,其他成员会根据连接延迟等因数选择最近的成员拉取 Oplog 数据. Oplog 存在集合 local.oplog.rs,这是系

  • mongodb中oplog介绍和格式详析

    mongodb中oplog介绍和格式详析

    目录 1. 基本概念 2. Oplog 的默认储存大小 3. 可能需要更大oplog的工作负载 4. Oplog状态 5. Oplog格式 6. CUD操作和Oplog的对应关系 delete操作 update操作 小结 总结 1. 基本概念 oplog使用固定大小集合记录了数据库中所有修改操作的操作日志(新增.修改和删除,无查询),mongodb收到修改请求后,先在主节点(Primary)执行请求,再把操作日志保存到oplog表中,其他从节点(Secondary)到主节点拉取oplog并在异步

  • MongoDB利用oplog恢复数据的方法

    目录 数据全备 模拟故障 写入数据 模拟误操作 恢复步骤 备份oplog 解析oplog 将oplog备份和全备复制到standalone机 查找误操作时间点 进行数据恢复 检查恢复结果 当我们对数据出现误操作的时候,可以利用oplog恢复数据. 使用前提: 1.环境是副本集 2.必须有全备 2.全备后oplog没有被覆盖 数据全备 mongodump -h 172.16.254.133 --port 27017 -o /mongodb/backup/backup 模拟故障 写入数据 hando

  • 解说mysql之binlog日志以及利用binlog日志恢复数据的方法

    众所周知,binlog日志对于mysql数据库来说是十分重要的.在数据丢失的紧急情况下,我们往往会想到用binlog日志功能进行数据恢复(定时全备份+binlog日志恢复增量数据部分),化险为夷! 废话不多说,下面是梳理的binlog日志操作解说: 一.初步了解binlog MySQL的二进制日志binlog可以说是MySQL最重要的日志,它记录了所有的DDL和DML语句(除了数据查询语句select),以事件形式记录,还包含语句所执行的消耗的时间,MySQL的二进制日志是事务安全型的. ---

  • Mongodb 利用mongoshell进行数据类型转换的实现方法

    $type操作符 检测类型 种类 代号 别名 Double 1 "double" String 2 "string" Object 3 "object" Array 4 "array" Binary data 5 "binData" Undefined 6 "undefined" Deprecated. ObjectId 7 "objectId" Boolean 8

  • pyqt5 tablewidget 利用线程动态刷新数据的方法

    问题 知道要用线程,所以就先尝试写了一个线程,然后每次都获取数据,然后直接通过这种方法来朝table里面更新数据. #python代码 table=MainWindow_ui.tableWidget_2 table.setItem(i,0,QtWidgets.QTableWidgetItem(str(jcb.Name))) 发现数据并不是想象中跟线程运行那样实时的,要点一下才能显示出数据来 并且还会出现一些问题 问题图片 为了做出对比,我将作业名的表格填写改成table.setItem的方式,其

  • MySQL 两种恢复数据的方法

    一 前言 前一段时间接二连三的出现开发人员在测试环境和生产误操作导致数据库误删除/更新,对DBA而言,回滚数据着实是一件头疼的事情,凡涉及到恢复线上数据必然对应用带来一定的影响.大多数情况是开发误操作delete数据,update多数行,根据之前的操作经验,本文介绍常用的恢复方法. 二 常用的恢复方式 2.1 利用备份恢复 使用这种方式的前提必须有最近的备份集或者知道出现误操作起始的binlog 位点或者GTID,利用备份集恢复到中间的机器上,然后利用MySQL的slave 特性 START S

  • mysql5.7使用binlog 恢复数据的方法

    mysql5.7使用binlog 恢复数据的方法

    第一步:保证mysql已经开启binlog show variables like '%log_bin%'; log_bin 为 on是开启. 第二步:进入binlog文件目录,找到二进制日志文件 mysql> show binary logs; #获取binlog文件列表 mysql> show master status: #查看当前正在写入的binlog文件 mysql> reset master; 重置binlog 第三步: 通过mysqlbinlog工具命令查看数据库增删改查记

  • Mongodb中MapReduce实现数据聚合方法详解

    Mongodb中MapReduce实现数据聚合方法详解

    Mongodb是针对大数据量环境下诞生的用于保存大数据量的非关系型数据库,针对大量的数据,如何进行统计操作至关重要,那么如何从Mongodb中统计一些数据呢? 在Mongodb中,给我们提供了三种用于数据聚合的方式: (1)简单的用户聚合函数: (2)使用aggregate进行统计: (3)使用mapReduce进行统计: 今天我们首先来讲讲mapReduce是如何统计,在后续的文章中,将另起文章进行相关说明. MapReduce是啥呢?以我的理解,其实就是对集合中的各个满足条件的文档进行预处理

  • window环境redis通过AOF恢复数据的方法

    首先要启动AOF持久化配置,在redis.windows-server.conf配置文件中做出如下更改 ................ appendonly yes # The name of the append only file (default: "appendonly.aof") appendfilename "appendonly.aof" ..................................... # appendfsync alwa

  • 利用Spring Data MongoDB持久化文档数据的方法教程

    前言 本文主要给大家介绍了关于利用Spring Data MongoDB持久化文档数据的相关内容,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧. 介绍 NoSQL:not only SQL,非关系型数据 MongoDB是文档型数据,文档是独立的实体,文档数据库不适用于关联关系明显的数据 Spring Data MongoDB 1.Spring Data MongoDB提供了三种方式在Spring应用中使用MongoDB 通过注解实现对象-文档映射 使用MongoTemplate

  • SqlServer2008误操作数据(delete或者update)后恢复数据的方法

    SqlServer2008误操作数据(delete或者update)后恢复数据的方法

    实际工作中,有时会直接在数据库中操作数据,比如对数据进行delete或者update操作,当进行这些操作的时候,如果没有加上 where条件或者where条件不合理,那么导致的结果可想而知,如果操作的又是线上数据库,那么这个后果将会非常严重. 当事情发生后,我们要想办法补救,针对于sqlserver2005数据库,有个很出名的工具Log Exploer.具体操作使用大家可以自行搜索;针对于sqlserver2008也有这样的工具,但是大多是需要付费的...我们尝试用 sqlserver的事务日志

随机推荐