A backlog that is too small
High write rate against the 1 MB default, which covers under a second
writes-per-second: 50000 bytes-per-write: 200 repl-backlog-size: 1mb dataset: 30gb
Give the write rate and the replica count. The important output is how long the backlog covers, because past that a reconnecting replica transfers the entire dataset again.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Calculate. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
High write rate against the 1 MB default, which covers under a second
writes-per-second: 50000 bytes-per-write: 200 repl-backlog-size: 1mb dataset: 30gb
The same write rate with a backlog covering several minutes
writes-per-second: 50000 bytes-per-write: 200 repl-backlog-size: 3gb dataset: 30gb
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
1 MB covers well under a second on a busy instance, so any brief disconnection forces a full resync of the whole dataset.
Instead:Size it for the longest expected disconnection, including a replica restart.
Every replica receives the full write stream. Three replicas is three times the outbound bandwidth, and across zones it is billed.
Instead:Include the replica count in the network budget.
Simultaneous full resyncs saturate the primary's network and disk at once.
Instead:Stagger them, and watch for the resync completing before starting the next.