01A replica has offset 9,750 and the primary is at 10,000. What does the replica need if the replication ID matches?introScenarioA replica reconnects after a brief network blip and reports where it left off in the replication stream.AIt needs a fresh snapshot, because offsets only describe how far out of date the replica has become.BIt needs the last 250 commands replayed from the primary's append-only file on disk, which doubles as the durability log for the same byte range.CIt needs the backlog bytes for offsets after 9,750 through 10,000, assuming the replication ID is the same history.DIt needs nothing yet, since replicas wait until the gap exceeds the backlog before resynchronizing.
02Why is a matching offset meaningless when the replication ID is different?introScenarioTwo servers happen to report similar replication offsets, but their replication IDs differ.AOffsets only have meaning within a specific replication history; a different replication ID means the byte positions refer to another stream.BA different ID only means a different primary hostname, so the offsets remain directly comparable.CThe offsets stay meaningful but must first be scaled by the relative lengths of the two histories.DThe replication ID is a checksum of the dataset, so a mismatch signals corruption rather than a different history, forcing an immediate full resynchronization to repair the damage.
03A backlog covers offsets 9,900 through 10,000. Can a replica at 9,750 partial-sync?appliedScenarioA long-disconnected replica reconnects and asks to resume from an offset the primary's ring buffer no longer holds.AYes, the primary replays 9,900 through 10,000 and the replica tolerates the missing 150 bytes as acceptable drift.BYes, provided the replica first replays its own AOF to advance itself past offset 9,900.CNo, but the primary can rebuild offsets 9,750 through 9,900 from its RDB file and then continue from the backlog.DNo. Offset 9,750 is older than the backlog range, so the primary must fall back to full sync.
04What operational tradeoff does backlog size control?appliedScenarioAn operator is sizing the replication backlog for a fleet that rides out frequent brief network partitions.ABacklog size controls replication latency, since larger backlogs batch more bytes into each transmission.BBacklog size trades memory for the ability to survive longer replica disconnects without a full sync.CBacklog size bounds how many replicas can attach concurrently, with one backlog slot consumed per replica.DBacklog size sets the fsync unit of the replication stream, trading durability against throughput.
05Why is partial sync an optimization rather than a separate correctness model?advancedScenarioA design review asks whether partial sync changes what replication guarantees, or just what it costs.APartial sync is a weaker consistency mode that operators opt into when they prefer throughput over safety.BPartial sync is a correctness feature, because without it full sync would miss writes that occur during snapshot transfer.CPartial sync is an optimization because replicas can keep serving reads while catching up, which full sync forbids.DPartial sync is an optimization because it resumes the same command stream; correctness still falls back to full sync when history is unavailable.