Tair (Redis® OSS-Compatible):Change instance architecture

Avant de commencer

Examinez les impacts suivants avant de démarrer la modification.

• Les endpoints, comptes, mots de passe et listes d'autorisation restent inchangés. Aucune modification du code de l'application n'est requise.

• Les données sont généralement conservées. Dans le cas rare où le nœud principal tombe en panne pendant le basculement, une petite quantité de données non synchronisées peut être perdue.

• Une à deux déconnexions transitoires, chacune durant moins de 30 secondes. Assurez-vous que votre application dispose d'un mécanisme de reconnexion.

• État en lecture seule pendant environ 1 minute. L'instance passe en mode lecture seule pendant que la nouvelle instance synchronise les données incrémentielles et que le cache DNS se vide. Les instances soumises à une charge d'écriture élevée peuvent connaître une période en lecture seule plus longue.

• Les scripts Lua peuvent être perdus. Sauvegardez vos scripts Lua avant de poursuivre. Pour plus de détails, consultez la rubrique Limites spécifiques aux instances cluster.

• Dans les clusters en mode proxy, le premier argument de redis.call ou redis.pcall dans les scripts Lua doit être une chaîne littérale (par exemple, 'GET'), et non une variable. Un argument variable déclenche l'erreur ERR bad lua script for redis cluster, first parameter of redis.call/redis.pcall must be a single literal string. Cette restriction affecte les frameworks tiers tels que Redisson qui construisent dynamiquement les noms de commandes. Pour désactiver cette vérification, définissez le paramètre script_check_enable sur 0. Pour plus d'informations, consultez la rubrique Limites spécifiques aux instances cluster.

• Des limitations supplémentaires s'appliquent aux commandes. Certaines commandes ne sont pas prises en charge dans l'architecture cluster. Évaluez l'impact sur votre charge de travail avant de procéder au changement. Pour plus de détails, consultez la rubrique Limitations des commandes pour les instances cluster.

• L'instance est mise à niveau vers la dernière version mineure. Les versions mineures sont compatibles ascendantes, donc aucun problème de compatibilité n'est attendu.

Modifier l'architecture

1. Connectez-vous à la console et accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où réside votre instance, puis cliquez sur l'ID de l'instance.

2. Dans le coin supérieur droit, cliquez sur Specification Adjustment, puis :

   • Pour une instance sous abonnement : sélectionnez Specification Upgrade.

   • Pour une instance en paiement à l'utilisation : sélectionnez Specification Upgrade/Downgrade.

3. Sur la page de modification des spécifications, sélectionnez la configuration cible, puis cliquez sur Buy Now. Pour le paramètre Switching Time, choisissez l'une des options suivantes :

   Option	Comportement
   Switch Within Maintenance Window (recommandé)	Le basculement s'exécute pendant la fenêtre de maintenance (heures creuses). Avant le basculement, accédez à Task Hub et cliquez sur Modify Switchover Time pour ajuster l'heure si nécessaire.
   Switch after Data Migration	Le basculement s'exécute immédiatement après la fin de la migration des données.

4. Effectuez le paiement comme indiqué.

Après avoir soumis la demande, le statut de l'instance passe à Changing Configuration, quelle que soit l'heure de basculement sélectionnée. Ce statut n'affecte pas vos services en cours d'exécution — le système prépare les ressources et synchronise les données en arrière-plan. Les déconnexions transitoires ne se produisent qu'au moment du basculement.

Après la modification

• Le mode de connexion est par défaut le mode proxy. Surveillez les connexions client sur la page de surveillance du nœud proxy. Le nombre de connexions sur les nœuds de données s'affiche comme étant 0.

• Les paramètres d'alerte sont désactivés. Les groupes d'applications existants dans Cloud Monitor peuvent également être désactivés. Reconfigurez-les pour reprendre la surveillance.

• La fonction Data flashback est désactivée. Reconfigurez cette fonctionnalité pour reprendre la récupération à un instant donné.

• Si votre application repose sur les notifications d'espace de clés (notify-keyspace-events), reconfigurez le paramètre sur la page Parameter Settings une fois la modification terminée.

Avant de commencer

Examinez les impacts suivants avant de démarrer la modification.

• Les endpoints, comptes, mots de passe et listes d'autorisation restent inchangés. Aucune modification du code de l'application n'est requise.

• Les données sont généralement conservées. Dans le cas rare où le nœud principal tombe en panne pendant le basculement, une petite quantité de données non synchronisées peut être perdue.

• Une à deux déconnexions transitoires, chacune durant moins de 30 secondes. Assurez-vous que votre application dispose d'un mécanisme de reconnexion.

• État en lecture seule pendant environ 1 minute. L'instance passe en mode lecture seule pendant que la nouvelle instance synchronise les données incrémentielles et que le cache DNS se vide. Les instances soumises à une charge d'écriture élevée peuvent connaître une période en lecture seule plus longue.

• L'instance est mise à niveau vers la dernière version mineure. Les versions mineures sont compatibles ascendantes, donc aucun problème de compatibilité n'est attendu.

Modifier l'architecture

1. Connectez-vous à la console et accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où réside votre instance, puis cliquez sur l'ID de l'instance.

2. Pour une instance sous abonnement, dans le coin supérieur droit, cliquez sur Specification Adjustment et sélectionnez Specification Downgrade.

   Important

   Les instances en paiement à l'utilisation ne peuvent pas être rétrogradées directement depuis la console d'une architecture cluster vers une architecture standard (maître-réplica). Utilisez plutôt l'une des méthodes suivantes :

   • Appelez l'API ModifyInstanceSpec pour rétrograder l'instance. Veillez à spécifier la bonne InstanceClass pour la famille de spécifications cible.

   • Convertir en abonnement d'abord, puis suivez les étapes ci-dessus.

3. Sur la page de modification des spécifications, sélectionnez la configuration cible, puis cliquez sur Buy Now. Pour le paramètre Switching Time, choisissez l'une des options suivantes :

   Option	Comportement
   Switch During Maintenance Window (recommandé)	Le basculement s'exécute pendant la fenêtre de maintenance (heures creuses). Avant le basculement, accédez à Task Hub et cliquez sur Modify Switchover Time pour ajuster l'heure si nécessaire.
   Switch after Data Migration	Le basculement s'exécute immédiatement après la fin de la migration des données.

4. Effectuez le paiement comme indiqué.

Après avoir soumis la demande, le statut de l'instance passe à Changing Configuration, quelle que soit l'heure de basculement sélectionnée. Ce statut n'affecte pas vos services en cours d'exécution — le système prépare les ressources et synchronise les données en arrière-plan. Les déconnexions transitoires ne se produisent qu'au moment du basculement.

Après la modification

• Les paramètres d'alerte sont désactivés. Les groupes d'applications existants dans Cloud Monitor peuvent également être désactivés. Reconfigurez-les pour reprendre la surveillance.

• La fonction Data flashback est désactivée. Reconfigurez cette fonctionnalité pour reprendre la récupération à un instant donné.