CCNA Replication Questions

Without a majority, the remaining nodes cannot achieve consensus for write operations. To prevent split-brain and maintain consistent data, the replica set stops accepting writes. This ensures that no data is committed until the cluster can confirm that a quorum of nodes has successfully processed the operation.

This read concern ensures that the returned data is part of the majority-committed history. This means the data is permanent and cannot be rolled back during a future election. It is a fundamental feature for building reliable distributed systems where data integrity must be maintained across node failures.

During a rollback, the node reverts its local state to the point of divergence from the current primary. The discarded operations are written to separate BSON files on the local filesystem. This process ensures the cluster returns to a consistent state while preserving the orphaned data for forensic analysis.

This specific shell helper calculates the difference between the primary's last operation and the secondary's applied operation, outputting the lag in seconds. It is the most effective command for quickly identifying which nodes are falling behind and verifying that the entire set is effectively synchronized.

The first step of initial sync is to copy the data from all databases on the source. The node iterates through each collection and copies all documents. This is necessary to build a baseline state for the new member before it can begin processing the real-time oplog operations from the primary.

When a secondary's oplog is too stale and the primary's oplog has wrapped, the secondary cannot catch up incrementally. The only way to resync is to perform a full resync, which involves stopping the secondary, deleting its data directory (or using rs.resync() in the shell), and restarting it to perform an initial sync from scratch.

Setting priority to 0 prevents the member from being elected primary. However, it alone does not make the member invisible to clients. A priority 0 member can still be a sync source and can serve reads if clients connect with appropriate read preferences, unless it is also hidden.

The oplog is indeed a capped collection that stores every modification to the data. Secondaries tail this collection continuously, pulling the operations and applying them to their own datasets. This ensures that all members of the replica set eventually reach the same state as the current primary node.

Raising rs0-secondary-1's priority above rs0-secondary-2's priority ensures that, when the current primary is unavailable, rs0-secondary-1 is more likely to win the election. Lowering rs0-secondary-2's priority to 0.5 further reduces its chance of being elected, while still allowing it to vote. This is the correct way to influence election outcomes without making the member unelectable.

If the oplog is too small, the primary will roll over its log entries before the new member finishes copying all data. Once the primary wraps around, the new member loses the pointer to the operations it needs to replay, causing it to fall behind and fail the initial sync process.

A node with a priority of 0 is ineligible to become the primary. This configuration is the standard administrative method to pin a node to a secondary role. It is ideal for nodes that are undersized, geographically distant, or dedicated to tasks that should not be interrupted by election activity.

When a primary node detects that it can no longer see a majority of the voting members, it transitions to a secondary state. This is essential for cluster health because it allows the remaining nodes in the replica set to hold an election and select a new primary to handle operations.

By setting votes to 0, the node is explicitly removed from the voting pool. This means the node will not contribute to the quorum required for electing a primary node. This is often used in large replica sets to ensure that voting remains efficient without requiring an excessive number of nodes.

When the oplog entries required for synchronization are no longer present on the primary, the secondary can no longer replicate incrementally. It transitions to a recovering state and must perform a full initial sync, which involves deleting existing data and copying the entire dataset from a healthy replica set member.

During an election, nodes compare their oplog state. Member[2] has an optime of 95, making it the most current secondary. Nodes that are more up-to-date are preferred in elections because they minimize the need for rollbacks or data re-syncs, helping to maintain overall cluster consistency and reliability after a failure.

The oplog is essential for replication. It acts as a chronological ledger of every write operation performed on the primary. Secondaries continuously tail this log and apply the operations locally, ensuring that they stay synchronized with the primary node, which is the core mechanism behind MongoDB's high availability model.

The arbiter exists strictly to vote in elections. In a replica set, elections require a majority of voting members to succeed. By adding an arbiter, you increase the number of voting members, which can help reach that majority quorum without the cost or storage requirements of a full-data node.

In MongoDB 4.4 and later, index builds are coordinated across all data-bearing replica set members. The primary starts the build and waits for the secondaries to complete their builds before committing the index, ensuring the index is consistent across the set. This behavior affects the duration and resource usage during the build.

Copying data files from an existing secondary (while it is offline) is a valid method to seed a new member. This avoids the primary having to serve the entire initial sync, distributing the load. It is faster than syncing over a slow network and reduces impact on the primary. The new member must be started with the same replica set name and oplog sufficient to catch up.

Replication lag often occurs when the secondary cannot apply oplog entries as fast as the primary generates them. Upgrading the secondary's hardware—especially faster disks and more CPU—can increase its oplog application rate, reducing lag. This addresses the underlying performance bottleneck and is the most direct way to improve replication throughput.

In MongoDB, a new primary is elected only if a majority of voting members are available and can communicate. In a three-member replica set, two voting members must be reachable. This ensures that the replica set does not split-brain and that the elected primary has the most recent data, as it must have the highest optime among the majority.

The oplog (operations log) is a capped collection in the local database that records all write operations. Secondaries continuously read the oplog from their sync source and apply the operations to their own data sets, ensuring replication. It is essential for maintaining data consistency across replica set members.

The 'optimeDate' field in rs.status() provides the human-readable date of the last oplog entry applied by each member. Subtracting the secondary's 'optimeDate' from the primary's 'optimeDate' gives the replication lag. This is the standard method to quickly assess lag.

Since the write was only acknowledged by the original primary and not replicated to the secondaries, it exists only on the crashed node. When a new primary is elected, it only contains data that was replicated. The original write is effectively discarded from the cluster's consistent view.

Restarting secondaries one at a time ensures that at any moment, at least one secondary remains available to maintain a majority with the primary. Waiting for each secondary to fully rejoin and catch up before restarting the next prevents the set from losing majority and ensures that if the primary fails, a fully caught-up secondary can be elected. This is a standard rolling maintenance practice.

A priority 0 secondary cannot be elected primary, making it perfect for remote sites. It maintains a full copy of the data, which allows it to serve read requests locally. Because it cannot become primary, it eliminates the risk of a high-latency node taking control of the entire cluster's operations.

The arbiter is specifically configured to provide a voting member to the replica set without requiring the storage overhead of a data-bearing node. By participating in elections, it helps reach a majority of votes, which is required to elect a new primary during failover events in small sets.

Higher network latency increases the time required for heartbeat signals to travel between nodes. If heartbeats take longer to arrive, the remaining nodes will wait longer before declaring the primary unreachable, thereby increasing the total time elapsed before a new election is triggered and a new primary is established.