You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we use acknowledged write concern, which does not confirm that the write operation has persisted to the disk system.
We could switch to journaled.
With a journaled write concern, the MongoDB acknowledges the write operation only after committing the data to the journal. This write concern ensures that MongoDB can recover the data following a shutdown or power interruption.
Additonally: We can ack for replica sets.
With replica acknowledged write concern, you can guarantee that the write operation propagates to additional members of the replica set (not only the primary server).
If we want to use replica acknowleged write concern, we could need additional options for the mongo adapter in the constructor (how many replicates and timeout).
Imho the journaled acknowlegement makes sence, since we don't want to lose information when there is a server crash following microseconds after we persisted an event when it's not yet written to disk. But do we need to have acks for distributing them across replicas?
The text was updated successfully, but these errors were encountered:
yeah, sounds like journaled is the best default. But would be great to allow the user to configure the writeConcern. Can we pass a WriteConcernOptions object as optional parameter to the constructor?
Supporting all options defined here: http://docs.mongodb.org/v3.0/reference/connection-string/#write-concern-options
In this case setting the WriteConcernOptions via a setter would also be ok because the adapter does not need them to function correctly.
Events are the only source of truth so I can imagine that some users want to use the replica set write concern.
ah the user could also configure the \MongoClient before passing it to the adapter. But yeah, in this case we can not default to journaled so 👍 for adding the WriteConcernOptions.
Currently we use acknowledged write concern, which does not confirm that the write operation has persisted to the disk system.
We could switch to journaled.
With a journaled write concern, the MongoDB acknowledges the write operation only after committing the data to the journal. This write concern ensures that MongoDB can recover the data following a shutdown or power interruption.
Additonally: We can ack for replica sets.
With replica acknowledged write concern, you can guarantee that the write operation propagates to additional members of the replica set (not only the primary server).
If we want to use replica acknowleged write concern, we could need additional options for the mongo adapter in the constructor (how many replicates and timeout).
For more information about this see:
http://docs.mongodb.org/v3.0/core/write-concern/
http://docs.mongodb.org/v3.0/core/replica-set-write-concern/
Imho the journaled acknowlegement makes sence, since we don't want to lose information when there is a server crash following microseconds after we persisted an event when it's not yet written to disk. But do we need to have acks for distributing them across replicas?
The text was updated successfully, but these errors were encountered: