PolarDB:Cloner une instance ApsaraDB RDS for MySQL vers PolarDB for MySQL

Remarques importantes

Lorsque vous clonez des données vers un cluster PolarDB à l'aide de la fonctionnalité de clonage en un clic, celle-ci ne synchronise pas les données incrémentielles de l'instance RDS source vers le cluster PolarDB cible.

Présentation

PolarDB prend en charge le clonage en un clic des données d'une instance ApsaraDB RDS for MySQL vers un nouveau cluster PolarDB for MySQL. La fonctionnalité de clonage en un clic crée un nouveau cluster PolarDB contenant les mêmes données que l'instance RDS source. Le cluster PolarDB inclut les comptes, les bases de données, la liste d'autorisation IP et les paramètres nécessaires de l'instance RDS source.

La liste suivante décrit les versions et types de stockage pris en charge pour l'instance ApsaraDB RDS for MySQL source et le cluster PolarDB for MySQL cible :

• Vous pouvez cloner des instances ApsaraDB RDS for MySQL source de toutes les versions et de tous les types de stockage. Les instances ApsaraDB RDS for MySQL 5.6, 5,7 et 8,0 utilisant des SSD locaux ou des disques cloud peuvent être clonées vers un cluster PolarDB for MySQL.

• Vous pouvez cloner une instance ApsaraDB RDS for MySQL vers un cluster PolarDB for MySQL de la même version ou d'une version différente. Par exemple, vous pouvez cloner une instance ApsaraDB RDS for MySQL 5.6 vers un cluster PolarDB for MySQL 5,6 ou vers un cluster PolarDB for MySQL 8,0.

Comparaison entre la migration physique et la migration logique

La fonctionnalité de clonage en un clic prend en charge deux méthodes : la migration physique (réplication physique) et la migration logique (synchronisation des données via DTS).

• Migration physique (réplication physique) : cette méthode utilise la réplication physique pour copier toutes les données de l'instance ApsaraDB RDS for MySQL source vers le nouveau cluster PolarDB for MySQL créé.

• Migration logique (synchronisation des données via DTS) : cette méthode utilise Data Transmission Service (DTS) pour créer une tâche de synchronisation des données. La tâche synchronise le schéma et les données complètes de l'instance ApsaraDB RDS for MySQL source vers le nouveau cluster PolarDB for MySQL créé.

Le tableau suivant compare les méthodes de migration physique et logique.

Le tableau suivant décrit les versions et types de stockage d'ApsaraDB RDS for MySQL pouvant être clonés.

Utilisez la migration physique uniquement lorsque vous clonez une instance ApsaraDB RDS for MySQL 5.6 ou 5,7 en édition Haute disponibilité utilisant un SSD local vers un cluster PolarDB for MySQL de la même version. Pour toutes les autres configurations, la migration logique est utilisée pour cloner une instance ApsaraDB RDS for MySQL vers un cluster PolarDB for MySQL de la même version ou d'une version différente.

Avantages

Le processus de clonage n'entraîne aucune perte de données.

Prérequis

• Pour la migration physique, l'instance RDS source doit respecter les exigences de version mineure suivantes. La migration logique n'impose aucune limitation de version.

  • Pour ApsaraDB RDS for MySQL 5.6, la version mineure doit être 20190815 ou ultérieure.

  • Pour ApsaraDB RDS for MySQL 5.7, la version mineure doit être 20200331 ou ultérieure.

  Remarque

  Exécutez la commande SHOW VARIABLES LIKE '%rds_release_date%'; pour vérifier la version mineure de l'instance RDS source. Si la version mineure est antérieure à celle requise, vous pouvez la mettre à niveau vers la dernière version. Pour plus d'informations, consultez la section Mettre à niveau la version mineure du moteur.

• La fonctionnalité de clonage en un clic est prise en charge uniquement pour les instances RDS source utilisant le moteur de stockage InnoDB ou X-Engine.

• Les fonctionnalités TDE et SSL ne sont pas activées sur l'instance RDS source. Si l'une de ces fonctionnalités est activée, vous pouvez créer manuellement une tâche de migration de données Data Transmission Service (DTS) pour migrer l'instance RDS source vers PolarDB. Pour plus d'informations, consultez la section Migrer ApsaraDB RDS for MySQL vers PolarDB for MySQL.

• Si votre instance RDS s'exécute en mode Haute sécurité (avec Database Proxy activé), vous devez créer un compte privilégié (consultez la section Créer un compte) ou passer en mode Haute performance (consultez la section [[Modification produit/fonctionnalité] Avis de mise à niveau du lien réseau RDS](t64586.dita#concept_vyz_wf2_wfb)) pour effectuer un clonage en un clic. Sur la page Database Connection de la console ApsaraDB RDS, vous pouvez afficher l'état de Database Proxy, ainsi que l'endpoint interne (au format InstanceID.mysql.rds.aliyuncs.com) et le port pour le type de réseau actuel, tel que le réseau classique.

Limites

• Vous pouvez uniquement cloner une instance ApsaraDB RDS for MySQL vers un cluster PolarDB for MySQL de la même version ou d'une version ultérieure. Le rétrogradage n'est pas pris en charge.

  Par exemple, vous ne pouvez pas cloner une instance ApsaraDB RDS for MySQL 5.7 vers un cluster PolarDB for MySQL 5,6, ni une instance ApsaraDB RDS for MySQL 8.0.2 vers un cluster PolarDB for MySQL 8.0.1.

• La migration physique présente les limites suivantes :

  • La migration inter-régions n'est pas prise en charge.

  • Vous ne pouvez pas modifier les paramètres de l'instance RDS source pendant la migration.

• La migration logique présente les limites suivantes :

  • La migration inter-régions n'est pas prise en charge.

  • Vous ne pouvez pas modifier les paramètres de l'instance RDS source pendant la migration.

  • La base de données source présente les limites suivantes :

    Type

    Description

    Limites de la base de données source

    Les tables que vous synchronisez doivent disposer d'une clé primaire ou d'une contrainte unique, et tous les champs de la contrainte doivent être uniques. Sinon, des données en double peuvent exister dans la base de données de destination. Lors de la synchronisation au niveau de la table et de la modification d'objets (tels que le mappage des noms de colonnes), une seule tâche prend en charge jusqu'à 1 000 tables. Si vous dépassez cette limite, une erreur est signalée lors de la soumission de la tâche. Dans ce cas, nous vous recommandons de répartir les tables sur plusieurs tâches ou de configurer une tâche pour synchroniser l'intégralité de la base de données. Binlog doit être activé et le paramètre binlog_row_image doit être défini sur FULL. Pour plus d'informations sur l'activation de Binlog, consultez la section Modifier les paramètres de l'instance. Sinon, la prévérification échouera et la tâche de synchronisation des données ne pourra pas démarrer.

  • Autres limites :

    Type

    Description

    Autres limites

    Avant de synchroniser les données, évaluez les performances des bases de données source et de destination. Nous vous recommandons d'effectuer la synchronisation des données pendant les heures creuses. La synchronisation initiale des données complètes consomme des ressources de lecture et d'écriture sur les deux bases de données, ce qui peut augmenter leur charge. La synchronisation initiale des données complètes effectue des opérations INSERT concurrentes, ce qui peut provoquer une fragmentation des tables de la base de données de destination. Par conséquent, l'espace de table dans l'instance de destination sera plus grand que dans l'instance source après la synchronisation. Si vous synchronisez des tables individuelles au lieu de l'intégralité de la base de données, n'effectuez pas de modifications DDL en ligne sur les tables sources à l'aide d'outils tels que gh-ost ou pt-online-schema-change pendant la synchronisation des données. Cela entraînerait l'échec de la synchronisation. Vous pouvez utiliser Data Management Service (DMS) pour effectuer des modifications DDL en ligne. Pour plus d'informations, consultez la section Modifier les schémas sans verrouiller les tables. Pendant la synchronisation DTS, n'écrivez pas de données dans la base de données de destination à partir d'une source autre que DTS. Cela pourrait provoquer des incohérences de données. Par exemple, si vous utilisez DMS pour effectuer une modification DDL en ligne tandis qu'une autre source écrit dans la base de données de destination, une perte de données peut se produire. Par défaut, DTS désactive les contraintes de clé étrangère lors de la synchronisation vers la base de données de destination. Par conséquent, les opérations de cascade et de suppression de la base de données source ne sont pas synchronisées.

Facturation

• La migration d'ApsaraDB RDS vers PolarDB est gratuite. Vous êtes facturé uniquement pour le nouveau cluster PolarDB. Pour plus d'informations sur la tarification des clusters PolarDB, consultez la section Éléments facturables.

• Vous êtes facturé pour le cluster PolarDB et pour la tâche de synchronisation des données DTS. Toutefois, la tâche est gratuite pendant les 30 premiers jours dans le cadre d'un essai. Cet essai gratuit n'est pas disponible pour les comptes d'opérateurs de réseau virtuel (VNO), les comptes Jushita, les comptes du site international Alibaba Cloud ou les utilisateurs RAM (sous-comptes). Le tableau suivant décrit les détails.

  Objet de la migration	Frais
  Synchronisation du schéma et des données complètes	Aucun frais ne vous est facturé pour la tâche de synchronisation pendant 30 jours après sa création. Après 30 jours, la tâche de synchronisation est automatiquement annulée. Remarque Vous pouvez accéder à la page Data Synchronization Tasks de la nouvelle console DTS pour afficher le temps restant pour la tâche de synchronisation.

Les sections suivantes décrivent comment cloner une instance ApsaraDB RDS for MySQL vers un cluster PolarDB for MySQL.

Prévérifications (migration logique uniquement)

Étape 1 : Cloner depuis une instance RDS

Cette étape crée un cluster PolarDB contenant les mêmes données que l'instance RDS source.

1. Connectez-vous à la console PolarDB.

2. Dans le coin supérieur gauche, sélectionnez la région où le cluster est déployé.

3. Cliquez sur Create Cluster.

4. Sélectionnez une méthode de facturation : Subscription, Pay-As-You-Go ou Serverless.

   • Subscription : vous payez les nœuds de calcul lors de la création du cluster. Le stockage est facturé à l'heure en fonction du volume réel de vos données, et les frais sont déduits du solde de votre compte toutes les heures.

   • Pay-As-You-Go : aucun paiement initial n'est requis. Les nœuds de calcul et le stockage (en fonction du volume réel de vos données) sont facturés à l'heure, et les frais sont déduits du solde de votre compte toutes les heures.

   • Serverless : aucun paiement initial n'est requis. Les ressources telles que les nœuds de calcul, le stockage et les proxys de base de données sont mises à l'échelle dynamiquement en fonction des besoins réels de la charge de travail pendant l'utilisation du cluster, et vous êtes facturé en fonction de la quantité réelle de ressources utilisées.

5. Configurez les paramètres suivants.

   Remarque

   Pour obtenir des informations sur les paramètres non décrits dans le tableau suivant, consultez les rubriques relatives à Acheter un cluster.

   Paramètre	Description
   Creation Method	Sélectionnez Clone from RDS.
   Region	Sélectionnez la région où se trouve l'instance ApsaraDB RDS for MySQL source. Remarque Le nouveau cluster PolarDB sera également créé dans cette région.
   Source RDS Version	Version de l'instance RDS source. Vous pouvez sélectionner 5,6, 5,7 ou 8,0.
   Source RDS Instance	Sélectionnez l'instance RDS source. Les instances en lecture seule ne sont pas répertoriées.
   Database Engine	Version du moteur de base de données pour le cluster PolarDB de destination. Vous pouvez sélectionner la même version que l'instance RDS source ou une version différente.
   Node Specifications	Sélectionnez une spécification en fonction de vos besoins métier. Nous vous recommandons de choisir une spécification égale ou supérieure à celle de l'instance RDS source. Pour plus d'informations sur les spécifications des nœuds PolarDB, consultez la section Spécifications des nœuds de calcul de l'édition Enterprise.

6. Dans le coin supérieur droit, passez en revue la configuration du cluster. Définissez la Subscription Duration (pour les clusters Subscription ), la Quantity et indiquez si vous souhaitez activer l'Auto-renewal.

7. Lisez et acceptez le contrat de service. Cliquez sur Buy Now.

8. Sur la page Payment , confirmez les détails de la commande impayée et la méthode de paiement, puis cliquez sur Place Order .

   Remarque

   • Après un paiement réussi, la création du cluster prend 10 à 15 minutes. Vous pouvez ensuite voir le nouveau cluster dans la Cluster List .

   • Si les nœuds du cluster affichent Creating , le cluster n'est pas prêt. Vous ne pouvez l'utiliser que lorsque l'état du cluster est Running .

   • Assurez-vous d'avoir sélectionné la bonne région. Sinon, vous ne verrez pas votre cluster.

   • Si la prévérification échoue, le cluster de destination reste à l'état Creating et la mise à niveau ne peut pas se poursuivre automatiquement. Résolvez l'échec de la prévérification en vous basant sur le message d'erreur, puis cliquez sur Continue Upgrade pour continuer. Dans ce cas, la création du cluster peut prendre plus de 15 minutes, ce qui est normal.

9. Connectez-vous à la console PolarDB et affichez l'état du nouveau cluster PolarDB.

   Remarque

   Si vous utilisez la migration logique, cliquez sur l'ID du cluster pour accéder à la page Basic Information et vérifiez l'état de la migration. Si l'état de la migration RDS passe à Pre-check failed, suivez les instructions de la section Error Message pour résoudre le problème.

   Par exemple, si des déclencheurs ont été créés dans l'instance RDS source, la prévérification échoue avec le message d'erreur « Triggers exist in the RDS instance ». Dans ce cas, supprimez les déclencheurs de l'instance RDS source, puis cliquez sur Continue Migration. Vous pouvez également cliquer sur Cancel Migration et créer manuellement une tâche de migration de données dans la console DTS. Pour plus d'informations, consultez la section [Configurer des tâches pour les bases de données sources avec des déclencheurs].

   Vous pouvez également sélectionner Give up migration à cette étape. Pour connaître les impacts, consultez la section FAQ.

Étape 2 : Afficher les détails de la synchronisation des données (migration logique uniquement)

Si vous utilisez la migration logique, cliquez sur l'ID du cluster pour accéder à la page Basic Information et vérifiez l'état de la migration. En cas d'erreur de migration (tel qu'un échec de prévérification) ou d'une autre exception (telle qu'une latence de réplication élevée), vous pouvez accéder à la page de détails de la tâche de synchronisation des données DTS correspondante pour afficher des informations spécifiques.

1. Accédez à la console PolarDB.

2. Recherchez le cluster cible et cliquez sur son ID.

3. Sur la page Basic Information, dans la section RDS Migration, cliquez sur le nom de la tâche sous DTS Data Synchronization Task pour accéder à la liste de synchronisation des données dans la console DTS.

4. Recherchez la tâche de synchronisation des données correspondante. Vous pouvez afficher les détails de l'échec de la prévérification, les détails de la tâche et les journaux de la tâche.

   Sur la page des détails de la tâche, la section Task Progress affiche l'état d'exécution de quatre étapes : prévérification, migration du schéma 1, migration complète et migration du schéma 2. Cliquez sur l'onglet Check Items pour afficher le taux de réussite de la prévérification et les résultats de chaque élément de vérification, y compris les vérifications de connectivité et d'autorisation des bases de données source et de destination. La prévérification est réussie si tous les éléments de vérification passent.

FAQ

• Q : Quelle est la différence entre la mise à niveau d'une instance ApsaraDB RDS for MySQL et le clonage en un clic d'une instance ApsaraDB RDS for MySQL vers un cluster PolarDB for MySQL ?

  R : Le tableau suivant décrit les différences.

  Élément	Mise à niveau en un clic	Cloner en un clic ApsaraDB RDS for MySQL vers PolarDB for MySQL
  Migration des données incrémentielles	Prise en charge	Non prise en charge
  Impact sur les opérations de l'instance RDS source	Aucun impact	Aucun impact
  Migration inter-versions	Prise en charge	Prise en charge

• Q : Quels sont les impacts de l'annulation d'une migration ?

  R : L'annulation d'une migration a les impacts suivants :

  • Le lien de synchronisation entre le cluster source et le cluster de destination est déconnecté, et les deux clusters ne sont plus associés l'un à l'autre.

  • Le cluster de destination devient accessible en lecture et en écriture et n'est pas automatiquement libéré. Si vous n'avez plus besoin du cluster, libérez-le dès que possible pour éviter des coûts supplémentaires.

  • Lorsque vous annulez manuellement une migration, vous pouvez choisir de désactiver les binlogs pour le cluster. Si la migration est automatiquement annulée, les binlogs ne sont pas désactivés. La désactivation des binlogs améliore légèrement les performances d'écriture. Après la désactivation des binlogs, les fichiers binlog existants sont conservés de manière permanente. Vous pouvez d'abord réduire la période de rétention des fichiers binlog, attendre que les fichiers inutiles soient automatiquement supprimés, puis désactiver les binlogs.

    Remarque

    Après la désactivation des binlogs, le cluster redémarre automatiquement. Le redémarrage est terminé en 5 minutes et le service est interrompu pendant environ 40 secondes durant le redémarrage. La durée réelle varie en fonction du volume de données et du nombre de tables. Nous vous recommandons d'effectuer cette opération pendant les heures creuses et de vous assurer que vos applications peuvent se reconnecter automatiquement.

Référence API

Étapes suivantes

Mettez à jour l'adresse de connexion à la base de données de votre application avec l'adresse PolarDB. Pour plus d'informations, consultez la section Gérer les adresses de connexion.