mongodb数据库迁移报错解决--writeConcern选项

备份

./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  (故障恢复)

--writeConcern  <document>

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选项如下

  1. w: <number>,数据写入到number个节点才向用客户端确认

    • {w: 0} 对客户端的写入不需要发送任何确认,适用于性能要求高,但不关注正确性的场景
    • {w: 1} 默认的writeConcern,数据写入到Primary就向客户端发送确认
    • {w: "majority"} 数据写入到副本集大多数成员后向客户端发送确认,适用于对数据安全性要求比较高的场景,该选项会降低写入性能
  2. j: <boolean> ,写入操作的journal持久化后才向客户端确认

    • 默认为"{j: false},如果要求Primary写入持久化了才向客户端确认,则指定该选项为true
  3. wtimeout: <millseconds>,写入超时时间,仅w的值大于1时有效。

    • 当指定{w: }时,数据需要成功写入number个节点才算成功,如果写入过程中有节点故障,可能导致这个条件一直不能满足,从而一直不能向客户端发送确认结果,针对这种情况,客户端可设置wtimeout选项来指定超时时间,当写入过程持续超过该时间仍未结束,则认为写入失败。

{w: "majority"}解析

{w: 1}、{j: true}等writeConcern选项很好理解,Primary等待条件满足发送确认;但{w: "majority"}则相对复杂些,需要确认数据成功写入到大多数节点才算成功,而MongoDB的复制是通过Secondary不断拉取oplog并重放来实现的,并不是Primary主动将写入同步给Secondary,那么Primary是如何确认数据已成功写入到大多数节点的?

http://77g6ez.com1.z0.glb.clouddn.com/majority.png

  1. Client向Primary发起请求,指定writeConcern为{w: "majority"},Primary收到请求,本地写入并记录写请求到oplog,然后等待大多数节点都同步了这条/批oplog(Secondary应用完oplog会向主报告最新进度)。

  2. Secondary拉取到Primary上新写入的oplog,本地重放并记录oplog。为了让Secondary能在第一时间内拉取到主上的oplog,find命令支持一个awaitData的选项,当find没有任何符合条件的文档时,并不立即返回,而是等待最多maxTimeMS(默认为2s)时间看是否有新的符合条件的数据,如果有就返回;所以当新写入oplog时,备立马能获取到新的oplog。

  3. Secondary上有单独的线程,当oplog的最新时间戳发生更新时,就会向Primary发送replSetUpdatePosition命令更新自己的oplog时间戳。

  4. 当Primary发现有足够多的节点oplog时间戳已经满足条件了,向客户端发送确认。


对于 MongoDB 启动时出现的错误,可以尝试以下解决方案: 1. 检查配置文件路径:确保您提供的配置文件路径正确无误,并且配置文件存在于指定的位置。在您的命令中,确认 `~/softconfig/mongodb-macos-x86_64-6.0.8/mongodb.conf` 是否是正确的配置文件路径。 2. 检查配置文件内容:打开配置文件 `mongodb.conf`,确保其中的配置选项正确设置。特别注意以下几个常见的配置项: - `bindIp`:MongoDB 绑定的 IP 地址,可以尝试将其设置为 `0.0.0.0`,以允许所有 IP 地址连接到 MongoDB。 - `port`:MongoDB 监听的端口号,默认是 27017,确保该端口没有被其他进程占用。 - `dbpath`:MongoDB 数据库文件存储路径,确保该路径存在并且有正确的读写权限。 3. 检查日志文件:运行命令时,观察控制台输出的错误信息。如果有提供日志文件路径,可以查看相关日志文件,以获取更详细的错误信息。通常,MongoDB 的日志文件位于 `/var/log/mongodb/` 目录下。 4. 检查数据库文件权限:确保 MongoDB 数据库文件所在的目录具有正确的读写权限。可以尝试使用管理员权限运行启动命令。 5. 检查 MongoDB 版本和操作系统兼容性:确保您所使用的 MongoDB 版本与您的操作系统兼容。如果您的操作系统是最新版本,但 MongoDB 版本较旧,可能需要升级 MongoDB。 如果尝试了以上解决方案后仍然无法解决问题,建议您查阅 MongoDB 的官方文档、社区论坛或向 MongoDB 开发人员社区求助,以获得更具体的问题解决方案。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值