writeConcern
-
writeConcern决定一个写操作落在多少个节点上才算成功。writeConcern的取值包括:
- writeConcern 虽然会增加写操作延迟时间,但并不会显著增加集群压力,因此无论是否等待,写操作最终都会复制到所有节点上。设置writeConcern只是让写操作等待复制后再返回而已。
- 应对重要数据应该使用 {w:"majority"},普通数据可以应用 {w:1} 以确保最佳性能。
- 0:发起写操作,不关心是否成功;
-
1~集群最大数据节点数:写操作需要被复制到指定节点数才算成功;
- majority:写操作需要被复制到大多数节点上才算成功。
- 发起写操作的程序将阻塞到写操作复制完成,到达指定的节点数为止。
-
w默认行为
db.test.insert({count:1})
-
默认只写入主节点一个。
-
甚至默认情况下都不用写到盘里,内存里写完就返回了。
-
如下图所示,解释一下实现表示完成操作,虚线表示会异步进行结果就不保证了。
-
-
w: "majority" 大多数节点确认模式【推荐】
db.test.insert({count:1},{writeConcern:{w:"majority"}}) db.test.insert({count:1},{writeConcern:{w:3}}) db.test.insert({count:1},{writeConcern:{w:4}})
-
w: "all" 全部节点确认模式
-
弊端就是有一个节点挂了就会一直阻塞。
-
-
j:true
-
conf=rs.conf() conf.members[2].slaveDelay=5 # 延迟同步 conf.members[2].priority=0 # 关掉选举, 因为上一步设置了延迟同步,这个地方必须设置关掉;不然报错。 rs.reconfig(conf)
-
writeConcern 可以决定写操作到达多少个节点才算成功,journal 则定义如何才算成功。
-
取值包括:
- true,写操作要落到 journal 文件中才算成功;
- false,默认值,写操作到达内存即算作成功。
-
-
观察复制延迟下的写入,以及 timeout 参数
db.test.insert({count:1},{writeConcern:{w:3}}) db.test.insert({count:1},{writeConcern:{w:3,wtimeout:3000}}) # 为了防止节点挂掉,一直阻塞,可以设置返回一个超时的警告。 # 但是要注意,数据实际上写进去了,这里只是警告!!