D-UN-OE-23 · Question #82
Drag and Drop Question What is the correct order of steps for the Failover with Sync operation from site A to site B? Answer:
The correct answer is Issue Failover with sync from site A.; Sync site B object.; Access to site A object removed.; Access to site B object allowed.; Replication paused. Failover with Sync: Step-by-Step Explanation This sequence describes a controlled failover in a storage replication context (e.g., IBM SVC/Spectrum Virtualize). Each step is ordered to ensure data integrity and prevent split-brain scenarios. --- Step-by-Step Breakdown 1. Issue…
Question
Drag and Drop Question What is the correct order of steps for the Failover with Sync operation from site A to site B? Answer:
Exhibit
Answer Area
Drag items
Correct arrangement
- Issue Failover with sync from site A.
- Sync site B object.
- Access to site A object removed.
- Access to site B object allowed.
- Replication paused.
Explanation
Failover with Sync: Step-by-Step Explanation
This sequence describes a controlled failover in a storage replication context (e.g., IBM SVC/Spectrum Virtualize). Each step is ordered to ensure data integrity and prevent split-brain scenarios.
Step-by-Step Breakdown
1. Issue Failover with Sync from site A This is the trigger - an administrator initiates the failover command at site A. Everything downstream depends on this command being issued first. It signals intent to the system and begins the controlled handoff process.
2. Sync site B object Before cutting over, the system pushes any remaining in-flight or pending writes to site B. This happens before access is changed anywhere, because syncing while both sites are still in their original roles is safe and minimizes data loss (RPO ≈ 0). Doing this later would risk syncing stale or inconsistent data.
3. Access to site A object removed Once sync is confirmed complete, site A's object is made inaccessible. This is the "commit point" - removing site A access prevents any new writes from landing on the old primary, eliminating split-brain risk. Site B is not yet open, so there is a brief access gap - this is intentional and safe.
4. Access to site B object allowed Only after site A is locked out is site B opened for I/O. This ordering is critical: allowing site B before removing site A access would create a split-brain condition where both sites accept writes simultaneously.
5. Replication paused Replication is paused last because the original replication relationship (A → B) is now stale - site A is offline and site B is the new active. Pausing at the end cleanly suspends the relationship without interrupting the sync or the access switchover.
Common Mistakes
| Misconception | Why it's wrong |
|---|---|
| Pausing replication first | Sync in step 2 depends on replication still being active |
| Allowing site B access before removing site A | Creates split-brain; both sites accept writes concurrently |
| Syncing after access changes | You'd be syncing to an already-active target, risking overwriting new writes |
| Removing site A access before syncing | You lose any data still in-flight to site B |
Key principle: The sync must complete while the old topology is still intact, and access must switch atomically (A removed → B allowed), with replication cleanup happening only after the new state is stable.
Topics
Community Discussion
No community discussion yet for this question.