## 11.6.9 Why use journaling if replication already provides data redundancy? 

Journaling facilitates faster crash recovery. Prior to journaling, crashes often required database repairs or full data resync. Both were slow, and the first was unreliable. 

Journaling is particularly useful for protection against power failures, especially if your replica set resides in a single data center or power circuit. 

When a replica set runs with journaling, mongod instances can safely restart without any administrator intervention. 

Note: Journaling requires some resource overhead for write operations. Journaling has no effect on read performance, however. 

Journaling is enabled by default on all 64-bit builds of MongoDB v2.0 and greater. 

## 11.6.10 Are write operations durable if write concern does not acknowledge writes? 

Yes. 

However, if you want confirmation that a given write has arrived at the server, use write concern (page 78). 

After the default write concern change (page 924), the default write concern acknowledges all write operations, and unacknowledged writes must be explicitly configured. See the http://docs.mongodb.org/manual/applications/drivers documentation for your driver for more information. 

Changed in version 2.6: The mongo shell now defaults to use safe writes (page 78). See Write Method Acknowledge- ments (page 857) for more information. 

A new protocol for write operations (page 852) integrates write concerns with the write operations. Previous versions issued a getLastError command after a write to specify a write concern. 

## 11.6.11 How many arbiters do replica sets need? 

Some configurations do not require any arbiter instances. Arbiters vote in elections for primary but do not replicate the data like secondary members. 

Replica sets require a majority of the remaining nodes present to elect a primary. Arbiters allow you to construct this majority without the overhead of adding replicating nodes to the system. 

There are many possible replica set architectures (page 572). 

A replica set with an odd number of voting nodes does not need an arbiter. 

A common configuration consists of two replicating nodes that include a primary and a secondary , as well as an arbiter for the third node. This configuration makes it possible for the set to elect a primary in the event of failure, without requiring three replicating nodes. 

You may also consider adding an arbiter to a set if it has an equal number of nodes in two facilities and network partitions between the facilities are possible. In these cases, the arbiter will break the tie between the two facilities and allow the set to elect a new primary. 

## See also: 

Replica Set Deployment Architectures (page 572) 

