mongodb如何判断一次操作是否成功

关注

转载最新推荐文章于 2026-03-29 09:30:01 发布 8k 阅读 AI 写同款· GEO 优化 ›

【深度学习】肺结节分割项目实战二：分割肺实质在后续训练模型的时候如果直接使用原始的肺部CT图像，其中的非肺区域会对训练造成干扰，因此我们需要提取分割肺实质。这一部分参考了kaggle上的教程。从这张CT图像中可以看出扫描器以外的部分为黑色，背景和肺内部颜色较深，非肺组织和骨头颜色较浅。我们的目的是将肺部分割出来。由于肺部区域和其他部分对比明显，我们可以设置一个合适的阈值对图像中的区域进行隔离。 import argparse import os import numpy as np from medpy.filter.smoothing imp 阅读详情

MongoDB核心开发工程师 Kristina Chodorow（@kchodorow）最近在她的博客上表示，她会发表一系列关于MongoDB Replica Sets相关的文章，向大家详细的进行一次 Replica Sets的知识培训。其系列文章内容包括下面一些章节：

Elections（选举）
Creating a set（创建一个replica sets）
Reconfiguring（更新配置）
Syncing（同步）
Initial Sync（初始化同步）
Rollback（数据回滚）
Authentication（权限控制）
Debugging（故障排除）

本文主要对Replica Sets节点间的同步机制和同步协议进行了深入讲解。

同步过程

一个健康的secondary在运行时，会选择一个离自己最近的，数据比自己新的节点进行数据同步。选定节点后，它会从这个节点拉取oplog同步日志，具体流程是这样的：

执行这个op日志
将这个op日志写入到自己的oplog中(local.oplog.rs)
再请求下一个op日志

如果同步操作在第1步和第2步之间出现问题宕机，那么secondary再重新恢复后，会检查自己这边最新的oplog，由于第2步还没有执行，所以自己这边还没有这条写操作的日志。这时候他会再把刚才执行过的那个操作执行一次。那对同一个写操作执行两次会不会有问题呢？MongoDB在设计oplog时就考虑到了这一点，所以所有的oplog都是可以重复执行的，比如你执行 {$inc:{counter:1}} 对counter字段加1，counter字段在加1 后值为2，那么在oplog里并不会记录 {$inc:{counter:1}} 这个操作，而是记录 {$set:{counter:2}}这个操作。所以无论多少次执行同一个写操作，都不会出现问题。

w参数

当我们在MongoDB时执行一个写操作时，默认会直接返回成功，同时也可以通过设置w参数，指定这个写操作同步到几个节点后才返回成功。如下：

db.foo.runCommand({getLastError:1, w:2})

上面例子就是执行getLastError命令，使其在上一个写操作同步到两个节点上后再返回。不同的客户端可能在写法上不太一样，不过这个功能应该都是有的。对于重要数据，可以考虑采用这样的方式，通过牺牲一部分写性能来提升数据的安全性。

这个功能是如何实现的呢，primary节点是如何知道数据同步了几份呢？

在调用上面命令时，实际上MongoDB内部执行了如下的一些流程：

在primary上完成写操作
在primary上记录一条oplog日志，日志中包含一个ts字段，值为写操作执行的时间，比如本例中记为t
客户端调用{getLastError:1, w:2}命令等待primary返回结果
secondary从primary拉取oplog，获取到刚才那一次写操作的日志
secondary按获取到的日志执行相应的写操作
执行完成后，secondary再获取新的日志，其向primary上拉取oplog的条件为{ts:{$gt:t}}
primary此时收到secondary的请求，了解到secondary在请求时间大于t的写操作日志，所以他知道操作在t之前的日志都已经成功执行了
这时候getLastError命令检测到primary与secondary都完成了这次写操作，于是 w:2 的条件满足了，返回给客户端成功

启动初始化

当一个新节点启动并加入到现在的Replica Sets中时，这时候新启动的节点会查看自己的oplog，通过一个叫 lastOpTimeWritten 的命令查找到它最近的一条写操作。这个命令你也可以随便在命令行执行：

> rs.debug.getLastOpWritten()

这个命令会返回一条oplog记录，其中的ts字段就是最近一次写操作的时间了。

如果你这个节点是全新的，没有数据，那么oplog里也没有数据，这时候节点会选择执行一次全量的同步。本文暂时不对全量同步的方法进行描述。

选择同步源节点

Replica Sets中的节点之间总在同步数据，但是他们不是通过传统的一主多从的方式来同步的。MongoDB的策略是选择一个合适的节点作为数据源。

首先secondary节点会通过ping的时间来确定其它节点与它的距离。时间越长的识为距离越远。然后通过下面方法确定其源节点：

for each member that is healthy: if member[state] == PRIMARY add to set of possible sync targets if member[lastOpTimeWritten] > our[lastOpTimeWritten] add to set of possible sync targetssync target = member with the min ping time from the possible sync targets

对于节点是否healthy的判断，各个版本不同，但是其目的都是找出正常运转的节点。在2.0版本中，它的判断还包括了salve delay这个因素。

你可以通过运行db.adminCommand({replSetGetStatus:1})命令来查看当前的节点状况，在secondary上运行这个命令，你能看到syncingTo这个字段，这个字段的值就是这个secondary的同步源。（其实名字应该是叫syncingFrom，但是由于版本兼容的原因，沿用了这个错误的名字）

链式同步结构

上面对w参数的实现，讲解上比较简单，只讲了w为2的情况，但是当w更大时，由于我们并不是采用一主多从的方式进行同步。所以情况会复杂一些。

比如我们有节点A，为primary节点，然后B节点为secondary节点，它从A节点同步数据，同时又有secondary节点C，它从同是secondary的B节点同步数据。这样A->B->C之间就形成了一个链式的同步结构。如果我们设定w为3，那么A节点如何能知道C节点已经从B节点同步成功了呢？

这是通过oplog同步协议来实现的，我们用通俗的语言来解释一下oplog的同步协议。

当C从B同步数据时，C会在协议中对B说：我要从你这同步数据了，如果写操作有w参数的话，我的同步也算上吧。
然后B会回答说：我不是一个primary节点，我会把你的这个计数转到我的同步源上去。
然后B再对A打开一个新的连接，并且对A说：这个连接你就当成是C的吧，也算一个计数在w里。
这时候在A看来，就有两个连接连到他上面，一个是B，一个是虚拟的C，这两个连接都能报告他说完成了同步操作。

当一个写操作在A上执行后，B首先同步到这个操作的oplog，执行完后会告诉A，我执行完了。然后C同样从B上获取到B的oplog，也执行了这一条写操作，然后他告诉B，我执行完了，B在收到这个响应后，会通过刚才开通的虚拟通道跟A说，我是虚拟的C节点，我也完成写操作了。这时候A就知道，A、B、C三个节点都完成写操作了。w：3的条件满足，然后返回给调用getLastError的客户端，完成这次操作。

具体三个节点间的连接如下图：

C B A <====> <====> <---->

B和A之间有两条通道，双线那条是真正的同步连接，单线那条是一个虚拟连接。

新功能展望

上面就是当前的Replica Sets同步的内部实现，在后续这一块还会进行一些新特性的开发。在2.2版本中，我们会提供replSetSyncFrom命令，让用户可以手动设置一个secondary的同步源。使用方法大概是这样：

> db.adminCommand({replSetSyncFrom:"otherHost:27017"})

文章来源：http://blog.nosqlfan.com/html/3944.html

收录于