Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
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
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 la consoleGoogle Cloud .
Comportement du scaling des instances
Les données sont conservées lors du scaling pour les instances de niveau de base et standard.
Lors du scaling, l'instance subit une brève réinitialisation de la connexion de quelques minutes, voire moins. Les applications doivent intégrer une logique de nouvelles tentatives dans le code pour pouvoir se reconnecter à l'instance. L'adresse IP et la chaîne de connexion restent les mêmes.
En raison de la brève interruption de la connexion, il est possible qu'une petite quantité de données obsolètes ou incohérentes n'ait pas été écrite ni mise à jour dans le cache pendant la courte période d'indisponibilité de l'instance.
Si vous émettez une écriture pendant l'interruption de la connexion, Memorystore renvoie l'erreur READONLY You can't write against a read only replica. Cette erreur est temporaire et ne dure que quelques secondes. Elle est résolue une fois l'opération de scaling terminée.
Charge d'écriture lors du scaling
Vous devez procéder au scaling d'une instance pendant une période de faible trafic afin de minimiser l'impact sur les performances de votre application. Une charge d'écriture élevée ou une forte pression sur la mémoire peuvent entraîner un scaling beaucoup plus long et provoquer l'échec de l'opération. Pour en savoir plus, consultez Opérations de scaling et de mise à niveau de version.
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.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/05 (UTC)."],[],[],null,["# About scaling instances\n\n| **Note:** If you are looking for the Memorystore for Redis Cluster documentation, see [About scaling instance capacity](/memorystore/docs/cluster/about-scaling-instance-capacity).\n\nThis page describes how your Memorystore for Redis instance behaves during scaling.\nTo learn how to scale a Redis instance, see [Scaling Redis Instances](/memorystore/docs/redis/scaling-instances).\n\nDepending on the instance's tier, scaling an instance has performance and\nstorage implications for your application. There are also some limitations to\nscaling instances based on the amount of memory that is currently in use. This\npage describes how scaling an instance can affect your application and when\nyou can scale an instance.\n| **Note:** When you scale an instance, there might be a gap of 3-5 minutes when the [core metrics](/memorystore/docs/redis/monitor-instances#monitoring-instances-console) for the instance don't appear. During this time, the instance is available. After the time interval completes, the metrics appear.\n\nBest practices for scaling an instance\n--------------------------------------\n\n- For Standard Tier instances, to increase the speed and reliability of\n your scaling operation, scale your instance during periods of low instance\n traffic. To learn how to monitor instance traffic, see [Monitoring Redis instances](/memorystore/docs/redis/monitoring-instances).\n\n- When reducing a Standard Tier instance's capacity, you must choose a size\n greater than the amount of data being stored or scaling fails.\n\n - For example, if your have a 10 GB instance that has 5.5 GB of data stored in it, you can resize the instance to a minimum of 6 GB. The amount of storage your instance uses is visible on its details page in the Google Cloud console.\n\nInstance scaling behavior\n-------------------------\n\nData is preserved during scaling for both Basic and Standard Tier instances.\nDuring scaling the instance undergoes a short connection reset of a couple\nminutes, or less. Applications should incorporate retry logic in the code to be\nable to reconnect to the instance. The IP address and connection string remain\nthe same.\n\nBecause of the short term connection break, there may be a small amount of stale\nor inconsistent data that didn't write or update to the cache for the short\namount of time the instance was unavailable.\n\nIf you issue a write during the connection break, Memorystore\nreturns the error `READONLY You can't write against a read only replica`. This\nerror is transient, and only lasts a few seconds. It resolves once the scaling\noperation completes.\n\n### Write load when scaling\n\nYou should scale an instance during a period of low instance traffic to minimize the performance impact on your application. A high write load, or high memory pressure, can cause an scaling operation to take significantly longer and can cause the operation to fail. For more information see [Scaling and version upgrade operations](/memorystore/docs/redis/memory-management-best-practices#scaling_and_version_upgrade_operations).\n\n### Expired keys\n\nWhen you scale a Standard Tier instance, expired keys are not synced. If you have\nexpired keys in your Redis instance before you scale, you will have fewer keys\nafter the instance is scaled."]]
