Poate fi automat sau inițiat de operator. Rezultatul intenționat este serviciul restaurat sau continuu, dar întreruperea, capacitatea, starea și corectitudinea acceptabile trebuie definite în avans.
Failover-ul fiabil depinde de semnale de sănătate demne de încredere, reguli de decizie, pregătirea rezervei, replicarea stării, acoperirea dependențelor, schimbări de rutare sau nume și prevenirea instanțelor active conflictuale. Revenirea (failback) la primarul recuperat este o modificare controlată separată și poate purta propriul risc.
Puncte esențiale
Stabiliți logica de declanșareDefiniți dovezile de eșec, timpul de detecție și confirmare, regulile de cvorum sau izolare (fencing), autoritatea pentru acțiune manuală și protecții împotriva oscilației sau failover-ului fals.
Acoperiți dependențeleIncludeți date, identitate, chei, rețele, planuri de control, furnizori, capacitate, configurație, observabilitate și căile de care utilizatorii au nevoie pentru a ajunge la serviciul alternativ.
Testați tranzițiileExersați failover și failback sub sarcină și scenarii de eșec parțial, verificați tranzacțiile și consistența datelor, măsurați obiectivele de recuperare și înregistrați funcționalitățile degradate.
Limitare importantăO comutare reușită de componente nu dovedește continuitate de la cap la cap. Dependențe partajate, stare învechită sau coruptă, operare split-brain, configurație incompatibilă, capacitate insuficientă sau un atacator prezent în ambele medii pot face failover-ul ineficace sau nesigur.