The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →A MongoDB write acknowledged with w: 1 can still be rolled back after a primary failover: the old primary may have replied before another replica-set member received the write, and the new primary’s history can win. An acknowledgment confirms the write concern that was requested—not an unconditional guarantee against rollback. First determine whether the write was rolled back, the outcome was ambiguous, or the read path simply has not shown the write.
What an acknowledgment does—and does not—mean
MongoDB acknowledges a write when it has satisfied the write concern in effect for that operation. With w: 1, that means the primary acknowledged it; it does not mean a secondary has replicated it. If the primary steps down before another member receives the write, a new primary can be elected with a different history. When the former primary rejoins, MongoDB may roll back its divergent write. The MongoDB Database Manual’s v8.0 guide, “Rollbacks During Replica Set Failover,” describes rollback as reverting writes on a former primary when it rejoins after failover.
That is a specific failure mode, not the only explanation for a missing value. An application may have treated an uncertain response as success, a write concern timeout may have left the result unknown, or a read from a lagging or rollback-prone member may not yet show a write that still exists. The title alone cannot establish which happened in a particular deployment.
Identify which kind of “missing write” you have
| What you observe | What it can mean | What to check |
|---|---|---|
| The client received a successful acknowledgment, but the write later disappeared after an election. | A write acknowledged by the former primary may not have replicated before it stepped down, particularly with w: 1, and may have been rolled back. |
The effective write concern, election and rollback events, rollback files, and the operation’s application identifier. |
| The client received a write concern timeout or the connection broke while waiting. | The requested acknowledgments did not arrive within the limit. The primary may nevertheless have applied the write, and replication may continue; the result is uncertain, not proof of non-application. | The server response, write concern and timeout, retry history, and whether the operation is present in application-level state. |
| A read immediately after the write returns the old value. | The read may have gone to a member that has not caught up, or used a read concern that can expose data later rolled back. | Which member served the read, read preference, read concern, and session use. |
| The application reported success, but there is no MongoDB success response in its logs. | The application may have returned success before receiving MongoDB’s acknowledgment, or may have mishandled a network or driver error. | Application response logic and correlated client and server logs. |
How to investigate before changing settings
- Establish the operation’s actual outcome. Correlate the application’s operation ID and timestamps with driver responses, write concern errors, election events, and server logs. Distinguish a received success acknowledgment from a timeout, a broken connection, or application-level success reported before the database response.
- Find the effective write concern. Check any per-operation override and the applicable collection, database, client, or deployment defaults. Do not infer the setting from a deployment’s version or from what the application normally uses; verify what this write actually requested.
- Trace the read path. Record the read preference and read concern, whether a session was used, and which replica-set member answered. A stale read by itself does not prove that the write was rolled back.
- Check replica-set history and health. Review election and rollback events, member health, replication lag, and voting versus data-bearing membership around the incident. MongoDB identifies network partitions as a common cause of rollback; secondaries that cannot keep up can increase rollback size and impact.
- Preserve rollback evidence. Retain relevant logs and rollback files before attempting recovery. MongoDB documents using
bsondumpto read rollback files; administrators must use the contents and application knowledge to decide what, if anything, should be restored.
Choose write concern for the durability you need
Write concern is a trade-off among acknowledgment latency, tolerance of member failures, and rollback risk. A larger numeric w requires acknowledgments from more members; w: "majority" uses the calculated majority of voting members. Neither is simply “always best”: a write requiring more acknowledgments may wait longer or fail to receive them when members are unavailable.
#1 Best Overall
| Write concern | What acknowledgment requires | Failover and availability implications |
|---|---|---|
w: 1 |
The primary acknowledges the write. | Another member need not have replicated it, so a primary failover before replication can lead to rollback. It can acknowledge without waiting for additional replica-set members. |
Numeric w: n |
The requested number of members must acknowledge; the value is not itself a promise that the write is on disk. | Requiring more acknowledgments can reduce the chance that the write exists only on the primary, but may reduce write availability when members are down. The exact majority and data-bearing requirements depend on topology. |
w: "majority" |
A calculated majority of voting members must acknowledge. | MongoDB recommends majority writes, together with journaling enabled on all voting members, to prevent rollback in the documented failover scenario. They may be unavailable when that majority cannot acknowledge. |
MongoDB’s rollback guidance recommends w: "majority" with journaling enabled on all voting members for rollback protection in the documented failover case. Treat that as a deliberate durability target, not a claim that every possible failure or configuration is covered. MongoDB says majority has been the default for most deployments since version 5.0; verify the effective concern rather than assuming the default applies to your deployment.
Verify majority journaling semantics
For self-managed replica sets, inspect writeConcernMajorityJournalDefault, explicit j settings, the storage engine, and whether journaling is enabled on every voting member. The MongoDB replica-configuration reference describes writeConcernMajorityJournalDefault as true by default, with requirements and an in-memory storage engine exception. Do not change this setting without checking the storage engine and server version.
If writeConcernMajorityJournalDefault is false, majority acknowledgment may not wait for on-disk journal persistence. MongoDB warns that such writes may roll back if a majority of nodes transiently crash and restart. An explicit journaling request and the deployment’s supported configuration also matter; do not assume the word “majority” alone describes every persistence detail.
Match read concern and session behavior to the requirement
local and available reads can return data that is later rolled back. Outside transactions, majority read concern returns data acknowledged by a majority and guaranteed not to roll back under the documented behavior. It does not guarantee that a particular member’s read includes the replica set’s newest write: that member may still lag.
Recommended Free Tools
Rank #3
If an application needs causal consistency in a causally consistent session, MongoDB documents using majority read concern together with majority write concern. Select read preference, read concern, and session behavior for the consistency requirement; switching to majority read concern is not a substitute for investigating a write that may already have been rolled back.
Handle timeouts and retries without duplicating business actions
A write concern timeout says the requested acknowledgments were not received within the time limit. It does not establish that the primary never applied the write. Before replaying an operation that charges a customer, increments a counter, or otherwise has non-idempotent effects, reconcile against application state using an operation ID or another reliable idempotency mechanism.
Rank #4
Retryable writes can help with certain eligible writes after network errors or difficulty finding a healthy primary. They do not replace an appropriate write concern when rollback durability matters, nor do they resolve every uncertain outcome. MongoDB documents that retry behavior is bounded by failover discovery timeout: the default behavior retries once, while configured timeoutMS can allow multiple attempts. Writes using w: 0 are not retryable. Starting in MongoDB 6.1, NoWritesPerformed is returned in the documented case where both attempts fail without performing a write. Check the specific server and driver versions, retryWrites configuration, transaction behavior, and server-selection timeout before relying on a retry outcome.
Check topology before treating majority as a setting alone
Arbiters vote in elections but do not store data. As a result, a primary-secondary-arbiter topology can require every data-bearing voting member for a majority write, affecting write availability if that member is down. Calculate the voting majority for the actual configuration and review member health and replication lag; the word “majority” does not mean “any two servers” in every topology.
Best Value
MongoDB Atlas documents w: "majority" as its default and has Atlas-specific rollback and operational documentation. That default should not be generalized to self-managed replica sets or taken to mean Atlas prevents every data-loss scenario. Verify the deployment type and its effective configuration.
Quick Recap
Apply fixes in order of risk
- Set the required durability target. For writes that must survive the documented ordinary primary-failover rollback scenario, use
w: "majority"and ensure voting members have journaling enabled, subject to the deployment’s supported configuration. - Confirm majority journal behavior. Check
writeConcernMajorityJournalDefault, explicit journal options, storage engine, and server version rather than relying on an assumed default. - Align reads with consistency needs. Use majority read concern when a read must exclude data that can later roll back; pair majority read and write concern in causally consistent sessions when that guarantee is required.
- Make operations safe to reconcile. Log operation IDs, write concern, timeouts, server responses, and retries. Use idempotent operations where possible, and reconcile ambiguous results before replaying business actions.
- Retain compatible retryable writes. Verify driver support and retry settings, while accounting for failovers that outlast server selection and version-specific behavior.
- Investigate before recovery. Preserve and examine rollback files and logs, then decide using the rollback contents and application-level state whether compensating or replaying an operation is appropriate.
- Reassess availability. Review the number of voting and data-bearing members, arbiters, member failures, and replication lag against the application’s tolerance for delayed or unavailable writes.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
