Comportement pendant le scaling

Cette page décrit le comportement de votre instance Memorystore pour Redis pendant le scaling. Pour découvrir comment faire évoluer une instance Redis, reportez-vous à la section Réaliser le scaling d'instances Redis.

En fonction du niveau de l'instance, le scaling entraîne des conséquences sur les performances et le stockage de votre application. Il existe également certaines limites associées au scaling d'instances en fonction de la quantité de mémoire actuellement utilisée. Cette page explique comment le scaling d'une instance peut affecter votre application et quand vous pouvez l'effectuer.

Bonnes pratiques pour le scaling d'une instance

  • Nous vous recommandons d'exporter les données de votre instance avant de procéder au scaling de votre opération.

  • Pour les instances de niveau standard, effectuez le scaling pendant les périodes de faible trafic des instances afin d'augmenter la vitesse et la fiabilité de l'opération. Pour savoir comment surveiller le trafic des instances, consultez la page Surveiller des instances Redis.

  • Lorsque vous réduisez la capacité d'une instance de niveau standard, vous devez choisir une taille supérieure à la quantité de données stockée ou le scaling échouera.

    • Par exemple, si vous disposez d'une instance de 10 Go qui contient 5,5 Go de données, vous pouvez redimensionner l'instance à un minimum de 6 Go. L'espace de stockage utilisé par votre instance est visible sur sa page d'informations dans Cloud Console.

Comportement de scaling au niveau de base

Les instances de niveau de base bloquent les lectures et les écritures pendant que l'instance subit un redimensionnement lui permettant d'atteindre la capacité souhaitée. Une fois l'instance redimensionnée, les données du cache subissent une purge. Procédez au scaling d'une instance pendant une période de faible trafic afin de minimiser l'impact sur les performances de votre application.

Comportement de scaling au niveau standard

Procédez au scaling des instances de niveau standard pendant une période de faible activité pour minimiser l'impact sur les performances de votre application.

Les instances de niveau standard ne subissent quasiment pas d'interruptions pendant le processus de scaling, car toutes les instances de niveau standard possèdent des instances maîtres et des instances dupliquées. Lors du scaling, l'instance dupliquée est redimensionnée en premier, puis synchronisée avec l'instance maître. Une fois que la nouvelle instance dupliquée a rattrapé la nouvelle instance maître, celle-ci bascule sur la nouvelle instance dupliquée. Pendant le basculement, les connexions à l'instance sont interrompues. Les applications doivent incorporer une logique de répétition d'essai dans le code pour pouvoir se reconnecter à la nouvelle instance maître. Enfin, l'ancienne instance maître est redimensionnée.

Une fois le scaling effectué, des données obsolètes ou incohérentes peuvent se trouver dans le cache en raison de la nature asynchrone de la réplication Redis. L'application doit être suffisamment résiliente pour gérer les incohérences dues au basculement.

Charge d'écriture pendant le scaling

Lors du scaling d'une instance de niveau standard, maintenez la charge d'écriture de l'instance au minimum. Une charge d'écriture élevée peut entraîner un scaling beaucoup plus long et provoquer l'échec de l'opération de scaling.

Clés expirées

Lors du scaling d'une instance de niveau standard, les clés expirées ne sont pas synchronisées. Si vous avez des clés expirées dans l'instance Redis avant le scaling, vous aurez moins de clés après le scaling de l'instance.