Professional Cloud Database Engineer — Questions d'entraînement et examen blanc

Spanner est la base de données relationnelle de Google, scalable horizontalement et à cohérence forte. Sa disponibilité dépend de la configuration d'instance : les configurations régionales gardent les réplicas dans une seule région et offrent un SLA de 99.99%, tandis que les configurations multirégionales répartissent les réplicas en lecture-écriture sur plusieurs régions et offrent le SLA supérieur de 99.999% (moins de cinq minutes d'indisponibilité par an). Une configuration multirégionale comprend au moins trois régions et cinq réplicas, et Spanner gère automatiquement le basculement lorsqu'une région devient indisponible. C'est différent de Cloud SQL, où la haute disponibilité reste zonale à l'intérieur d'une région. Le choix de la configuration d'instance est donc le levier de conception central, à la fois pour la disponibilité et pour la résidence des données. Astuce d'examen : associe le chiffre magique 99.999% directement à Spanner multirégional, et 99.99% (Spanner régional) ou 99.95% (Cloud SQL HA) aux niveaux inférieurs.

Cloud SQL te permet de configurer une fenêtre de maintenance en précisant le jour et l'heure des mises à jour. La documentation de Google recommande de planifier la maintenance pendant les périodes de faible trafic afin de limiter l'impact sur les utilisateurs. Les fenêtres de maintenance par défaut sont déjà placées en heures creuses : en semaine de 10 PM à 6 AM, et le week-end. L'exemple donné par Google montre un commerçant qui planifie la maintenance le dimanche à minuit — la période au trafic le plus faible. Avec un pic d'utilisation de 9 AM à 6 PM en semaine, planifier la maintenance en heures creuses (week-end ou tard dans la nuit) est le bon choix. La maintenance est entièrement planifiable (l'option « La maintenance ne peut pas être planifiée et se produit de façon aléatoire » est fausse — elle ne se produit pas de façon aléatoire). La planifier après les fenêtres de sauvegarde n'a aucun lien avec un impact faible. La planifier en heures de pointe maximiserait la gêne. Tu peux aussi définir des périodes d'interdiction de maintenance allant jusqu'à 90 jours pour bloquer les mises à jour pendant les moments critiques pour l'activité. Ref: cloud.google.com/sql/docs/mysql/maintenance

Cloud SQL propose un basculement manuel prévu précisément pour tester la reprise après sinistre en haute disponibilité. La documentation de Google indique : « Tester le basculement est facultatif, mais recommandé pour que tu puisses voir comment ton application réagit en cas de basculement. » Tu le déclenches avec gcloud sql instances failover INSTANCE_NAME, via la Cloud SQL Admin API (instances.failover), ou avec le bouton Failover de la Console. Cela simule la panne d'une zone et déclenche le mécanisme de basculement automatique vers l'instance de secours, ce qui te permet de valider la logique de reconnexion de ton application et de mesurer le temps de basculement réel. Supprimer l'instance principale la détruit définitivement — ce n'est pas un test. Éteindre une zone depuis la Console n'est pas possible pour un utilisateur. Couper le réseau n'est pas fiable et ne teste pas le vrai mécanisme de basculement de Cloud SQL. Ref: cloud.google.com/sql/docs/postgres/configure-ha#initiate-failover

Migrer d'Oracle vers Spanner impose une approche par phases, car il s'agit d'une migration hétérogène — Spanner a un modèle de données fondamentalement différent (pas de procédures stockées, pas de triggers, conception des clés différente). Le guide de migration officiel de Google prescrit : (1) convertir le schéma et le modèle de données, (2) traduire les requêtes SQL, (3) modifier l'application pour qu'elle écrive dans les deux bases (double écriture), (4) exporter/importer les données en masse via Dataflow, (5) maintenir la cohérence avec le CDC (par exemple Striim ou Oracle LogMiner), (6) valider et basculer. Cette approche par phases permet zéro interruption de service en gardant les deux systèmes synchronisés jusqu'à ce que la confiance soit établie. Datastream ne peut pas écrire directement dans Spanner en streaming. DMS ne prend pas en charge la migration directe d'Oracle vers Spanner. L'export/import CSV impose une interruption et n'assure aucune synchronisation des modifications. Ref: cloud.google.com/spanner/docs/migrating-oracle-to-cloud-spanner