MongoDB Documentation, Release 3.0.4 The C, C++, Perl, and PHP drivers, as well as the earlier versions of the Ruby, Python, and Node.JS drivers, discover and monitor replica set members serially, and thus are not suitable for use with large replica sets. The process that a primary member of a replica set uses to step down has the following changes: Replication Changes (page 805) in Compatibility Changes in MongoDB 3.0 (page 804) MongoDB 3.0 provides the following enhancements to sharded clusters: Sharded Cluster Setting (page 806) in Compatibility Changes in MongoDB 3.0 (page 804) 801 12.1. Current Stable Release • Improves visibility of balancer operations. sh.status() includes information about the state of the balancer. See sh.status() for details. • Provides a new writeConcern setting to configure the write concern (page 78) of chunk migration opera- tions. You can configure the writeConcern setting for the balancer (page 714) as well as for moveChunk and cleanupOrphaned commands. • Provides a more predictable read preference behavior. mongos instances no longer pin connections to members of replica sets when performing read operations. Instead, mongos reevaluates read preferences (page 588) for every operation to provide a more predictable read preference behavior when read preferences change. • Adds a new sh.removeTagRange() helper to improve management of sharded collections with tags. The new sh.removeTagRange() method acts as a complement to sh.addTagRange() . • For pre-existing collections on secondary members, MongoDB 3.0 no longer automatically builds missing _id indexes. • Stronger restrictions on Replica Set Configuration (page 652). For details, see Replica Set Configuration Vali- dation (page 805). • Definition of w: “majority” (page 130) write concern changed to mean majority of voting nodes. • Initial sync builds indexes more efficiently for each collection and applies oplog entries in batches using threads. • replSetStepDown now allows users to specify a secondaryCatchUpPeriodSecs parameter to spec- ify how long the primary should wait for a secondary to catch up before stepping down. • To help prevent rollbacks, the replSetStepDown will wait for an electable secondary to catch up to the state of the primary before stepping down. Previously, a primary would wait for a secondary to catch up to within 10 seconds of the primary (i.e. a secondary with a replication lag of 10 seconds or less) before stepping down. • Before stepping down, replSetStepDown will attempt to terminate long running user operations that would block the primary from stepping down, such as an index build, a write operation or a map-reduce job. Replica Set Step Down Behavior Changes Other Replica Set Operational Changes See also: Sharded Clusters See also: