Utilisez ce guide pour adapter la taille de votre instance Tair (compatible avec OSS Redis). Effectuez une mise à niveau pour gérer une augmentation du trafic, ou une rétrogradation pour réduire les coûts lors des périodes de faible utilisation.
Facturation
La facturation dépend de votre mode de paiement :
| Mode de facturation | Conséquences |
|---|---|
| Abonnement | Payez la différence de prix pour une mise à niveau, ou recevez un remboursement pour une rétrogradation. |
| Paiement à l'utilisation | Facturation basée sur les nouvelles spécifications. |
Pour plus de détails sur les tarifs, consultez la rubrique Modifications de configuration.
Limites
Vérifiez les contraintes suivantes avant de commencer :
| Contrainte | Détails |
|---|---|
| Seuil minimal de mémoire pour les rétrogradations | Après une rétrogradation, la mémoire utilisée ne peut pas dépasser 80 % de la nouvelle capacité mémoire. Par exemple, si votre instance basée sur DRAM utilise actuellement 2 Go, vous ne pouvez pas rétrograder vers une capacité inférieure à 2,5 Go. |
| Instances distribuées | Toutes les instances enfants au sein d'une instance distribuée doivent avoir des spécifications identiques. Les spécifications mixtes ne sont pas prises en charge. |
| Instances basées sur ESSD | La capacité de stockage ne peut qu'augmenter, par incréments de 10 Go. La réduction du stockage n'est pas prise en charge. |
| Mises à niveau du CPU uniquement | Vous ne pouvez pas mettre à niveau le CPU indépendamment. Pour augmenter le nombre de cœurs CPU disponibles, passez à une architecture en cluster, activez la séparation lecture/écriture, ajoutez des nœuds en lecture seule ou ajoutez des shards. |
Modifier les spécifications de l'instance
Éléments inchangés
Lorsque vous modifiez les spécifications, les éléments suivants restent inchangés ; aucune modification du code de l'application n'est requise :
Endpoints
Comptes de base de données et mots de passe
Paramètres de la liste d'autorisation
Les données de l'instance sont conservées. Dans le cas rare où le nœud principal échoue pendant le basculement, une petite quantité de données non synchronisées peut être perdue. Par mesure de précaution, créez une sauvegarde manuelle avant de modifier les spécifications.
La modification des spécifications (qu'il s'agisse d'une mise à l'échelle verticale ou horizontale) n'affecte pas directement l'utilisation du CPU, le nombre de connexions client, le débit ou le taux de succès du cache. Ces métriques sont déterminées par votre charge de travail réelle, et non par le niveau de spécification.
Impact sur le service
Les mises à l'échelle ascendantes (mises à niveau) et descendantes (rétrogradations, y compris celles qui réduisent uniquement la mémoire des nœuds) peuvent déclencher une migration d'hôte lorsque l'hôte actuel ne peut pas accueillir les spécifications cibles. Un basculement migré n'est pas transparent : il provoque 1 à 2 brèves interruptions de connexion et environ 1 minute d'état en lecture seule. Seules les instances de cluster cloud-native et les instances standard cloud-native hébergées sur des hôtes disposant de ressources suffisantes effectuent la modification sur place sans temps d'arrêt.
| Scénario | Interruption de service |
|---|---|
| Instance de cluster cloud-native, ou instance standard cloud-native sur un hôte disposant de ressources suffisantes | Aucune. Mise à jour transparente sur place, sans temps d'arrêt. |
| Instance standard cloud-native sur un hôte disposant de ressources insuffisantes, ou toute instance Classic | 1 à 2 déconnexions transitoires (chacune durant moins de 30 secondes), plus environ 1 minute d'état en lecture seule. Assurez-vous que votre application se reconnecte automatiquement. |
Lorsqu'un basculement se produit, l'instance passe également en lecture seule pendant environ une minute afin de garantir une synchronisation rapide des données et d'éviter les problèmes de double écriture causés par la mise en cache DNS. Pour les instances générant un volume d'écriture élevé, cette période peut être plus longue.
Pendant la modification, la version mineure de votre instance est automatiquement mise à niveau vers la dernière version. Les versions mineures sont rétrocompatibles.
Durée de la modification de configuration
La durée totale d'une modification de configuration se compose de deux phases :
Préparation en arrière-plan : Le système provisionne de nouveaux nœuds avec les spécifications cibles et synchronise les données. Cette opération peut prendre de quelques dizaines de minutes à plusieurs heures, selon le volume de données. Pendant cette phase, l'instance continue de traiter les requêtes normalement et l'activité n'est pas affectée.
Basculement : Une fois la préparation terminée, le trafic est redirigé vers les nouveaux nœuds. Les instances de cluster cloud-native et les instances standard disposant de ressources suffisantes basculent de manière transparente ; dans les autres cas, 1 à 2 déconnexions transitoires de moins de 30 secondes chacune se produisent.
Par conséquent, la durée totale de la modification de configuration (de quelques dizaines de minutes à plusieurs heures) et la durée d'impact sur l'activité (moins de 30 secondes, ou nulle) sont deux concepts distincts. Vous pouvez suivre la progression dans le Task Center de la console.
Étapes
Connectez-vous à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où se trouve votre instance, puis cliquez sur l'ID de l'instance.
-
Dans le coin supérieur droit, cliquez sur Specification Adjustment, puis sélectionnez l'option appropriée :
Instance sous abonnement : Sélectionnez Specification Upgrade ou Specification Downgrade.
Instance en paiement à l'utilisation : Sélectionnez Specifications Upgrade/Downgrade.
Sur la page qui s'affiche, sélectionnez les spécifications cibles.
-
Définissez l'option Switching Time :
Switch During the Maintenance Window : Le système applique la modification pendant la fenêtre de maintenance configurée (heures creuses). Pour ajuster l'horaire avant le basculement, accédez au Task Center et cliquez sur Change Switching Time à côté de la tâche.
Switch Immediately After Data Migration : Le système bascule vers le nouveau nœud immédiatement après la fin de la migration des données.
Cliquez sur Create Now et effectuez le paiement.
Après soumission, le statut de l'instance passe à Changing Configuration. Le système commence à demander des ressources et à synchroniser les données en arrière-plan ; vos services ne sont pas affectés à ce stade. Les déconnexions transitoires ne se produisent qu'au moment du basculement vers le nouveau nœud.
Fonctionnement des modifications de spécifications
Comprendre le processus sous-jacent vous aide à prévoir quand des interruptions peuvent se produire.
Instance cloud-native
L'instance passe à l'état Changing Configuration.
Le système vérifie si l'hôte actuel dispose de suffisamment de ressources pour les spécifications cibles.
-
Selon les ressources disponibles, le système emprunte l'une des deux voies suivantes :
Ressources suffisantes : La modification des spécifications s'effectue sur place sans interruption.
Ressources insuffisantes : Le système provisionne un nouveau nœud hôte, pré-synchronise les données de l'instance vers celui-ci, puis redirige le trafic vers le nouveau nœud pendant la fenêtre de maintenance (ou immédiatement). Cela provoque une brève déconnexion transitoire.
L'instance revient à l'état Running.
Instance Classic
L'instance passe à l'état Changing Configuration.
Le système provisionne un nouveau nœud hôte et pré-synchronise les données de l'instance vers celui-ci.
Le système redirige le trafic vers le nouveau nœud pendant la fenêtre de maintenance (ou immédiatement). Cela provoque une brève déconnexion transitoire.
L'instance revient à l'état Running.
FAQ
Puis-je mettre à niveau uniquement le CPU sans modifier la mémoire ?
Non. Tair (y compris l'édition Open-Source de Redis) ne prend pas en charge la mise à niveau indépendante du CPU. Pour augmenter le nombre de cœurs CPU disponibles, utilisez l'une des approches suivantes :
Passez d'une architecture standard à une architecture en cluster, ou activez la séparation lecture/écriture.
Ajoutez des nœuds en lecture seule (pour les instances avec séparation lecture/écriture activée).
Ajoutez des shards (pour les instances en cluster).
Pour plus de détails, consultez les rubriques Comment mettre à niveau les spécifications CPU d'une instance et Types d'instance et FAQ.
La mise à niveau des spécifications de mémoire augmente-t-elle la bande passante ?
Que signifie l'erreur "The direct custins transfer node double target level error" ?
Que dois-je prendre en compte avant de modifier les spécifications lorsque l'utilisation de la mémoire est élevée ?
Si vous envisagez une rétrogradation et que votre utilisation actuelle de la mémoire est élevée, vérifiez d'abord que les spécifications cibles satisfont la contrainte suivante : capacité mémoire nouvelle × 0,8 > mémoire actuellement utilisée. Si cette condition n'est pas remplie, la rétrogradation échoue et la configuration d'origine est conservée ; aucune donnée n'est perdue.
Si vous envisagez une mise à niveau pour remédier à une utilisation persistante et élevée de la mémoire, pensez d'abord à enquêter sur la cause racine. La réduction des données inutiles (par exemple, en nettoyant les clés inutilisées, en définissant des politiques TTL ou en ajustant la politique d'éviction) peut diminuer la consommation de mémoire et vous permettre de différer ou d'éviter une mise à niveau. Pour une approche systématique de dépannage, consultez la rubrique Dépannage d'une utilisation élevée de la mémoire.