01The primary starts snapshotting at `t0`, then accepts `SET a 1` at `t1`. Where must that write appear for the replica to catch up?introScenarioA replica requested a full sync; the primary forked a snapshot at `t0` and keeps serving writes during the transfer.AIt must appear inside the snapshot itself, which the primary patches just before streaming it out to the replica.BThat write must be in the primary buffer of writes after t0 and then replayed on the replica after the snapshot loads.CIt must be written to the replica's AOF, so local recovery applies it once the snapshot finishes loading.DThe replica fetches it afterward by comparing per-key versions with the primary and pulling differences.
02Why can a replica load a snapshot and still be behind the primary?introScenarioA replica has finished loading the transferred snapshot, yet the primary's dataset has already moved on.ASnapshot loading is lossy for large values, which are truncated and re-fetched lazily afterward.BThe replica applies the snapshot at lower priority than its client reads, so loading lags its own traffic.CThe snapshot is only a point-in-time copy; writes accepted during transfer still need to be applied afterward.DIt cannot be behind, because full sync completes only when both datasets match byte for byte at that moment.
03What state should a replica discard or replace when full sync begins?appliedScenarioA replica that was previously following a different primary begins a full sync with a new one.AThe replica should discard or replace its old dataset and replication progress so the new snapshot becomes the base state.BIt should keep the old dataset and merge the snapshot key by key, preferring whichever side has newer values, the way a conflict-free replicated structure would.CIt should keep its replication offset, since offsets are global and resume counting after the snapshot loads.DIt should discard only keys that carry TTLs, because persistent keys are guaranteed identical on both sides.
04Why does asynchronous replication allow lower write latency and possible data loss?appliedScenarioYou are explaining to an application team what the primary does and does not wait for when acknowledging their writes.AAsynchrony batches writes so none are lost, and the only cost is occasional reordering on the replica.BThe replica acknowledges before applying, so latency is low but the primary can lose track of replica state.CLower latency comes from compressing the replication link, and loss occurs only when compression fails.DThe primary can reply before replicas durably apply the write, reducing latency but allowing acknowledged writes to be missing after failure.
05Which part of full sync resembles RDB, and which part resembles AOF?advancedScenarioAfter studying persistence, you notice full sync reuses both of its big ideas in one protocol.AThe snapshot transfer resembles RDB, while replaying buffered and live writes resembles AOF-style command application.BThe snapshot resembles AOF because it streams over the network, while the live writes resemble RDB pages.CNeither comparison applies, because replication uses a wire format unrelated to either persistence mechanism.DBoth halves resemble RDB, since commands are converted into serialized objects before being sent to the replica, reusing the snapshot serializer for consistency.
fivenines