mongo之Wtire Concern(安全写级别)

The mongo shell and the MongoDB drivers use Acknowledged as the default write concern.
//mongo shell和monogdb驱动将Acknowledged 作为默认的写安全级别

Read Isolation(读隔离)
MongoDB allows clients to read documents inserted or modified before it commits these modifications to disk, 
regardless of write concern level or journaling configuration
//mongodb允许客户端读取插入或修改的文档,在文档写到磁盘之前。

For systems with multiple concurrent readers and writers, 
MongoDB will allow clients to read the results of a write operation before the write operation returns.
//在多并发的读写系统中,mongodb将允许客户端读取写操作的结果,在写操作返回之前。

If the mongod terminates before the journal commits, even if a write returns successfully, 
queries may have read data that will not exist after the mongod restarts.
//如果mongod在日志提交前中断了,尽管写操作返回成功,在重启mongod之后,数据将不存在。

For replica sets, write operations are durable only after a write replicates and commits 
to the journal of a majority of the voting members of the set.
MongoDB regularly commits data to the journal regardless of journaled write concern: 
use the commitIntervalMs to control how often a mongod commits the journal.
//对于复制集中,只有写操作复制并且提交到大多数的投票复制集成员,写操作才能继续。
//对于复制集中,mongodb定期提交数据到日志中不受Journaled安全写级别的控制,通过commitIntervalMs来控制提交日志的频率。

MongoDB does not “rollback” or undo modifications made before the wtimeout interval expired
//mongodb 不能撤销做出的修改在wtimeout超时到期前。

write Concern Levels(安全写级别分类):

1.Unacknowledged: {w: 0}
 Unacknowledged is similar to errors ignored; 
 however,drivers will attempt to receive and handle network errors when possible
//不确认 类似于忽略错误,但是Mongo的驱动会尝试接收和处理网络的错误

2.Acknowledged: {w: 1}
 With a receipt acknowledged write concern, 
 the mongod confirms that it received the write operation and applied the change to the in-memory view of data.
 Acknowledged write concern allows clients to catch network, duplicate key, and other errors.
 Acknowledged write concern does not confirm that the write operation has persisted to the disk system.
//mongod确保客户端接收到写操作返回的结果并将改变写入到数据内存区域中,
//Acknowledged级别不保证写操作是否写入到磁盘中,它是默认级别

3.Journaled: {w: 1, j: true}
With a journaled write concern, the MongoDB acknowledges the write operation only after committing the data to the journal
Specifying a write concern that includes j: true to a mongod or mongos running with --nojournal option now errors. Previous versions would ignore the j: true.

4.Replica Acknowledged: {w: 2} {w: "majority"}
The default write concern only requires acknowledgement from the primary.
With replica acknowledged write concern, you can guarantee that the write operation propagates to additional members of the replica set. 
See Write Concern for Replica Sets for more information.
Write operation to a replica set with write concern level of w:2 or write to the primary and at least one secondary.

Confirms that write operations have propagated to the majority of configured replica set: 
a majority of the set’s configured members must acknowledge the write operation before it succeeds. 
This allows you to avoid hard coding assumptions about the size of your replica set into your application.
Changed in version 2.6: In Master/Slave deployments, MongoDB treats w: "majority" as equivalent to w: 1. 
In earlier versions of MongoDB, w: "majority" produces an error in master/slave deployments.

最后附一下 这个参数的说明:
storage.journal.commitIntervalMs
Type: number
Default: 100 or 30
The maximum amount of time the mongod process allows between journal operations. Values can range from 2 to 300 milliseconds. 
Lower values increase the durability of the journal, at the expense of disk performance.
The default journal commit interval is 100 milliseconds if a single block device 
(e.g. physical volume, RAID device, or LVM volume) contains both the journal and the data files.
If the journal is on a different block device than the data files the default journal commit interval is 30 milliseconds.
To force mongod to commit to the journal more frequently, you can specify j:true. 
When a write operation with j:true is pending, mongod will reduce commitIntervalMs to a third of the set value.
The storage.journal.commitIntervalMs option is available only for mongod.

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
MongoDB中,Secondary节点默认是只读的,因为主要的入操作是由Primary节点执行的。如果您想让Secondary节点也能够执行操作,您可以将它们配置为“可入”节点。但是需要注意的是,这种配置会增加复制集的复杂性,并可能导致数据一致性问题。 如果您仍然希望进行此配置,您可以按照以下步骤进行操作: 1. 在Secondary节点上启用入操作: 在MongoDB Shell中执行以下命令: ``` rs.slaveOk() ``` 这个命令将启用Secondary节点的读能力。 2. 在Primary节点上配置Secondary节点的复制选项: 在Primary节点上执行以下命令: ``` rs.reconfig({ "members": [{ "_id": <id>, "host": "<hostname>", "priority": 0, "votes": 0 }] }) ``` 其中,<id>是Secondary节点的_id,<hostname>是Secondary节点的主机名。将“priority”设置为0并将“votes”设置为0会将Secondary节点配置为不可选举节点,并防止它成为新的Primary节点。 3. 在Secondary节点上配置复制选项: 在Secondary节点上执行以下命令: ``` rs.reconfig({ "members": [{ "_id": <id>, "host": "<hostname>", "priority": 0, "votes": 0, "slaveDelay": 0 }] }) ``` 其中,“slaveDelay”选项指定了延迟副本的时间。将其设置为0将使Secondary节点立即接收入操作。 请注意,在将Secondary节点配置为可入节点之前,请仔细考虑这样做的风险和后果,以确保您的数据安全和一致性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值