ApsaraDB RDS:Passer de Serverless à paiement à l'utilisation

Prérequis

Votre instance ApsaraDB RDS for SQL Server doit répondre aux exigences suivantes :

• Édition : Édition haute disponibilité

• Méthode de facturation : Serverless

• État de l'instance : En cours d'exécution

Considérations

Lorsque vous sélectionnez un type d'instance, nous vous recommandons de choisir un nombre de vCores supérieur ou égal à la limite supérieure actuelle des unités RCU. Par exemple, si la limite supérieure des unités RCU de l'instance d'origine est de 4, sélectionnez un type d'instance disposant d'au moins 4 vCores.

Limites

• Vous ne pouvez modifier la méthode de facturation de Serverless à paiement à l'utilisation qu'une seule fois toutes les 24 heures.

• Vous ne pouvez convertir votre instance qu'en un type d'instance partagé. Si vous avez besoin d'un autre type d'instance, commencez par convertir l'instance en type d'instance partagé comme décrit dans cette rubrique. Ensuite, vous pourrez modifier la configuration de l'instance pour passer à un autre type d'instance.

Impacts

• Cette conversion nécessite une migration des données sous-jacentes, ce qui implique la création d'une nouvelle instance, l'exécution d'une sauvegarde complète, la synchronisation des journaux incrémentiels, la restauration des données et le basculement du réseau. L'interruption de service dure généralement moins de 20 minutes. Assurez-vous que votre application dispose d'une fonctionnalité de reconnexion automatique.

  Durée estimée pour la conversion d'une instance Serverless en instance à paiement à l'utilisation

  Le tableau suivant répertorie la durée estimée de chaque étape. Les vitesses de sauvegarde et de restauration sont basées sur la taille des données non compressées.

  Opération	Requis	Durée estimée	Notes
  Créer et configurer la nouvelle instance	Oui	10 à 15 minutes	La durée dépend de l'édition du produit et du type d'instance que vous sélectionnez.
  Effectuer une sauvegarde complète de l'instance	Conditionnel	200 Go/heure	Selon la politique de sauvegarde complète, si aucune sauvegarde complète n'a été effectuée sur l'instance au cours des 36 dernières heures, une sauvegarde complète est réalisée pendant la conversion. Cela permet d'équilibrer le temps nécessaire à la restauration de la sauvegarde complète et à la relecture des journaux de transactions. Pour réduire la durée de la conversion, nous vous recommandons de sauvegarder les données SQL Server à un moment approprié avant la conversion. Vous pouvez également lancer la conversion dans les 36 heures suivant la fin d'une sauvegarde complète automatique. La vitesse de sauvegarde peut varier selon la région et l'heure de la journée. Pour obtenir une estimation plus précise des performances de sauvegarde et de restauration, reportez-vous au volume de données et à la durée de votre dernière sauvegarde complète.
  Restaurer la sauvegarde complète sur l'instance de destination	Oui	200 Go/heure	Aucune
  Sauvegarder les journaux de transactions incrémentiels sur l'instance source	Oui	200 Go/heure	Deux minutes supplémentaires peuvent être nécessaires avant et après la sauvegarde des journaux incrémentiels pour des tâches telles que la préparation, la finalisation et l'allocation des ressources.
  Appliquer les sauvegardes des journaux de transactions incrémentiels sur l'instance de destination	Oui	200 Go/heure	Deux minutes supplémentaires peuvent être nécessaires avant et après l'application des sauvegardes de journaux pour des tâches telles que la vérification de la cohérence des sauvegardes.
  Mettre la base de données en ligne	Oui	Généralement en moins de 2 minutes	Consommation de ressources : L'application des journaux de transactions incrémentiels est une opération gourmande en ressources. Pour les instances de petite taille, telles que celles dotées de 2 vCores et de 4 Go de mémoire, la vitesse de récupération peut diminuer si un grand nombre de journaux de transactions existe. Récupération accélérée de la base de données : ApsaraDB RDS for SQL Server 2019 et versions ultérieures proposent la fonctionnalité Accelerated Database Recovery, qui peut réduire le temps nécessaire pour mettre la base de données en ligne. Pour plus de détails, consultez la documentation officielle de Microsoft.
  Basculement du réseau et migration de la connexion	Oui	10 minutes	Aucune

• L'adresse IP virtuelle (VIP) change lors de la conversion car les ressources sous-jacentes sont migrées. Pour garantir la stabilité et la continuité du service, utilisez l'endpoint interne ou public de l'instance RDS dans votre application plutôt qu'une adresse IP codée en dur. L'endpoint est un nom de domaine dynamique qui achemine automatiquement le trafic vers l'adresse IP backend mise à jour.

• Videz le cache DNS sur votre client. Si votre client est une application basée sur JVM, nous vous recommandons de définir le TTL dans la configuration JVM à 60 secondes ou moins. Cela garantit que lorsque l'adresse VIP de l'endpoint change, l'application peut obtenir la nouvelle adresse VIP en interrogeant à nouveau le DNS.

  Remarque

  Les méthodes suivantes pour définir le TTL dans la JVM sont fournies à titre indicatif :

  • Pour définir le TTL pour toutes les applications basées sur JVM, définissez le paramètre networkaddress.cache.ttl dans le fichier $JAVA_HOME/jre/lib/security/java.security sur 60.

  • Pour définir le TTL uniquement pour une application locale, définissez java.security.Security.setProperty("networkaddress.cache.ttl" , "60"); dans le code d'initialisation de l'application avant l'établissement de toute connexion réseau, et plus précisément avant le premier appel à InetAddress.getByName().

Facturation

La conversion de Serverless vers paiement à l'utilisation est gratuite. Pour plus d'informations sur la facturation des instances à paiement à l'utilisation, consultez la rubrique Présentation de la facturation.

Procédure

1. Accédez à la page Instances ApsaraDB RDS. Dans le coin supérieur gauche, sélectionnez la région où se trouve votre instance, puis cliquez sur l'ID de l'instance.

2. Sur la page Basic Information, dans la section Configuration Information, cliquez sur Change to Pay-As-You-Go.

3. Sur la page d'achat, configurez les paramètres Instance Type et Switching Time.

4. Cliquez sur Pay Now. Confirmez les détails de la configuration avant et après la modification, cliquez sur OK, puis effectuez le paiement.

   Remarque

   Pendant la conversion, l'état de l'instance passe à Upgrading/Downgrading. Une fois la conversion terminée, l'état de l'instance passe à Running.

FAQ

Q : Après avoir converti une instance Serverless en paiement à l'utilisation, pourquoi le type de commande s'affiche-t-il comme Nouvel achat dans Expenses and Costs > Order Management ?

R : La conversion provisionne une nouvelle instance à paiement à l'utilisation et migre les données depuis l'instance d'origine, c'est pourquoi la commande est enregistrée comme un Nouvel achat.

Opérations connexes

Si vous utilisez l'opération ModifyDBInstanceSpec pour modifier la méthode de facturation de Serverless à paiement à l'utilisation, tenez compte des points suivants :

• Assurez-vous que la méthode de facturation d'origine de l'instance est Serverless et définissez le paramètre PayType sur Postpaid.

• Définissez le paramètre DBInstanceClass sur le type d'instance cible. Pour obtenir la liste des types d'instances pris en charge, consultez la rubrique Types d'instances principales ApsaraDB RDS for SQL Server.

• Laissez les autres paramètres, tels que la capacité de stockage, inchangés. Ils ne peuvent pas être modifiés pendant la conversion.