Documentation de référence sur les défaillances de basculement Cloud SQL

Cette page décrit ce qui se passe lors d'un test avec un type de défaillance Cloud SQL "Basculement".

Fonctionnement du défaut de basculement Cloud SQL

Le déclencheur de défaillance Cloud SQL de basculement déclenche un basculement à haute disponibilité pour une instance Cloud SQL en appelant la méthode failover dans l'API Cloud SQL Admin. L'objectif de cette défaillance est de vous permettre de tester le comportement et la résilience de votre service lorsque l'instance Cloud SQL principale passe à l'instance de secours dans une autre zone de la même région.

La cible de cette défaillance est une instance Cloud SQL.

Que se passe-t-il pendant l'exécution du test ?

À mesure que le test progresse dans les états, les ressources concernées subissent les modifications suivantes.

Ressource

PREPARING

INJECTING

REVERTING

Instance

Aucun

Promouvoir une instance de secours à haute disponibilité

Non applicable

Validation et nouvelles tentatives de basculement HA

Le backend Fault Injection Testing effectue des vérifications de validation avant de lancer le basculement pour s'assurer que l'environnement est adapté. Ce processus se déroule lors de l'étape INJECTING, avant l'envoi de l'appel d'API sqladmin.instances.failover au plan de contrôle Cloud SQL :

  • Le système vérifie que l'état de l'instance Cloud SQL est RUNNABLE. Si l'instance se trouve dans un autre état pendant l'exécution d'un test, Fault Injection Testing vous en informe.
  • Il vérifie que la métrique cloudsql.googleapis.com/database/available_for_failover est définie sur TRUE.

Si ces conditions ne sont pas remplies, la demande de basculement est mise en file d'attente pour être réessayée.

Gestion des pannes

Si le basculement est déjà en cours ou rencontre une erreur :

  • Pendant l'injection : si l'appel de basculement est rejeté par le plan de contrôle Cloud SQL (par exemple, si l'instance de secours n'est pas opérationnelle), l'état de l'expérience passe à STOPPING.
  • Surveillance post-basculement : si l'opération de basculement n'atteint pas l'état DONE dans un délai prédéterminé de 10 minutes, le backend de Fault Injection Testing interroge les erreurs d'opération, fait passer l'expérience à l'état STOPPING et la marque comme ayant rencontré une erreur.

Fault Injection Testing s'appuie sur le plan de contrôle Cloud SQL comme source de vérité. Le plan de contrôle rejette toute tentative de basculement si l'instance de secours n'est pas opérationnelle. Fault Injection Testing utilise des vérifications préliminaires et la surveillance de l'état pour éviter ou signaler ces échecs plutôt que de tenter des nouvelles tentatives automatisées après un refus.

Rétablissement manuel

Étant donné que le basculement est un changement avec état, l'arrêt du test ne rétablit pas automatiquement l'instance principale d'origine (comme indiqué par "Non applicable" dans l'étape REVERTING). La base de données continuera de s'exécuter dans la zone secondaire.

Pour renvoyer l'instance dans sa zone d'origine une fois le test terminé, vous devez déclencher manuellement un autre basculement à l'aide de la console Google Cloud ou de la CLI gcloud.