Résoudre des problèmes

Cette page décrit différents scénarios d'erreur et fournit des conseils pour les résoudre.

Scénarios de réplication

Cette section explique les problèmes de réplication qui peuvent survenir avec votre instance.

Comment surveillez-vous les délais de réplication ?

Memorystore pour Valkey propose la métrique /instance/replication/maximum_offset_diff. Cette métrique surveille la différence maximale de décalage de réplication (en octets) pour un nœud dans une instance principale.

En maintenant une faible différence de décalage de réplication, les réplicas peuvent effectuer des opérations de synchronisation incrémentielle plus fréquemment et à un coût inférieur à celui des opérations de synchronisation complète.

Nous vous recommandons de définir un seuil pour la métrique maximum_offset_diff. Si le seuil est dépassé, Memorystore for Valkey peut vous en informer par le biais d'une alerte.

En fonction du type de nœud de votre instance, nous vous recommandons de définir le seuil comme suit :

  • Si le type de nœud est shared-core-nano, custom-pico, custom-micro, custom-mini, standard-small, highmem-medium, highcpu-medium ou standard-large, définissez le seuil sur une valeur inférieure à 64 Mo.

  • Si le type de nœud est highmem-xlarge ou highmem-2xlarge, définissez le seuil sur une valeur inférieure à 1 Go.

Que faire en cas de décalage de réplication entre votre instance principale et ses instances répliquées ?

Il peut y avoir un décalage de réplication important si l'instance principale comporte trop d'opérations d'écriture et que les instances répliquées ne peuvent pas les rattraper. Pour résoudre ce problème, nous vous recommandons de faire évoluer la capacité de l'instance en augmentant le nombre de partitions pour l'instance.

Scénarios d'utilisation du processeur

Cette section explique les problèmes d'utilisation du processeur que votre instance peut rencontrer.

Que faire si le tampon de sortie de votre instance manque d'espace ?

Si le tampon de sortie de votre instance Memorystore pour Valkey manque d'espace, procédez comme suit :

  • Définissez une valeur plus petite pour le paramètre maxmemory.
  • Utilisez la règle maxmemory allkeys-lru.

Si la mémoire de votre instance est saturée et qu'une nouvelle écriture arrive, Memorystore pour Valkey supprime les clés conformément à la règle maxmemory de l'instance afin de libérer de l'espace pour l'écriture. La règle allkeys-lru supprime les clés les moins récemment utilisées (LRU, least recently used) de la collection de clés.

Nous vous recommandons de surveiller la maxmemory et la mémoire utilisée de votre instance. Cela vous permet de savoir si votre instance atteint la capacité d'instance provisionnée. De plus, en réduisant la valeur du paramètre maxmemory, vous obtenez plus d'espace pour les frais généraux.

Pourquoi des métriques externes peuvent-elles manquer pour votre instance ?

Si votre instance connaît une utilisation élevée du processeur ou si ses ressources sont épuisées (par exemple, en raison d'un nombre trop important de connexions), elle peut se comporter de manière anormale et des métriques externes peuvent manquer.

Comment isoler la source de la latence de votre instance ?

Pour déterminer si la latence que vous rencontrez provient de votre instance, de votre application cliente ou de votre environnement réseau, utilisez l'outil valkey-cli pour exécuter un test de latence continu.

Pour isoler la source de la latence de votre instance, procédez comme suit :

  1. Connectez-vous à une VM Compute Engine située dans la même région et le même réseau VPC que votre instance.

  2. Si l'outil valkey-cli n'est pas encore installé, installez-le sur votre VM.

    • Pour les VM basées sur Debian ou Ubuntu, exécutez la commande suivante :

      sudo apt-get install valkey-tools

    • Pour les VM basées sur RHEL ou CentOS, exécutez la commande suivante :

      sudo yum install valkey-tools

  3. Pour mesurer la latence de l'instance en millisecondes, exécutez la commande suivante :

    redis-cli --latency -h ENDPOINT_ADDRESS -p PORT

    Si votre instance utilise le chiffrement en transit, ajoutez le flag --tls et spécifiez vos autorités de certification (CA) pour vous connecter.

    Effectuez les remplacements suivants :

    • ENDPOINT_ADDRESS : adresse IP du point de terminaison de votre instance.
    • PORT : numéro de port réservé au point de terminaison de votre instance. Ce numéro de port est généralement 6379.

  4. Laissez la commande s'exécuter pendant quelques minutes. L'outil envoie en continu des requêtes ping au serveur et calcule les valeurs de latence minimale, maximale et moyenne.

  5. Pour arrêter la commande et afficher les résultats, appuyez sur Ctrl+C.

Si la commande génère une latence moyenne constamment faible (généralement 1 milliseconde ou moins), cela signifie que l'instance est saine et réagit rapidement.

Si la commande affiche une latence constamment faible, mais que votre application cliente rencontre toujours des retards, les problèmes suivants peuvent être à l'origine de la latence :

  • Réseau : le trafic acheminé entre votre client et l'instance dans différentes régions ou zones peut entraîner des latences réseau importantes.
  • Client : une utilisation intensive du processeur ou de la mémoire sur le client, des pools de connexions épuisés ou des goulots d'étranglement de la logique d'application peuvent augmenter le délai aller-retour total que le client rencontre.

Scénarios de gestion de la mémoire

Cette section explique les problèmes de gestion de la mémoire que votre instance peut rencontrer.

Quelle métrique pouvez-vous utiliser pour déterminer si votre instance est soumise à une forte pression sur la mémoire ?

Pour surveiller l'utilisation de la mémoire d'une instance Memorystore pour Valkey, nous vous recommandons d'afficher la métrique /instance/memory/maximum_utilization. Si l'utilisation de la mémoire de l'instance approche les 80% et que vous prévoyez une augmentation de la consommation des données, augmentez la taille de l'instance pour améliorer les performances et faire de la place pour de nouvelles données.

Scénarios de surveillance

Cette section explique les problèmes de surveillance que votre instance peut rencontrer.

Comment configurer des alertes pour Memorystore pour Valkey ?

Vous pouvez utiliser Cloud Monitoring pour définir des alertes qui vous avertissent si des métriques dépassent les seuils que vous avez définis pour votre instance. Pour en savoir plus sur la configuration d'alertes dans Cloud Monitoring, consultez Définir une alerte Monitoring pour l'utilisation de la mémoire.

Scénarios de gestion des connexions

Cette section explique les problèmes de gestion des connexions que votre instance peut rencontrer.

Que faire si vous atteignez votre limite de connexions ou si vous recevez un message d'erreur de délai de connexion dépassé ?

Lorsque vous atteignez la limite de connexions, votre client ne parvient pas à se connecter à votre serveur. C'est ce qu'on appelle un refus de connexion.

Si cela se produit, procédez comme suit :

  • Utilisez la métrique /instance/node/stats/rejected_connections_count pour déterminer le nombre de connexions que Memorystore pour Valkey refuse, car le nœud de l'instance atteint la limite maximale de clients.
  • Utilisez la métrique /instance/node/clients/connected_clients pour déterminer le nombre de clients connectés au nœud d'instance. Vous pouvez ainsi vérifier si tous les nœuds de l'instance sont en dessous de la limite.
  • Arrêtez les connexions indésirables ou ayant fait l'objet d'une fuite à l'aide de la commande client kill.
  • Réduisez le nombre de connexions ou la taille du pool dans l'application cliente. Pour en savoir plus, consultez la documentation associée à l'application cliente.
  • Ajustez la limite maximale de clients. Pour en savoir plus, consultez Configurer une instance.
  • Faites évoluer votre instance vers un type de nœud plus grand afin qu'elle dispose d'une limite de connexion plus élevée.

Scénarios de délai avant expiration

Cette section explique les problèmes de délai d'attente que votre instance peut rencontrer.

Que faire si vous recevez un message d'erreur de délai d'attente d'E/S ?

Lorsqu'une opération de lecture ou d'écriture dans Memorystore pour Valkey ne parvient pas à se terminer dans un délai spécifié, un délai d'attente d'E/S se produit. Ce délai d'inactivité peut être dû à diverses raisons. Par exemple, un ou plusieurs nœuds de votre instance peuvent être surchargés.

Si vous recevez un message d'expiration du délai d'E/S, procédez comme suit :

Scénarios d'erreur de connectivité

Cette section explique les problèmes de connectivité que votre instance peut rencontrer.

Erreur de connexion provoquée par des règles de pare-feu

Si vous n'autorisez pas les ports appropriés sur votre pare-feu, votre instance peut rencontrer des erreurs de connexion, car le pare-feu peut bloquer les ports utilisés par Memorystore pour Valkey.

Pour tous les points de terminaison Private Service Connect de votre instance, vous devez autoriser le port TCP 6379, ainsi que les ports TCP 11000 à 13047. Pour en savoir plus sur ces points de terminaison, consultez Adresses réseau réservées.

Erreur de connexion causée par des règles d'administration

Vous pouvez disposer d'une règle d'administration qui bloque vos connexions Private Service Connect à votre instance Memorystore pour Valkey.

Si votre règle d'administration utilise la règle .restrictPrivateServiceConnectProducer, ajoutez le numéro de dossier 672235397475 à la liste d'autorisation. Il s'agit d'un dossier spécifiquement destiné à Memorystore pour Valkey. Exemple :

name: organizations/Consumer-org-1/policies/compute.restrictPrivateServiceConnectProducer
spec:
    rules:
      - values:
          allowedValues:
          - under:folders/672235397475

Si votre règle d'administration utilise la règle .disablePrivateServiceConnectCreationForConsumers, ajoutez SERVICE_PRODUCERS à la liste d'autorisation. Exemple :

name: organizations/Consumer-org-1/policies/compute.disablePrivateServiceConnectCreationForConsumers
spec:
    rules:
      - values:
          allowedValues:
          - SERVICE_PRODUCERS

Erreur de connexion provoquée par des connexions non réactives

Nous vous recommandons vivement de configurer votre application cliente pour qu'elle détecte les connexions non réactives à Memorystore for Valkey. Lorsqu'une connexion qui ne répond pas est détectée, le client doit la réinitialiser. Pour créer une application résiliente, nous vous recommandons les configurations client suivantes :

  • Configurez les paramètres de message keep-alive TCP : définissez les paramètres TCP keepalive time, TCP keepalive interval et TCP keepalive probes afin que les clients détectent et abandonnent de manière proactive les connexions qui ne répondent pas, même lorsqu'elles sont inactives. Par exemple, si vous définissez le paramètre TCP keepalive time sur 30 secondes, TCP keepalive interval sur 10 secondes et TCP keepalive probes sur 3, les clients réinitialisent les connexions inactives qui ne répondent pas en une minute.
  • Configurer les délais d'inactivité TCP : définissez ce délai d'inactivité dans vos clients pour réinitialiser les connexions qui ont des requêtes en attente et qui ne répondent plus. Par exemple, si vous définissez le délai avant expiration sur 15 secondes, les clients réinitialisent les connexions non réactives qui ont des requêtes en attente au bout de 15 secondes.

Gérer les erreurs pour les instances avec le mode cluster désactivé

  • Si l'application se connecte au point de terminaison de lecture d'une instance qui ne comporte pas d'instances répliquées avec accès en lecture, la connexion se ferme et le message d'erreur ERR no replicas found s'affiche. Dans ce cas, essayez de connecter l'application au point de terminaison principal ou d'ajouter des instances répliquées avec accès en lecture à l'instance.

  • En cas de basculement, les connexions existantes de votre application se ferment et le message d'erreur ERR role change occurred s'affiche. Ce message d'erreur s'affiche également si votre application se connecte au point de terminaison de lecture d'une instance et que toutes les instances répliquées avec accès en lecture de l'instance échouent. Dans ce cas, l'application doit réessayer d'établir la connexion avec un intervalle exponentiel entre les tentatives.

Scénarios de persistance

Cette section explique les problèmes de persistance qui peuvent survenir avec votre instance.

Votre trafic d'écriture dépasse la capacité de Memorystore pour Valkey à compacter et à récupérer de l'espace grâce à la réécriture AOF.

Dans ce cas, le fichier AOF (Append-Only File) croît plus rapidement que le processus de réécriture ne peut le gérer. Cela entraîne l'épuisement de l'espace disque, des échecs d'écriture et le blocage des opérations nécessitant la création d'un réplica et une synchronisation complète.

Memorystore pour Valkey a mis en place des garde-fous pour réguler le débit d'écriture. Cela garantit que la réécriture AOF peut suivre le rythme des charges de travail à écriture élevée soutenues.