À propos de la maintenance des instances Cloud SQL

Cette page explique comment les mises à jour de maintenance sont effectuées sur les instances Cloud SQL et comment en modifier la chronologie. Pour commencer, consultez la page Rechercher et définir des intervalles de maintenance.

Présentation

En tant que service géré, Cloud SQL met automatiquement à jour les instances pour garantir que le matériel, le système d'exploitation et le moteur de base de données sous-jacents sont fiables, performants, sécurisés et à jour. La plupart de ces mises à jour sont effectuées tant que votre instance Cloud SQL est opérationnelle. Toutefois, certaines mises à jour du système nécessitent une brève interruption de service. Ces mises à jour sont appelées maintenances.

La maintenance met à jour le système d'exploitation et le moteur de base de données. Comme ces mises à jour nécessitent le redémarrage de l'instance, elles entraînent un temps d'arrêt. Les mises à jour de maintenance offrent les avantages suivants :

  • Fonctionnalités de Cloud SQL : pour lancer de nouvelles fonctionnalités, le moteur de la base de données est mis à jour et de nouveaux plug-ins sont installés.

  • Mises à niveau des versions de bases de données : Le fournisseur de logiciels de base de données qui développe MySQL publie de nouvelles versions mineures plusieurs fois par an. Chaque nouvelle version inclut des corrections de bugs, des correctifs de sécurité, des améliorations de performances et de nouvelles fonctionnalités de base de données. Pour trouver la dernière version mineure compatible avec Cloud SQL pour MySQL, consultez les notes de version ou la page Versions de bases de données et règles de version. Les instances Cloud SQL sont mises à niveau vers la dernière version de la base de données peu de temps après leur publication afin de vous permettre de tirer parti de la dernière version du logiciel de base de données.

    Vous devez effectuer manuellement les mises à niveau des versions mineures de MySQL 8.0. Consultez la section Définir la version mineure de MySQL pour une instance.

  • Correctifs du système d'exploitation : nous surveillons en permanence les dernières failles de sécurité détectées dans le système d'exploitation. Lorsque des failles sont découvertes, nous appliquons des correctifs au système d'exploitation pour vous protéger contre de nouveaux risques.

Impact de la maintenance

Lors d'un événement de maintenance, une instance Cloud SQL pour MySQL perd la connectivité pendant moins de 60 secondes en moyenne.

Pour l'édition Cloud SQL Enterprise Plus, Cloud SQL offre une maintenance planifiée avec un temps d'arrêt quasiment nul.

Les temps d'arrêt peuvent être plus importants pour les instances avec une activité élevée pendant la maintenance ou pour celles contenant des ensembles de données très volumineux. Cloud SQL planifie généralement la maintenance une fois tous les deux ou trois mois.

Pour vous assurer que la maintenance a le moins d'impact possible sur vos opérations, utilisez nos paramètres de maintenance et rendez vos systèmes résilients aux erreurs temporaires.

Maintenance planifiée avec un temps d'arrêt quasiment nul

Grâce à la maintenance planifiée avec un temps d'arrêt quasiment nul, les instances Cloud SQL Enterprise Plus à haute disponibilité perdent généralement la connectivité pendant moins d'une seconde lors de la maintenance planifiée.

Les temps d'arrêt peuvent être plus importants pour les instances avec une activité élevée pendant la maintenance.

Prérequis et contraintes

  • Si vous utilisez l'une des options suivantes, elle doit être définie sur une valeur par défaut :

    • sync_binlog, valeur : 1
    • innodb_flush_log_at_trx_commit, valeur : 1
    • replica_skip_errors, valeur : OFF
    • binlog_order_commit, valeur : ON

    Pour en savoir plus, consultez la page Configurer des options de base de données.

  • Si vous utilisez le proxy d'authentification Cloud SQL ou les connecteurs de langage Cloud SQL, assurez-vous que leur version est la plus récente.

  • Si vous disposez d'instances répliquées externes avec GTID activé, vous devez les configurer pour utiliser le positionnement automatique basé sur GTID. Sinon, la réplication sera interrompue après la maintenance. Pour en savoir plus, consultez Positionnement automatique GTID.

  • L'UID de votre serveur MySQL sera modifié pendant la maintenance.

  • Pendant la maintenance, les journaux de la base de données contiennent des messages provenant de deux VM différentes.
  • Si un LDD est émis pendant la maintenance planifiée, les modifications peuvent avoir un code temporel de création ou de modification postérieur au code temporel de la maintenance.

Simuler une maintenance planifiée avec un temps d'arrêt quasiment nul

Pour tester le temps d'arrêt de maintenance planifié de votre instance principale Cloud SQL Enterprise Plus sans mettre à jour votre instance de base de données, vous pouvez simuler une maintenance planifiée avec un temps d'arrêt quasiment nul.

Pour ce faire, appelez la simulation d'un événement de maintenance sur une instance Cloud SQL Enterprise Plus éligible à une maintenance planifiée avec un temps d'arrêt quasiment nul. La requête de simulation génère une opération de mise à jour d'instance vers la même version de maintenance avant l'opération.

Vous pouvez effectuer la simulation même si une mise à jour de maintenance est en attente sur l'instance. La version de l'instance reste la même tout au long de la simulation.

Pour simuler un événement de maintenance planifié avec un temps d'arrêt quasiment nul, utilisez la commande gcloud CLI suivante :

gcloud sql instances patch INSTANCE_NAME --simulate-maintenance-event

Remplacez INSTANCE_NAME par le nom de l'instance sur laquelle vous souhaitez exécuter l'événement de maintenance simulé.

Paramètres de maintenance

Cloud SQL vous permet de configurer les mises à jour de maintenance via un ensemble de paramètres de maintenance.

Vous pouvez configurer la maintenance de sorte qu'elle soit planifiée à des moments où un bref temps d'arrêt aura le moins d'impact sur vos applications. Pour chaque instance Cloud SQL, vous pouvez configurer les éléments suivants :

  • Intervalle de maintenance : jour de la semaine et heure auxquels Cloud SQL planifie la maintenance. Les intervalles de maintenance durent une heure. Découvrez comment configurer un intervalle de maintenance.

  • Ordre des mises à jour. définit l'ordre dans lequel l'instance Cloud SQL est mise à jour par rapport aux autres instances de la même région. L'ordre des mises à jour peut être défini sur Any, Earlier ou Later. Les instances définies sur Later sont mises à jour une semaine après celles définies sur Earlier avec le même intervalle de maintenance dans la même région. Vous définissez l'ordre des mises à jour lorsque vous configurez un intervalle de maintenance.

  • Période de refus de maintenance : bloc de jours pendant lesquels Cloud SQL ne planifie pas de maintenance. Les périodes de refus de maintenance peuvent durer jusqu'à 90 jours. Découvrez comment configurer une période de refus de maintenance.

Intervalles de maintenance par défaut

Si vous ne définissez pas d'intervalle de maintenance, Cloud SQL met à jour votre instance dans les fenêtres par défaut suivantes en fonction du fuseau horaire de votre instance :

  • Période de la semaine (du lundi au vendredi) : de 22 h à 6 h
  • Période du week-end : du vendredi, à 22 h au lundi, à 6 h

Exemple de maintenance

Supposons que vous travaillez pour un site marchand en tant que développeur responsable d'un service de panier d'achat. Vous disposez d'une première instance Cloud SQL pour un environnement de production et d'une seconde pour un environnement de préproduction. Vous souhaitez que les opérations de maintenance soient effectuées au moment où votre instance gère la plus faible quantité de trafic, soit vers minuit le dimanche. Vous souhaitez également éviter les opérations de maintenance pendant la période des fêtes de fin d'année.

Dans ce cas, vous définissez les paramètres de maintenance de votre instance de production sur :

  • Intervalle de maintenance : dimanche entre 0h et 1h (EST)
  • Ordre des mises à jour : Later
  • Période de refus de maintenance : du 1er novembre au 15 janvier.

Les paramètres de maintenance de votre environnement de préproduction sont identiques, à l'exception de l'ordre de mise à jour défini sur Earlier. Cela vous permet de mettre en œuvre des tests de validation opérationnels sur la nouvelle version associée à la maintenance, en préproduction et au minimum sept jours avant son déploiement en production. Si un problème survient dans l'environnement de préproduction, vous avez le temps de le diagnostiquer et de le résoudre afin que votre environnement de production ne soit pas affecté.

Notifications de maintenance à venir

Vous pouvez recevoir un e-mail de notification concernant la maintenance à venir au moins 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 instancename.

Par défaut, les notifications de maintenance ne sont pas envoyées. Vous devez activer les notifications de maintenance. Pour pouvoir recevoir des notifications, vous devez également sélectionner un intervalle de maintenance.

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).

L'activation des notifications de maintenance s'applique à toutes les instances Cloud SQL faisant l'objet d'intervalles de maintenance dans un projet donné. Vous recevez une notification par instance. Pour les instances dupliquées avec accès en lecture, aucune notification de maintenance à venir n'est envoyée.

Vous pouvez également consulter les informations de maintenance à venir dans Google Cloud Console.

  • 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 la console Google Cloud, vous pouvez afficher la liste des instances pour lesquelles des opérations de maintenance sont programmées. Si des opérations de maintenance sont programmées, les instances affichent le message Maintenance SQL, ainsi que la date et l'heure auxquelles celles-ci doivent démarrer.

Reprogrammer la maintenance

Si vous disposez d'un intervalle de maintenance pour votre instance, vous pouvez replanifier la maintenance à tout moment avant qu'elle ne soit planifiée. Par exemple, si vous lancez un nouveau service pendant la période de maintenance prévue, vous pouvez replanifier l'intervalle de maintenance quelques jours après le lancement.

Vous pouvez replanifier la maintenance plusieurs fois tant que la nouvelle date ne s'étend pas au-delà de 28 jours à compter de l'heure planifiée initialement.

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

  • Appliquer les mises à jour immédiatement. Vous pouvez immédiatement appliquer la mise à jour à votre instance au lieu d'attendre l'intervalle de maintenance programmé. Dans ce cas, la maintenance démarre généralement dans les 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 la maintenance au prochain intervalle de maintenance disponible suivant l'heure de maintenance planifiée actuelle, généralement une semaine plus tard.
    • Heure précise. Cette option vous permet de choisir une heure spécifique dans les 28 jours suivant l'heure de maintenance initialement planifiée.

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

Fonctionnement de la maintenance

Pour que la maintenance soit brève, Cloud SQL utilise un workflow de basculement de maintenance qui ressemble beaucoup à notre workflow de basculement automatique pour les instances à disponibilité élevée.

En résumé, voici les étapes du workflow :

  1. Configurer une VM mise à jour avec le nouveau logiciel
  2. Arrêter la VM d'origine
  3. Basculer le disque et l'adresse IP statique sur la VM mise à jour
  4. Démarrer la VM mise à jour

Parcourez les onglets ci-dessous pour afficher les détails du workflow, y compris avant et après la maintenance.

Avant la maintenance

Avant la maintenance, le client communique avec la VM d'origine via une adresse IP statique. Les données sont stockées sur un disque persistant associé à la VM d'origine. Dans cet exemple, la haute disponibilité est configurée pour l'instance Cloud SQL, ce qui signifie qu'une autre VM de secours est en mesure de prendre le relais en cas de panne imprévue. L'instance Cloud SQL diffuse du trafic vers l'application.

Schéma illustrant l'état avant la maintenance

Étape 1

Configurer la nouvelle VM

Une nouvelle machine virtuelle (VM) est configurée avec le dernier logiciel de base de données et le dernier système d'exploitation de VM. Le système d'exploitation de VM mis à jour est démarré. À ce stade, le moteur de base de données n'est pas encore démarré. Pour les instances à disponibilité élevée, une nouvelle VM de secours est également configurée.

L'installation d'une mise à jour logicielle sur une autre VM pendant que l'instance Cloud SQL d'origine continue de diffuser du trafic réduit considérablement le temps d'arrêt total.

Schéma illustrant la configuration de la VM

Étape 2

Arrêter la VM d'origine

Le moteur de base de données est arrêté afin que le disque puisse être détaché de la VM d'origine et associé à la VM mise à jour. Avant de s'arrêter, le moteur de base de données attend quelques secondes afin de valider les transactions en cours et de drainer les requêtes provenant des connexions restantes. Ensuite, toutes les transactions ouvertes ou de longue durée sont annulées. La base de données cesse d'accepter de nouvelles connexions et les connexions existantes sont interrompues. L'instance devient indisponible et le temps d'arrêt de maintenance commence.

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

Étape 3

Basculer vers la VM mise à jour

Le disque est dissocié de la VM d'origine et associé à la VM mise à jour. L'adresse IP statique est reconfigurée de manière à pointer vers la VM mise à jour. Cela garantit que l'application utilise la même adresse IP après la maintenance. Le cache de base de données est perdu avec la VM d'origine et on peut donc considérer que le cache de base de données est vidé pendant la maintenance.

Schéma de basculement vers la VM mise à jour

Étape 4

Démarrer la VM mise à jour

Le moteur de base de données mis à jour est démarré sur le disque de données. L'utilisation d'un disque de données commun garantit que toutes les transactions écrites sur l'instance d'origine avant la maintenance sont toujours présentes dans la base de données mise à jour après la maintenance. Si des transactions incomplètes n'ont pas été annulées lors de l'arrêt de la base de données, cette dernière applique automatiquement le processus de récupération après plantage afin de garantir qu'elle est restaurée dans un état utilisable.

Schéma de démarrage de la VM mise à jour

Après la maintenance

Après l'étape 4, l'instance Cloud SQL est disponible pour accepter les connexions et recommence à diffuser le trafic vers l'application.

Pour l'application, en dehors du logiciel mis à jour, l'instance Cloud SQL est identique. L'application se connecte toujours à l'instance Cloud SQL avec la même adresse IP statique, et la VM mise à jour s'exécute dans la même zone que la VM d'origine. Toutes les données écrites dans la base de données d'origine sont conservées.

Schéma après la maintenance

Réduire l'impact de la maintenance

En général, Google Cloud recommande aux utilisateurs qui exécutent des applications dans le cloud de rendre leurs systèmes résilients aux erreurs temporaires, qui sont des problèmes de communication temporaires entre les services causés par une indisponibilité temporaire. Des erreurs temporaires occasionnelles sont inévitables dans le cloud.

Certaines des erreurs temporaires qui se produisent pendant la maintenance sont des connexions interrompues et des transactions en cours ayant échoué. Si vous concevez vos systèmes et ajustez vos applications de manière à ce qu'elles soient résilientes aux erreurs temporaires, vous pouvez également minimiser les impacts liés à la maintenance de la base de données.

Pour minimiser l'impact des connexions interrompues, vous pouvez utiliser des pools de connexions. Bien que les connexions entre le pool et la base de données soient supprimées pendant la maintenance, les connexions entre l'application et le pool sont conservées. De cette manière, le travail de rétablissement des connexions est transparent pour l'application et déchargé vers le pool de connexions.

Pour réduire les échecs de transaction, vous pouvez limiter le nombre de transactions de longue durée. Réécrire des requêtes pour les rendre plus petites et plus efficaces permet non seulement de réduire les temps d'arrêt de maintenance, mais également d'améliorer les performances et la fiabilité de la base de données.

Pour une récupération efficace après les pertes de connexion et les échecs de transaction, pensez à gérer efficacement les connexions à la base de données. Vous pouvez créer une logique de nouvelle tentative avec un intervalle exponentiel entre les tentatives pour les connexions et requêtes dans vos applications et pools de connexions. En cas d'échec d'une requête ou d'abandon d'une connexion, le système instaure avant la nouvelle tentative un délai d'attente qui augmente avec chaque nouvelle tentative. Par exemple, le système peut n'attendre que quelques secondes pour la première nouvelle tentative mais jusqu'à une minute pour la quatrième. Suivre ce modèle permet de corriger ces défaillances sans surcharger le service.

D'autres solutions créatives peuvent également minimiser les impacts de maintenance, par exemple en utilisant des scripts pour réchauffer le cache de base de données après la maintenance ou pour optimiser le nombre de tables dans les bases de données. Nous vous recommandons de suivre les bonnes pratiques et les consignes opérationnelles liées à la gestion de base de données pour assurer le bon déroulement de la maintenance.

Maintenance urgente

Dans de très rares cas, Cloud SQL peut avoir besoin de planifier une maintenance en dehors de vos paramètres de maintenance pour corriger de graves problèmes de stabilité ou des failles urgentes. Ces mises à jour sont livrées rapidement, et Cloud SQL les considère comme des temps d'arrêt allant à l'encontre du contrat de niveau service.

Maintenance en libre-service

Cloud SQL publie régulièrement des améliorations logicielles et des correctifs pour corriger les failles de sécurité via de nouvelles versions de maintenance que vous pouvez installer sur vos instances. Cloud SQL tient à jour un journal des modifications de maintenance Cloud SQL pour chaque version majeure du moteur de base de données. Pour en savoir plus, consultez la page Journaux des modifications de maintenance Cloud SQL.

Bien que Cloud SQL planifie les mises à jour de maintenance tous les deux ou trois mois pour vous assurer que vous disposez des dernières versions logicielles en date, vous pouvez utiliser la maintenance en libre-service pour maintenir votre instance à jour, notamment si :

  • Vous aurez besoin d'une mise à jour avant votre prochain événement de maintenance programmé.
  • Vous souhaitez rattraper le logiciel le plus récent après avoir ignoré votre dernière mise à jour de maintenance.

Si vous utilisez des instances répliquées avec accès en lecture, vous pouvez utiliser la maintenance en libre-service pour mettre à jour toutes vos instances répliquées avec accès en lecture. Vous spécifiez l'instance principale. La requête de maintenance met à jour toutes les instances répliquées avec accès en lecture de l'instance principale vers la version de maintenance spécifiée. L'instance principale est ensuite mise à jour vers la version de maintenance.

Limites de maintenance

Cette section décrit les limites de la maintenance Cloud SQL.

Limites de reprogrammation

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).

  • 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 28 jours.

  • Si une opération de maintenance est en cours, la reprogrammation est retardée jusqu'à la fin de l'opération.

Limites des périodes de refus de maintenance

Vous devez connaître certaines informations concernant les périodes de refus de maintenance :

  • 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.

  • La période de refus de maintenance prévaut sur tout intervalle de maintenance programmé. En cas de conflit entre le moment où un intervalle de maintenance et une période de refus de maintenance doivent avoir lieu, la période de refus de maintenance remplace l'intervalle de maintenance.

  • 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 s'inscrit dans la période de refus de maintenance des instances définies sur 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é.

  • Si une période de refus de maintenance est définie après que la maintenance a été programmée, de sorte que la période de refus de maintenance chevauche l'heure de maintenance programmée, la mise à jour est ignorée.

  • 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.

  • Vous pouvez définir plusieurs périodes de refus de maintenance par an. Nous vous recommandons d'éviter d'associer des périodes de refus de façon à ignorer des événements de maintenance programmés consécutivement. L'actualisation de la maintenance de Cloud SQL est importante, car elle assure que votre instance fonctionne de manière fiable. En règle générale, la maintenance de Cloud SQL est programmée une fois tous les deux ou trois mois.

  • Afin de garantir la fiabilité du service, Cloud SQL peut notifier les utilisateurs dont les instances exécutent des versions de maintenance datant de plus de 12 mois que le prochain déploiement de maintenance devra être appliqué.

  • À la fin d'une période de refus de maintenance, le comportement standard de maintenance reprend.

  • Les périodes de refus de maintenance n'affectent pas les opérations déclenchées par l'utilisateur, telles que la maintenance en libre-service.

Questions fréquentes sur la maintenance

Comment la maintenance affecte-t-elle les anciennes instances de basculement à haute disponibilité ?

Les anciennes instances de basculement à haute disponibilité 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 ancienne instance de basculement à haute disponibilité, car celle-ci partage l'intervalle de maintenance de l'instance principale.

Les temps d'arrêt pour maintenance sont-ils comptabilisés dans le contrat de niveau de service ?

Les temps d'arrêt liés aux opérations de maintenance normale ne sont pas comptabilisés dans le contrat de niveau de service. Toutefois, Cloud SQL comptabilise les temps d'arrêt pour maintenance urgente par rapport au contrat de niveau de service.

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

  • Cloud SQL effectue toujours la maintenance des instances dupliquées avec accès en lecture avant celle de l'instance principale. Si l'instance principale comporte un intervalle de maintenance, les instances dupliquées avec accès en lecture observent le même intervalle de maintenance.
  • Si votre instance principale comporte plusieurs instances dupliquées avec accès en lecture, Cloud SQL peut mettre à jour certaines d'entre elles simultanément.
  • Les instances dupliquées avec accès en lecture observent la période de refus de maintenance définie pour l'instance principale.

Puis-je annuler une maintenance planifiée ?

Vous ne pouvez pas annuler un intervalle de maintenance planifié, mais vous pouvez le replanifier. Vous pouvez également configurer une Période de refus de maintenance qui chevauche l'heure de maintenance planifiée ce qui, dans les faits, ignore la maintenance.

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 à l'avance, lorsque cela est possible.

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

La maintenance Cloud SQL est-elle cumulative ?

Les mises à jour de maintenance sont cumulatives. Il n'est pas nécessaire d'appliquer chaque mise à jour de maintenance que vous avez peut-être manquée. La dernière version de maintenance est appliquée lors de la prochaine mise à jour de maintenance planifiée. Vous pouvez également appliquer la dernière mise à jour de maintenance à l'aide de la maintenance en libre-service.

Combien de temps prend la maintenance en libre-service pour toutes les instances répliquées avec accès en lecture d'une instance principale ?

La durée d'une mise à jour de maintenance en libre-service dépend du nombre total d'instances répliquées avec accès en lecture de votre instance principale. Pour réduire le délai nécessaire à la mise à jour de maintenance en libre-service, vous pouvez mettre à jour quelques instances répliquées avec accès en lecture individuellement, puis effectuer la mise à jour sur l'instance principale pour mettre à jour le reste des instances répliquées avec accès en lecture.

La deuxième mise à jour ignore toutes les instances répliquées qui ont déjà la version de maintenance cible.

Si mon instance principale dispose de plusieurs instances répliquées avec accès en lecture, puis-je effectuer une maintenance en libre-service sur une seule instance répliquée avec accès en lecture ?

Oui, vous pouvez effectuer la maintenance en libre-service sur une instance répliquée individuelle avec accès en lecture. Toutefois, nous vous recommandons de mettre à jour peu de temps après le reste des instances répliquées avec accès en lecture et l'instance principale vers la même version de maintenance. Nous vous recommandons d'exploiter toutes les instances répliquées avec accès en lecture et l'instance principale avec une version de maintenance identique.

Étapes suivantes