Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

À propos des déploiements bleu-vert dans Cloud SQL

MySQL | PostgreSQL | SQL Server

Ce document présente les déploiements bleu-vert Cloud SQL, qui vous permettent d'effectuer des mises à jour de base de données, telles que des mises à niveau de version majeure et des modifications matérielles, tout en minimisant les temps d'arrêt.

Intents et cas d'utilisation du déploiement

Vous pouvez créer un déploiement bleu-vert avec ou sans intention d'effectuer une mise à niveau de version majeure :

Créer avec intention (mise à niveau de version majeure) : met à niveau votre moteur de base de données vers une version majeure plus récente. Lors de la création du déploiement, Cloud SQL exécute l'API de vérification préalable de la mise à niveau de la version majeure pour vérifier la compatibilité avant de poursuivre le workflow de mise à niveau.
Créer sans intention (modifications de configuration ou matérielles) : prépare les modifications au niveau de la version actuelle de la base de données. Les cas d'utilisation incluent la modification des types de machines (scaling du processeur/de la RAM), le test des indicateurs de base de données ou l'évaluation des modifications de stockage sans mise à niveau de la version du moteur.

Fonctionnement des déploiements bleu-vert

Les déploiements bleu-vert Cloud SQL fournissent un workflow automatisé en mettant en scène les modifications dans un environnement secondaire temporaire avant de basculer le trafic en direct.

Lors d'un déploiement bleu-vert, Cloud SQL crée un environnement de préproduction distinct (vert) qui reflète votre environnement de production existant (bleu). Le service maintient une réplication logique continue du bleu vers le vert. Vous pouvez tester minutieusement la compatibilité et les performances de l'application dans l'environnement vert sans affecter le trafic de production. Lorsque vous êtes prêt, vous déclenchez une commutation rapide qui attribue l'environnement vert à l'état de lecture et d'écriture de production avec un temps d'arrêt minimal de l'application (généralement en quelques secondes).

Composants d'un déploiement bleu-vert

Un déploiement bleu-vert se compose des éléments suivants :

Environnement bleu (source) : votre environnement de production existant qui diffuse activement le trafic d'application. Elle se compose de l'instance source de lecture et d'écriture, ainsi que de toute configuration associée.
Environnement vert (cible) : environnement de préproduction temporaire et isolé créé par Cloud SQL en tant que clone de l'environnement bleu. L'environnement vert intègre les modifications que vous avez demandées (comme une version plus récente de la base de données) et reste synchronisé avec l'environnement bleu grâce à la réplication continue. Cloud SQL nomme automatiquement l'instance de préproduction verte en utilisant le modèle BLUE_INSTANCE_NAME-green-UNIQUE_ID (où BLUE_INSTANCE_NAME est tronqué à un maximum de 48 caractères et UNIQUE_ID est un identifiant hexadécimal de 8 caractères).
Basculement : processus planifié et initié par l'utilisateur pour convertir l'environnement vert en nouvelle instance de production en lecture et en écriture. Lors du basculement, Cloud SQL échange les points de terminaison de connexion afin que les applications se connectent à l'environnement vert avec une brève interruption de la connexion (généralement en quelques secondes). Le temps d'arrêt attendu lors du basculement varie en fonction de l'édition Cloud SQL :
- Édition Cloud SQL Enterprise Plus : le temps d'arrêt pour le basculement est généralement inférieur à une seconde.
- Édition Cloud SQL Enterprise : le temps d'arrêt pour basculement est généralement inférieur à 60 secondes, selon la charge de travail et le décalage de réplication.
Contrairement à un basculement non planifié (qui est déclenché automatiquement en cas d'indisponibilité), un switchover est une opération contrôlée utilisée pour la gestion des modifications planifiées.
Suppression : processus de suppression de la ressource de déploiement bleu-vert. Le comportement de suppression diffère selon que le basculement a eu lieu ou non :
- Avant le basculement : la suppression du déploiement supprime l'instance de préproduction verte et la ressource de déploiement. Votre instance de production bleue n'est pas affectée et continue de diffuser du trafic.
- Après le basculement : la suppression du déploiement supprime les métadonnées de déploiement. Par défaut, l'instance convertie (verte) et l'instance bleue sont conservées. Vous pouvez éventuellement supprimer l'instance bleue pour éviter des frais continus.

Cycle de vie et états de déploiement

Un déploiement bleu-vert passe par quatre phases de cycle de vie distinctes :

Création et préparation (PROVISIONING) : lorsque vous demandez un déploiement bleu-vert, Cloud SQL provisionne une instance cible verte temporaire qui clone votre environnement de production bleu. En cas de mise à niveau d'une version majeure, Cloud SQL exécute également l'API de vérification préalable de la mise à niveau de la version majeure pour valider la compatibilité de la base de données avant de poursuivre le workflow de mise à niveau. Cloud SQL applique la mise à niveau ou la modification de configuration demandée à l'environnement vert et lance la réplication logique continue du bleu vers le vert.
Validation de l'environnement intermédiaire (SWITCHOVER_READY ou SWITCHOVER_NOT_READY) : une fois la réplication initiale terminée, le déploiement passe à l'état SWITCHOVER_READY (ou SWITCHOVER_NOT_READY si la réplication est interrompue ou si des erreurs se produisent). Le déploiement bleu continue de diffuser le trafic de production réel. Connectez-vous à l'environnement vert pour exécuter des tests de validation, vérifier la compatibilité des applications et tester les performances des requêtes.
Exécution de la commutation (SWITCHOVER_IN_PROGRESS ou SWITCHOVER_COMPLETED) : lorsque vous déclenchez la commutation, Cloud SQL exécute des prévérifications de sécurité, échange les points de terminaison de connexion et définit l'instance verte comme instance de production active avec accès en lecture et écriture (SWITCHOVER_COMPLETED), puis transforme l'instance bleue en instance autonome avec accès en lecture et écriture. Les opérations de lecture et d'écriture actives sont routées exclusivement vers l'instance verte, et la réplication logique du bleu vers le vert est arrêtée. Pour en savoir plus, consultez Effectuer un basculement de déploiement bleu-vert.
Suppression (DELETING) : une fois les tests terminés ou après avoir vérifié les opérations de production, supprimez la ressource de déploiement. Le comportement de suppression diffère selon l'état du déploiement :
- Avant le basculement (annulation) : si vous décidez de ne pas poursuivre le déploiement ou si des problèmes de validation surviennent, la suppression du déploiement supprime l'instance de préproduction verte et les métadonnées du déploiement. L'instance de production bleue d'origine reste inchangée et continue de diffuser du trafic sans interruption.
- Après le basculement (nettoyage) : une fois le basculement terminé et les opérations vérifiées sur la nouvelle instance de production, la suppression du déploiement supprime les métadonnées de déploiement. Par défaut, la nouvelle instance de production (verte) et l'instance bleue sont conservées en tant qu'instances autonomes de lecture et d'écriture. Vous pouvez éventuellement spécifier l'indicateur --delete-old-source pour supprimer définitivement l'instance bleue et ne plus être facturé pour celle-ci.
Pour en savoir plus, consultez Supprimer un déploiement bleu-vert.

États des ressources de déploiement

Lorsque vous inspectez un déploiement bleu-vert, le champ state indique son état actuel du cycle de vie :

PROVISIONING : le déploiement est en cours de création. Pour les mises à niveau de version majeure, Cloud SQL exécute l'API de vérification préalable pour valider la compatibilité avant de continuer. Cloud SQL provisionne l'environnement vert, applique les mises à niveau demandées et configure la réplication logique continue.
SWITCHOVER_READY : l'environnement vert est provisionné, la réplication logique du bleu vers le vert est opérationnelle et le déploiement est prêt pour le basculement.
SWITCHOVER_NOT_READY : le déploiement est provisionné, mais le basculement ne peut pas être lancé. Cela se produit si la réplication logique est interrompue ou arrêtée, si la réplication initiale n'est pas terminée ou si un nœud associé a rencontré une erreur.
SWITCHOVER_IN_PROGRESS : une opération de basculement est en cours d'exécution. Cloud SQL échange les points de terminaison de connexion et convertit l'instance verte en instance de production active avec accès en lecture et écriture.
SWITCHOVER_COMPLETED : l'opération de basculement a réussi. L'instance verte est désormais votre instance de production active en lecture et en écriture, et l'instance bleue est conservée en tant qu'instance autonome en lecture et en écriture.
DELETING : le déploiement est en cours de suppression. Si vous supprimez l'instance avant la bascule, Cloud SQL supprime l'instance de préproduction verte et les métadonnées de déploiement. Si vous supprimez l'instance après le basculement, Cloud SQL supprime les métadonnées de déploiement et, si l'indicateur --delete-old-source est spécifié, supprime éventuellement l'instance bleue.
STATE_UNSPECIFIED : l'état du déploiement est inconnu.

États et préparation du basculement

L'état de préparation au basculement dépend de l'état de la réplication et de l'état des nœuds pour protéger votre base de données de production contre la perte de données ou les temps d'arrêt prolongés :

État et latence de la réplication : si la réplication logique entre les environnements bleu et vert est interrompue, suspendue ou échoue, l'état du déploiement passe à SWITCHOVER_NOT_READY. La sortie de déploiement state et de description ne signale pas le délai avant réplication, et Cloud SQL n'évalue pas le délai avant réplication comme vérification préalable pour déterminer l'état du déploiement. Toutefois, l'opération de basculement échoue si le décalage de réplication est trop élevé au moment du basculement. Pour que la commutation se déroule correctement, assurez-vous que le décalage de réplication est minimal avant de la lancer. Vous pouvez surveiller le temps de latence de la réplication dans Cloud Monitoring (en vérifiant des métriques telles que replica_lag dans la liste des métriques Cloud SQL) ou directement sur l'instance verte. Pour en savoir plus, consultez Surveiller le décalage de réplication.
État des nœuds associés : sous deploymentMappings, chaque nœud associé indique son propre état (par exemple, PROVISIONED, UPGRADED, UPGRADE_FAILED, SWITCHOVER_IN_PROGRESS, SWITCHOVER_SUCCEEDED ou SWITCHOVER_FAILED). Si un nœud associé rencontre une erreur (UPGRADE_FAILED ou SWITCHOVER_FAILED), l'état global du déploiement passe à SWITCHOVER_NOT_READY. Si un basculement échoue, le routage reste sur l'instance bleue sans perte de données.
Résolution des problèmes de préparation au basculement : si votre déploiement signale SWITCHOVER_NOT_READY, vérifiez le champ errorDetail pour diagnostiquer les erreurs de réplication ou de nœud. Avant de lancer le basculement, assurez-vous que le décalage de réplication est minimal et vérifiez que les opérations LDD par lot actives ou les transactions d'écriture de longue durée sur l'instance bleue sont terminées.

Limites

Avant d'utiliser les déploiements bleu-vert, consultez les limites suivantes :

Moteurs et versions compatibles : les instances Cloud SQL pour MySQL sur MySQL 5.7 et versions ultérieures sont compatibles avec la préparation de la configuration (création sans intention). Les cibles de mise à niveau de version majeure (créer avec intention) sont compatibles avec MySQL 8.0 vers 8.4. MySQL 8.0.18 n'est pas compatible avec les déploiements bleu-vert.
Moteurs de base de données non compatibles : Cloud SQL pour PostgreSQL et Cloud SQL pour SQL Server ne sont pas compatibles.
Instances avec instances répliquées avec accès en lecture : les déploiements bleu-vert ne sont pas compatibles avec les instances comportant des instances répliquées avec accès en lecture.
Configurations réseau non compatibles : les déploiements bleu-vert ne sont pas compatibles avec les configurations sortantes de Private Service Connect.
Authentification IAM de groupe : les déploiements bleu-vert sont incompatibles avec l'authentification IAM de groupe MySQL et peuvent entraîner des échecs de bascule.
Exigence concernant l'architecture réseau : les instances Cloud SQL doivent utiliser la nouvelle architecture réseau. Les instances qui utilisent l'ancienne architecture réseau ne sont pas compatibles.
Exigence de journalisation binaire : les sauvegardes automatiques et la journalisation binaire doivent être activées sur les instances MySQL pour permettre la réplication logique continue vers l'environnement vert.
Exigence concernant la version de maintenance : votre instance source bleue doit exécuter la dernière version de maintenance avant de créer un déploiement bleu-vert. Pour vérifier ou mettre à jour la version de maintenance de votre instance, consultez Effectuer une maintenance en libre-service.
Disponibilité des ressources : le provisionnement d'instances lors des workflows de déploiement bleu-vert (y compris la création de l'instance de préproduction verte et de l'instance bleue après le basculement) peut être affecté par des contraintes de ressources de calcul dans la région ou la zone sélectionnée.
Pannes et basculements non planifiés : le basculement du déploiement bleu-vert est une opération strictement planifiée qui nécessite une instance source bleue RUNNING opérationnelle. L'instance de préproduction verte fonctionne comme une instance répliquée de lecture spécialisée. Comme les instances répliquées de lecture standards, l'instance verte ne peut pas être utilisée comme cible de basculement en cas d'indisponibilité non planifiée de l'instance source. Pour la récupération automatisée en cas d'indisponibilité, configurez votre instance pour la haute disponibilité ou utilisez une instance répliquée de reprise après sinistre (DR).

Facturation et tarifs

L'utilisation des déploiements bleu-vert n'entraîne pas de frais supplémentaires. Toutefois, comme un environnement vert parallèle complet est provisionné lors du déploiement, vous êtes facturé aux tarifs standards pour les instances bleues et vertes pendant toute la durée d'existence des deux environnements.

Pour éviter des frais inutiles, supprimez le déploiement et les instances associées :

Avant le basculement : si vous annulez le déploiement, supprimez-le pour supprimer l'instance de préproduction verte et arrêter les frais associés.
Après le basculement : supprimez le déploiement et spécifiez l'indicateur --delete-old-source pour supprimer définitivement l'instance bleue après avoir vérifié la nouvelle instance de production. Si vous ne supprimez pas l'instance bleue, vous continuerez à être facturé pour les deux instances.