Présentation de la configuration de la haute disponibilité

Cette page présente la configuration de la haute disponibilité pour les instances Cloud SQL. Pour configurer la haute disponibilité pour une nouvelle instance ou pour l'activer sur une instance existante, consultez la page Activer et désactiver la haute disponibilité sur une instance.

Présentation de la configuration de la haute disponibilité

L'objectif d'une configuration de haute disponibilité est de réduire les temps d'arrêt lorsqu'une zone ou une instance devient indisponible. Cela peut se produire lors d'une panne de zone ou de la corruption d'une instance. Avec la haute disponibilité, vos données restent disponibles pour les applications clientes.

La configuration de la haute disponibilité, parfois appelée cluster, fournit une redondance des données. Une instance Cloud SQL configurée pour la haute disponibilité est également appelée une instance régionale. Elle se situe dans une zone principale et dans une zone secondaire de la région configurée. Au sein d'une instance régionale, la configuration se compose d'une instance principale et d'une instance de secours. Grâce à la réplication synchrone sur le disque persistant de chaque zone, toutes les écritures effectuées sur l'instance principale sont répliquées sur les disques des deux zones avant que la transaction ne soit signalée comme validée. En cas de défaillance d'une instance ou d'une zone, le disque persistant est associé à l'instance de secours, et devient la nouvelle instance principale. Les utilisateurs sont ensuite réacheminés vers la nouvelle instance principale. Ce processus est appelé basculement.

Après un basculement, l'instance qui a reçu le basculement continue d'être l'instance principale, même après la reconnexion de l'instance d'origine. Lorsque la zone ou l'instance ayant subi une panne redevient disponible, l'instance principale d'origine est détruite et recréée. Puis elle devient la nouvelle instance de secours. Si un basculement se produit dans le futur, la nouvelle instance principale basculera vers l'instance d'origine dans la zone d'origine.

Si vous devez disposer de l'instance principale dans la zone où la panne a eu lieu, vous pouvez effectuer une restauration. Une restauration effectue les mêmes étapes que le basculement, uniquement dans la direction opposée, pour rediriger le trafic vers l'instance d'origine. Pour effectuer une restauration, suivez la procédure décrite dans Lancer un basculement.

L'assistance concernant les disques persistants régionaux pour Cloud SQL et la configuration de la haute disponibilité de Cloud SQL est couverte par le contrat de niveau de service complet. Une instance configurée pour la haute disponibilité est facturée le double du prix d'une instance autonome. Le processeur, la mémoire RAM et le stockage sont inclus dans ce prix. Pour en savoir plus, consultez la page des tarifs.

Schéma de présentation de la configuration de la haute disponibilité de Cloud SQL. Décrit dans le texte ci-dessous.

Instances dupliquées avec accès en lecture

Les instances dupliquées avec accès en lecture ne peuvent pas être hautement disponibles comme les instances principales. En cas d'indisponibilité de zone, le trafic destiné aux instances dupliquées avec accès en lecture de cette zone s'arrête. Lorsque la zone redevient disponible, toute instance dupliquée avec accès en lecture de la zone reprend la réplication à partir de l'instance principale. Si les instances dupliquées avec accès en lecture se trouvent dans une zone qui ne subi pas d'indisponibilité, elles sont connectées à l'instance de secours lorsqu'elle devient l'instance principale.

Il est recommandé de placer les instances dupliquées avec accès en lecture dans une zone différente de celle des instances principale et de secours. Par exemple, si vous disposez d'une instance principale dans la zone A et d'une instance de secours dans la zone B, placez les instances dupliquées avec accès en lecture dans la zone C. Cette pratique garantit que les instances dupliquées avec accès en lecture continuent de fonctionner même si la zone de l'instance principale subit une panne. Vous devez également ajouter une logique métier dans l'application cliente afin d'envoyer des lectures à l'instance principale lorsque les instances dupliquées avec accès en lecture ne sont pas disponibles.

Remarque : L'instance de secours ne peut pas être utilisée pour les requêtes de lecture. Cela diffère de l'ancienne configuration de la haute disponibilité de Cloud SQL pour MySQL.

Présentation du basculement

Si une instance configurée pour la haute disponibilité ne répond plus, Cloud SQL passe automatiquement à l'instance de secours pour la diffusion des données. Pour savoir si un basculement a eu lieu, vous pouvez consulter l'historique dans le journal des opérations.

Cliquez sur les onglets pour découvrir les conséquences du basculement sur vos instances.

Normal

Schéma d'une instance saine avant le basculement

Basculement

Schéma de l'instance lors du basculement

Après le basculement

Schéma de l'instance après le basculement

Restauration automatique

Schéma de l'instance après la restauration automatique

Processus

Le processus suivant se produit :

  • L'instance principale ou la zone échoue.

    L'instance principale écrit chaque seconde un signal de pulsation dans la base de données système. Si le système ne parvient pas à détecter plusieurs pulsations, le basculement est lancé. Cette opération se produit lorsque l'instance principale ne répond plus pendant environ 60 secondes ou que la zone contenant l'instance principale cesse de fonctionner.

  • Au moment de la reconnexion, c'est l'instance de secours qui diffuse des données.

    Par le biais d'une adresse IP statique partagée avec l'instance principale, l'instance de secours diffuse désormais des données depuis la zone secondaire.

Exigences

Pour que Cloud SQL autorise un basculement, la configuration doit répondre aux critères suivants :

  • L'instance principale doit se trouver dans un état de fonctionnement normal. Cela signifie qu'elle n'est pas arrêtée ni en cours de maintenance, et n'effectue pas d'opération de longue durée sur une instance Cloud SQL, telle qu'une opération de sauvegarde, d'importation ou d'exportation.
  • La zone secondaire et l'instance de secours doivent toutes deux se trouver dans un état sain. Lorsque l'instance de secours ne répond pas et/ou que la réplication sur la zone secondaire est interrompue, les opérations de basculement sont bloquées. Une fois que Cloud SQL a réparé l'instance de secours et que la zone secondaire est disponible, la réplication reprend et Cloud SQL autorise le basculement.

Sauvegarde et restauration

Les sauvegardes automatiques et la récupération à un moment précis doivent être activées pour la haute disponibilité (la récupération à un moment précis utilise la journalisation binaire).

Applications et instances

Comme le fonctionnement des instances standards et des instances haute disponibilité est identique, vous n'avez pas besoin de configurer votre application d'une manière spécifique. Lors du basculement, toutes les connexions existantes à l'instance principale et aux instances dupliquées avec accès en lecture sont fermées. Le rétablissement des connexions à l'instance principale prend environ deux à trois minutes. Les connexions aux instances dupliquées peuvent prendre plus de temps. Votre application se reconnecte à l'aide de la même chaîne de connexion ou de la même adresse IP. Vous n'avez pas besoin de mettre à jour votre application une fois le basculement terminé.

Pour découvrir comment le basculement affecte vos applications, lancez le processus manuellement.

Temps d'arrêt pour maintenance

Les événements de maintenance affectent les instances principales configurées pour la haute disponibilité de la même manière que les autres instances. Vous pouvez vous attendre à ce que les instances principales soient indisponibles pendant cette période. Pour minimiser l'impact sur votre service, vous pouvez définir un intervalle de maintenance afin de contrôler le moment où les temps d'arrêt surviennent.

Lors de la maintenance d'une instance, celle-ci ne bascule pas vers l'instance de secours. Les mises à jour de maintenance sont appliquées à l'instance de secours en même temps qu'à l'instance principale.

Performances

Les performances des disques persistants régionaux dépendent de nombreux facteurs. Plus précisément, examinez la taille du type d'instance de VM, ainsi que l'entrée et la sortie de la charge de travail. Notez également que la latence d'un disque persistant régional avec des disques durs SSD est supérieure à celle des disques persistants SSD locaux. Cela signifie que si votre charge de travail n'est pas une charge de travail en streaming sensible à la latence, elle ne peut pas atteindre la limite d'opérations d'entrée/sortie par seconde (IOPS) puisque le disque persistant régional avec SSD a une latence plus élevée qu'un disque persistant avec un disque SSD local. En effet, la redondance nécessaire pour écrire deux copies augmente la latence de queue.

Ancienne option de haute disponibilité MySQL

Jusqu'au 1er trimestre 2021, vous avez la possibilité d'utiliser l'ancien processus d'ajout de la haute disponibilité aux instances MySQL, qui utilise une instance dupliquée de basculement. L'ancienne fonctionnalité n'est pas disponible dans Cloud Console. À la place, utilisez les commandes gcloud ou cURL. Consultez les sections Ancienne configuration : Créer une instance configurée pour la haute disponibilité ou Ancienne configuration : Configurer la haute disponibilité d'une instance existante.

Étapes suivantes