Replication - MongoDB in Action - page 179

arbiter nodes. If an operation on the primary fails, then on subsequent requests, the
driver can attempt to connect to one of the remaining nodes until it can reconnect to
a primary.
It's important to keep in mind that although replica set failover is automatic, the
drivers don't attempt to hide the fact that a failover has occurred. The course of
events goes something like this: First, the primary fails or a new election takes place.
Subsequent requests will reveal that the socket connection has been broken, and the
driver will then raise a connection exception and close any open sockets to the data-
base. It's now up to the application developer to decide what happens next, and this
decision will depend on both the operation being performed and the specific needs
of the application.
Keeping in mind that the driver will automatically attempt to reconnect on any
subsequent request, let's imagine a couple of scenarios. First, suppose that you only
issue reads to the database. In this case, there's little harm in retrying a failed read
since there's no possibility of changing database state. But now imagine that you also
regularly write to the database. As stated many times before, you can write to the data-
base with and without safe mode enabled. With safe mode, the driver appends to each
write a call to the getlasterror command. This ensures that the write has arrived
safely and reports any server errors back to the application. Without safe mode, the
driver simply writes to the TCP socket.
If your application writes without safe mode and a failover occurs, then you're left
in an uncertain state. How many of the recent writes made it to the server? How many
were lost in the socket buffer? The indeterminate nature of writing to a TCP socket
makes answering these questions practically impossible. How big of a problem this is
depends on the application. For logging, non-safe-mode writes are probably accept-
able, since losing writes hardly changes the overall logging picture; but for users creat-
ing data in the application, non-safe-mode writes can be a disaster.
With safe mode enabled, only the most recent write is in question; it may have
arrived on the server, or it may not have. At times it'll be appropriate to retry the write,
and at other times an application error should be thrown. The drivers will always raise
an exception; developers can then decide how these exceptions are handled.
In any case, retrying an operation will cause the driver to attempt to reconnect to
the replica set. But since drivers will differ somewhat in their replica set connection
behavior, you should always consult your driver's documentation for specifics.

8.4.2 Write concern

It should be clear now that running in safe mode by default is reasonable for most
applications, as it's important to know that writes have arrived error-free at the pri-
mary server. But greater levels of assurance are frequently desired, and write concern
addresses this by allowing developers to specify the extent to which a write should be
replicated before allowing the application to continue on. Technically, you control
write concern via two parameters on the getlasterror command: w and wtimeout .