Consignes opérationnelles pour les instances SQL Server

Le contrat de niveau de service de Cloud SQL exclut les pannes "causées par des facteurs indépendants de la volonté de Google". Cette page décrit certaines des configurations contrôlées par l'utilisateur qui peuvent entraîner l'exclusion d'une panne d'instance Cloud SQL.

Présentation

Cloud SQL s'efforce de vous donner le plus de contrôle possible sur la configuration de votre instance. Cela inclut certaines configurations qui augmentent le risque de temps d'arrêt des instances, en fonction de leur charge et d'autres paramètres de configuration. Si votre instance tombe en panne et que Cloud SQL détermine qu'elle ne respectait pas les limites opérationnelles décrites dans cette page, la période d'indisponibilité n'est pas couverte (ou n'est pas comptabilisée) par le contrat de niveau de service Cloud SQL.

Cette liste de limites opérationnelles vous est présentée afin de vous informer des configurations qui comportent des risques, des moyens d'éviter de passer par inadvertance à l'une de ces configurations, ainsi que des précautions à prendre pour atténuer les risques lorsqu'une de ces configurations est requise par votre environnement d'entreprise.

Configurations exclues

Les configurations exclues appartiennent à l'une des catégories suivantes :

  • Configuration générale requise
  • Valeurs d'indicateurs de base de données
  • Contraintes liées aux ressources

Configuration générale requise

Seules les instances Cloud SQL configurées pour la haute disponibilité avec au moins un processeur dédié sont couvertes par le contrat de niveau de service. Les instances à cœur partagé et les instances à zone unique ne le sont pas.

Si l'instance est configurée et utilisée de manière à ce que la charge de travail surcharge l'instance, le contrat de niveau de service ne s'applique pas. Voici quelques exemples de cas :

  • La combinaison de work_mem, de requêtes de charge de travail spécifiques et d'un nombre de connexions actives en parallèle entraîne un manque de mémoire du système, ce qui provoque le plantage des backends de nœuds de calcul PostgreSQL avec les opérations de récupération résultantes exécutées par PostgreSQL.
  • La combinaison de checkpoint_timeout, max_wal_size et d'une charge de travail élevée, éventuellement avec une VM qui n'est pas suffisamment puissante, entraîne une situation dans laquelle la récupération (relecture WA) prend beaucoup de temps.
  • Les transactions très longues exécutées avec des charges de travail qui créent un grand nombre de fichiers temporaires compliquent le suivi de autovacuum, ce qui peut générer des données volumineuses dans la table et diminuer les performances.

Ces exemples ne constituent pas la liste complète, car il existe de nombreuses façons de surcharger la base de données PostgreSQL. Nous vous recommandons vivement de configurer des alertes et la surveillance dans Cloud Monitoring.

Valeurs d'options de base de données

Cloud SQL vous permet de configurer votre instance avec des options de base de données. Il se peut que la définition de certains de ces indicateurs compromette la stabilité de l’instance ou la durabilité de ses données.

Contraintes liées aux ressources

Les contraintes de ressources suivantes doivent être évitées afin de bénéficier du contrat de niveau de service :

Contrainte Description Détection Solution Prévention
Espace de stockage plein Si votre instance manque d'espace de stockage et que la fonctionnalité d'augmentation automatique de la capacité de stockage n'est pas activée, votre instance se déconnecte. Cette interruption n'est pas couverte par le contrat de niveau de service. Vous pouvez vérifier la quantité de stockage utilisée par l'instance sur la page de détails de l'instance de Google Cloud Console. En savoir plus

Pour surveiller l'utilisation de votre espace de stockage et recevoir des alertes à un seuil spécifié, configurez une alerte Stackdriver. En savoir plus.

Augmentez la taille de l'espace de stockage de l'instance. Notez qu'il est possible d'augmenter la taille de l'espace stockage, mais pas de la diminuer. Activez l'augmentation automatique de l'espace de stockage de l'instance. En savoir plus.
Processeur surchargé Si l'utilisation du processeur est supérieure à 98 % pendant 6 heures, l'instance n'est pas correctement dimensionnée par rapport à la charge de travail, et n'est donc pas couverte par le contrat de niveau de service. Vous pouvez vérifier le pourcentage du processeur utilisé par l'instance sur la page de détails de l'instance de Google Cloud Console. En savoir plus

Pour surveiller l'utilisation du processeur et recevoir des alertes à un seuil spécifié, configurez une alerte Stackdriver. En savoir plus.

Augmentez le nombre de processeurs pour l'instance. Notez que la modification des processeurs nécessite un redémarrage de l'instance.

Si votre instance a déjà atteint le nombre maximal de processeurs, segmentez la base de données sur plusieurs instances.

Surveillez l'utilisation du processeur et augmentez sa capacité si nécessaire. Notez que toute modification du nombre de processeurs de l'instance nécessite un redémarrage.