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é

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 s'appliquent également à l'instance de secours. En cas de défaillance d'une instance ou d'une zone, cette configuration réduit les temps d'arrêt et permet à vos données de rester disponibles auprès des applications clientes.

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.

L'assistance concernant les disques persistants régionaux pour Cloud SQL et la configuration de la haute disponibilité de Cloud SQL sont en disponibilité générale et entièrement couvertes par un Contrat de niveau de service. 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.

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. Ce processus s'appelle un basculement. 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

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, c'est-à-dire qu'elle n'est pas arrêtée, ni en cours de maintenance, et qu'elle n'effectue pas d'opération de longue durée.
  • 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 d'une opération de basculement, toutes les connexions existantes vers l'instance principale et les instances dupliquées avec accès en lecture sont fermées. La connexion met 2 à 3 minutes pour être rétablie. 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