Présentation de la maintenance des instances Cloud SQL

Cette page explique comment s'effectue la maintenance sur les instances Cloud SQL et comment en modifier la chronologie. Pour commencer, consultez la page Rechercher et définir des intervalles de maintenance.

En quoi consiste la maintenance ?

Les instances Cloud SQL nécessitent des mises à jour occasionnelles pour corriger les bugs, éviter les problèmes de sécurité et effectuer des mises à niveau. Une fois les mises à jour appliquées, Cloud SQL redémarre les instances, ce qui peut perturber le service. Pendant la maintenance, les instances principales à haute disponibilité ne basculent pas vers les instances de secours.

Pour en savoir plus sur les mises à jour en production, consultez les notes de version.

Que sont les intervalles de maintenance ?

Les intervalles de maintenance sont des créneaux horaires programmés pendant lesquels Cloud SQL exécute les opérations de maintenance.

Si vous souhaitez être informé des prochaines mises à jour de maintenance, vous devez effectuer les deux tâches suivantes :

Si vous ne définissez pas d'intervalle souhaité, des mises à jour perturbatrices peuvent se produire à tout moment. Toutefois, elles n'ont généralement lieu que tous les deux ou trois mois.

Maintenance urgente

Bien que la plupart des opérations de maintenance respectent les intervalles que vous définissez, il est possible que cela ne soit pas le cas pour les mises à jour de services critiques, telles que les correctifs de vulnérabilités urgents. Ces mises à jour sont rapidement déployées et Cloud SQL les considère comme des temps d'arrêt allant à l'encontre de son contrat de niveau service.

Comment définir les intervalles de maintenance souhaités sur une instance ?

Vous programmez la maintenance en sélectionnant le jour de la semaine, l'heure et l'ordre selon lesquels vos instances seront mises à jour. Vous configurez ces options sur une instance en définissant les paramètres Intervalle souhaité et Ordre des mises à jour.

Lorsque vous configurez le paramètre Intervalle souhaité pour une instance, Cloud SQL ne lance pas les mises à jour de cette instance en dehors de cet intervalle. Les opérations de maintenance ont lieu à quelques mois d'intervalle et se terminent généralement en quelques minutes. En aucun cas elles ne commencent en dehors de l'intervalle souhaité. En revanche, il n'est pas garanti que les opérations de maintenance se terminent dans l'intervalle souhaité. Les intervalles souhaités sont définis en temps UTC. Par conséquent, les modifications de l'heure d'été n'y sont pas appliquées. Pour que l'intervalle souhaité respecte les modifications de l'heure locale, vous devez le reconfigurer en conséquence.

Lorsque vous configurez le paramètre Ordre des mises à jour, vous définissez la chronologie relative des mises à jour susceptibles de provoquer des temps d'arrêt. Les options de chronologie sont À n'importe quel moment, Avant ou Plus tard. Toutes les instances reçoivent exactement la même mise à jour. La différence est que les instances dont la mise à jour a été définie avec le paramètre "Plus tard" reçoivent leur mise à jour une semaine après les instances définies avec le paramètre "Avant". La réception anticipée d'une mise à jour sur une instance unique vous permet de tester votre application mise à jour avant de mettre à jour le reste de vos instances.

La chronologie relative des mises à jour n'est pas respectée entre des projets ou régions différents. Si vous avez défini le paramètre "Avant" pour les instances d'un projet ou d'un emplacement différent (par exemple dans une région différente) de celui des instances définies avec le paramètre "Plus tard", Cloud SQL ne tente pas de mettre à jour en premier les instances définies avec le paramètre "Plus tard".

Si vous ne définissez pas l'ordre des mises à jour, Cloud SQL choisit lui-même la chronologie de mise à jour de votre instance (en fonction de l'intervalle souhaité, le cas échéant).

Le paramètre Ordre des mises à jour n'a aucune incidence sur la version du logiciel que Cloud SQL applique à votre instance.

Pour définir un intervalle de maintenance souhaité dès maintenant, consultez la page Définir un intervalle souhaité pour les opérations de maintenance sur une instance.

Comment la maintenance affecte-t-elle les instances dupliquées avec accès en lecture et les instances de basculement ?

Les instances dupliquées avec accès en lecture sont supprimées lors des mises à jour de maintenance. Il n'existe aucune garantie quant au moment où les mises à jour auront lieu, et qu'elles pourront se chevaucher ou se produire de manière très rapprochée de la mise à jour de l'instance principale. Les instances de basculement sont supprimées lors des mises à jour de maintenance. Elles reçoivent des mises à jour de maintenance juste avant l'instance principale. Vous ne pouvez pas définir un intervalle de maintenance directement sur une instance de basculement, car celle-ci partage l'intervalle de maintenance de l'instance principale.

Existe-t-il des recommandations de conception pour faciliter la gestion des arrêts pour cause de maintenance ?

Nous vous recommandons de concevoir vos applications de façon à pouvoir gérer les situations où votre instance n'est pas accessible pendant de courtes périodes, par exemple lors d'un arrêt pour cause de maintenance. Pour tester le comportement de votre application lors d'un arrêt pour cause de maintenance, redémarrez votre instance. En règle générale, nous vous recommandons de n'utiliser que des connexions de courte durée et, en cas de connexions refusées, de respecter un intervalle exponentiel entre les tentatives de reconnexion.

Pour obtenir plus de conseils, consultez la section Comment dois-je gérer les connexions ?

Problèmes d'arrêt de maintenance pour les instances MySQL

Pour les instances MySQL, le délai maximal pour l'arrêt de mysqld est de 1 minute. S'il ne se termine pas dans ce délai, l'arrêt du processus mysqld est forcé. Cela entraîne un temps de démarrage plus long, car le moteur de stockage InnoDB doit procéder à une reprise après plantage avant que le serveur ne soit prêt à répondre aux requêtes. Le temps nécessaire à la reprise après plantage dépend de la taille de la base de données. Plus elle est volumineuse, plus elle a besoin de temps pour la récupération.

Comment recevoir les notifications de maintenance ?

Par défaut, les notifications de maintenance ne sont pas envoyées. Si vous souhaitez les recevoir, vous devez définir l'option Intervalle de maintenance Cloud SQL sur la page Communications de Cloud Console et sélectionner ACTIVÉ sous E-mail. Vous ne pouvez recevoir les notifications que par e-mail. Vous devez également sélectionner un intervalle de maintenance afin de pouvoir recevoir des notifications.

Les notifications de maintenance sont définies au niveau du projet plutôt que sur les instances. Les notifications par e-mail sont envoyées à l'adresse e-mail associée à votre compte Google. Il n'est pas possible de configurer un alias d'adresse e-mail personnalisé (par exemple, un alias d'adresse e-mail d'équipe).

Pour recevoir les notifications de maintenance, consultez la section Activer les notifications de maintenance.

Où trouver des informations sur les opérations de maintenance à venir ?

Si vous vous inscrivez pour recevoir la notification de maintenance par e-mail, celle-ci est envoyée à votre adresse e-mail une semaine avant la planification des opérations de maintenance. Si vous souhaitez définir un filtre de messagerie pour les notifications, le titre de l'e-mail est "Opérations de maintenance à venir pour votre instance Cloud SQL nom de l'instance".

Dans la console, vous pouvez également voir si une mise à jour de maintenance est programmée pour une instance :

  • Dans la liste Instances, dans la colonne Maintenance. Si des opérations de maintenance sont planifiées, la date et l'heure de début de la maintenance s'affichent. Vous pouvez filtrer la liste des instances en utilisant le terme Maintenance afin de rechercher toutes les instances pour lesquelles des opérations de maintenance sont programmées. La colonne Maintenance ne s'affiche que si la maintenance est planifiée sur une ou plusieurs instances du projet. Dans le cas contraire, cette colonne est masquée.
  • Sur la page Détails de l'instance du volet Maintenance. Si la maintenance est planifiée, la date et l'heure de début des opérations de maintenance sont indiquées sous À venir.
  • Sur la page ACTIVITÉ de Cloud Console, vous pouvez afficher la liste des instances pour lesquelles des opérations de maintenance sont programmées. Si la maintenance est programmée, les instances affichent le message Maintenance SQL, ainsi que la date et l'heure auxquelles elle doit démarrer.

Que se passe-t-il si l'événement de maintenance est annulé ?

Si Cloud SQL annule un événement de maintenance, vous recevez une notification vous en informant. Il est rare, mais possible, que Cloud SQL ne puisse pas envoyer de notification d'annulation à l'avance. Si tel est le cas, vous êtes averti que la maintenance n'a pas été effectuée une fois que l'intervalle de maintenance programmé s'est écoulé.

Vous recevrez une autre notification vous informant des maintenances à venir dès que l'événement de maintenance sera reprogrammé.

Comment reprogrammer la maintenance ?

Lorsque vous recevez une notification de maintenance, vous avez la possibilité de modifier l'intervalle de maintenance. Par exemple, si vous souhaitez lancer une version de service, vous pouvez reprogrammer l'intervalle de maintenance à quelques jours avant ou après le lancement.

Pour reprogrammer la maintenance, accédez à la page où se trouve la liste Instances. La colonne Maintenance affiche les dates et heures des opérations de maintenance programmées. Dans la même colonne, un bouton Reprogrammer permet de reprogrammer la maintenance.

Vous disposez de quelques options de programmation pour le nouvel intervalle de maintenance :

  • Appliquer les mises à jour immédiatement. Vous pouvez immédiatement appliquer les mises à jour à votre instance au lieu d'attendre l'intervalle de maintenance programmé. Si vous choisissez de démarrer immédiatement la maintenance, elle commencera généralement au bout de cinq minutes.
  • Reprogrammer une heure différente. Vous pouvez reporter un événement de maintenance programmé de deux façons :

    • Prochain intervalle de maintenance disponible. Cette option reporte l'intervalle de maintenance d'une semaine à la fois, en n'autorisant qu'une reprogrammation par événement de maintenance et par instance.
    • Heure précise. Cette option vous permet de choisir une heure précise dans la semaine pour laquelle la maintenance était initialement programmée.

Voici quelques points à retenir concernant la reprogrammation :

  • Vous devez reprogrammer la maintenance dans un délai d'au moins 24 heures avant que l'événement de maintenance initialement programmé ne se produise.

  • Vous pouvez reprogrammer la maintenance sur une ou plusieurs instances de votre projet. En revanche, vous ne pouvez le faire que sur une seule instance à la fois (la reprogrammation groupée n'est pas disponible).

  • Il n'est pas non plus possible de modifier plusieurs fois un intervalle de maintenance, même si vous essayez d'appliquer immédiatement les modifications.

  • Vous pouvez reprogrammer la maintenance sur une heure qui se situe pendant une période de refus de maintenance ou même en dehors de l'intervalle de maintenance, à condition que le délai soit compris dans la limite de reprogrammation de la semaine.

Pour reprogrammer la maintenance dès maintenant, consultez la section Reprogrammer une maintenance planifiée.

Périodes de refus de maintenance

Les refus de périodes de maintenance vous permettent d'empêcher la maintenance automatique pendant une période spécifique. Par exemple, la période des fêtes de fin d'année est un moment de pic de charge qui nécessite une attention plus particulière au niveau de la stabilité de l'infrastructure pour de nombreuses entreprises de vente au détail. En définissant une période de refus de maintenance entre mi-octobre et mi-janvier, ces entreprises peuvent empêcher les mises à niveau planifiées de Cloud SQL pendant la période la plus chargée de l'année.

Vous ne pouvez avoir qu'une période de refus de maintenance à la fois pour votre instance Cloud SQL. Vous pouvez refuser une période de maintenance même si aucun intervalle de maintenance n'est configuré pour votre instance. Un refus de la période de maintenance peut durer de un à 90 jours.

Le refus de la période de maintenance et la planification relative sont des fonctionnalités indépendantes. Un refus de période de maintenance spécifié sur une instance Earlier n'a aucune incidence sur la planification de l'instance Later. Les notifications ne sont pas envoyées si le calendrier de maintenance dépasse le refus de période de maintenance pour les instances Earlier ou Later.

Lorsqu'une période de refus est définie sur une instance principale, la maintenance pour toutes les instances dupliquées associées à cette instance est également refusée. Par exemple, une instance principale située dans la région A possède trois instances dupliquées avec accès en lecture : deux dans la région A et une dans la région B. Lorsqu'une période de refus est définie sur l'instance principale, la maintenance pour chacune des instances dupliquées, y compris l'instance dupliquée de la région B, ne sera pas effectuée tant que la période de refus définie sur l'instance principale n'aura pas expiré.

Vous pouvez définir le refus de la période de maintenance de manière à ce qu'il se répète tous les ans en n'incluant pas l'année dans les paramètres de date de début et de fin. Si l'année est spécifiée, la période de refus de maintenance n'est définie que pour cette année.

Découvrez comment configurer un refus de période de maintenance.

Étape suivante