Database Reference
In-Depth Information
The first value, w , admits a few possible values, but usually indicates the total number
of servers that the latest write should be replicated to; the second is a timeout that
causes the command to return an error if the write can't be replicated in the specified
number of milliseconds.
For example, if you want to make sure that a given write is replicated to at least one
server, then you can indicate a w value of 2. If you want the operation to time out if this
level of replication isn't achieved in 500 ms, you include a wtimeout of 500. Note that
if you don't specify a value for wtimeout , and the replication for some reason never
occurs, then the operation will block indefinitely.
When using a driver, you enable write concern not by calling getLastError explic-
itly but rather by creating a write concern object or by setting the appropriate safe
mode option; it depends on the specific driver's API . 12 In Ruby, you can specify a write
concern on a single operation like so:
@collection.insert(doc, :safe => {:w => 2, :wtimeout => 200})
Sometimes you simply want to ensure that a write is replicated to a majority of avail-
able nodes. For this case, you can set a w value of majority :
@collection.insert(doc, :safe => {:w => "majority"})
Even fancier options exist. For instance, if you've enabled journaling, then you can
also force that the journal be synced to disk by adding the j option:
@collection.insert(doc, :safe => {:w => 2, :j => true})
Many drivers also support setting default write concern values for a given connection
or database. To find out how to set write concern in your particular case, check your
driver's documentation. A few more language examples can be found in appendix D.
Write concern works with both replica sets and master-slave replication. If you
examine the local databases, you'll see a couple collections, me on secondary nodes
and slaves on the primary node, that are used to implement write concern. Whenever
a secondary polls a primary, the primary makes a note of the latest oplog entry applied
to each secondary in its slaves collection. Thus, the primary knows what each second-
ary has replicated at all times and can therefore reliably answer the getlasterror com-
mand's write requests.
Keep in mind that using write concern with values of w greater than 1 will intro-
duce extra latency. Configurable write concern essentially allows you to make the
trade-off between speed and durability. If you're running with journaling, then a write
concern with w equal to 1 should be fine for most applications. On the other hand, for
logging or analytics, you might elect to disable journaling and write concern alto-
gether and rely solely on replication for durability, allowing that you may lose some
writes in the event of a failure. Consider these trade-offs carefully and test the differ-
ent scenarios when designing your application.
12
There are examples of setting write concern in Java, PHP, and C++ in appendix D.
Search WWH ::




Custom Search