01One monitor cannot reach the primary, but two others can. What state should the controller avoid entering too early?introScenarioThree monitor processes watch one primary; a network blip makes the primary unreachable from exactly one of them.AIt should avoid marking the primary subjectively down, since a single missed ping is below any reasonable threshold.BIt should avoid demoting the monitor that lost connectivity, because that monitor might be the failed component.CIt should promote the freshest replica immediately but keep the old primary writable until a quorum confirms the failure.DIt should avoid objective down and promotion too early because one monitor only has a subjective failure observation.
02Why should replication offset influence replica promotion?introScenarioA failover is starting and the controller must pick which of several replicas to promote.AReplication offset indicates freshness, so promoting the most advanced eligible replica reduces lost writes.BReplication offset measures uptime, and longer-running replicas make more stable promotion choices.CComparing offsets prevents two replicas from being promoted at once, acting as a distributed lock.DThe offset renumbers the replication stream after promotion; freshness is irrelevant since failover replays missing writes from the old primary.
03A promoted replica is missing the last acknowledged write. Which replication property made this possible?appliedScenarioAfter failover, a client reports that a write the old primary acknowledged is missing from the new primary.APartial resynchronization trimmed the backlog and deleted the acknowledged write before the replica could read it.BAsynchronous replication made the missing acknowledged write possible because the primary replied before every replica applied it.CPromotion clears the replica's dataset so it can start from a clean replication history, dropping recent writes.DReplication is asynchronous only for reads, so the loss means the client opted into a relaxed acknowledgment mode, a mode deprecated since asynchronous replication became the default.
04How do epochs reduce the risk of stale controllers undoing a newer topology?appliedScenarioA controller that was network-partitioned during a failover comes back and tries to push its old view of the topology.AEpochs are timestamps, letting nodes reject any change older than the configured clock-skew window.BEpochs encrypt configuration messages so that stale controllers cannot forge new topology updates.CEpochs let nodes reject stale configuration changes from older failover attempts, reducing topology rollback risk.DEpochs cap how many failovers can run per hour, throttling controllers that flap between configurations.
05What should happen when the old primary returns after a successful failover?advancedScenarioThe failed primary finishes rebooting an hour after a replica was promoted in its place.AIt should resume as primary because it has the longest history, and the promoted replica should step back down.BThe old primary should be demoted and reconfigured to follow the promoted primary before serving writes again.CBoth nodes should serve writes while their offsets converge, and the cluster keeps whichever dataset grew larger.DIt should stay isolated permanently, because rejoining after a failover is unsafe under asynchronous replication.
fivenines