mongodb数据库迁移报错解决--writeConcern选项
来源:互联网 发布:pl sql scott登录不了 编辑:程序博客网 时间:2024/05/16 10:15
备份
./mongodump -h 10.*.*.* --port 27017 -d userPortrait -o /tmp/wolf.bak (成功)
恢复
mongorestore --host 10.*.*.* :27101 --writeConcern=1 -drop -d HRM /tmp/wolf.bak/userPortrait/
一共788.7M从开始restore,等了大概10多分钟,感觉不正常。
检查复制集状态
wolfmongodb:PRIMARY> db.printReplicationInfo()
configured oplog size: 20480MB
log length start to end: 17528397secs (4869hrs)
oplog first event time: Tue May 31 2016 22:58:42 GMT+0800 (CST)
oplog last event time: Tue Dec 20 2016 19:58:39 GMT+0800 (CST)
now: Tue Dec 20 2016 20:01:11 GMT+0800 (CST)
wolfmongodb:PRIMARY> rs.printSlaveReplicationInfo()
source: 10.*.*.*:27101
syncedTo: Tue Dec 20 2016 19:58:39 GMT+0800 (CST)
0 secs (0 hrs) behind the primary
source: 10.*.*.*:27101
syncedTo: Thu Jan 01 1970 08:00:00 GMT+0800 (CST)
1482235119 secs (411731.98 hrs) behind the primary 发现节点延迟
由于次节点不在我的处理范围,网络无法连接,但是当前迁移库必须进行,restore中加了一个参数
--writeConcern=1 (故障恢复)
Default: majority
Specifies the write concern for each write operation that mongorestore writes to the target database.
Specify the write concern as a document with w options.
--writeConcern=<write-concern> write concern options e.g. --writeConcern majority, --writeConcern '{w:3, wtimeout:500, fsync: true, j: true}' (defaults to 'majority')再恢复
mongorestore --host 10.**.*.*:27101 --writeConcern=1 -drop -d HRM /tmp/wolf.bak/userPortrait/
================================================================
MongoDB支持客户端灵活配置写入策略(writeConcern),以满足不同场景的需求。
db.collection.insert({x: 1}, {writeConcern: {w: 1}})
writeConcern选项
MongoDB支持的WriteConncern选项如下
w: <number>,数据写入到number个节点才向用客户端确认
- {w: 0} 对客户端的写入不需要发送任何确认,适用于性能要求高,但不关注正确性的场景
- {w: 1} 默认的writeConcern,数据写入到Primary就向客户端发送确认
- {w: "majority"} 数据写入到副本集大多数成员后向客户端发送确认,适用于对数据安全性要求比较高的场景,该选项会降低写入性能
j: <boolean> ,写入操作的journal持久化后才向客户端确认
- 默认为"{j: false},如果要求Primary写入持久化了才向客户端确认,则指定该选项为true
wtimeout: <millseconds>,写入超时时间,仅w的值大于1时有效。
- 当指定{w: }时,数据需要成功写入number个节点才算成功,如果写入过程中有节点故障,可能导致这个条件一直不能满足,从而一直不能向客户端发送确认结果,针对这种情况,客户端可设置wtimeout选项来指定超时时间,当写入过程持续超过该时间仍未结束,则认为写入失败。
{w: "majority"}解析
{w: 1}、{j: true}等writeConcern选项很好理解,Primary等待条件满足发送确认;但{w: "majority"}则相对复杂些,需要确认数据成功写入到大多数节点才算成功,而MongoDB的复制是通过Secondary不断拉取oplog并重放来实现的,并不是Primary主动将写入同步给Secondary,那么Primary是如何确认数据已成功写入到大多数节点的?
Client向Primary发起请求,指定writeConcern为{w: "majority"},Primary收到请求,本地写入并记录写请求到oplog,然后等待大多数节点都同步了这条/批oplog(Secondary应用完oplog会向主报告最新进度)。
Secondary拉取到Primary上新写入的oplog,本地重放并记录oplog。为了让Secondary能在第一时间内拉取到主上的oplog,find命令支持一个awaitData的选项,当find没有任何符合条件的文档时,并不立即返回,而是等待最多maxTimeMS(默认为2s)时间看是否有新的符合条件的数据,如果有就返回;所以当新写入oplog时,备立马能获取到新的oplog。
Secondary上有单独的线程,当oplog的最新时间戳发生更新时,就会向Primary发送replSetUpdatePosition命令更新自己的oplog时间戳。
当Primary发现有足够多的节点oplog时间戳已经满足条件了,向客户端发送确认。
- mongodb数据库迁移报错解决--writeConcern选项
- MongoDB WriteConcern
- MongoDB的WriteConcern 参数详解
- Laravel5.4的数据库迁移报错
- WriteConcern
- WriteConcern
- MongoDB readConcern readPreference writeConcern 原理解析
- 使用mongoDB的一些新的(mongoDB报错解决)
- 做Flask-Migrate数据库迁移 遇到了报错
- joomla迁移报错
- mongoDB常用命令和数据库迁移(亲测)
- 迁移mongodb数据库 版本3.0.6
- 【已解决】net start MongoDB报错:服务名无效
- 在恰当的地方使用MongoDB的WriteConcern.SAFE参数
- 在恰当的地方使用MongoDB的WriteConcern.SAFE参数
- 在恰当的地方使用MongoDB的WriteConcern.SAFE参数
- 在恰当的地方使用MongoDB的WriteConcern.SAFE参数
- 在恰当的地方使用MongoDB的WriteConcern.SAFE参数
- caffe--安装心得
- UVa11889 Benefit
- 记:STM32F205双USB开发做device
- 11个Java 开源 socket框架
- 算法Day2-三数之和
- mongodb数据库迁移报错解决--writeConcern选项
- OpenMP——共享编程知识点
- python3.4 信息门户登录请求
- 最小均方误差(MMSE)原理推导以及在MIMO系统中对性能的改善。
- 运动目标检测--三种方法比较
- Bootstrapping
- github提交和eclipse提交项目到多个git地址
- CH13,拍42,练习一。通过文本文件统计页面访问量
- 抢购倒计时制作