If any connection, in any direction fails, check your networking and firewall configuration and reconfigure your envi- ronment to allow these connections. 

## Socket Exceptions when Rebooting More than One Secondary 

When you reboot members of a replica set, ensure that the set is able to elect a primary during the maintenance. This means ensuring that a majority of the set’s ‘ votes are available. 

When a set’s active members can no longer form a majority, the set’s primary steps down and becomes a secondary . The former primary closes all open connections to client applications. Clients attempting to write to the former primary receive socket exceptions and Connection reset errors until the set can elect a primary. 

## Example 

Given a three-member replica set where every member has one vote, the set can elect a primary only as long as two members can connect to each other. If two you reboot the two secondaries once, the primary steps down and becomes a secondary. Until the at least one secondary becomes available, the set has no primary and cannot elect a new primary. 

For more information on votes, see Replica Set Elections (page 580). For related information on connection errors, see Does TCP keepalive time affect MongoDB Deployments? (page 779). 

## Check the Size of the Oplog 

A larger oplog can give a replica set a greater tolerance for lag, and make the set more resilient. 

To check the size of the oplog for a given replica set member, connect to the member in a mongo shell and run the rs.printReplicationInfo() method. 

The output displays the size of the oplog and the date ranges of the operations contained in the oplog. In the following example, the oplog is about 10MB and is able to fit about 26 hours (94400 seconds) of operations: 

configured oplog size: 10.10546875MB log length start to end: 94400 (26.22hrs) oplog first event time: Mon Mar 19 2012 13:50:38 GMT-0400 (EDT) oplog last event time: Wed Oct 03 2012 14:59:10 GMT-0400 (EDT) now: Wed Oct 03 2012 15:00:21 GMT-0400 (EDT) 

The oplog should be long enough to hold all transactions for the longest downtime you expect on a secondary. At a minimum, an oplog should be able to hold minimum 24 hours of operations; however, many users prefer to have 72 hours or even a week’s work of operations. 

For more information on how oplog size affects operations, see: 

• Oplog Size (page 593), 

• Delayed Replica Set Members (page 570), and 

• Check the Replication Lag (page 647). 

Note: You normally want the oplog to be the same size on all members. If you resize the oplog, resize it on all members. 

To change oplog size, see the Change the Size of the Oplog (page 628) tutorial. 

