## TL;DR
Mongodump failed after retry means its internal reconnection attempts could not save the dump, usually from an unstable primary, an election mid-dump, oversized collections timing out, or authentication changing under it. Check replica set state during the window, dump from a healthy secondary with appropriate read preference, and split very large collections.

```text
mongodump failed after retry
```

## Use this when
- mongodump ends with failed after retry or exhausted retry messages.
- The dump window overlaps a replica set election or stepdown.
- Some collections dump and later ones never start.

## Not for this skill when
- mongodump cannot authenticate at start. That fails before retries begin.
- Disk on the dump target fills. Different failure signature.

## Steps
1. Check replica set status and logs for elections, stepdowns or member flapping during the dump window. Verify: set stability during the window is confirmed or an event is found
2. Test a small collection dump with the same URI and options to prove basic connectivity and auth. Verify: the small dump succeeds
3. Point the dump at a healthy secondary with secondary read preference for large sets, keeping consistency requirements in mind. Verify: the target member is healthy and lag is acceptable
4. Dump the largest collections individually to isolate any single collection that triggers failure. Verify: problem collections are named or all pass individually
5. Run the full dump again in a stable window and verify archive integrity with a test restore of one collection. Verify: dump completes and a sample restore works

## Variant phrasings
### mongodump failed after retry replica set
The replica-set phrasing.
### mongodump exhausted retries connection
The connection variant.
### mongodb dump fails large collection retry
The large-collection wording.

Compatibility: MongoDB 6 and 7 database tools 100.x, standalone, replica set and sharded sources, archive and directory dump formats.

## Why it happens
Mongodump retries transient network faults a limited number of times, then gives up. Elections, stepdowns, network resets from long-running collection scans, and members under memory pressure all produce faults faster than the retry budget. Dumping from a stable secondary and avoiding election windows removes most triggers.

## Edge cases / pitfalls
- Oplog-backed archive dumps need the primary or a member with oplog access. A secondary plan must respect that.
- A dump taken during heavy write load without oplog is point-inconsistent per collection. Know your restore expectations.
- Sharded dumps for consistent backups should use the balancer-aware documented procedure, not ad hoc per-shard dumps.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Rjq0UtWvTuvZfLJHEvGMbw