Exercice de failover / transition de rôle planifiée
Un arbre de décision qui identifie le type de changement de rôle (switchover planifié, failover d'urgence ou exercice sans toucher à la production) et fournit la bonne séquence de commandes et les étapes de vérification pour chaque scénario. Objectif : être prêt à basculer sans perte de données en planifié, avec une perte minimale en urgence, et sans aucune interruption lors d'un exercice.
Que voulez-vous faire ?
Choisissez le contexte du changement de rôle. Effectuez-vous une transition planifiée alors que le primaire est sain (maintenance/migration), le primaire est-il réellement tombé et une transition d'urgence est-elle nécessaire, ou réalisez-vous un exercice/une validation de disponibilité sans toucher à la production ?
- Switchover planifié (primaire sain)
- Failover d'urgence (primaire tombé)
- Exercice / test de disponibilité (sans toucher à la production)
Transition planifiée — êtes-vous prêt ?
L'objectif d'un switchover planifié est une perte de données NULLE. Pour cela, avant la transition, assurez-vous que le réplica a rattrapé le primaire (retard ~0) et qu'il est sain. Vérifiez le retard avec les commandes ci-dessous ; s'il est proche de zéro, passez aux étapes de transition.
SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#; -- DG: SELECT name, value FROM v$dataguard_stats WHERE name LIKE '%lag%';- Retard proche de zéro, prêt pour la transition
- Retard élevé, attendez d'abord la synchronisation
Switchover planifié (transition contrôlée sans perte de données)
Tant que le primaire et le standby sont sains et synchronisés, échangez les rôles de façon contrôlée. L'ordre compte : arrêtez les écritures, assurez-vous que les dernières modifications ont atteint le standby, puis transférez le rôle et redirigez l'application vers le nouveau primaire.
Transition d'urgence — le primaire est-il vraiment tombé ?
Avant de forcer un failover, vérifiez que le primaire est réellement injoignable et évaluez le risque de split-brain. Si le primaire est en fait vivant (par ex. une coupure réseau passagère), une transition forcée aboutit à deux copies distinctes accessibles en écriture (split-brain). Comparez aussi le retard pour choisir le standby le plus à jour.
-- try to reach the primary: tnsping primary_db; and on the standby: SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#;- Oui, le primaire est tombé — forcez la transition
- Incertain / le primaire peut revenir
Failover d'urgence (primaire tombé, transition avec risque de perte de données)
Le primaire est injoignable et vous ne pouvez pas attendre son retour. Vous devez forcer la promotion du standby ; avec une réplication asynchrone, une partie des dernières transactions peut être perdue. Votre priorité est de rétablir le service, puis d'identifier la fenêtre de perte et de réintégrer l'ancien primaire en toute sécurité.
Exercice / test de disponibilité (valider sans toucher à la production)
Prouvez que vous êtes prêt pour un failover sans effectuer de transition réelle. Vérifiez la santé des réplicas, que le retard est acceptable et que l'application peut être redirigée, sans impact sur la production. En option, répétez un véritable switchover sur une copie isolée.