How to set up a replicaset in MongoDB 
https://www.mongodb.com/docs/v5.0/replication/
Replication
2013-01-01
None
<div><section><div><p>On this page</p><ul><li><a href="#redundancy-and-data-availability"></a></li><li><a href="#replication-in-mongodb"></a></li><li><a href="#asynchronous-replication"></a></li><li><a href="#automatic-failover"></a></li><li><a href="#read-operations"></a></li><li><a href="#transactions"></a></li><li><a href="#change-streams"></a></li><li><a href="#additional-features"></a></li></ul></div><p>A <em>replica set</em> in MongoDB is a group of <a href="https://www.mongodb.com/docs/v5.0/reference/program/mongod/#mongodb-binary-bin.mongod"><code>mongod</code></a> processes
that maintain the same data set. Replica sets provide redundancy and
<a href="https://www.mongodb.com/docs/v5.0/reference/glossary/#std-term-high-availability">high availability</a>, and are the basis for all production
deployments. This section introduces replication in MongoDB as well as
the components and architecture of replica sets. The section also
provides tutorials for common tasks related to replica sets.</p><a href="https://www.mongodb.com/docs/atlas/tutorial/create-new-cluster/"></a><section><p>Replication provides redundancy and increases
<a href="https://www.mongodb.com/docs/v5.0/reference/glossary/#std-term-high-availability">data availability</a>. With
multiple copies of data on different database servers, replication
provides a level of fault tolerance against the loss of a single
database server.</p><p>In some cases, replication can provide increased read capacity as
clients can send read operations to different servers. Maintaining
copies of data in different data centers can increase data locality
and availability for distributed applications. You can also maintain
additional copies for dedicated purposes, such as disaster recovery,
reporting, or backup.</p></section><section><p>A replica set is a group of <a href="https://www.mongodb.com/docs/v5.0/reference/program/mongod/#mongodb-binary-bin.mongod"><code>mongod</code></a> instances that maintain
the same data set. A replica set contains several data bearing nodes
and optionally one arbiter node. Of the data bearing nodes, one and
only one member is deemed the primary node, while the other nodes are
deemed secondary nodes.</p><div><p><h2>Warning</h2></p><div><p>Each replica set node must belong to one, and only one, replica
set. Replica set nodes cannot belong to more than one replica set.</p></div></div><p>The <a href="https://www.mongodb.com/docs/v5.0/core/replica-set-primary/">primary node</a> receives all write
operations. A replica set can have only one primary capable of
confirming writes with <a href="https://www.mongodb.com/docs/v5.0/reference/write-concern/#mongodb-writeconcern-writeconcern.-majority-"><code>{ w: "majority" }</code></a>
write concern; although in some circumstances, another mongod instance
may transiently believe itself to also be primary.
<a href="#footnote-edge-cases-2-primaries">[1]</a> The primary records all changes to its data
sets in its operation log, i.e. <a href="https://www.mongodb.com/docs/v5.0/core/replica-set-oplog/">oplog</a>. For more information on primary node
operation, see <a href="https://www.mongodb.com/docs/v5.0/core/replica-set-primary/">Replica Set Primary.</a></p><div><p></p><p>click to enlarge</p></div><p>The <a href="https://www.mongodb.com/docs/v5.0/core/replica-set-secondary/">secondaries</a> replicate the
primary's oplog and apply the operations to their data sets such that
the secondaries' data sets reflect the primary's data set. If the
primary is unavailable, an eligible secondary will hold an election to
elect itself the new primary. For more information on secondary
members, see <a href="https://www.mongodb.com/docs/v5.0/core/replica-set-secondary/">Replica Set Secondary Members.</a></p><p></p><p>In some circumstances (such as you have a primary and a secondary but
cost constraints prohibit adding another secondary), you may choose to
add a <a href="https://www.mongodb.com/docs/v5.0/reference/program/mongod/#mongodb-binary-bin.mongod"><code>mongod</code></a> instance to a replica set as an
<a href="https://www.mongodb.com/docs/v5.0/core/replica-set-arbiter/">arbiter</a>. An arbiter participates in
<a href="https://www.mongodb.com/docs/v5.0/core/replica-set-elections/#std-label-replica-set-elections">elections</a> but does not hold data (i.e.
does not provide data redundancy). For more information on arbiters,
see <a href="https://www.mongodb.com/docs/v5.0/core/replica-set-arbiter/">Replica Set Arbiter.</a></p><p></p><p>An <a href="https://www.mongodb.com/docs/v5.0/core/replica-set-arbiter/">arbiter</a> will always be an arbiter
whereas a <a href="https://www.mongodb.com/docs/v5.0/core/replica-set-primary/">primary</a> may step down and
become a <a href="https://www.mongodb.com/docs/v5.0/core/replica-set-secondary/">secondary</a> and a
<a href="https://www.mongodb.com/docs/v5.0/core/replica-set-secondary/">secondary</a> may become the primary
during an election.</p></section><section><p>Secondaries replicate the primary's oplog and apply the operations to
their data sets asynchronously. By having the secondaries' data sets
reflect the primary's data set, the replica set can continue to
function despite the failure of one or more members.</p><p>For more information on replication mechanics, see
<a href="https://www.mongodb.com/docs/v5.0/core/replica-set-oplog/#std-label-replica-set-oplog">Replica Set Oplog</a> and <a href="https://www.mongodb.com/docs/v5.0/core/replica-set-sync/#std-label-replica-set-sync">Replica Set Data Synchronization.</a></p><section><p>Starting in version 4.2, secondary
members of a replica set now <a href="https://www.mongodb.com/docs/v5.0/core/replica-set-oplog/#std-label-slow-oplog-application">log oplog entries</a> that take longer than the slow operation
threshold to apply. These slow oplog messages:</p><ul><li><p>Are logged for the secondaries in the
<a href="https://www.mongodb.com/docs/v5.0/reference/program/mongod/#std-option-mongod.--logpath"><code>diagnostic log</code>.</a></p></li><li><p>Are logged under the <a href="https://www.mongodb.com/docs/v5.0/reference/log-messages/#mongodb-data-REPL"><code>REPL</code></a> component with the text
<code>applied op: &lt;oplog entry&gt; took &lt;num&gt;ms</code>.</p></li><li><p>Do not depend on the log levels (either at the system or component
level)</p></li><li><p>Do not depend on the profiling level.</p></li><li><p>Are affected by <a href="https://www.mongodb.com/docs/v5.0/reference/configuration-options/#mongodb-setting-operationProfiling.slowOpSampleRate"><code>slowOpSampleRate</code>.</a></p></li></ul><p>The profiler does not capture slow oplog entries.</p></section><section><p><a href="https://www.mongodb.com/docs/v5.0/reference/glossary/#std-term-replication-lag">Replication lag</a> is a delay between an operation on the
<a href="https://www.mongodb.com/docs/v5.0/reference/glossary/#std-term-primary">primary</a> and the application of that operation from the <a href="https://www.mongodb.com/docs/v5.0/reference/glossary/#std-term-oplog">oplog</a> to
the <a href="https://www.mongodb.com/docs/v5.0/reference/glossary/#std-term-secondary">secondary</a>. Some small delay period may be
acceptable, but significant problems emerge as replication lag grows,
including building cache pressure on the primary.</p><p>Starting in MongoDB 4.2, administrators can limit the rate at which
the primary applies its writes with the goal of keeping the <a href="https://www.mongodb.com/docs/v5.0/reference/command/replSetGetStatus/#mongodb-data-replSetGetStatus.optimes.lastCommittedOpTime"><code>majority
committed</code></a> lag under
a configurable maximum value <a href="https://www.mongodb.com/docs/v5.0/reference/parameters/#mongodb-parameter-param.flowControlTargetLagSeconds"><code>flowControlTargetLagSeconds</code>.</a></p><p>By default, flow control is <a href="https://www.mongodb.com/docs/v5.0/reference/parameters/#mongodb-parameter-param.enableFlowControl"><code>enabled</code>.</a></p><div><p><h2>Note</h2></p><div><p>For flow control to engage, the replica set/sharded cluster must
have: <a href="https://www.mongodb.com/docs/v5.0/reference/command/setFeatureCompatibilityVersion/#std-label-view-fcv">featureCompatibilityVersion (fCV)</a> of
<code>4.2</code> and read concern <a href="https://www.mongodb.com/docs/v5.0/reference/configuration-options/#mongodb-setting-replication.enableMajorityReadConcern"><code>majority enabled</code></a>. That is, enabled flow
control has no effect if fCV is not <code>4.2</code> or if read concern
majority is disabled.</p></div></div><p>With flow control enabled, as the lag grows close to the
<a href="https://www.mongodb.com/docs/v5.0/reference/parameters/#mongodb-parameter-param.flowControlTargetLagSeconds"><code>flowControlTargetLagSeconds</code></a>, writes on the primary must obtain
tickets before taking locks to apply writes. By limiting the number of
tickets issued per second, the flow control mechanism attempts to keep
the lag under the target.</p><p>For more information, see <a href="https://www.mongodb.com/docs/v5.0/tutorial/troubleshoot-replica-sets/#std-label-replica-set-replication-lag">Check the Replication Lag</a> and
<a href="https://www.mongodb.com/docs/v5.0/tutorial/troubleshoot-replica-sets/#std-label-flow-control">Flow Control.</a></p></section></section><section><p>When a primary does not communicate with the other members of the set
for more than the configured <a href="https://www.mongodb.com/docs/v5.0/reference/replica-configuration/#mongodb-rsconf-rsconf.settings.electionTimeoutMillis"><code>electionTimeoutMillis</code></a>
period (10 seconds by default), an eligible secondary calls for an
election to nominate itself as the new primary. The cluster attempts to
complete the election of a new primary and resume normal operations.</p><div><p></p><p>click to enlarge</p></div><p>The replica set cannot process write operations
until the election completes successfully. The replica set can continue
to serve read queries if such queries are configured to
<a href="https://www.mongodb.com/docs/v5.0/core/read-preference/#std-label-replica-set-read-preference">run on secondaries</a> while the
primary is offline.</p><p>The median time before a cluster elects a new primary should not
typically exceed 12 seconds, assuming default <a href="https://www.mongodb.com/docs/v5.0/reference/replica-configuration/#mongodb-rsconf-rsconf.settings"><code>replica
configuration settings</code></a>. This includes time required to
mark the primary as <a href="#std-label-replication-auto-failover"></a> and
call and complete an <a href="https://www.mongodb.com/docs/v5.0/core/replica-set-elections/#std-label-replica-set-elections">election</a>.
You can tune this time period by modifying the
<a href="https://www.mongodb.com/docs/v5.0/reference/replica-configuration/#mongodb-rsconf-rsconf.settings.electionTimeoutMillis"><code>settings.electionTimeoutMillis</code></a> replication configuration
option. Factors such as network latency may extend the time required
for replica set elections to complete, which in turn affects the amount
of time your cluster may operate without a primary. These factors are
dependent on your particular cluster architecture.</p><p>Lowering the <a href="https://www.mongodb.com/docs/v5.0/reference/replica-configuration/#mongodb-rsconf-rsconf.settings.electionTimeoutMillis"><code>electionTimeoutMillis</code></a>
replication configuration option from the default <code>10000</code> (10 seconds)
can result in faster detection of primary failure. However,
the cluster may call elections more frequently due to factors such as
temporary network latency even if the primary is otherwise healthy.
This can result in increased <a href="https://www.mongodb.com/docs/v5.0/core/replica-set-rollbacks/#std-label-replica-set-rollback">rollbacks</a> for
<a href="https://www.mongodb.com/docs/v5.0/reference/write-concern/#std-label-wc-w">w : 1</a> write operations.</p><p>Your application connection logic should include tolerance for automatic
failovers and the subsequent elections. MongoDB drivers
can detect the loss of the primary and automatically
<a href="https://www.mongodb.com/docs/v5.0/core/retryable-writes/#std-label-retryable-writes">retry certain write operations</a> a single time,
providing additional built-in handling of automatic failovers and elections:</p><p>Compatible drivers enable retryable writes by default</p><p>MongoDB provides <a href="#std-label-mirrored-reads"></a> to pre-warm electable
secondary members' cache with the most recently accessed data. Pre-warming the
cache of a secondary can help restore performance more quickly after an
election.</p><p>To learn more about MongoDB’s failover process, see:</p><ul><li><p><a href="https://www.mongodb.com/docs/v5.0/core/replica-set-elections/#std-label-replica-set-elections">Replica Set Elections</a></p></li><li><p><a href="https://www.mongodb.com/docs/v5.0/core/retryable-writes/#std-label-retryable-writes">Retryable Writes</a></p></li><li><p><a href="https://www.mongodb.com/docs/v5.0/core/replica-set-rollbacks/#std-label-replica-set-rollback">Rollbacks During Replica Set Failover</a></p></li></ul></section><section><section><p>By default, clients read from the primary <a href="#footnote-edge-cases-2-primaries">[1]</a>;
however, clients can specify a <a href="https://www.mongodb.com/docs/v5.0/core/read-preference/">read preference</a> to send read operations to secondaries.</p><div><p></p><p>click to enlarge</p></div><p><a href="#std-label-asynchronous-replication"></a> to
secondaries means that reads from secondaries may return data that does
not reflect the state of the data on the primary.</p><p><a href="https://www.mongodb.com/docs/v5.0/core/transactions/#std-label-transactions">Distributed transactions</a> that contain
read operations must use read preference <a href="https://www.mongodb.com/docs/v5.0/core/read-preference/#mongodb-readmode-primary"><code>primary</code></a>. All
operations in a given transaction must route to the same member.</p><p>For information on reading from replica sets, see
<a href="https://www.mongodb.com/docs/v5.0/core/read-preference/">Read Preference.</a></p></section><section><p>Depending on the read concern, clients can see the results of writes
before the writes are <a href="https://www.mongodb.com/docs/v5.0/reference/glossary/#std-term-durable">durable:</a></p><ul><li><p>Regardless of a write's <a href="https://www.mongodb.com/docs/v5.0/reference/write-concern/">write concern</a>, other
clients using <a href="https://www.mongodb.com/docs/v5.0/reference/read-concern-local/#mongodb-readconcern-readconcern.-local-"><code>"local"</code></a> or <a href="https://www.mongodb.com/docs/v5.0/reference/read-concern-available/#mongodb-readconcern-readconcern.-available-"><code>"available"</code></a>
read concern can see the result of a write operation before the write
operation is acknowledged to the issuing client.</p></li><li><p>Clients using <a href="https://www.mongodb.com/docs/v5.0/reference/read-concern-local/#mongodb-readconcern-readconcern.-local-"><code>"local"</code></a> or <a href="https://www.mongodb.com/docs/v5.0/reference/read-concern-available/#mongodb-readconcern-readconcern.-available-"><code>"available"</code></a>
read concern can read data which may be subsequently <a href="https://www.mongodb.com/docs/v5.0/core/replica-set-rollbacks/">rolled
back</a> during replica set failovers.</p></li></ul><p>For operations in a <a href="https://www.mongodb.com/docs/v5.0/core/transactions/">multi-document transaction</a>, when a transaction commits, all data changes
made in the transaction are saved and visible outside the transaction.
That is, a transaction will not commit some of its changes while
rolling back others.</p><p>Until a transaction commits, the data changes made in the
transaction are not visible outside the transaction.</p><p>However, when a transaction writes to multiple shards, not all
outside read operations need to wait for the result of the committed
transaction to be visible across the shards. For example, if a
transaction is committed and write 1 is visible on shard A but write
2 is not yet visible on shard B, an outside read at read concern
<a href="https://www.mongodb.com/docs/v5.0/reference/read-concern-local/#mongodb-readconcern-readconcern.-local-"><code>"local"</code></a> can read the results of write 1 without
seeing write 2.</p><p>For more information on read isolations, consistency and recency for
MongoDB, see <a href="https://www.mongodb.com/docs/v5.0/core/read-isolation-consistency-recency/">Read Isolation, Consistency, and Recency.</a></p></section><section><p>Mirrored reads reduce the impact of primary elections following an
outage or planned maintenance. After a <a href="https://www.mongodb.com/docs/v5.0/reference/glossary/#std-term-failover">failover</a> in a replica
set, the secondary that takes over as the new primary updates its cache
as new queries come in. While the cache is warming up performance can be
impacted.</p><p>Mirrored reads pre-warm the caches of <a href="https://www.mongodb.com/docs/v5.0/reference/replica-configuration/#mongodb-rsconf-rsconf.members-n-.priority"><code>electable</code></a>
secondary replica set members. To pre-warm the caches of electable secondaries,
the primary mirrors a sample of the <a href="#std-label-mirrored-reads-supported-operations"></a> it receives to electable
secondaries.</p><p>The size of the subset of <a href="https://www.mongodb.com/docs/v5.0/reference/replica-configuration/#mongodb-rsconf-rsconf.members-n-.priority"><code>electable</code></a>
secondary replica set members that receive mirrored reads can be
configured with the <a href="https://www.mongodb.com/docs/v5.0/reference/parameters/#mongodb-parameter-param.mirrorReads"><code>mirrorReads</code></a>
parameter. See <a href="#std-label-mirrored-reads-parameters"></a> for further details.</p><div><p><h2>Note</h2></p><div><p>Mirrored reads do not affect the primary's response to the client.
The reads that the primary mirrors to secondaries are
"fire-and-forget" operations. The primary doesn't await responses.</p></div></div><section><p>Mirrored reads support the following operations:</p><ul><li><p><a href="https://www.mongodb.com/docs/v5.0/reference/command/count/#mongodb-dbcommand-dbcmd.count"><code>count</code></a></p></li><li><p><a href="https://www.mongodb.com/docs/v5.0/reference/command/distinct/#mongodb-dbcommand-dbcmd.distinct"><code>distinct</code></a></p></li><li><p><a href="https://www.mongodb.com/docs/v5.0/reference/command/find/#mongodb-dbcommand-dbcmd.find"><code>find</code></a></p></li><li><p><a href="https://www.mongodb.com/docs/v5.0/reference/command/findAndModify/#mongodb-dbcommand-dbcmd.findAndModify"><code>findAndModify</code></a> (Specifically, the filter is sent as a
mirrored read)</p></li><li><p><a href="https://www.mongodb.com/docs/v5.0/reference/command/update/#mongodb-dbcommand-dbcmd.update"><code>update</code></a> (Specifically, the filter is sent as a mirrored
read)</p></li></ul></section><section><p>Mirrored reads are enabled by default and use a default
<a href="https://www.mongodb.com/docs/v5.0/reference/parameters/#mongodb-parameter-param.mirrorReads"><code>sampling rate</code></a> of <code>0.01</code>. To disable
mirrored reads, set the <a href="https://www.mongodb.com/docs/v5.0/reference/parameters/#mongodb-parameter-param.mirrorReads"><code>mirrorReads</code></a> parameter to <code>{
samplingRate: 0.0 }</code>:</p><div><pre><code><table><tbody><tr><td>db.( {</td></tr><tr><td> : ,</td></tr><tr><td> : { : }</td></tr><tr><td>} )</td></tr></tbody></table></code></pre></div><p>With a sampling rate greater than <code>0.0</code>, the primary mirrors
<a href="#std-label-mirrored-reads-supported-operations"></a> to a subset
of <a href="https://www.mongodb.com/docs/v5.0/reference/replica-configuration/#mongodb-rsconf-rsconf.members-n-.priority"><code>electable</code></a> secondaries. With a sampling rate
of <code>0.01</code>, the primary mirrors one percent of the supported reads it receives
to a selection of electable secondaries.</p><p>For example, consider a replica set that consists of one primary and two
electable secondaries. If the primary receives <code>1000</code> operations that can be
mirrored and the sampling rate is <code>0.01</code>, the primary mirrors about <code>10</code>
supported reads to electable secondaries. Each electable secondary receives only
a fraction of the 10 reads. The primary sends each mirrored read to a randomly
chosen, non-empty selection of electable secondaries.</p></section><section><p>To change the sampling rate for mirrored reads, set the
<a href="https://www.mongodb.com/docs/v5.0/reference/parameters/#mongodb-parameter-param.mirrorReads"><code>mirrorReads</code></a> parameter to a number between <code>0.0</code> and
<code>1.0</code>:</p><ul><li><p>A sampling rate of <code>0.0</code> disables mirrored reads.</p></li><li><p>A sampling rate of a number between <code>0.0</code> and <code>1.0</code> results in
the primary forwarding a random sample of the <a href="#std-label-mirrored-reads-supported-operations"></a> at the specified sample rate to
electable secondaries.</p></li><li><p>A sampling rate of <code>1.0</code> results in the primary forwarding all
<a href="#std-label-mirrored-reads-supported-operations"></a> to
electable secondaries.</p></li></ul><p>For details, see <a href="https://www.mongodb.com/docs/v5.0/reference/parameters/#mongodb-parameter-param.mirrorReads"><code>mirrorReads</code>.</a></p></section><section><p>The <a href="https://www.mongodb.com/docs/v5.0/reference/command/serverStatus/#mongodb-dbcommand-dbcmd.serverStatus"><code>serverStatus</code></a> command and the <a href="https://www.mongodb.com/docs/v5.0/reference/method/db.serverStatus/#mongodb-method-db.serverStatus"><code>db.serverStatus()</code></a>
shell method return <a href="https://www.mongodb.com/docs/v5.0/reference/command/serverStatus/#mongodb-serverstatus-serverstatus.mirroredReads"><code>mirroredReads</code></a> metrics if you specify the
field in the operation:</p><div><pre><code><p>db.( { : } )</p></code></pre></div></section></section></section><section><p>Starting in MongoDB 4.0, <a href="https://www.mongodb.com/docs/v5.0/core/transactions/">multi-document transactions</a> are available for replica sets.</p><p><a href="https://www.mongodb.com/docs/v5.0/core/transactions/#std-label-transactions">Distributed transactions</a> that contain
read operations must use read preference <a href="https://www.mongodb.com/docs/v5.0/core/read-preference/#mongodb-readmode-primary"><code>primary</code></a>. All
operations in a given transaction must route to the same member.</p><p>Until a transaction commits, the data changes made in the
transaction are not visible outside the transaction.</p><p>However, when a transaction writes to multiple shards, not all
outside read operations need to wait for the result of the committed
transaction to be visible across the shards. For example, if a
transaction is committed and write 1 is visible on shard A but write
2 is not yet visible on shard B, an outside read at read concern
<a href="https://www.mongodb.com/docs/v5.0/reference/read-concern-local/#mongodb-readconcern-readconcern.-local-"><code>"local"</code></a> can read the results of write 1 without
seeing write 2.</p></section><section><p>Starting in MongoDB 3.6, <a href="https://www.mongodb.com/docs/v5.0/changeStreams/">change streams</a> are
available for replica sets and sharded clusters. Change streams allow
applications to access real-time data changes without the complexity
and risk of tailing the oplog. Applications can use change streams to
subscribe to all data changes on a collection or collections.</p></section><section><p>Replica sets provide a number of options to support application
needs. For example, you may deploy a replica set with <a href="https://www.mongodb.com/docs/v5.0/core/replica-set-architecture-geographically-distributed/">members in
multiple data centers</a>, or
control the outcome of elections by adjusting the
<a href="https://www.mongodb.com/docs/v5.0/reference/replica-configuration/#mongodb-rsconf-rsconf.members-n-.priority"><code>members[n].priority</code></a> of some
members. Replica sets also support dedicated members for reporting,
disaster recovery, or backup functions.</p><p>See <a href="https://www.mongodb.com/docs/v5.0/core/replica-set-priority-0-member/#std-label-replica-set-secondary-only-members">Priority 0 Replica Set Members</a>,
<a href="https://www.mongodb.com/docs/v5.0/core/replica-set-hidden-member/#std-label-replica-set-hidden-members">Hidden Replica Set Members</a> and
<a href="https://www.mongodb.com/docs/v5.0/core/replica-set-delayed-member/#std-label-replica-set-delayed-members">Delayed Replica Set Members</a> for more information.</p></section></section></div>||||I|||| Documentation
 * General Information
 * Documentation
 * Developer Articles & Topics
 * Community Forums
 * Blog
 * University
 * Products
 Platform
 Atlas Build on a developer data platform
 Platform Services
 Database Deploy a multi-cloud database Search Deliver engaging search experiences Vector Search Design intelligent apps with GenAI Stream Processing (Preview) Unify data in motion and data at rest
 Tools
 Compass Work with MongoDB data in a GUI Integrations Integrations with third-party services Relational Migrator Migrate to MongoDB with confidence
 Self Managed
 Enterprise Advanced Run and manage MongoDB yourself Community Edition Develop locally with MongoDB
 Build with MongoDB Atlas
 Get started for free in minutes
 Sign Up
 Test Enterprise Advanced
 Develop with MongoDB on-premises
 Download
 Try Community Edition
 Explore the latest version of MongoDB
 Download
 * Resources
 Documentation
 Atlas Documentation Get started using Atlas Server Documentation Learn to use MongoDB Start With Guides Get step-by-step guidance for key tasks
 Tools and Connectors Learn how to connect to MongoDB MongoDB Drivers Use drivers and libraries for MongoDB
 AI Resources Hub Get help building the next big thing in AI with MongoDB
 Connect
 Developer Center Explore a wide range of developer resources Community Join a global community of developers Courses and Certification Learn for free from MongoDB Webinars and Events Find a webinar or event near you
 * Solutions
 Use cases
 Artificial Intelligence Edge Computing Internet of Things Mobile Payments Serverless Development
 Industries
 Financial Services Telecommunications Healthcare Retail Public Sector Manufacturing
 Solutions Library Organized and tailored solutions to kick-start projects
 Developer Data Platform
 Accelerate innovation at scale
 Learn more
 Startups and AI Innovators
 For world-changing ideas and AI pioneers
 Learn more
 Customer Case Studies
 Hear directly from our users
 See Stories
 * Company
 Careers Start your next adventure Blog Read articles and announcements Newsroom Read press releases and news stories
 Partners Learn about our partner ecosystem Leadership Meet our executive team Company Learn more about who we are
 Contact Us
 Reach out to MongoDB
 Let’s chat
 Investors
 Visit our investor portal
 Learn more
 * Pricing
 Support Sign In
 Try Free
 Docs Menu
 * MongoDB Documentation
 * Back to Develop Applications
 * MongoDB Manual
 5.0
 * What is MongoDB?
 * Introduction
 * Installation
 * MongoDB Shell (mongosh)
 * MongoDB CRUD Operations
 * Aggregation Operations
 * Indexes
 * Atlas Search
 * Atlas Vector Search
 * Time Series Collections
 * Change Streams
 * Transactions
 * Data Models
 * Replication
 * Replica Set Members
 * Replica Set Oplog
 * Replica Set Data Synchronization
 * Replica Set Deployment Architectures
 * Replica Set High Availability
 * Replica Set Read and Write Semantics
 * Replica Set Deployment Tutorials
 * Member Configuration Tutorials
 * Replica Set Maintenance Tutorials
 * Replication Reference
 * Sharding
 * Storage
 * Administration
 * Security
 * Frequently Asked Questions
 * Reference
 * Release Notes
 * Technical Support
 * Introduction
 * Installation
 * MongoDB Shell (mongosh)
 * MongoDB CRUD Operations
 * Aggregation Operations
 * Indexes
 * Atlas Search
 * Atlas Vector Search
 * Time Series Collections
 * Change Streams
 * Transactions
 * Data Models
 * Replication
 * Sharding
 * Storage
 * Administration
 * Security
 * Frequently Asked Questions
 * Reference
 * Release Notes
 * Technical Support

 Docs Home → Develop Applications → MongoDB Manual

 Replication

 On this page

 * Redundancy and Data Availability
 * Replication in MongoDB
 * Asynchronous Replication
 * Automatic Failover
 * Read Operations
 * Transactions
 * Change Streams
 * Additional Features

 A replica set in MongoDB is a group of mongod processes that maintain the same data set. Replica sets provide redundancy and high availability, and are the basis for all production deployments. This section introduces replication in MongoDB as well as the components and architecture of replica sets. The section also provides tutorials for common tasks related to replica sets.

 You can deploy a replica set in the UI for deployments hosted in MongoDB Atlas .

 Redundancy and Data Availability

 Replication provides redundancy and increases data availability. With multiple copies of data on different database servers, replication provides a level of fault tolerance against the loss of a single database server.

 In some cases, replication can provide increased read capacity as clients can send read operations to different servers. Maintaining copies of data in different data centers can increase data locality and availability for distributed applications. You can also maintain additional copies for dedicated purposes, such as disaster recovery, reporting, or backup.

 Replication in MongoDB

 A replica set is a group of mongod instances that maintain the same data set. A replica set contains several data bearing nodes and optionally one arbiter node. Of the data bearing nodes, one and only one member is deemed the primary node, while the other nodes are deemed secondary nodes.

 Warning

 Each replica set node must belong to one, and only one, replica set. Replica set nodes cannot belong to more than one replica set.

 The primary node receives all write operations. A replica set can have only one primary capable of confirming writes with { w: "majority" } write concern; although in some circumstances, another mongod instance may transiently believe itself to also be primary. [1] The primary records all changes to its data sets in its operation log, i.e. oplog. For more information on primary node operation, see Replica Set Primary.

 click to enlarge

 The secondaries replicate the primary's oplog and apply the operations to their data sets such that the secondaries' data sets reflect the primary's data set. If the primary is unavailable, an eligible secondary will hold an election to elect itself the new primary. For more information on secondary members, see Replica Set Secondary Members.

 In some circumstances (such as you have a primary and a secondary but cost constraints prohibit adding another secondary), you may choose to add a mongod instance to a replica set as an arbiter. An arbiter participates in elections but does not hold data (i.e. does not provide data redundancy). For more information on arbiters, see Replica Set Arbiter.

 An arbiter will always be an arbiter whereas a primary may step down and become a secondary and a secondary may become the primary during an election.

 Asynchronous Replication

 Secondaries replicate the primary's oplog and apply the operations to their data sets asynchronously. By having the secondaries' data sets reflect the primary's data set, the replica set can continue to function despite the failure of one or more members.

 For more information on replication mechanics, see Replica Set Oplog and Replica Set Data Synchronization.

 Slow Operations

 Starting in version 4.2, secondary members of a replica set now log oplog entries that take longer than the slow operation threshold to apply. These slow oplog messages:

 * Are logged for the secondaries in the diagnostic log.

 * Are logged under the REPL component with the text applied op: <oplog entry> took <num>ms.

 * Do not depend on the log levels (either at the system or component level)

 * Do not depend on the profiling level.

 * Are affected by slowOpSampleRate.

 The profiler does not capture slow oplog entries.

 Replication Lag and Flow Control

 Replication lag is a delay between an operation on the primary and the application of that operation from the oplog to the secondary. Some small delay period may be acceptable, but significant problems emerge as replication lag grows, including building cache pressure on the primary.

 Starting in MongoDB 4.2, administrators can limit the rate at which the primary applies its writes with the goal of keeping the majority committed lag under a configurable maximum value flowControlTargetLagSeconds.

 By default, flow control is enabled.

 Note

 For flow control to engage, the replica set/sharded cluster must have: featureCompatibilityVersion (fCV) of 4.2 and read concern majority enabled. That is, enabled flow control has no effect if fCV is not 4.2 or if read concern majority is disabled.

 With flow control enabled, as the lag grows close to the flowControlTargetLagSeconds, writes on the primary must obtain tickets before taking locks to apply writes. By limiting the number of tickets issued per second, the flow control mechanism attempts to keep the lag under the target.

 For more information, see Check the Replication Lag and Flow Control.

 Automatic Failover

 When a primary does not communicate with the other members of the set for more than the configured electionTimeoutMillis period (10 seconds by default), an eligible secondary calls for an election to nominate itself as the new primary. The cluster attempts to complete the election of a new primary and resume normal operations.

 click to enlarge

 The replica set cannot process write operations until the election completes successfully. The replica set can continue to serve read queries if such queries are configured to run on secondaries while the primary is offline.

 The median time before a cluster elects a new primary should not typically exceed 12 seconds, assuming default replica configuration settings. This includes time required to mark the primary as unavailable and call and complete an election. You can tune this time period by modifying the settings.electionTimeoutMillis replication configuration option. Factors such as network latency may extend the time required for replica set elections to complete, which in turn affects the amount of time your cluster may operate without a primary. These factors are dependent on your particular cluster architecture.

 Lowering the electionTimeoutMillis replication configuration option from the default 10000 (10 seconds) can result in faster detection of primary failure. However, the cluster may call elections more frequently due to factors such as temporary network latency even if the primary is otherwise healthy. This can result in increased rollbacks for w : 1 write operations.

 Your application connection logic should include tolerance for automatic failovers and the subsequent elections. MongoDB drivers can detect the loss of the primary and automatically retry certain write operations a single time, providing additional built-in handling of automatic failovers and elections:

 Compatible drivers enable retryable writes by default

 MongoDB provides mirrored reads to pre-warm electable secondary members' cache with the most recently accessed data. Pre-warming the cache of a secondary can help restore performance more quickly after an election.

 To learn more about MongoDB’s failover process, see:

 * Replica Set Elections

 * Retryable Writes

 * Rollbacks During Replica Set Failover

 Read Operations

 Read Preference

 By default, clients read from the primary [1]; however, clients can specify a read preference to send read operations to secondaries.

 click to enlarge

 Asynchronous replication to secondaries means that reads from secondaries may return data that does not reflect the state of the data on the primary.

 Distributed transactions that contain read operations must use read preference primary. All operations in a given transaction must route to the same member.

 For information on reading from replica sets, see Read Preference.

 Data Visibility

 Depending on the read concern, clients can see the results of writes before the writes are durable:

 * Regardless of a write's write concern, other clients using "local" or "available" read concern can see the result of a write operation before the write operation is acknowledged to the issuing client.

 * Clients using "local" or "available" read concern can read data which may be subsequently rolled back during replica set failovers.

 For operations in a multi-document transaction, when a transaction commits, all data changes made in the transaction are saved and visible outside the transaction. That is, a transaction will not commit some of its changes while rolling back others.

 Until a transaction commits, the data changes made in the transaction are not visible outside the transaction.

 However, when a transaction writes to multiple shards, not all outside read operations need to wait for the result of the committed transaction to be visible across the shards. For example, if a transaction is committed and write 1 is visible on shard A but write 2 is not yet visible on shard B, an outside read at read concern "local" can read the results of write 1 without seeing write 2.

 For more information on read isolations, consistency and recency for MongoDB, see Read Isolation, Consistency, and Recency.

 Mirrored Reads

 Mirrored reads reduce the impact of primary elections following an outage or planned maintenance. After a failover in a replica set, the secondary that takes over as the new primary updates its cache as new queries come in. While the cache is warming up performance can be impacted.

 Mirrored reads pre-warm the caches of electable secondary replica set members. To pre-warm the caches of electable secondaries, the primary mirrors a sample of the supported operations it receives to electable secondaries.

 The size of the subset of electable secondary replica set members that receive mirrored reads can be configured with the mirrorReads parameter. See Enable/Disable Support for Mirrored Reads for further details.

 Note

 Mirrored reads do not affect the primary's response to the client. The reads that the primary mirrors to secondaries are "fire-and-forget" operations. The primary doesn't await responses.

 Supported Operations

 Mirrored reads support the following operations:

 * count

 * distinct

 * find

 * findAndModify (Specifically, the filter is sent as a mirrored read)

 * update (Specifically, the filter is sent as a mirrored read)

 Enable/Disable Support for Mirrored Reads

 Mirrored reads are enabled by default and use a default sampling rate of 0.01. To disable mirrored reads, set the mirrorReads parameter to { samplingRate: 0.0 }:

 db.adminCommand( { 
 setParameter: 1, 
 mirrorReads: { samplingRate: 0.0 }
 } ) 
 

 With a sampling rate greater than 0.0, the primary mirrors supported reads to a subset of electable secondaries. With a sampling rate of 0.01, the primary mirrors one percent of the supported reads it receives to a selection of electable secondaries.

 For example, consider a replica set that consists of one primary and two electable secondaries. If the primary receives 1000 operations that can be mirrored and the sampling rate is 0.01, the primary mirrors about 10 supported reads to electable secondaries. Each electable secondary receives only a fraction of the 10 reads. The primary sends each mirrored read to a randomly chosen, non-empty selection of electable secondaries.

 Change the Sampling Rate for Mirrored Reads

 To change the sampling rate for mirrored reads, set the mirrorReads parameter to a number between 0.0 and 1.0:

 * A sampling rate of 0.0 disables mirrored reads.

 * A sampling rate of a number between 0.0 and 1.0 results in the primary forwarding a random sample of the supported reads at the specified sample rate to electable secondaries.

 * A sampling rate of 1.0 results in the primary forwarding all supported reads to electable secondaries.

 For details, see mirrorReads.

 Mirrored Reads Metrics

 The serverStatus command and the db.serverStatus() shell method return mirroredReads metrics if you specify the field in the operation:

 db.serverStatus( { mirroredReads: 1 } )
 

 Transactions

 Starting in MongoDB 4.0, multi-document transactions are available for replica sets.

 Distributed transactions that contain read operations must use read preference primary. All operations in a given transaction must route to the same member.

 Until a transaction commits, the data changes made in the transaction are not visible outside the transaction.

 However, when a transaction writes to multiple shards, not all outside read operations need to wait for the result of the committed transaction to be visible across the shards. For example, if a transaction is committed and write 1 is visible on shard A but write 2 is not yet visible on shard B, an outside read at read concern "local" can read the results of write 1 without seeing write 2.

 Change Streams

 Starting in MongoDB 3.6, change streams are available for replica sets and sharded clusters. Change streams allow applications to access real-time data changes without the complexity and risk of tailing the oplog. Applications can use change streams to subscribe to all data changes on a collection or collections.

 Additional Features

 Replica sets provide a number of options to support application needs. For example, you may deploy a replica set with members in multiple data centers, or control the outcome of elections by adjusting the members[n].priority of some members. Replica sets also support dedicated members for reporting, disaster recovery, or backup functions.

 See Priority 0 Replica Set Members, Hidden Replica Set Members and Delayed Replica Set Members for more information.

 [1] (1, 2) In some circumstances, two nodes in a replica set may transiently believe that they are the primary, but at most, one of them will be able to complete writes with { w: "majority" } write concern. The node that can complete { w: "majority" } writes is the current primary, and the other node is a former primary that has not yet recognized its demotion, typically due to a network partition. When this occurs, clients that connect to the former primary may observe stale data despite having requested read preference primary, and new writes to the former primary will eventually roll back.
 
 ← Database References
 Replica Set Members →

 On this page

 * Redundancy and Data Availability
 * Replication in MongoDB
 * Asynchronous Replication
 * Automatic Failover
 * Read Operations
 * Transactions
 * Change Streams
 * Additional Features
On this page                                    A replica set in MongoDB is a group of  mongod  processes
that maintain the same data set. Replica sets provide redundancy and
high availability, and are the basis for all production
deployments. This section introduces replication in MongoDB as well as
the components and architecture of replica sets. The section also
provides tutorials for common tasks related to replica sets.    Replication provides redundancy and increases
data availability. With
multiple copies of data on different database servers, replication
provides a level of fault tolerance against the loss of a single
database server. In some cases, replication can provide increased read capacity as
clients can send read operations to different servers. Maintaining
copies of data in different data centers can increase data locality
and availability for distributed applications. You can also maintain
additional copies for dedicated purposes, such as disaster recovery,
reporting, or backup.   A replica set is a group of  mongod  instances that maintain
the same data set. A replica set contains several data bearing nodes
and optionally one arbiter node. Of the data bearing nodes, one and
only one member is deemed the primary node, while the other nodes are
deemed secondary nodes.   Warning   Each replica set node must belong to one, and only one, replica
set. Replica set nodes cannot belong to more than one replica set.   The primary node receives all write
operations. A replica set can have only one primary capable of
confirming writes with  { w: "majority" } 
write concern; although in some circumstances, another mongod instance
may transiently believe itself to also be primary.
[1] The primary records all changes to its data
sets in its operation log, i.e. oplog. For more information on primary node
operation, see Replica Set Primary.     click to enlarge  The secondaries replicate the
primary's oplog and apply the operations to their data sets such that
the secondaries' data sets reflect the primary's data set. If the
primary is unavailable, an eligible secondary will hold an election to
elect itself the new primary. For more information on secondary
members, see Replica Set Secondary Members.    In some circumstances (such as you have a primary and a secondary but
cost constraints prohibit adding another secondary), you may choose to
add a  mongod  instance to a replica set as an
arbiter. An arbiter participates in
elections but does not hold data (i.e.
does not provide data redundancy). For more information on arbiters,
see Replica Set Arbiter.    An arbiter will always be an arbiter
whereas a primary may step down and
become a secondary and a
secondary may become the primary
during an election.   Secondaries replicate the primary's oplog and apply the operations to
their data sets asynchronously. By having the secondaries' data sets
reflect the primary's data set, the replica set can continue to
function despite the failure of one or more members. For more information on replication mechanics, see
Replica Set Oplog and Replica Set Data Synchronization.   Starting in version 4.2, secondary
members of a replica set now log oplog entries that take longer than the slow operation
threshold to apply. These slow oplog messages:   Are logged for the secondaries in the
 diagnostic log.    Are logged under the  REPL  component with the text
applied op: &lt;oplog entry&gt; took &lt;num&gt;ms.   Do not depend on the log levels (either at the system or component
level)   Do not depend on the profiling level.   Are affected by  slowOpSampleRate.    The profiler does not capture slow oplog entries.    Replication lag is a delay between an operation on the
primary and the application of that operation from the oplog to
the secondary. Some small delay period may be
acceptable, but significant problems emerge as replication lag grows,
including building cache pressure on the primary. Starting in MongoDB 4.2, administrators can limit the rate at which
the primary applies its writes with the goal of keeping the  majority
committed  lag under
a configurable maximum value  flowControlTargetLagSeconds.  By default, flow control is  enabled.    Note   For flow control to engage, the replica set/sharded cluster must
have: featureCompatibilityVersion (fCV) of
4.2 and read concern  majority enabled . That is, enabled flow
control has no effect if fCV is not 4.2 or if read concern
majority is disabled.   With flow control enabled, as the lag grows close to the
 flowControlTargetLagSeconds , writes on the primary must obtain
tickets before taking locks to apply writes. By limiting the number of
tickets issued per second, the flow control mechanism attempts to keep
the lag under the target. For more information, see Check the Replication Lag and
Flow Control.     When a primary does not communicate with the other members of the set
for more than the configured  electionTimeoutMillis 
period (10 seconds by default), an eligible secondary calls for an
election to nominate itself as the new primary. The cluster attempts to
complete the election of a new primary and resume normal operations.    click to enlarge  The replica set cannot process write operations
until the election completes successfully. The replica set can continue
to serve read queries if such queries are configured to
run on secondaries while the
primary is offline. The median time before a cluster elects a new primary should not
typically exceed 12 seconds, assuming default  replica
configuration settings . This includes time required to
mark the primary as   and
call and complete an election.
You can tune this time period by modifying the
 settings.electionTimeoutMillis  replication configuration
option. Factors such as network latency may extend the time required
for replica set elections to complete, which in turn affects the amount
of time your cluster may operate without a primary. These factors are
dependent on your particular cluster architecture. Lowering the  electionTimeoutMillis 
replication configuration option from the default 10000 (10 seconds)
can result in faster detection of primary failure. However,
the cluster may call elections more frequently due to factors such as
temporary network latency even if the primary is otherwise healthy.
This can result in increased rollbacks for
w : 1 write operations. Your application connection logic should include tolerance for automatic
failovers and the subsequent elections. MongoDB drivers
can detect the loss of the primary and automatically
retry certain write operations a single time,
providing additional built-in handling of automatic failovers and elections: Compatible drivers enable retryable writes by default MongoDB provides   to pre-warm electable
secondary members' cache with the most recently accessed data. Pre-warming the
cache of a secondary can help restore performance more quickly after an
election. To learn more about MongoDB’s failover process, see:    Replica Set Elections     Retryable Writes     Rollbacks During Replica Set Failover       By default, clients read from the primary [1];
however, clients can specify a read preference to send read operations to secondaries.    click to enlarge     to
secondaries means that reads from secondaries may return data that does
not reflect the state of the data on the primary.  Distributed transactions that contain
read operations must use read preference  primary . All
operations in a given transaction must route to the same member. For information on reading from replica sets, see
Read Preference.    Depending on the read concern, clients can see the results of writes
before the writes are durable:    Regardless of a write's write concern, other
clients using  "local"  or  "available" 
read concern can see the result of a write operation before the write
operation is acknowledged to the issuing client.   Clients using  "local"  or  "available" 
read concern can read data which may be subsequently rolled
back during replica set failovers.   For operations in a multi-document transaction, when a transaction commits, all data changes
made in the transaction are saved and visible outside the transaction.
That is, a transaction will not commit some of its changes while
rolling back others. Until a transaction commits, the data changes made in the
transaction are not visible outside the transaction. However, when a transaction writes to multiple shards, not all
outside read operations need to wait for the result of the committed
transaction to be visible across the shards. For example, if a
transaction is committed and write 1 is visible on shard A but write
2 is not yet visible on shard B, an outside read at read concern
 "local"  can read the results of write 1 without
seeing write 2. For more information on read isolations, consistency and recency for
MongoDB, see Read Isolation, Consistency, and Recency.    Mirrored reads reduce the impact of primary elections following an
outage or planned maintenance. After a failover in a replica
set, the secondary that takes over as the new primary updates its cache
as new queries come in. While the cache is warming up performance can be
impacted. Mirrored reads pre-warm the caches of  electable 
secondary replica set members. To pre-warm the caches of electable secondaries,
the primary mirrors a sample of the   it receives to electable
secondaries. The size of the subset of  electable 
secondary replica set members that receive mirrored reads can be
configured with the  mirrorReads 
parameter. See   for further details.   Note   Mirrored reads do not affect the primary's response to the client.
The reads that the primary mirrors to secondaries are
"fire-and-forget" operations. The primary doesn't await responses.    Mirrored reads support the following operations:     count       distinct       find       findAndModify  (Specifically, the filter is sent as a
mirrored read)     update  (Specifically, the filter is sent as a mirrored
read)     Mirrored reads are enabled by default and use a default
 sampling rate  of 0.01. To disable
mirrored reads, set the  mirrorReads  parameter to {
samplingRate: 0.0 }:       db.( {    : ,    : { : }   } )       With a sampling rate greater than 0.0, the primary mirrors
  to a subset
of  electable  secondaries. With a sampling rate
of 0.01, the primary mirrors one percent of the supported reads it receives
to a selection of electable secondaries. For example, consider a replica set that consists of one primary and two
electable secondaries. If the primary receives 1000 operations that can be
mirrored and the sampling rate is 0.01, the primary mirrors about 10
supported reads to electable secondaries. Each electable secondary receives only
a fraction of the 10 reads. The primary sends each mirrored read to a randomly
chosen, non-empty selection of electable secondaries.   To change the sampling rate for mirrored reads, set the
 mirrorReads  parameter to a number between 0.0 and
1.0:   A sampling rate of 0.0 disables mirrored reads.   A sampling rate of a number between 0.0 and 1.0 results in
the primary forwarding a random sample of the   at the specified sample rate to
electable secondaries.   A sampling rate of 1.0 results in the primary forwarding all
  to
electable secondaries.   For details, see  mirrorReads.    The  serverStatus  command and the  db.serverStatus() 
shell method return  mirroredReads  metrics if you specify the
field in the operation:    db.( { : } )        Starting in MongoDB 4.0, multi-document transactions are available for replica sets.  Distributed transactions that contain
read operations must use read preference  primary . All
operations in a given transaction must route to the same member. Until a transaction commits, the data changes made in the
transaction are not visible outside the transaction. However, when a transaction writes to multiple shards, not all
outside read operations need to wait for the result of the committed
transaction to be visible across the shards. For example, if a
transaction is committed and write 1 is visible on shard A but write
2 is not yet visible on shard B, an outside read at read concern
 "local"  can read the results of write 1 without
seeing write 2.   Starting in MongoDB 3.6, change streams are
available for replica sets and sharded clusters. Change streams allow
applications to access real-time data changes without the complexity
and risk of tailing the oplog. Applications can use change streams to
subscribe to all data changes on a collection or collections.   Replica sets provide a number of options to support application
needs. For example, you may deploy a replica set with members in
multiple data centers, or
control the outcome of elections by adjusting the
 members[n].priority  of some
members. Replica sets also support dedicated members for reporting,
disaster recovery, or backup functions. See Priority 0 Replica Set Members,
Hidden Replica Set Members and
Delayed Replica Set Members for more information.
Replication
https://www.mongodb.com/docs/v5.0/replication/
https://www.tutorialspoint.com/mongodb/mongodb_replication.htm
MongoDB - Replication
2014-06-26
None
<div><div>
<hr />
<p>Replication is the process of synchronizing data across multiple servers. Replication provides redundancy and increases data availability with multiple copies of data on different database servers. Replication protects a database from the loss of a single server. Replication also allows you to recover from hardware failure and service interruptions. With additional copies of the data, you can dedicate one to disaster recovery, reporting, or backup.</p>
<h2>Why Replication?</h2>
<ul>
<li>To keep your data safe</li>
<li>High (24*7) availability of data</li>
<li>Disaster recovery</li>
<li>No downtime for maintenance (like backups, index rebuilds, compaction)</li>
<li>Read scaling (extra copies to read from)</li>
<li>Replica set is transparent to the application</li>
</ul>
<h2>How Replication Works in MongoDB</h2>
<p>MongoDB achieves replication by the use of replica set. A replica set is a group of <b>mongod</b> instances that host the same data set. In a replica, one node is primary node that receives all write operations. All other instances, such as secondaries, apply operations from the primary so that they have the same data set. Replica set can have only one primary node.</p>
<ul>
<li><p>Replica set is a group of two or more nodes (generally minimum 3 nodes are required).</p></li>
<li><p>In a replica set, one node is primary node and remaining nodes are secondary.</p></li>
<li><p>All data replicates from primary to secondary node.</p></li>
<li><p>At the time of automatic failover or maintenance, election establishes for primary and a new primary node is elected.</p></li>
<li><p>After the recovery of failed node, it again join the replica set and works as a secondary node.</p></li>
</ul>
<p>A typical diagram of MongoDB replication is shown in which client application always interact with the primary node and the primary node then replicates the data to the secondary nodes.</p>
<p></p><h2>Replica Set Features</h2>
<ul>
<li>A cluster of N nodes</li>
<li>Any one node can be primary</li>
<li>All write operations go to primary</li>
<li>Automatic failover</li>
<li>Automatic recovery</li>
<li>Consensus election of primary</li>
</ul>
<h2>Set Up a Replica Set</h2>
<p>In this tutorial, we will convert standalone MongoDB instance to a replica set. To convert to replica set, following are the steps −</p>
<ul>
<li><p>Shutdown already running MongoDB server.</p></li>
<li>
</li><li><p>Start the MongoDB server by specifying -- replSet option. Following is the basic syntax of --replSet −</p></li>
</ul>
<pre>mongod --port "PORT" --dbpath "YOUR_DB_DATA_PATH" --replSet "REPLICA_SET_INSTANCE_NAME"
</pre>
<h3>Example</h3>
<pre>mongod --port 27017 --dbpath "D:\set up\mongodb\data" --replSet rs0
</pre>
<ul>
<li><p>It will start a mongod instance with the name rs0, on port 27017.</p></li>
<li><p>Now start the command prompt and connect to this mongod instance.</p></li>
<li><p>In Mongo client, issue the command <b>rs.initiate()</b> to initiate a new replica set.</p></li>
<li><p>To check the replica set configuration, issue the command <b>rs.conf()</b>. To check the status of replica set issue the command <b>rs.status()</b>.</p></li>
</ul>
<h2>Add Members to Replica Set</h2>
<p>To add members to replica set, start mongod instances on multiple machines. Now start a mongo client and issue a command <b>rs.add()</b>.</p>
<h3>Syntax</h3>
<p>The basic syntax of <b>rs.add()</b> command is as follows −</p>
<pre>&gt;rs.add(HOST_NAME:PORT)
</pre>
<h3>Example</h3>
<p>Suppose your mongod instance name is <b>mongod1.net</b> and it is running on port <b>27017</b>. To add this instance to replica set, issue the command <b>rs.add()</b> in Mongo client.</p>
<pre>&gt;rs.add("mongod1.net:27017")
&gt;
</pre>
<p>You can add mongod instance to replica set only when you are connected to primary node. To check whether you are connected to primary or not, issue the command <b>db.isMaster()</b> in mongo client.</p>
	</div>||||I|||| * Home
 * Coding Ground
 * Jobs
 * Whiteboard
 * Tools
 * Corporate Training
 Teach with us
 * 
 * 
 * 
 * 
 * 
 * Login
 * Category
 + Academic Tutorials
 + Big Data & Analytics
 + Computer Programming
 + Computer Science
 + Databases
 + DevOps
 + Digital Marketing
 + Engineering Tutorials
 + Exams Syllabus
 + Famous Monuments
 + GATE Exams
 + Latest Technologies
 + Machine Learning
 + Mainframe Development
 + Management Tutorials
 + Mathematics Tutorials
 + Microsoft Technologies
 + Misc tutorials
 + Mobile Development
 + Java Technologies
 + Python Technologies
 + SAP Tutorials
 + Programming Scripts
 + Selected Reading
 + Software Quality
 + Soft Skills
 + Telecom Tutorials
 + UPSC IAS Exams
 + Web Development
 + Sports Tutorials
 + XML Technologies
 + Multi-Language
 + Interview Questions
 * Prime Packs
 * Courses
 * eBooks
 * Library
 * Articles
 Login
 * MongoDB Tutorial
 * MongoDB - Home
 * MongoDB - Overview
 * MongoDB - Advantages
 * MongoDB - Environment
 * MongoDB - Data Modeling
 * MongoDB - Create Database
 * MongoDB - Drop Database
 * MongoDB - Create Collection
 * MongoDB - Drop Collection
 * MongoDB - Data Types
 * MongoDB - Insert Document
 * MongoDB - Query Document
 * MongoDB - Update Document
 * MongoDB - Delete Document
 * MongoDB - Projection
 * MongoDB - Limiting Records
 * MongoDB - Sorting Records
 * MongoDB - Indexing
 * MongoDB - Aggregation
 * MongoDB - Replication
 * MongoDB - Sharding
 * MongoDB - Create Backup
 * MongoDB - Deployment
 * MongoDB - Java
 * MongoDB - PHP
 * Advanced MongoDB
 * MongoDB - Relationships
 * MongoDB - Database References
 * MongoDB - Covered Queries
 * MongoDB - Analyzing Queries
 * MongoDB - Atomic Operations
 * MongoDB - Advanced Indexing
 * MongoDB - Indexing Limitations
 * MongoDB - ObjectId
 * MongoDB - Map Reduce
 * MongoDB - Text Search
 * MongoDB - Regular Expression
 * Working with Rockmongo
 * MongoDB - GridFS
 * MongoDB - Capped Collections
 * Auto-Increment Sequence
 * MongoDB Useful Resources
 * MongoDB - Questions and Answers
 * MongoDB - Quick Guide
 * MongoDB - Useful Resources
 * MongoDB - Discussion
 * Selected Reading
 * UPSC IAS Exams Notes
 * Developer's Best Practices
 * Questions and Answers
 * Effective Resume Writing
 * HR Interview Questions
 * Computer Glossary
 * Who is Who

 MongoDB - Replication

 Previous Page
 Next Page

 Replication is the process of synchronizing data across multiple servers. Replication provides redundancy and increases data availability with multiple copies of data on different database servers. Replication protects a database from the loss of a single server. Replication also allows you to recover from hardware failure and service interruptions. With additional copies of the data, you can dedicate one to disaster recovery, reporting, or backup.

 Why Replication?

 * To keep your data safe
 * High (24*7) availability of data
 * Disaster recovery
 * No downtime for maintenance (like backups, index rebuilds, compaction)
 * Read scaling (extra copies to read from)
 * Replica set is transparent to the application

 How Replication Works in MongoDB

 MongoDB achieves replication by the use of replica set. A replica set is a group of mongod instances that host the same data set. In a replica, one node is primary node that receives all write operations. All other instances, such as secondaries, apply operations from the primary so that they have the same data set. Replica set can have only one primary node.

 * Replica set is a group of two or more nodes (generally minimum 3 nodes are required).

 * In a replica set, one node is primary node and remaining nodes are secondary.

 * All data replicates from primary to secondary node.

 * At the time of automatic failover or maintenance, election establishes for primary and a new primary node is elected.

 * After the recovery of failed node, it again join the replica set and works as a secondary node.

 A typical diagram of MongoDB replication is shown in which client application always interact with the primary node and the primary node then replicates the data to the secondary nodes.

 Replica Set Features

 * A cluster of N nodes
 * Any one node can be primary
 * All write operations go to primary
 * Automatic failover
 * Automatic recovery
 * Consensus election of primary

 Set Up a Replica Set

 In this tutorial, we will convert standalone MongoDB instance to a replica set. To convert to replica set, following are the steps −

 * Shutdown already running MongoDB server.

 * 

 * Start the MongoDB server by specifying -- replSet option. Following is the basic syntax of --replSet −

 
 mongod --port "PORT" --dbpath "YOUR_DB_DATA_PATH" --replSet "REPLICA_SET_INSTANCE_NAME"
 

 Example

 
 mongod --port 27017 --dbpath "D:\set up\mongodb\data" --replSet rs0
 

 * It will start a mongod instance with the name rs0, on port 27017.

 * Now start the command prompt and connect to this mongod instance.

 * In Mongo client, issue the command rs.initiate() to initiate a new replica set.

 * To check the replica set configuration, issue the command rs.conf(). To check the status of replica set issue the command rs.status().

 Add Members to Replica Set

 To add members to replica set, start mongod instances on multiple machines. Now start a mongo client and issue a command rs.add().

 Syntax

 The basic syntax of rs.add() command is as follows −

 
 >rs.add(HOST_NAME:PORT)
 

 Example

 Suppose your mongod instance name is mongod1.net and it is running on port 27017. To add this instance to replica set, issue the command rs.add() in Mongo client.

 
 >rs.add("mongod1.net:27017")
 >
 

 You can add mongod instance to replica set only when you are connected to primary node. To check whether you are connected to primary or not, issue the command db.isMaster() in mongo client.

 Previous Page Print Page Next Page
 Advertisements


 Annual Membership

 Enjoy unlimited access on 5500+ Hand Picked Quality Video Courses

 Subscribe Now

 Training for a Team

 Affordable solution to train a team and make them project ready.

 Submit Demo Request
 * About us
 * Refund Policy
 * Terms of use
 * Privacy Policy
 * FAQ's
 * Contact

 © Copyright 2023. All Rights Reserved.

 We make use of First and third party cookies to improve our user experience. By using this website, you agree with our Cookies Policy. Agree Learn more

Replication is the process of synchronizing data across multiple servers. Replication provides redundancy and increases data availability with multiple copies of data on different database servers. Replication protects a database from the loss of a single server. Replication also allows you to recover from hardware failure and service interruptions. With additional copies of the data, you can dedicate one to disaster recovery, reporting, or backup.
Why Replication?
To keep your data safe
High (24*7) availability of data
Disaster recovery
No downtime for maintenance (like backups, index rebuilds, compaction)
Read scaling (extra copies to read from)
Replica set is transparent to the application
How Replication Works in MongoDB
MongoDB achieves replication by the use of replica set. A replica set is a group of mongod instances that host the same data set. In a replica, one node is primary node that receives all write operations. All other instances, such as secondaries, apply operations from the primary so that they have the same data set. Replica set can have only one primary node.
 Replica set is a group of two or more nodes (generally minimum 3 nodes are required). 
 In a replica set, one node is primary node and remaining nodes are secondary. 
 All data replicates from primary to secondary node. 
 At the time of automatic failover or maintenance, election establishes for primary and a new primary node is elected. 
 After the recovery of failed node, it again join the replica set and works as a secondary node. 
A typical diagram of MongoDB replication is shown in which client application always interact with the primary node and the primary node then replicates the data to the secondary nodes.
  Replica Set Features
A cluster of N nodes
Any one node can be primary
All write operations go to primary
Automatic failover
Automatic recovery
Consensus election of primary
Set Up a Replica Set
In this tutorial, we will convert standalone MongoDB instance to a replica set. To convert to replica set, following are the steps −
 Shutdown already running MongoDB server. 
  Start the MongoDB server by specifying -- replSet option. Following is the basic syntax of --replSet − 
mongod --port "PORT" --dbpath "YOUR_DB_DATA_PATH" --replSet "REPLICA_SET_INSTANCE_NAME"
Example
mongod --port 27017 --dbpath "D:\set up\mongodb\data" --replSet rs0
 It will start a mongod instance with the name rs0, on port 27017. 
 Now start the command prompt and connect to this mongod instance. 
 In Mongo client, issue the command rs.initiate() to initiate a new replica set. 
 To check the replica set configuration, issue the command rs.conf(). To check the status of replica set issue the command rs.status(). 
Add Members to Replica Set
To add members to replica set, start mongod instances on multiple machines. Now start a mongo client and issue a command rs.add().
Syntax
The basic syntax of rs.add() command is as follows −
&gt;rs.add(HOST_NAME:PORT)
Example
Suppose your mongod instance name is mongod1.net and it is running on port 27017. To add this instance to replica set, issue the command rs.add() in Mongo client.
&gt;rs.add("mongod1.net:27017")
&gt;
You can add mongod instance to replica set only when you are connected to primary node. To check whether you are connected to primary or not, issue the command db.isMaster() in mongo client.
MongoDB - Replication
https://www.tutorialspoint.com/mongodb/mongodb_replication.htm
https://www.tugberkugurlu.com/archive/setting-up-a-mongodb-replica-set-with-docker-and-connecting-to-it-with-a--net-core-app
Setting up a MongoDB Replica Set with Docker and Connecting to It With a .NET Core App
2021-04-08
None
<div><div>
<p>Easily setting up realistic non-production (e.g. dev, test, QA, etc.) environments is really critical in order to reduce the feedback loop. In this blog post, I want to talk about how you can achieve this if your application relies on MongoDB Replica Set by showing you how to set it up with Docker for non-production environments. </p><blockquote> <h3>Hold on! I want to watch, not read!</h3> <p>I got you covered there! I have also recorded a ~5m covering the content of this blog post, where I also walks you through the steps visually. If you find this option useful, let me know through the comments below and I can aim harder to repeat that :) </p><p></p></blockquote> <h3>What are we trying to do here and why?</h3> <p><a href="https://tugberkugurlu.blob.core.windows.net/bloggyimages/67b0afbb-825b-4cd3-b1b0-522d2f6869f8.png"></a></p> <p>If you have an application which works against a MongoDB database, it’s very common to have a replica set in production. This approach ensures the high availability of the data, especially for read scenarios. However, applications mostly end up working against a single MongoDB instance, because setting up a Replica Set in isolation is a tedious process. As mentioned at the beginning of the post, we want to reflect the production environment to the process of developing or testing the software applications as much as possible. The reason for that is to catch unexpected behaviour which may only occur under a production environment. This approach is valuable because it would allow us to reduce the feedback loop on those exceptional cases.</p> <h3>Docker makes this all easy!</h3> <p>This is where Docker enters into the picture! Docker is containerization technology and it allows us to have repeatable process to provision environments in a declarative way. It also gives us a try and tear down model where we can experiment and easily start again from the initial state. Docker can also help us with easily setting up a MongoDB Replica Set. Within our Docker Host, we can create Docker Network which would give us the isolated DNS resolution across containers. Then we can start creating the MongoDB docker containers. They would initially be unaware of each other. However, we can initialise the replication by connecting to one of the containers and running the replica set initialisation command. Finally,  we can deploy our application container under the same docker network. </p><p><a href="https://tugberkugurlu.blob.core.windows.net/bloggyimages/34165076-d303-419d-a7c1-505c5fc277ec.png"></a> </p><p>There are a handful of advantages to setting up this with Docker and I want to specifically touch on some of them: </p><ul> <li> <strong>It can be automated easily</strong>. This is especially crucial for test environments which are provisioned on demand.</li> <li><strong>It’s repeatable!</strong> The declarative nature of the Dockerfile makes it possible to end up with the same environment setup even if you run the scripts months later after your initial setup.</li> <li><strong>Familiarity!</strong> Docker is a widely known and used tool for lots of other purposes and familiarity to the tool is high. Of course, this may depend on your development environment</li></ul> <h3>Let’s make it work!</h3> <p>First of all, I need to create a docker network. I can achieve this by running the "docker network create” command and giving it a unique name. </p><div><pre>docker network create mymongocluster</pre></div>
<p>The next step is to create the MongoDB docker containers and start them. I can use “docker run” command for this. Also, MongoDB has an official image on Docker Hub. So, I can reuse that to simplify the acqusition of MongoDB. For convenience, I will name the container with a number suffix. The container also needs to be tied to the network we have previously created. Finally, I need to specify the name of the replica set for each container.</p>
<div><pre>docker run name mongonode1 d net mymongocluster mongo replSet “rs0"</pre></div>
<p>First container is created and I need to run the same command to create two more MongoDB containers. The only difference is with the container names.
</p><div><pre>docker run name mongonode2 d net mymongocluster mongo replSet 
docker run name mongonode3 d net mymongocluster mongo replSet “rs0"</pre></div>
<p>I can see that all of my MongoDB containers are at the running state by executing the “docker ps” command.
</p><p><a href="https://tugberkugurlu.blob.core.windows.net/bloggyimages/0ccafe12-d243-48c3-93ea-0930fbaa2b99.png"></a>
</p><p>In order to form a replica set, I need to initialise the replication. I will do that by connecting to one of the containers through the “docker exec” command and starting the mongo shell client.
</p><div><pre>docker exec it mongonode1 mongo</pre></div>
<p><a href="https://tugberkugurlu.blob.core.windows.net/bloggyimages/a2b23cf7-54c7-42d9-9e8e-67f79f1fdb44.png"></a>
</p><p>As I now have a connection to the server, I can initialise the replication. This requires me to declare a config object which will include connection details of all the servers.
</p><div><pre>config = {
 : ,
 : [
 {
 : 0,
 : 
 },
 {
 : 1,
 : 
 },
 {
 : 2,
 : 
 }
 ]
 }</pre></div>
<p>Finally, we can run “rs.initialize" command to complete the set up.
</p><p>You will notice that the server I am connected to will be elected as the primary in the replica set shortly. By running “rs.status()”, I can view the status of other MongoDB servers within the replica set. We can see that there are two secondaries and one primary in the replica set.
</p><h3>.NET Core Application</h3>
<p>As a scenario, I want to run <a href="https://github.com/tugberkugurlu/mongodb-replica-set">my .NET Core application</a> which writes data to a MongoDB database and start reading it in a loop. This application will be connecting to the MongoDB replica set which we have just created.  This is a standard .NET Core console application which you can create by running the following script:
</p>
<p>The csproj file for this application looks like below.
</p><div><pre> 
 
 Exe
 netcoreapp2.0
 
 
 
 
 
 
</pre></div>
<p>Notice that I have two interesting dependencies there. Polly is used to retry the read calls to MongoDB based on defined policies. This bit is interesting as I would expect the MongoDB client to handle that for read calls. However, it might be also a good way of explicitly stating which calls can be retried inside your application. Bogus, on the other hand, is just here to be able to create fake names to make the application a bit more realistic :)
</p><p> Finally, this is the code to make this application work:
</p><div><pre> Program
{
 Main([] args)
 {
 settings = MongoClientSettings
 {
 Servers = []
 {
 MongoServerAddress(, 27017),
 MongoServerAddress(, 27017),
 MongoServerAddress(, 27017)
 },
 ConnectionMode = ConnectionMode.ReplicaSet,
 ReplicaSetName = 
 };
 client = MongoClient(settings);
 database = client.GetDatabase();
 collection = database.GetCollection&lt;User&gt;();
 System.Console.WriteLine(, client.Cluster.ClusterId);
 client.Cluster.DescriptionChanged += ( sender, ClusterDescriptionChangedEventArgs foo) =&gt; 
 {
 System.Console.WriteLine(, foo.NewClusterDescription.ClusterId);
 };
 ( i = 0; i &lt; 100; i++)
 {
 user = User { Id = ObjectId.GenerateNewId(), Name = Bogus.Faker().Name.FullName() };
 collection.InsertOne(user);
 }
 ()
 {
 randomUser = collection.GetRandom();
 Console.WriteLine(randomUser.Name);
 Thread.Sleep(500);
 }
 }
}</pre></div>
<p>This is not the most beautiful and optimized code ever but should demonstrate what we are trying to achieve by having a replica set. It's actually the GetRandom method on the MongoDB collection object which handles the retry:
</p><div><pre> CollectionExtensions 
{
 Random random = Random();
 T GetRandom&lt;T&gt;( IMongoCollection&lt;T&gt; collection) 
 {
 retryPolicy = Policy
 .Handle&lt;MongoCommandException&gt;()
 .Or&lt;MongoConnectionException&gt;()
 .WaitAndRetry(2, retryAttempt =&gt; 
 TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)) 
 );
 retryPolicy.Execute(() =&gt; GetRandomImpl(collection));
 }
 T GetRandomImpl&lt;T&gt;( IMongoCollection&lt;T&gt; collection)
 {
 collection.Find(FilterDefinition&lt;T&gt;.Empty)
 .Limit(-1)
 .Skip(random.Next(99))
 .First();
 }
}</pre></div>
<p>I will run this through docker as well and here is the dockerfile for this:  </p><div><pre>FROM microsoft/dotnet:2-sdk
COPY ./mongodb-replica-set.csproj /app/
WORKDIR /app/
RUN dotnet --info
RUN dotnet restore
ADD ./ /app/
RUN dotnet publish -c DEBUG -o out
ENTRYPOINT ["dotnet", "out/mongodb-replica-set.dll"]</pre></div>
<p>When it starts, we can see that it will output the result to the console:
</p><p><a href="https://tugberkugurlu.blob.core.windows.net/bloggyimages/404373db-0d84-4fa2-96f5-5f50a5bc8370.png"></a>
</p><h3>Prove that It Works!</h3>
<p>In order to demonstrate the effect of the replica set, I want to take down the primary node. First of all, we need to have look at the output of rs.status command we have previously ran in order to identify the primary node. We can see that it’s node1!  </p><p><a href="https://tugberkugurlu.blob.core.windows.net/bloggyimages/ea0da0c1-4c20-4242-a766-5f4ff0598be4.png"></a>
</p><p>Secondly, we need to get the container id for that node.  </p><p><a href="https://tugberkugurlu.blob.core.windows.net/bloggyimages/ce3a7018-9e43-48fd-be87-488a0e71e784.png"></a>
</p><p>Finally, we can kill the container by running the “docker stop command”. Once the container is stopped, you will notice that application will gracefully recover and continue reading the data.  </p><p><a href="https://tugberkugurlu.blob.core.windows.net/bloggyimages/d583a8d9-fbd8-4c85-8c79-668f3ef50f3a.png"></a>
</p></div></div>||||I|||| Tugberk @ the Heart of Software
 Blog Speaking About Contact
 Home Speaking About Contact


 Setting up a MongoDB Replica Set with Docker and Connecting to It With a .NET Core App

 Easily setting up realistic non-production (e.g. dev, test, QA, etc.) environments is really critical in order to reduce the feedback loop. In this blog post, I want to talk about how you can achieve this if your application relies on MongoDB Replica Set by showing you how to set it up with Docker for non-production environments.
 31 January 2018
 7 minutes read
 MongoDB
 6
 Docker
 5
 Databases
 3
 Architecture
 9
 ASP.NET Core
 4

 Related Posts

 20 minutes read
 My Mental Model on Choosing a Database for a Particular Problem
 8 April 2021
 Databases
 3
 Architecture
 9
 Distributed Systems
 3
 16 minutes read
 Redis Cluster - Benefits of Sharding and How It Works
 20 December 2020
 Redis
 5
 Databases
 3
 Distributed Systems
 3
 Sharding
 1
 Architecture
 9
 6 minutes read
 Kafka Core Concepts and Producer Semantics
 26 May 2020
 Kafka
 1
 Distributed Systems
 3
 Messaging
 1
 Architecture
 9
 6 minutes read
 Software Architecture and System Design - Getting Your Grip and Some Related Resources
 23 February 2019
 Architecture
 9
 Software Development
 4
 Career
 4
 Interviewing
 2
 7 minutes read
 Pulling an Old Article From the Coffin: SignalR with Redis Running on a Windows Azure Virtual Machine
 8 August 2018
 Architecture
 9
 Azure
 1
 Redis
 5
 Scaling
 1
 SignalR
 16
 6 minutes read
 ASP.NET Core Authentication in a Load Balanced Environment with HAProxy and Redis
 28 November 2016
 ASP.Net
 101
 ASP.NET Core
 4
 Docker
 5
 HTTP
 11
 Security
 3
 Architecture
 9
 3 minutes read
 Moving to ASP.NET Core RC2: Tooling
 22 May 2016
 .NET
 75
 .NET Core
 4
 ASP.Net
 101
 ASP.NET Core
 4
 8 minutes read
 Microsoft Build 2016 in a Nutshell
 9 April 2016
 .NET
 75
 .NET Core
 4
 ASP.NET Core
 4
 Microsoft Azure
 5
 3 minutes read
 Upcoming Conferences and Talks
 27 February 2016
 Deployments
 2
 Docker
 5
 Geek Talks
 30
 Polyglot Persistance
 2
 6 minutes read
 NGINX Reverse Proxy and Load Balancing for ASP.NET 5 Applications with Docker Compose
 17 January 2016
 ASP.NET 5
 16
 Docker
 5
 Docker Compose
 1
 NGINX
 1
 2 minutes read
 ASP.NET 5 Identity MongoDB Implementation
 5 November 2015
 .NET
 75
 ASP.Net
 101
 ASP.NET 5
 16
 Identity
 1
 MongoDB
 6
 7 minutes read
 Playing Around with Docker: Hello World, Development Environment and Your Application
 13 July 2015
 Docker
 5
 Linux
 2
 4 minutes read
 Software Applications Should Work Like Restaurants
 14 February 2015
 Architecture
 9
 HTTP
 11
 Software
 1
 3 minutes read
 Securing MongoDB Access with Username and Password
 1 May 2014
 MongoDB
 6
 2 minutes read
 Order of Fields Matters on MongoDB Indexes
 12 April 2014
 .NET
 75
 JavaScript
 6
 MongoDB
 6
 4 minutes read
 A C# Developer's First Thoughts on MongoDB
 12 April 2014
 .NET
 75
 JavaScript
 6
 MongoDB
 6

 Easily setting up realistic non-production (e.g. dev, test, QA, etc.) environments is really critical in order to reduce the feedback loop. In this blog post, I want to talk about how you can achieve this if your application relies on MongoDB Replica Set by showing you how to set it up with Docker for non-production environments.

 Hold on! I want to watch, not read!

 I got you covered there! I have also recorded a ~5m covering the content of this blog post, where I also walks you through the steps visually. If you find this option useful, let me know through the comments below and I can aim harder to repeat that :)

 What are we trying to do here and why?

 If you have an application which works against a MongoDB database, it’s very common to have a replica set in production. This approach ensures the high availability of the data, especially for read scenarios. However, applications mostly end up working against a single MongoDB instance, because setting up a Replica Set in isolation is a tedious process. As mentioned at the beginning of the post, we want to reflect the production environment to the process of developing or testing the software applications as much as possible. The reason for that is to catch unexpected behaviour which may only occur under a production environment. This approach is valuable because it would allow us to reduce the feedback loop on those exceptional cases.

 Docker makes this all easy!

 This is where Docker enters into the picture! Docker is containerization technology and it allows us to have repeatable process to provision environments in a declarative way. It also gives us a try and tear down model where we can experiment and easily start again from the initial state. Docker can also help us with easily setting up a MongoDB Replica Set. Within our Docker Host, we can create Docker Network which would give us the isolated DNS resolution across containers. Then we can start creating the MongoDB docker containers. They would initially be unaware of each other. However, we can initialise the replication by connecting to one of the containers and running the replica set initialisation command. Finally, we can deploy our application container under the same docker network.

 There are a handful of advantages to setting up this with Docker and I want to specifically touch on some of them:

 * It can be automated easily. This is especially crucial for test environments which are provisioned on demand.
 * It’s repeatable! The declarative nature of the Dockerfile makes it possible to end up with the same environment setup even if you run the scripts months later after your initial setup.
 * Familiarity! Docker is a widely known and used tool for lots of other purposes and familiarity to the tool is high. Of course, this may depend on your development environment

 Let’s make it work!

 First of all, I need to create a docker network. I can achieve this by running the "docker network create” command and giving it a unique name.

 docker network create my-mongo-cluster

 The next step is to create the MongoDB docker containers and start them. I can use “docker run” command for this. Also, MongoDB has an official image on Docker Hub. So, I can reuse that to simplify the acqusition of MongoDB. For convenience, I will name the container with a number suffix. The container also needs to be tied to the network we have previously created. Finally, I need to specify the name of the replica set for each container.

 docker run --name mongo-node1 -d --net my-mongo-cluster mongo --replSet “rs0"

 First container is created and I need to run the same command to create two more MongoDB containers. The only difference is with the container names.

 docker run --name mongo-node2 -d --net my-mongo-cluster mongo --replSet "rs0"
 docker run --name mongo-node3 -d --net my-mongo-cluster mongo --replSet “rs0"

 I can see that all of my MongoDB containers are at the running state by executing the “docker ps” command.

 In order to form a replica set, I need to initialise the replication. I will do that by connecting to one of the containers through the “docker exec” command and starting the mongo shell client.

 docker exec -it mongo-node1 mongo

 As I now have a connection to the server, I can initialise the replication. This requires me to declare a config object which will include connection details of all the servers.

 config = {
 "_id" : "rs0",
 "members" : [
 {
 "_id" : 0,
 "host" : "mongo-node1:27017"
 },
 {
 "_id" : 1,
 "host" : "mongo-node2:27017"
 },
 {
 "_id" : 2,
 "host" : "mongo-node3:27017"
 }
 ]
 }

 Finally, we can run “rs.initialize" command to complete the set up.

 You will notice that the server I am connected to will be elected as the primary in the replica set shortly. By running “rs.status()”, I can view the status of other MongoDB servers within the replica set. We can see that there are two secondaries and one primary in the replica set.

 .NET Core Application

 As a scenario, I want to run my .NET Core application which writes data to a MongoDB database and start reading it in a loop. This application will be connecting to the MongoDB replica set which we have just created. This is a standard .NET Core console application which you can create by running the following script:

 dotnet new console

 The csproj file for this application looks like below.

 <Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <OutputType>Exe</OutputType>
 <TargetFramework>netcoreapp2.0</TargetFramework>
 </PropertyGroup>
 <ItemGroup>
 <PackageReference Include="Bogus" Version="18.0.2" />
 <PackageReference Include="MongoDB.Driver" Version="2.4.4" />
 <PackageReference Include="Polly" Version="5.3.1" />
 </ItemGroup>
 </Project>

 Notice that I have two interesting dependencies there. Polly is used to retry the read calls to MongoDB based on defined policies. This bit is interesting as I would expect the MongoDB client to handle that for read calls. However, it might be also a good way of explicitly stating which calls can be retried inside your application. Bogus, on the other hand, is just here to be able to create fake names to make the application a bit more realistic :)

 Finally, this is the code to make this application work:

 partial class Program
 {
 static void Main(string[] args)
 {
 var settings = new MongoClientSettings
 {
 Servers = new[]
 {
 new MongoServerAddress("mongo-node1", 27017),
 new MongoServerAddress("mongo-node2", 27017),
 new MongoServerAddress("mongo-node3", 27017)
 },
 ConnectionMode = ConnectionMode.ReplicaSet,
 ReplicaSetName = "rs0"
 };
 
 var client = new MongoClient(settings);
 var database = client.GetDatabase("mydatabase");
 var collection = database.GetCollection<User>("users");
 
 System.Console.WriteLine("Cluster Id: {0}", client.Cluster.ClusterId);
 client.Cluster.DescriptionChanged += (object sender, ClusterDescriptionChangedEventArgs foo) => 
 {
 System.Console.WriteLine("New Cluster Id: {0}", foo.NewClusterDescription.ClusterId);
 };
 
 for (int i = 0; i < 100; i++)
 {
 var user = new User { Id = ObjectId.GenerateNewId(), Name = new Bogus.Faker().Name.FullName() };
 collection.InsertOne(user);
 }
 
 while (true)
 {
 var randomUser = collection.GetRandom();
 Console.WriteLine(randomUser.Name);
 
 Thread.Sleep(500);
 }
 }
 }

 This is not the most beautiful and optimized code ever but should demonstrate what we are trying to achieve by having a replica set. It's actually the GetRandom method on the MongoDB collection object which handles the retry:

 public static class CollectionExtensions 
 {
 private readonly static Random random = new Random();
 
 public static T GetRandom<T>(this IMongoCollection<T> collection) 
 {
 var retryPolicy = Policy
 .Handle<MongoCommandException>()
 .Or<MongoConnectionException>()
 .WaitAndRetry(2, retryAttempt => 
 TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)) 
 );
 
 return retryPolicy.Execute(() => GetRandomImpl(collection));
 }
 
 private static T GetRandomImpl<T>(this IMongoCollection<T> collection)
 
 {
 return collection.Find(FilterDefinition<T>.Empty)
 .Limit(-1)
 .Skip(random.Next(99))
 .First();
 }
 }

 I will run this through docker as well and here is the dockerfile for this:

 FROM microsoft/dotnet:2-sdk
 
 COPY ./mongodb-replica-set.csproj /app/
 WORKDIR /app/
 RUN dotnet --info
 RUN dotnet restore
 ADD ./ /app/
 RUN dotnet publish -c DEBUG -o out
 ENTRYPOINT ["dotnet", "out/mongodb-replica-set.dll"]

 When it starts, we can see that it will output the result to the console:

 Prove that It Works!

 In order to demonstrate the effect of the replica set, I want to take down the primary node. First of all, we need to have look at the output of rs.status command we have previously ran in order to identify the primary node. We can see that it’s node1!

 Secondly, we need to get the container id for that node.

 Finally, we can kill the container by running the “docker stop command”. Once the container is stopped, you will notice that application will gracefully recover and continue reading the data.

 Please enable JavaScript to view the comments powered by Disqus.
 Hey, I'm Tugberk 👋

 Coder 👨🏻‍💻, Speaker 🗣, Author 📚, ex-Microsoft MVP 🕸, Blogger 💻

 I live in London, UK 🏡

 Tags

 ASP.Net
 101
 .NET
 75
 ASP.NET Web API
 49
 ASP.NET MVC
 42
 C#
 36
 Geek Talks
 30
 ASP.NET 5
 16
 SignalR
 16
 Tips
 14
 async
 11
 Visual Studio
 11
 HTTP
 11
 Tourism
 10
 Windows Azure
 10
 Architecture
 9
 TPL
 9
 ASP.NET vNext
 8
 OWIN
 8
 JQuery
 7
 Git
 7
 Katana
 7
 Microsoft
 6
 JavaScript
 6
 DLM
 6
 NuGet
 6
 Deployment
 6
 MongoDB
 6
 PowerShell
 6
 MS SQL
 6
 Razor
 5
 Microsoft Azure
 5
 Entity Framework
 5
 DbContext
 5
 Docker
 5
 Redis
 5
 Unit Testing
 5
 Data Structures
 5
 Algorithms
 5
 ASP.NET Core
 4
 IIS
 4
 Continuous Delivery
 4
 SQL Server
 4
 Hosting
 4
 Career
 4
 GitHub
 4
 .NET Core
 4
 UNWTO
 4
 Software Development
 4
 Elasticsearch
 4
 IT Stuff
 4
 Golang
 3
 Software Engineer
 3
 Go
 3
 Databases
 3
 Distributed Systems
 3
 Security
 3
 Caching
 3
 OAuth
 2
 gulp
 2
 Autofac
 2
 Azure Search
 2
 Aspect Oriented Programming
 2
 Linux
 2
 Interviewing
 2
 Random
 2
 SQL Release
 2
 Polyglot Persistance
 2
 Blogging
 2
 Assignments
 2
 C++
 2
 Continuous Integration
 2
 RavenDB
 2
 PostSharp
 2
 Facts & Figures
 2
 Code Review
 2
 SemVer
 2
 WCF Web API
 2
 nodejs
 2
 Deployments
 2
 Windows Server AppFabric
 1
 Sharding
 1
 SQL Injection
 1
 xUnit
 1
 Dexter
 1
 Visual Basic
 1
 Programming
 1
 Octopus Deploy
 1
 NGINX
 1
 Azure
 1
 Excel
 1
 eCommerce
 1
 Travis CI
 1
 Blob Storage
 1
 Bash
 1
 MVP
 1
 tugberkugurlu.com
 1
 Time Saviour
 1
 Graph
 1
 Web.Config
 1
 AWS
 1
 Messaging
 1
 Tourism Business
 1
 Windows 8
 1
 Search
 1
 Azure Web Apps
 1
 Scaling
 1
 React
 1
 Continious Delivery
 1
 Concurrency
 1
 Kafka
 1
 Tech Guys
 1
 TV Series
 1
 MvcScaffolding
 1
 Windows Live Writer
 1
 Redux
 1
 Docker Compose
 1
 Business
 1
 Microsoft SQL Server
 1
 Azure Storage
 1
 Projects
 1
 Congress & Convention Tourism
 1
 Software
 1
 UX
 1
 Neo4j
 1
 Microsoft Office
 1
 Roslyn
 1
 TourismGeek
 1
 Go Slices
 1
 Web
 1
 Lucene.NET
 1
 Web Application
 1
 Identity
 1
Easily setting up realistic non-production (e.g. dev, test, QA, etc.) environments is really critical in order to reduce the feedback loop. In this blog post, I want to talk about how you can achieve this if your application relies on MongoDB Replica Set by showing you how to set it up with Docker for non-production environments.   Hold on! I want to watch, not read! I got you covered there! I have also recorded a ~5m covering the content of this blog post, where I also walks you through the steps visually. If you find this option useful, let me know through the comments below and I can aim harder to repeat that :)     What are we trying to do here and why?     If you have an application which works against a MongoDB database, it’s very common to have a replica set in production. This approach ensures the high availability of the data, especially for read scenarios. However, applications mostly end up working against a single MongoDB instance, because setting up a Replica Set in isolation is a tedious process. As mentioned at the beginning of the post, we want to reflect the production environment to the process of developing or testing the software applications as much as possible. The reason for that is to catch unexpected behaviour which may only occur under a production environment. This approach is valuable because it would allow us to reduce the feedback loop on those exceptional cases. Docker makes this all easy! This is where Docker enters into the picture! Docker is containerization technology and it allows us to have repeatable process to provision environments in a declarative way. It also gives us a try and tear down model where we can experiment and easily start again from the initial state. Docker can also help us with easily setting up a MongoDB Replica Set. Within our Docker Host, we can create Docker Network which would give us the isolated DNS resolution across containers. Then we can start creating the MongoDB docker containers. They would initially be unaware of each other. However, we can initialise the replication by connecting to one of the containers and running the replica set initialisation command. Finally,  we can deploy our application container under the same docker network.      There are a handful of advantages to setting up this with Docker and I want to specifically touch on some of them:    It can be automated easily. This is especially crucial for test environments which are provisioned on demand.  It’s repeatable! The declarative nature of the Dockerfile makes it possible to end up with the same environment setup even if you run the scripts months later after your initial setup.  Familiarity! Docker is a widely known and used tool for lots of other purposes and familiarity to the tool is high. Of course, this may depend on your development environment  Let’s make it work! First of all, I need to create a docker network. I can achieve this by running the "docker network create” command and giving it a unique name.   docker network create mymongocluster 
The next step is to create the MongoDB docker containers and start them. I can use “docker run” command for this. Also, MongoDB has an official image on Docker Hub. So, I can reuse that to simplify the acqusition of MongoDB. For convenience, I will name the container with a number suffix. The container also needs to be tied to the network we have previously created. Finally, I need to specify the name of the replica set for each container.
 docker run name mongonode1 d net mymongocluster mongo replSet “rs0" 
First container is created and I need to run the same command to create two more MongoDB containers. The only difference is with the container names.
  docker run name mongonode2 d net mymongocluster mongo replSet 
docker run name mongonode3 d net mymongocluster mongo replSet “rs0" 
I can see that all of my MongoDB containers are at the running state by executing the “docker ps” command.
   
 In order to form a replica set, I need to initialise the replication. I will do that by connecting to one of the containers through the “docker exec” command and starting the mongo shell client.
  docker exec it mongonode1 mongo 
  
 As I now have a connection to the server, I can initialise the replication. This requires me to declare a config object which will include connection details of all the servers.
  config = {
 : ,
 : [
 {
 : 0,
 : 
 },
 {
 : 1,
 : 
 },
 {
 : 2,
 : 
 }
 ]
 } 
Finally, we can run “rs.initialize" command to complete the set up.
 You will notice that the server I am connected to will be elected as the primary in the replica set shortly. By running “rs.status()”, I can view the status of other MongoDB servers within the replica set. We can see that there are two secondaries and one primary in the replica set.
 .NET Core Application
As a scenario, I want to run my .NET Core application which writes data to a MongoDB database and start reading it in a loop. This application will be connecting to the MongoDB replica set which we have just created.  This is a standard .NET Core console application which you can create by running the following script:
The csproj file for this application looks like below.
   
 
 Exe
 netcoreapp2.0
 
 
 
 
 
 
 
Notice that I have two interesting dependencies there. Polly is used to retry the read calls to MongoDB based on defined policies. This bit is interesting as I would expect the MongoDB client to handle that for read calls. However, it might be also a good way of explicitly stating which calls can be retried inside your application. Bogus, on the other hand, is just here to be able to create fake names to make the application a bit more realistic :)
  Finally, this is the code to make this application work:
   Program
{
 Main([] args)
 {
 settings = MongoClientSettings
 {
 Servers = []
 {
 MongoServerAddress(, 27017),
 MongoServerAddress(, 27017),
 MongoServerAddress(, 27017)
 },
 ConnectionMode = ConnectionMode.ReplicaSet,
 ReplicaSetName = 
 };
 client = MongoClient(settings);
 database = client.GetDatabase();
 collection = database.GetCollection&lt;User&gt;();
 System.Console.WriteLine(, client.Cluster.ClusterId);
 client.Cluster.DescriptionChanged += ( sender, ClusterDescriptionChangedEventArgs foo) =&gt; 
 {
 System.Console.WriteLine(, foo.NewClusterDescription.ClusterId);
 };
 ( i = 0; i &lt; 100; i++)
 {
 user = User { Id = ObjectId.GenerateNewId(), Name = Bogus.Faker().Name.FullName() };
 collection.InsertOne(user);
 }
 ()
 {
 randomUser = collection.GetRandom();
 Console.WriteLine(randomUser.Name);
 Thread.Sleep(500);
 }
 }
} 
This is not the most beautiful and optimized code ever but should demonstrate what we are trying to achieve by having a replica set. It's actually the GetRandom method on the MongoDB collection object which handles the retry:
   CollectionExtensions 
{
 Random random = Random();
 T GetRandom&lt;T&gt;( IMongoCollection&lt;T&gt; collection) 
 {
 retryPolicy = Policy
 .Handle&lt;MongoCommandException&gt;()
 .Or&lt;MongoConnectionException&gt;()
 .WaitAndRetry(2, retryAttempt =&gt; 
 TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)) 
 );
 retryPolicy.Execute(() =&gt; GetRandomImpl(collection));
 }
 T GetRandomImpl&lt;T&gt;( IMongoCollection&lt;T&gt; collection)
 {
 collection.Find(FilterDefinition&lt;T&gt;.Empty)
 .Limit(-1)
 .Skip(random.Next(99))
 .First();
 }
} 
I will run this through docker as well and here is the dockerfile for this:    FROM microsoft/dotnet:2-sdk
COPY ./mongodb-replica-set.csproj /app/
WORKDIR /app/
RUN dotnet --info
RUN dotnet restore
ADD ./ /app/
RUN dotnet publish -c DEBUG -o out
ENTRYPOINT ["dotnet", "out/mongodb-replica-set.dll"] 
When it starts, we can see that it will output the result to the console:
   
 Prove that It Works!
In order to demonstrate the effect of the replica set, I want to take down the primary node. First of all, we need to have look at the output of rs.status command we have previously ran in order to identify the primary node. We can see that it’s node1!     
 Secondly, we need to get the container id for that node.     
 Finally, we can kill the container by running the “docker stop command”. Once the container is stopped, you will notice that application will gracefully recover and continue reading the data.
Setting up a MongoDB Replica Set with Docker and Connecting to It With a .NET Core App
https://www.tugberkugurlu.com/archive/setting-up-a-mongodb-replica-set-with-docker-and-connecting-to-it-with-a--net-core-app
https://kchodorow.com/2010/07/30/replica-sets-part-1-master-slave-is-so-2009/
Replica Sets Part 1: Master-Slave is so 2009
2010-07-30
Kchodorow
<div><article>
	<div>
	<p><em>Replica sets are really cool and can be customized out the wazoo, so I’ll be doing a couple of posts on them (I have three written so far and I think I have a few more in there). If there’s any replica-set-related topic you’d like to see covered, please let me know and I’ll make sure to get to it.</em></p>
<p>This post shows how to do the “Hello, world” of replica sets. I was going to start with a post explaining what they are, but coding is more fun than reading. For now, all you have to know is that they’re master-slave with automatic failover.</p>
<p>Make sure you have version <a href="http://www.mongodb.org/downloads">1.5.7</a> or better of the database before trying out the code below.</p>
<p><b>Step 1: Choose a name for your set.</b></p>
<p>This is just organizational, so <a href="http://www.babyzone.com/babynames/nameinventor.asp?gender=neutral">choose whatever</a>. I’ll be using “<a href="http://en.wikipedia.org/wiki/Unicomplex">unicomplex</a>” for my example.</p>
<p><b>Step 2: Create the data directories.</b></p>
<p>We need a data directory for each server we’ll be starting:</p>
<pre>$ mkdir -p ~/dbs/borg1 ~/dbs/borg2 ~/dbs/arbiter
</pre>
<p><b>Step 3: Start the servers.</b></p>
<p>We’ll start up our three servers:</p>
<pre>$ ./mongod --dbpath ~/dbs/borg1 --port 27017 --replSet unicomplex/
$ ./mongod --dbpath ~/dbs/borg2 --port 27018 --replSet unicomplex/
$ ./mongod --dbpath ~/dbs/arbiter --port 27019 --replSet unicomplex/
</pre>
<p><b>Step 4: Initialize the set.</b></p>
<p>Now you have to tell the set, “hey, you exist!” Start up the <em>mongo</em> shell and run:</p>
<pre>MongoDB shell version: 1.5.7
connecting to: test
&gt; rs.initiate({"_id" : "unicomplex", "members" : [
... {"_id" : 0, "host" : "localhost:27017"}, 
... {"_id" : 1, "host" : "localhost:27018"}, 
... {"_id" : 2, "host" : "localhost:27019", "arbiterOnly" : true}]})
{
 "info" : "Config now saved locally. Should come online in about a minute.",
 "ok" : 1
}
</pre>
<p><em>rs</em> is a global variable that holds a bunch of useful replica set functions. </p>
<p>The message says it’ll be online in about a minute, but it’s always been ~5 seconds for me. Once you see the following line in one of the logs:</p>
<pre>replSet PRIMARY
</pre>
<p>…your replica set is ready to go!</p>
<p><b>Playing with the set</b></p>
<p>One of the servers will be master, the other is a slave. You can figure out which is which by running the <em>isMaster</em> command in the shell:</p>
<pre>&gt; db.isMaster()
{
 "ismaster" : true,
 "secondary" : false,
 "hosts" : [
 "localhost:27017",
 "localhost:27018",
 ],
 "arbiters" : [
 "localhost:27019"
 ],
 "ok" : 1
}
</pre>
<p>If <em>db</em> isn’t primary, the server that is will be listed in the “primary” field:</p>
<pre>&gt; db.isMaster()
{
 "ismaster" : false,
 "secondary" : true,
 "hosts" : [
 "localhost:27017",
 "localhost:27018",
 ],
 "arbiters" : [
 "localhost:27019"
 ],
 "primary" : "localhost:27018",
 "ok" : 1
}
</pre>
<p>Now, try killing the primary server. Wait a couple seconds and you’ll see the other (non-arbiter) server be elected primary. </p>
<p>Once there’s a new primary, restart the <em>mongod</em> you just killed. You’ll see it join in the fray, though not become master (there’s already a master, so it won’t rock the boat). After a few seconds, kill the current master. Now the old master will become master again!</p>
<p>It’s pretty fun to play with this, bringing them up and down and watching the mastership go back and forth (or maybe I’m easily amused).</p>
<p><b>Inserting and querying data</b></p>
<p>By default, slaves are for backup only, but you can also use them for queries (reads) if you set the “slave ok” flag. Connect to each of the servers and set this flag:</p>
<pre>&gt; db.getMongo().setSlaveOk()
&gt; borg2 = connect("localhost:27018/test")
connecting to: localhost:27018/test
test
&gt; borg2.getMongo().setSlaveOk()
</pre>
<p>Now you can insert, update, and remove data on the master and read the changes on the slave.</p>
<p>On Monday: <a href="http://www.kchodorow.com/blog/2010/08/02/replica-sets-part-2-what-are-replica-sets/">the “why” behind what we just did</a>.</p>
	</div>
	
</article>||||I|||| Skip to content

 Kristina Chodorow's Blog

 Snail in a Turtleneck

 Replica Sets Part 1: Master-Slave is so 2009

 Posted by kchodorowJuly 30, 2010 Posted in MongoDB Tags: replica sets

 Replica sets are really cool and can be customized out the wazoo, so I’ll be doing a couple of posts on them (I have three written so far and I think I have a few more in there). If there’s any replica-set-related topic you’d like to see covered, please let me know and I’ll make sure to get to it.

 This post shows how to do the “Hello, world” of replica sets. I was going to start with a post explaining what they are, but coding is more fun than reading. For now, all you have to know is that they’re master-slave with automatic failover.

 Make sure you have version 1.5.7 or better of the database before trying out the code below.

 Step 1: Choose a name for your set.

 This is just organizational, so choose whatever. I’ll be using “unicomplex” for my example.

 Step 2: Create the data directories.

 We need a data directory for each server we’ll be starting:

 $ mkdir -p ~/dbs/borg1 ~/dbs/borg2 ~/dbs/arbiter
 

 Step 3: Start the servers.

 We’ll start up our three servers:

 $ ./mongod --dbpath ~/dbs/borg1 --port 27017 --replSet unicomplex/
 $ ./mongod --dbpath ~/dbs/borg2 --port 27018 --replSet unicomplex/
 $ ./mongod --dbpath ~/dbs/arbiter --port 27019 --replSet unicomplex/
 

 Step 4: Initialize the set.

 Now you have to tell the set, “hey, you exist!” Start up the mongo shell and run:

 MongoDB shell version: 1.5.7
 connecting to: test
 > rs.initiate({"_id" : "unicomplex", "members" : [
 ... {"_id" : 0, "host" : "localhost:27017"}, 
 ... {"_id" : 1, "host" : "localhost:27018"}, 
 ... {"_id" : 2, "host" : "localhost:27019", "arbiterOnly" : true}]})
 {
 "info" : "Config now saved locally. Should come online in about a minute.",
 "ok" : 1
 }
 

 rs is a global variable that holds a bunch of useful replica set functions.

 The message says it’ll be online in about a minute, but it’s always been ~5 seconds for me. Once you see the following line in one of the logs:

 replSet PRIMARY
 

 …your replica set is ready to go!

 Playing with the set

 One of the servers will be master, the other is a slave. You can figure out which is which by running the isMaster command in the shell:

 > db.isMaster()
 {
 "ismaster" : true,
 "secondary" : false,
 "hosts" : [
 "localhost:27017",
 "localhost:27018",
 ],
 "arbiters" : [
 "localhost:27019"
 ],
 "ok" : 1
 }
 

 If db isn’t primary, the server that is will be listed in the “primary” field:

 > db.isMaster()
 {
 "ismaster" : false,
 "secondary" : true,
 "hosts" : [
 "localhost:27017",
 "localhost:27018",
 ],
 "arbiters" : [
 "localhost:27019"
 ],
 "primary" : "localhost:27018",
 "ok" : 1
 }
 

 Now, try killing the primary server. Wait a couple seconds and you’ll see the other (non-arbiter) server be elected primary.

 Once there’s a new primary, restart the mongod you just killed. You’ll see it join in the fray, though not become master (there’s already a master, so it won’t rock the boat). After a few seconds, kill the current master. Now the old master will become master again!

 It’s pretty fun to play with this, bringing them up and down and watching the mastership go back and forth (or maybe I’m easily amused).

 Inserting and querying data

 By default, slaves are for backup only, but you can also use them for queries (reads) if you set the “slave ok” flag. Connect to each of the servers and set this flag:

 > db.getMongo().setSlaveOk()
 > borg2 = connect("localhost:27018/test")
 connecting to: localhost:27018/test
 test
 > borg2.getMongo().setSlaveOk()
 

 Now you can insert, update, and remove data on the master and read the changes on the slave.

 On Monday: the “why” behind what we just did.

 Share this:

 * Twitter
 * Facebook
 * 

 Like this:

 Like Loading...

 Related

 There must be 50 ways to start your Mongo

 April 23, 2010
 In "MongoDB"

 Replica Sets Part 2: What are Replica Sets?

 August 2, 2010
 In "MongoDB"

 Part 3: Replica Sets in the Wild

 August 3, 2010
 In "MongoDB"

 Posted by kchodorowJuly 30, 2010 Posted in MongoDB Tags: replica sets

 Post navigation

 Previous Post Previous post:
 MongoDB backups & corn on the cob in 10 minutes
 Next Post Next post:
 Replica Sets Part 2: What are Replica Sets?

 24 thoughts on “ Replica Sets Part 1: Master-Slave is so 2009 ”

 1. Mardix says:
 August 4, 2010 at 2:56 am

 Thanks. Good post!I got a question, how do you set Replica Set to make it work properly with PHP? Thanks Kristina.

 Like Like

 Reply
 2. kristina1 says:
 August 4, 2010 at 1:55 pm

 Thanks! See example #1 at http://php.net/manual/en/mongo.construct.php.1.0.9 will be coming out in the next day or two.

 Like Like

 Reply
 3. Mardix says:
 August 4, 2010 at 9:48 pm

 Kristina, thanx so much. I'm a big fan of yours…. Whoooo Ooooohhhhh!

 Like Like

 Reply
 4. kristina1 says:
 August 5, 2010 at 1:53 pm

 Haha, thanks!

 Like Like

 Reply
 1. arun singh says:
 July 13, 2014 at 1:00 am

 Hi kristina,
 I need a simple document how to upgrade mongodb version through live data , online & offline

 Like Like

 Reply
 5. Mark says:
 December 24, 2010 at 8:09 am

 It should be noted that it appears that you can’t have a / in your replica name. Everything looks alright until you try to initialize your set it and it always complains that it can’t find any servers (even if you’re on one of them as you try to configure it!)

 Like Like

 Reply
 1. Anonymous says:
 December 24, 2010 at 5:22 pm

 Good point! I added a note about that to http://www.mongodb.org/display/DOCS/Replica+Set+Configuration#ReplicaSetConfiguration-Requiredarguments.

 Like Like

 Reply
 6. Anonymous says:
 February 3, 2011 at 9:53 am

 Hi,how to execute the queries below.
 MongoDB shell version: 1.5.7
 connecting to: test
 > rs.initiate({“_id” : “unicomplex”, “members” : [
 … {“_id” : 0, “host” : “localhost:27017”},
 … {“_id” : 1, “host” : “localhost:27018”},
 … {“_id” : 2, “host” : “localhost:27019”, “arbiterOnly” : true}]})
 Atleast one full execution of the query…Please…

 Like Like

 Reply
 1. Anonymous says:
 February 3, 2011 at 2:07 pm

 You’ll need to upgrade, I don’t think replica sets existed in 1.5.7. I think 1.8.0-rc0 is coming out today, give that a try!

 Like Like

 Reply
 1. Anonymous says:
 February 3, 2011 at 2:50 pm

 Thanks for your kind attention on my question…Thanks for your reply….I
 understood…

 Like Like

 2. Anonymous says:
 February 7, 2011 at 8:06 am

 Hi Kristina..U told that the version 1.8.0-rco will be get released I think its not yet release..Can u tel When it will be get releases?

 Like Like

 3. Anonymous says:
 February 12, 2011 at 7:07 am

 Hi kristina1,I am using 64-bit MongoDB and i had done testing with 64-bit MongoDB.The testing details as follows:- 1)I gave one million files as backup to my server using mongodb as my Database Storage. 2)My backup data size is “22.8-GB”. 3)The mongodb size is “1.95GB”. Now, my question, is there any settings available to compress the DB-Size Before configuring the backup to the server?.Please help me folks…Advance Thanks,

 Like Like

 7. Sudhakar says:
 March 14, 2011 at 6:44 am

 Hi,

 The above example works perfectly and its great when all the three nodes working on a single server.
 But having problem when nodes are in different servers, using above example while working with Python (http://api.mongodb.org/python/1.9%2B/examples/replica_set.html), I’m getting problem:

 Problem: When I kill mongo server from sf1:27017 [Primary] instance then my secondary [sf2:27017] should elect as Primary to overcome the failover which is not happening.

 Complete discussion:
 http://comments.gmane.org/gmane.comp.db.mongodb.user/27810

 Need help on this.

 Like Like

 Reply
 1. Anonymous says:
 March 14, 2011 at 3:36 pm

 Failover isn’t instantaneous, especially with network latency. You have to put a try/except around your database calls and wait (or keep retrying in a try/except) until a new master is elected.

 Like Like

 Reply
 8. Erick says:
 December 20, 2011 at 6:02 pm

 Hi,
 I tried to use your example above, buy I keep getting the following error on the initiate code:
 ‘couldn’t initiate : need all members up to initiate, not ok: localhost27018’

 I have also tried adding using rs.add, but that gave me the same error. I’m using 2.0.2 x64 version on Windows. Any ideas on what to do?

 Thanks.

 Like Like

 Reply
 1. Cayden Liew says:
 October 16, 2012 at 1:17 am

 Hi Erick, im having the same problem, are you able to solve that? thanks.

 Like Like

 Reply
 1. Erick says:
 October 16, 2012 at 7:05 am

 Cayden,
 No I never did. I’m just working with a single instance for now and figure I’ll attack the issue later. But I was disappointed to not receive any help on this.

 Like Like

 2. kristina1 says:
 October 16, 2012 at 7:55 am

 Hey guys, not sure why I didn’t see this comment before. If you have questions, the mailing list (groups.google.com/d/topic/mongodb-user/) is a good place to get help. @ericklind:disqus in the error you pasted, it looks like you’re missing a : in your host string: “localhost:27018”.

 Like Like

 9. Rakesh Sankar says:
 March 25, 2012 at 10:58 pm

 Please correct me if I am wrong, shouldn’t we start these mongo with “–journal” option.

 Like Like

 Reply
 1. kristina1 says:
 March 26, 2012 at 6:57 am

 In 2.0, journaling is on by default. You can turn it of with –nojournal. If you’re still using 1.8, yes, use –journal. When this was written, journaling didn’t exist, yet.

 Like Like

 Reply
 10. Manivannan Thirugnanam says:
 August 31, 2015 at 3:22 am

 Hi,
 i tried with multiple systems instead of single system. i can able to done replicaset. this scenario i am using ip to specify systems but i need to do without hardcode anything like specific ip or system name.. how it is possible to make this replication…? please help me…

 Like Like

 Reply
 1. kristina1 says:
 August 31, 2015 at 12:46 pm

 In general you’re going to want to use hostnames so you can change the IPs underneath. You have to configure a set somewhere, so you need some things hardcoded. You might want to ask on the list (https://groups.google.com/forum/#!forum/mongodb-user) if you have specific configuration requirements.

 Like Like

 Reply
 11. Ravinder Battula says:
 September 28, 2015 at 11:37 pm

 Hi Kristina,

 I am going through your blog on MongoDB, it is really excellent and more informative with simple easy steps. I became a fan of your blog. i have configured 3 shards and added to cluster. I do not know how to add members to each shard as primary member, secondary member and Arbiter. I have mentioned below what I have done for your review. Could you please help me to add members as said.

 Shard configuration:

 [root@localhost bin]# mkdir -p /srv/sharding/shard1/data /srv/sharding/shard2/data /srv/sharding/shard3/data

 [root@localhost bin]# mkdir -p /srv/sharding/configsvr1/data /srv/sharding/configsvr2/data /srv/sharding/configsvr3/data

 ./mongod –shardsvr –dbpath /srv/sharding/shard1/data –port 4001

 ./mongod –shardsvr –dbpath /srv/sharding/shard2/data –port 4002

 ./mongod –shardsvr –dbpath /srv/sharding/shard3/data –port 4003

 Shard all 3 mongod instances considering each as a config server:

 ./mongod –configsvr –dbpath /srv/sharding/configsvr1/data –port 4011

 ./mongod –configsvr –dbpath /srv/sharding/configsvr2/data –port 4012

 ./mongod –configsvr –dbpath /srv/sharding/configsvr3/data –port 4013

 Start Query Router (mongos) giving reference to all config db’s at specific port:

 [root@localhost bin]# ./mongos –port 2000 –configdb localhost:4011,localhost:4012,localhost:4013

 Open mongo connecting to mongos on the same port on which mongos is running:

 ./mongo –port 2000

 add each shard to the cluster:

 mongos> sh.addShard(“localhost:4001”)

 { “shardAdded” : “shard0000”, “ok” : 1 }

 mongos> sh.addShard(“localhost:4002”)

 { “shardAdded” : “shard0001”, “ok” : 1 }

 mongos> sh.addShard(“localhost:4003”)

 { “shardAdded” : “shard0002”, “ok” : 1 }

 mongos>

 mongos> sh.status()

 — Sharding Status —

 sharding version: {

 “_id” : 1,

 “minCompatibleVersion” : 5,

 “currentVersion” : 6,

 “clusterId” : ObjectId(“56052aa6b9d93739b67bbb57”)

 }

 shards:

 { “_id” : “shard0000”, “host” : “localhost:4001” }

 { “_id” : “shard0001”, “host” : “localhost:4002” }

 { “_id” : “shard0002”, “host” : “localhost:4003” }

 balancer:

 Currently enabled: yes

 Currently running: no

 Failed balancer rounds in last 5 attempts: 0

 Migration Results for the last 24 hours:

 No recent migrations

 databases:

 { “_id” : “admin”, “partitioned” : false, “primary” : “config” }

 Like Like

 Reply
 1. kristina1 says:
 September 29, 2015 at 8:21 am

 Thanks! Glad you like my blog.

 Take a look at the documentation for setting up a replica set: http://docs.mongodb.org/manual/tutorial/deploy-replica-set/. Once you have three replica sets running, add each one as a shard: http://docs.mongodb.org/manual/tutorial/add-shards-to-shard-cluster/.

 Like Like

 Reply

 Leave a Reply

 Δ

 Subscribe to get new posts in your email:

 Type your email…

 Subscribe

 Kristina Chodorow's Blog , Blog at WordPress.com.
 * Follow Following
 + Kristina Chodorow's Blog
 * Already have a WordPress.com account? Log in now.
 * 
 + Kristina Chodorow's Blog
 + Customize
 + Follow Following
 + Sign up
 + Log in
 + Copy shortlink
 + Report this content
 + View post in Reader
 + Manage subscriptions
 + Collapse this bar
 %d bloggers like this:
Replica sets are really cool and can be customized out the wazoo, so I’ll be doing a couple of posts on them (I have three written so far and I think I have a few more in there). If there’s any replica-set-related topic you’d like to see covered, please let me know and I’ll make sure to get to it. 
This post shows how to do the “Hello, world” of replica sets. I was going to start with a post explaining what they are, but coding is more fun than reading. For now, all you have to know is that they’re master-slave with automatic failover.
Make sure you have version 1.5.7 or better of the database before trying out the code below.
 Step 1: Choose a name for your set. 
This is just organizational, so choose whatever. I’ll be using “unicomplex” for my example.
 Step 2: Create the data directories. 
We need a data directory for each server we’ll be starting:
$ mkdir -p ~/dbs/borg1 ~/dbs/borg2 ~/dbs/arbiter
 Step 3: Start the servers. 
We’ll start up our three servers:
$ ./mongod --dbpath ~/dbs/borg1 --port 27017 --replSet unicomplex/
$ ./mongod --dbpath ~/dbs/borg2 --port 27018 --replSet unicomplex/
$ ./mongod --dbpath ~/dbs/arbiter --port 27019 --replSet unicomplex/
 Step 4: Initialize the set. 
Now you have to tell the set, “hey, you exist!” Start up the mongo shell and run:
MongoDB shell version: 1.5.7
connecting to: test
&gt; rs.initiate({"_id" : "unicomplex", "members" : [
... {"_id" : 0, "host" : "localhost:27017"}, 
... {"_id" : 1, "host" : "localhost:27018"}, 
... {"_id" : 2, "host" : "localhost:27019", "arbiterOnly" : true}]})
{
 "info" : "Config now saved locally. Should come online in about a minute.",
 "ok" : 1
}
 rs is a global variable that holds a bunch of useful replica set functions. 
The message says it’ll be online in about a minute, but it’s always been ~5 seconds for me. Once you see the following line in one of the logs:
replSet PRIMARY
…your replica set is ready to go!
 Playing with the set 
One of the servers will be master, the other is a slave. You can figure out which is which by running the isMaster command in the shell:
&gt; db.isMaster()
{
 "ismaster" : true,
 "secondary" : false,
 "hosts" : [
 "localhost:27017",
 "localhost:27018",
 ],
 "arbiters" : [
 "localhost:27019"
 ],
 "ok" : 1
}
If db isn’t primary, the server that is will be listed in the “primary” field:
&gt; db.isMaster()
{
 "ismaster" : false,
 "secondary" : true,
 "hosts" : [
 "localhost:27017",
 "localhost:27018",
 ],
 "arbiters" : [
 "localhost:27019"
 ],
 "primary" : "localhost:27018",
 "ok" : 1
}
Now, try killing the primary server. Wait a couple seconds and you’ll see the other (non-arbiter) server be elected primary. 
Once there’s a new primary, restart the mongod you just killed. You’ll see it join in the fray, though not become master (there’s already a master, so it won’t rock the boat). After a few seconds, kill the current master. Now the old master will become master again!
It’s pretty fun to play with this, bringing them up and down and watching the mastership go back and forth (or maybe I’m easily amused).
 Inserting and querying data 
By default, slaves are for backup only, but you can also use them for queries (reads) if you set the “slave ok” flag. Connect to each of the servers and set this flag:
&gt; db.getMongo().setSlaveOk()
&gt; borg2 = connect("localhost:27018/test")
connecting to: localhost:27018/test
test
&gt; borg2.getMongo().setSlaveOk()
Now you can insert, update, and remove data on the master and read the changes on the slave.
On Monday: the “why” behind what we just did.
Replica Sets Part 1: Master-Slave is so 2009
https://kchodorow.com/2010/07/30/replica-sets-part-1-master-slave-is-so-2009/
https://news.ycombinator.com/item?id=3202028
yes, we are using mongo from 1.6.3. Reliability, Locking and Data security (not ...
2011-11-06
None
<div><p></p></div>||||I|||| Hacker News new | past | comments | ask | show | jobs | submit login        
         

 stoneg on Nov 6, 2011 | parent | context | favorite | on: Failing with MongoDB        
         
 yes, we are using mongo from 1.6.3. Reliability, Locking and Data security (not losing data) are never first priorities on their to-do list, they just push new features and busy doing marketing propaganda about how web-scale mongodb is(which is fake). I submitted a jira issue about losing data when sync a slave, it's already 3+ months, all they did is let me try the new releases to see if it fix the problem. I tried the latest 2.0.1 release, and it's still cause data loss. Every time I sync a new slave, I pray to god, hoping not lose data.
         
 How come a DB lose data so frequently and it sill call itself web-scale? It just breaks when you need scale!       
         
 For auto-sharding it's also super unreliable, tried once and it failed, and now we are using a lib that do application level sharding. We are also considering move to other databases that at least know not losing data is the first and most important thing of a DB.     
         
 Some one summarized the issues of mongodb, http://pastebin.com/raw.php?i=FD3xe6Jt , we experienced most problems in the article. So just a remind for someone who want to create serious product using mongodb, read the article, it's not FUD, it's just so true that I hope I read it 1 year ago, so we don't have to try moving so much legacy data to a new database solution.   
         
         
         
         
         
         
         
         
         
Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact        
         
Search:         

Hacker News new | past | comments | ask | show | jobs | submit login        
         
 stoneg on Nov 6, 2011 | parent | context | favorite | on: Failing with MongoDB        
         
 yes, we are using mongo from 1.6.3. Reliability, Locking and Data security (not losing data) are never first priorities on their to-do list, they just push new features and busy doing marketing propaganda about how web-scale mongodb is(which is fake). I submitted a jira issue about losing data when sync a slave, it's already 3+ months, all they did is let me try the new releases to see if it fix the problem. I tried the latest 2.0.1 release, and it's still cause data loss. Every time I sync a new slave, I pray to god, hoping not lose data.
         
 How come a DB lose data so frequently and it sill call itself web-scale? It just breaks when you need scale!       
         
 For auto-sharding it's also super unreliable, tried once and it failed, and now we are using a lib that do application level sharding. We are also considering move to other databases that at least know not losing data is the first and most important thing of a DB.     
         
 Some one summarized the issues of mongodb, http://pastebin.com/raw.php?i=FD3xe6Jt , we experienced most problems in the article. So just a remind for someone who want to create serious product using mongodb, read the article, it's not FUD, it's just so true that I hope I read it 1 year ago, so we don't have to try moving so much legacy data to a new database solution.   
         
         
         
         
         
         
         
         
         
Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact        
         
Search:
yes, we are using mongo from 1.6.3. Reliability, Locking and Data security (not ...
https://news.ycombinator.com/item?id=3202028