Replication practice questions

The member must be the node with the highest amount of storage allocated.

Why it fails: Storage allocation is unrelated to election eligibility. MongoDB elections are based on data freshness and the voting protocol. A node with significantly more data but a lagging oplog synchronization status would still be ineligible, as the protocol prioritizes nodes that possess the most recent, consistent state of the database.

The member must have at least 50% of the total disk space available.

Why it fails: Disk capacity requirements are not part of the election protocol. While sufficient disk space is necessary for the node to function correctly and receive replication updates, the election algorithm evaluates oplog position and network visibility, not the underlying hardware resource availability or remaining capacity of the storage volumes.

The member must be running a different OS than the current primary.

Why it fails: Heterogeneous operating system environments are supported in MongoDB, but they have no bearing on election eligibility. Consistency is maintained through the replication protocol, which operates at the application level. Whether nodes run on Linux, Windows, or macOS, the election logic remains identical across all supported platforms within the set.

readPreference=nearest

Why it fails: The nearest read preference selects the node with the lowest network latency. It does not account for data freshness and may return stale data if the nearest node is a secondary that has not yet replicated the latest writes from the primary. It is purely performance-oriented, not consistency-oriented.

readConcern=majority

Why it fails: While majority read concern ensures the data read has been acknowledged by a majority of nodes, it does not strictly guarantee that the read operation reflects the most recent writes from the client session. It is a necessary component for consistency but not the complete solution for session-based sequential ordering.

writeConcern=majority

Why it fails: Write concern determines the durability of the write operation but does not dictate the consistency of subsequent read operations. While it is best practice to use majority write concern, it does not guarantee that a subsequent read will be able to see that data unless session causal consistency is also enabled.

Manually edit the data files in the /data/db directory.

Why it fails: Directly modifying the data files or configuration stored in the MongoDB data directory is highly dangerous and unsupported. MongoDB manages its internal state, including the replica set configuration, through protected system collections. Manual edits will likely lead to data corruption or the node being permanently removed from the cluster.

Use the rs.initiate() method on the new node.

Why it fails: rs.initiate() is used only when starting a brand new replica set. If used on a node that is already part of a running set, or if used to 'add' a node to an existing set, it will fail because the command expects to define the configuration from scratch, not join.

Node 2

Why it fails: Node 2 has a priority of 0, which explicitly prevents it from becoming a primary. It can serve reads, but it will never be a candidate for an election. Therefore, it is impossible for Node 2 to win this election, regardless of the health of the other nodes in the set.

Both Node 1 and Node 2 will share the primary role.

Why it fails: A MongoDB replica set always maintains exactly one primary at any given time. The consensus protocol is designed to ensure there is no split-brain scenario where two nodes believe they are the primary. If multiple nodes could become primary, it would lead to data divergence and severe corruption.

The cluster will remain without a primary until Node 0 is repaired.

Why it fails: The replica set is designed for high availability. As long as a majority of nodes remain online, the set will automatically elect a new primary. Since two out of three nodes are still functional, the majority requirement is satisfied, and the set will proceed with an automatic election.

To determine the node's priority in an election.

Why it fails: The 'priority' field is used to influence which node is chosen as primary, while the 'votes' field determines if a node has the authority to participate in the voting process at all. They are separate configuration properties that serve distinct roles in the overall management of replica set elections.

To define the read preference of the client connection.

Why it fails: Read preference is a client-side setting that dictates how the driver routes queries. It has no relationship with the server-side configuration of votes. The server is unaware of the client's read preference configuration, and the number of votes a node has does not influence client read routing behavior.

To set the maximum number of concurrent connections for the node.

Why it fails: The votes field is strictly related to the replication protocol and election consensus. It does not control server-side resources like memory, CPU allocation, or the maximum number of concurrent client connections. These limits are managed via separate configuration settings in the mongod.conf file or operating system environment variables.

It stops replicating data from the primary to save bandwidth.

Why it fails: Hidden members continue to replicate all data from the primary just like a standard secondary. Being hidden only affects the member's visibility to clients and its eligibility for elections. The replication process itself remains fully functional, ensuring the node maintains an up-to-date copy of the database at all times.

It is invisible to the primary and does not participate in any replication.

Why it fails: A hidden member is very much visible to the primary and the rest of the replica set. It participates in the replication heartbeat and maintains a complete copy of the data. The 'hidden' attribute only applies to the client-side drivers, preventing them from sending read queries to the node.

It is prohibited from participating in replica set elections.

Why it fails: While hidden members usually have a priority of 0, this is a separate setting. A hidden member could technically be configured to participate in elections if desired, although it is best practice to keep priority at 0 for nodes that are intended to be hidden from the client traffic.

All nodes configured with priority 0.

Why it fails: Setting all nodes to priority 0 would prevent any node from becoming primary. In such a configuration, the replica set would become read-only if the primary failed, as no node would be eligible to run for election, completely defeating the purpose of high availability and automatic failover in MongoDB.

Enabling the 'delayed' attribute on all members.

Why it fails: The delayed attribute is used to maintain a copy of the data that lags behind the primary. Enabling this on all nodes would mean that none of the nodes have current data, which is completely counterproductive for a production environment and would result in significant data loss during a switchover.

Setting all nodes to 'hidden' status.

Why it fails: Hidden nodes are excluded from service discovery and are not intended to act as primary members for production traffic. Configuring all nodes as hidden would prevent clients from effectively finding the primary, causing application connection errors and making the replica set unusable for standard read and write operations in production.

The election will fail because the majority cannot be reached.

Why it fails: The replica set has three members, so a majority requires two nodes. Even after the primary crashes, two secondary nodes remain active. Since these two nodes are enough to form a quorum, an election will definitely be successful, provided the nodes can communicate with each other over the network.

The set will enter a read-only state indefinitely.

Why it fails: A read-only state only occurs if no primary can be elected. In this three-node set, the two remaining secondaries can easily elect a new primary because they form a majority. Therefore, the set will resume write operations as soon as the new primary is elected and verified by the others.

The secondaries will initiate a rollback before electing a primary.

Why it fails: Rollbacks occur when a node joins a cluster and finds its data inconsistent with the majority. Here, the nodes were already part of the set and are perfectly synchronized. No rollback is needed because the state of the data is identical across all nodes at the time of the failure.

The set becomes read-only because srv2 was the only node allowed to be primary.

Why it fails: While srv2 had the highest priority, it is not the only node eligible to be primary. Both srv1 and srv2 are eligible. Since srv1 has a priority greater than zero, it is perfectly capable of being promoted to primary when srv2 is unavailable, allowing the set to remain writable.

srv3 will be elected as the new primary.

Why it fails: srv3 has a priority of 0, which explicitly disqualifies it from ever becoming a primary node. Regardless of the state of the other nodes, srv3 will never be promoted during an election. This configuration is often used to ensure specific nodes stay as secondaries to avoid latency or cost.

The election will fail, and the replica set will crash.

Why it fails: The replica set requires a majority to elect a new primary. With three original members, a majority is two. Even with srv2 down, srv1 and srv3 remain online and can communicate, forming a majority and allowing srv1 to be elected as primary, keeping the database fully operational and stable.

oplogSizeMB

Why it fails: The oplogSizeMB setting defines the maximum size of the operation log, which determines how much history the replica set keeps for replication. It has no bearing on connection timeouts or the logic used by members to detect if a primary node has gone offline or lost network connectivity.

replSetName

Why it fails: The replSetName configuration simply identifies the nodes that belong to the same replica set. It is a cluster identification string used to prevent cross-contamination between different clusters. It does not contain any logic related to timeouts, heartbeat frequencies, or the behavior of node reconnection during a failure event.

wiredTigerCacheSizeGB

Why it fails: This setting controls the amount of memory allocated to the WiredTiger storage engine's cache. It is purely performance-related for data storage and retrieval. It has no influence on the networking logic, replication protocols, or the election mechanics that govern how replica set nodes interact with one another.

db.listCollections()

Why it fails: This command is used to list the collections within a specific database, not to monitor replica set health. It is a standard operational command for viewing database contents, but it provides zero visibility into the underlying cluster architecture, replication logs, or the status of other nodes in the cluster.

db.serverStatus()

Why it fails: While db.serverStatus() provides detailed metrics about the mongod instance—such as memory, connections, and storage—it is not the primary command for checking replica set membership or synchronization. It is a general-purpose command for performance monitoring, rather than a specialized tool for managing cluster membership and election status.

rs.printReplicationInfo()

Why it fails: This command specifically reports on the status of the oplog, including its size and the time range of operations stored within it. While useful for replication troubleshooting, it is not the correct command for viewing the overall replica set status or checking the state of individual cluster members.

Set the priority of the Site B member to 0.

Why it fails: Setting priority to 0 prevents the member from being elected primary in normal circumstances, but it does not prevent it from becoming primary if it is the only member available and has the highest priority among remaining members. In a two-member surviving set, a priority 0 member can still be elected if no higher-priority member is available, unless other settings prevent it.

Set the write concern for the replica set to majority.

Why it fails: Write concern majority ensures that writes are acknowledged by a majority of voting members, but it does not control which member can become primary. Even with majority write concern, a member in Site B could become primary if it is the only available member and is eligible. Write concern affects durability, not election eligibility.

Set the votes of the Site B member to 0.

Why it fails: Setting votes to 0 makes the member a non-voting member, but it can still become primary if it has a non-zero priority and is the only electable member. Non-voting members can be elected primary if they are the only candidate, unless they are also configured as hidden or priority 0. Votes control election participation, not eligibility to become primary.

Configure a delayed secondary to allow point-in-time recovery.

Why it fails: A delayed secondary is useful for protection against human error by maintaining a delayed copy of data, but it does not help with automatic failover or high availability. Delayed members have priority 0 and cannot become primary. While valuable for disaster recovery, it is not a setting to ensure the replica set can accept writes after primary failure.

Set the write concern to w:1 to improve write performance during failover.

Why it fails: Write concern w:1 acknowledges writes from the primary only, which can lead to rollbacks if the primary fails before replication. It does not improve failover capability; in fact, it reduces durability. For high availability with data safety, a majority write concern is often recommended, but it is not a configuration for enabling failover.

Set the priority of all secondaries to 0 to prevent them from becoming primary.

Why it fails: Setting all secondaries' priority to 0 would make no member eligible to become primary if the primary fails, leading to a write outage. This defeats the goal of high availability. Priorities should be set to allow at least one secondary to be elected primary, typically with a higher priority on preferred members.

Configure the secondary in Site B with a higher priority than the primary in Site A.

Why it fails: Priority affects which eligible secondary is elected primary, but it does not change the majority requirement. If Site A fails, only one voting member remains in Site B. A single member cannot form a majority of a three-member set, so no election can occur regardless of priority settings.

Add an arbiter in Site B to provide an additional vote.

Why it fails: Adding an arbiter in Site B would increase the number of voting members to four, requiring three votes for a majority. If Site A fails, only the arbiter and the secondary in Site B remain, totaling two votes, which is not a majority of four. Thus, the secondary in Site B could not become primary, defeating the goal.

Set the secondary in Site B to have a vote of 0 and rely on the primary in Site A to remain available.

Why it fails: Setting the secondary in Site B to vote 0 removes its ability to participate in elections, making it a non-voting member. If Site A fails, there would be no voting members left to elect a primary, and the replica set would become read-only. This configuration reduces availability and does not meet the requirement.

Add the new member with { priority: 0, votes: 0 } and set its buildIndexes to false to speed up the initial sync.

Why it fails: Setting buildIndexes to false means the new member will not build indexes, which can speed up initial sync, but it also makes the member unsuitable for read operations that require indexes. Moreover, buildIndexes is a permanent setting that cannot be changed later without removing and re-adding the member. This is not a recommended way to minimize impact on the primary; it's a trade-off that sacrifices functionality.

Add the new member with { priority: 0, votes: 0 } and then initiate the initial sync during off-peak hours.

Why it fails: Setting priority 0 and votes 0 prevents the new member from becoming primary and from voting, which is good for a new member, but it does not minimize the impact on the primary during initial sync. Initial sync still reads from the primary or another sync source, potentially affecting performance regardless of priority or votes. The timing of the sync is more important than these settings for performance impact.

Add the new member with { priority: 0, votes: 0 } and use a secondary as the sync source by setting the new member's syncSourceHost to that secondary.

Why it fails: While using a secondary as the sync source can reduce load on the primary, the syncSourceHost setting is not a standard configuration option in MongoDB 6.0. MongoDB automatically selects a sync source based on proximity and oplog freshness. You cannot directly set syncSourceHost in the replica set configuration. Therefore, this approach is not valid, and the question tests whether you know the correct way to influence sync source selection.

mongodb-3

Why it fails: mongodb-3 is hidden, which means it cannot become primary regardless of its priority or votes. Hidden members are invisible to client applications and are ineligible for primary election. Even if it has the same oplog as mongodb-2, its hidden status disqualifies it.

No new primary will be elected because the remaining members cannot form a majority.

Why it fails: The replica set has three voting members. With mongodb-1 down, mongodb-2 and mongodb-3 remain, which is a majority (2 out of 3). Therefore, a new primary can be elected. The majority requirement is satisfied, so this option is incorrect.

mongodb-1 will remain primary until it is manually stepped down.

Why it fails: In a network partition, if the primary cannot communicate with a majority of voting members, it will step down after a short timeout. It does not remain primary indefinitely. Manual stepdown is not required; the system automatically detects loss of majority and steps down.

rs.printSlaveReplicationInfo()

Why it fails: rs.printSlaveReplicationInfo() is a valid command that shows replication lag for each secondary by comparing the last oplog entry timestamp on the secondary with the current time on the primary. However, the question asks for the command to check replication lag on the secondary, and this command is run on the primary to show lag for all secondaries. It is not run on the secondary itself. Thus, it is not the best choice when you are on the secondary and need to check its own lag.

db.serverStatus().repl

Why it fails: db.serverStatus().repl provides replication information such as the oplog window and replication lag, but it is not the most direct way to check lag. It returns a large document with many fields, and the lag is not always clearly stated. The rs.status() command is more straightforward for comparing optimes between members. Therefore, this is not the best choice for quickly determining replication lag.

db.printReplicationInfo()

Why it fails: db.printReplicationInfo() displays information about the oplog, such as its size and time range, but it does not show replication lag relative to the primary. It is useful for checking oplog window but not for determining how far behind a secondary is. Therefore, it is not the correct command for this scenario.

Configure the new member with a lower priority than the existing members.

Why it fails: While setting a lower priority (or 0) is beneficial, simply setting a lower priority than existing members does not guarantee it will not become primary if the existing members are unavailable. Setting priority to 0 is the definitive way to prevent it from becoming primary. A lower but non-zero priority could still result in election if other members are down.

Set the new member as hidden to prevent client reads.

Why it fails: Setting the new member as hidden would make it invisible to client applications, which may not be desired if the member is intended to serve reads. The scenario does not specify that the member should be hidden. Hidden members are typically used for dedicated tasks like reporting, not for general read scaling.

Set the new member's votes to 0 to prevent it from participating in elections.

Why it fails: Setting votes to 0 would prevent the new member from voting in elections, which could affect the replica set's ability to elect a primary if other members are unavailable. It is not necessary to set votes to 0 for a data-bearing member; this is typically reserved for arbiters. The new member should have a vote to maintain a healthy voting majority.

The write is automatically rolled back and re-applied when the old primary recovers.

Why it fails: Rollback occurs when an old primary rejoins and discovers its local oplog diverged from the new primary. It reverts the data to match the sync source. However, the client never received confirmation of the write, so it effectively disappears from the perspective of the application's current database state.

The write remains in the local storage of the crashed node and becomes visible upon restart.

Why it fails: While the data exists in the crashed node's storage files, it is not part of the active, consistent cluster state. Once the node rejoins, it must undergo a rollback process to align with the current primary, which involves discarding the unacknowledged write to maintain data integrity across the cluster.

The replica set triggers an automatic consistency recovery to force the write to other nodes.

Why it fails: MongoDB replica sets prioritize cluster consensus over individual unacknowledged writes. There is no automated mechanism to force a write that was never replicated onto other nodes after a primary failure. The system ensures that all nodes eventually converge on a single, consistent history starting from the last common ancestor.

It stores a copy of the data and can serve read queries.

Why it fails: Arbiters do not contain data files or the capacity to sync data from the primary. They are intentionally designed to be lightweight, meaning they cannot participate in read scaling or serve as a redundant data source. Their sole purpose is to contribute a vote to the replica set consensus.

It performs automatic failover by hosting a redundant copy of the oplog.

Why it fails: Arbiters do not maintain an oplog, nor do they process any data replication. They are strictly limited to the voting process. If the primary fails, the arbiter helps elect a new primary, but it does not participate in the actual data recovery or the synchronization of the new primary.

It acts as a load balancer for incoming read requests.

Why it fails: Arbiters are not part of the read-routing path. Incoming read requests are handled by the primary or secondaries depending on the read preference. Since an arbiter does not hold data, it cannot answer queries, nor does it have any networking components configured to proxy or balance traffic for clients.