PolarDB vous permet de mettre à niveau une instance ApsaraDB RDS for MySQL vers un cluster PolarDB for MySQL en un seul clic. PolarDB synchronise automatiquement les comptes, les bases de données, les listes d'autorisation IP et les paramètres depuis l'instance RDS source. Vous pouvez conserver le point de terminaison d'origine afin que vos applications basculent vers le cluster PolarDB sans modifier leur configuration.
Vous pouvez mettre à niveau une instance RDS vers un cluster PolarDB de même version ou d'une version supérieure. Par exemple :
Une instance ApsaraDB RDS for MySQL 5,6 peut être mise à niveau vers un cluster PolarDB for MySQL 5.6, 5.7, 8.0.1 ou 8.0.2.
Une instance ApsaraDB RDS for MySQL 5,7 peut être mise à niveau vers un cluster PolarDB for MySQL 5.7, 8.0.1 ou 8.0.2.
-
Une instance ApsaraDB RDS for MySQL 8,0 peut être mise à niveau vers un cluster PolarDB for MySQL 8.0.1 ou 8.0.2.
RemarquePolarDB for MySQL 8.0.1 est entièrement compatible avec MySQL Community Edition 8.0.13 et versions antérieures. La version 8.0.2 est entièrement compatible avec MySQL Community Edition 8.0.18 et versions antérieures.
Les fonctionnalités prises en charge par PolarDB for MySQL 8.0.1 et 8.0.2 diffèrent. Consultez la Comparaison des fonctionnalités des versions du noyau.
Méthodes de migration
Deux méthodes de migration sont disponibles : la migration physique (réplication physique) et la migration logique (synchronisation des données DTS). Le système sélectionne la méthode en fonction de la version MySQL, de l'édition et du type de stockage de l'instance RDS. Vous ne pouvez pas modifier cette méthode.
|
Élément |
Migration physique (réplication physique) |
Migration logique (synchronisation des données DTS) |
|
Instance concernée |
Instances ApsaraDB RDS for MySQL 5,6 et 5,7 High-availability Edition utilisant des SSD locaux. Ces instances peuvent être mises à niveau vers des clusters PolarDB for MySQL de même version. Remarque
Exigences relatives aux versions mineures :
|
À l'exception de la méthode de migration physique (réplication physique), les autres types d'instances RDS for MySQL peuvent être mis à niveau vers des clusters PolarDB for MySQL de même version ou de version différente. Remarque
Aucune restriction relative aux versions mineures. |
|
Fonctionnement |
Copie l'intégralité des données depuis l'instance RDS, puis maintient une synchronisation incrémentielle vers le cluster PolarDB. Important
Lors de la synchronisation incrémentielle, toutes les tables non-InnoDB créées sont converties en tables InnoDB. |
Utilise DTS pour créer une tâche qui effectue la synchronisation complète des données et du schéma depuis l'instance RDS vers le cluster PolarDB, suivie d'une synchronisation incrémentielle. Remarque
|
|
DTS requis |
Non. |
Oui. |
|
Version MySQL migrée |
Seule la migration vers la même version est prise en charge. |
Prend en charge la migration vers la même version ou une version supérieure. |
|
Limite de durée de mise à niveau |
Vous devez terminer la migration sous 30 jours. Passé ce délai, la fonctionnalité de migration est désactivée. |
Vous devez terminer la migration sous 30 jours. Passé ce délai, la fonctionnalité de migration est désactivée. |
|
Migration interrégionale |
Non prise en charge. |
Non prise en charge. |
|
Synchronisation incrémentielle |
Prise en charge. |
Prise en charge. |
|
Migration de nouvelles bases de données |
Prise en charge. |
Non prise en charge. Remarque
Pour synchroniser de nouvelles bases de données, accédez à la console DTS afin de modifier les objets de synchronisation. Ajoutez les nouvelles bases de données aux tâches de synchronisation directe et inverse. |
|
Migration du schéma |
Prise en charge. |
Seuls les schémas des bases de données, des tables, des vues, des procédures stockées et des fonctions peuvent être migrés. |
Avantages
Basculement avec points de terminaison : vous pouvez conserver le point de terminaison de base de données d'origine, permettant à vos applications de basculer vers le cluster PolarDB sans modifier aucune configuration de connexion.
Le processus de mise à niveau en un clic garantit une perte de données nulle.
Prend en charge la migration incrémentielle.
Prend en charge la migration à chaud en ligne. Votre service ne subit qu'une seule brève interruption de moins de 10 minutes lors de l'opération de basculement.
Prend en charge le retour arrière de migration. Vous pouvez annuler la migration sous 10 minutes en cas d'échec ou si vos besoins métier évoluent.
Impact sur les instances RDS
La mise à niveau en un clic restreint certaines opérations sur l'instance RDS et peut entraîner une brève interruption ou une augmentation de la charge.
Vous ne pouvez pas modifier les paramètres de l'instance pendant le processus de mise à niveau en un clic.
Pendant le processus de mise à niveau en un clic, vous ne pouvez pas résilier, libérer ou changer la zone de l'instance RDS.
Lors de l'opération de basculement, si vous choisissez Switchover with Endpoints, votre activité peut être interrompue pendant 1 à 5 minutes. Si vous choisissez Switchover without Endpoints, vous devez mettre à jour rapidement les paramètres de connexion de votre application pour vous connecter au cluster PolarDB.
-
Selon la méthode de migration, si vous effectuez une mise à niveau en un clic en utilisant la migration logique (synchronisation des données DTS), les impacts suivants s'appliquent :
Si des déclencheurs existent sur l'instance RDS, vous devez les supprimer avant de commencer. Sinon, la migration sera interrompue.
Lors de l'initialisation complète des données, n'effectuez pas d'opérations DDL modifiant les schémas de base de données ou de tables. Cela pourrait entraîner l'échec de la tâche de synchronisation des données.
L'initialisation complète des données consomme des ressources de lecture et d'écriture, telles que le CPU et les IOPS, à la fois sur l'instance RDS et sur le cluster PolarDB. Cela peut augmenter la charge sur l'instance RDS.
Remarques d'utilisation
Prérequis
Votre instance RDS doit répondre aux conditions suivantes :
-
Spécifications de l'instance :
Version MySQL
Basic Edition
High-availability Edition
Cluster Edition
5,6
-
SSD local
-
5,7
Disque cloud
SSD local, disque cloud
Disque cloud
8,0
Disque cloud
SSD local, disque cloud
Disque cloud
Le type de moteur de stockage pour la table de données doit être InnoDB ou X-Engine.
-
Si votre instance ne répond pas aux exigences de la migration physique (réplication physique), le système sélectionnera automatiquement la migration logique (synchronisation des données DTS) pour la mise à niveau. Dans ce cas, pour éviter l'échec de la mise à niveau en un clic, l'instance RDS doit également remplir les conditions suivantes :
L'instance RDS ne doit faire partie d'aucune tâche de synchronisation bidirectionnelle DTS existante. Procéder à la mise à niveau dans ce cas peut entraîner une incohérence des données.
Si des déclencheurs existent sur l'instance RDS, vous devez les supprimer avant de commencer. Sinon, la migration sera interrompue.
-
La journalisation binaire est activée par défaut sur l'instance RDS. Assurez-vous que le paramètre binlog_row_image est défini sur full. Sinon, une erreur est signalée lors de la pré-vérification et la tâche de synchronisation des données ne peut pas démarrer.
-
DTS exige que les journaux binaires de l'instance RDS soient conservés pendant au moins sept jours. Sinon, DTS pourrait ne pas réussir à obtenir les journaux binaires, ce qui entraînerait l'échec de la tâche et, dans des cas extrêmes, une incohérence ou une perte de données. Les problèmes causés par la définition d'une période de rétention des journaux binaires inférieure à l'exigence DTS ne sont pas couverts par l'accord de niveau de service (SLA) DTS.
-
Si votre instance ne répond pas aux exigences de la migration physique (réplication physique), mais que vous souhaitez utiliser cette méthode pour effectuer une mise à niveau en un clic, vous pouvez effectuer les opérations suivantes pour que votre instance RDS réponde aux exigences de la migration physique (réplication physique), puis effectuer la mise à niveau en un clic :
Pour ApsaraDB RDS for MySQL 5,6 High-availability Edition, la version mineure doit être 20190815 ou ultérieure.
Pour ApsaraDB RDS for MySQL 5,7 High-availability Edition, la version mineure doit être 20200331 ou ultérieure.
RemarqueVous pouvez accéder à la page . Dans la section Configurations, consultez les minor version information de l'instance RDS. Si la version est inférieure à celle spécifiée ci-dessus, vous pouvez mettre à niveau la version mineure vers la dernière version.
Pour la migration physique (réplication physique), définissez la période de rétention des journaux binaires à au moins 24 heures.
Limitations
Si votre instance ne répond pas aux exigences de la migration physique (réplication physique), le système sélectionne automatiquement la migration logique (synchronisation des données DTS) pour effectuer la mise à niveau. Cette méthode de migration présente les limitations d'utilisation suivantes :
N'écrivez pas de données dans la base de données de destination autrement que via DTS pendant l'exécution de la synchronisation. Sinon, une incohérence des données peut survenir entre les bases de données source et de destination. Par exemple, si vous utilisez DMS pour effectuer des opérations DDL en ligne pendant que d'autres données sont écrites dans la base de données de destination, une perte de données peut se produire.
DTS désactive par défaut les contraintes de clé étrangère lors de la synchronisation vers une base de données de destination. Par conséquent, les opérations en cascade et les suppressions dans la base de données source ne sont pas synchronisées vers la base de données de destination.
-
Instructions SQL prises en charge pour la synchronisation incrémentielle :
Type d'opération
Instruction SQL
DML
INSERT,UPDATE,DELETEDDL
-
ALTER TABLE,ALTER VIEW -
CREATE FUNCTION,CREATE INDEX,CREATE PROCEDURE,CREATE TABLE,CREATE VIEW -
DROP INDEX,DROP TABLE -
RENAME TABLE -
TRUNCATE TABLE
-
Considérations
|
Phase de migration |
Description |
|
Avant la migration |
|
|
Pendant la migration |
|
Facturation
Migration logique (synchronisation des données DTS)
Avec la méthode de migration logique (synchronisation des données DTS), la tâche de synchronisation des données DTS et le cluster PolarDB cible sont facturés.
-
Tâche de synchronisation des données DTS :
Lors de la mise à niveau, le système crée automatiquement une tâche de synchronisation des données DTS entre l'instance RDS et le cluster PolarDB. Consultez l'aperçu de la facturation DTS.
-
Cluster PolarDB cible :
-
Si la méthode de facturation est le paiement à l'utilisation, le cluster n'est pas facturé pendant le processus de mise à niveau. La facturation standard au paiement à l'utilisation commence après l'une des opérations suivantes :
-
La migration est terminée (y compris l'opération Terminer la migration).
RemarqueLa migration est considérée comme terminée lorsque le lien de synchronisation entre l'instance RDS et le cluster PolarDB prend fin.
La migration doit être achevée dans un délai de 30 jours. Passé ce délai, la fonctionnalité de migration est désactivée et l'instance RDS ainsi que le cluster PolarDB repassent tous deux en statut lecture/écriture, ce qui rompt le lien de réplication.
-
La migration est arrêtée (y compris l'opération Abandonner la migration en cas d'échec de la pré-vérification et l'opération Annuler la migration).
À ce stade, le cluster PolarDB cible a été créé, mais le processus de mise à niveau est interrompu. Si vous n'avez plus besoin du cluster PolarDB cible, libérez-le sans délai.
-
Si la méthode de facturation est Serverless, la facturation débute dès que le statut du cluster passe à Running.
Si la méthode de facturation est l'abonnement, vous devez régler les frais correspondants lors de la création du cluster.
-
Migration physique (réplication physique)
Avec la méthode de migration physique (réplication physique), aucun frais supplémentaire n'est appliqué pour le processus de mise à niveau. Seule la facturation du cluster PolarDB cible s'applique.
-
Si la méthode de facturation est le paiement à l'utilisation, le cluster n'est pas facturé pendant le processus de mise à niveau. La facturation standard au paiement à l'utilisation commence après l'une des opérations suivantes :
-
La migration est terminée (y compris l'opération Terminer la migration).
RemarqueLa migration est considérée comme terminée lorsque le lien de synchronisation entre l'instance RDS et le cluster PolarDB prend fin.
La migration doit être achevée dans un délai de 30 jours. Passé ce délai, la fonctionnalité de migration est désactivée et l'instance RDS ainsi que le cluster PolarDB repassent tous deux en statut lecture/écriture, ce qui rompt le lien de réplication.
-
La migration est arrêtée (y compris l'opération Abandonner la migration en cas d'échec de la pré-vérification et l'opération Annuler la migration).
À ce stade, le cluster PolarDB cible a été créé, mais le processus de mise à niveau est interrompu. Si vous n'avez plus besoin du cluster PolarDB cible, libérez-le sans délai.
-
Si la méthode de facturation est Serverless, la facturation débute dès que le statut du cluster passe à Running.
Si la méthode de facturation est l'abonnement, vous devez régler les frais correspondants lors de la création du cluster.
Premiers pas
1. Évaluation de la migration
PolarDB propose une fonctionnalité d'évaluation de la migration permettant de pré-vérifier l'état de l'instance, les dépendances des tâches et les attributs de l'instance avant le démarrage. Cela permet d'identifier et de résoudre les problèmes potentiels en amont.
2. Étapes de mise à niveau
Opérations via la console
Cette section décrit le processus de mise à niveau en un clic. Consultez les étapes de mise à niveau.
-
(Facultatif) Vérifiez la liste d'autorisation d'adresses IP
Si votre instance RDS comporte des instances en lecture seule dont les listes d'autorisation d'adresses IP diffèrent de celle de l'instance principale, fusionnez les listes des instances en lecture seule avec celle de l'instance principale. Cette opération garantit la synchronisation automatique des listes d'autorisation vers le cluster PolarDB.
RemarqueLa liste d'autorisation d'adresses IP d'un cluster PolarDB s'applique à l'ensemble du cluster. Il est impossible de configurer des listes distinctes pour chaque nœud. Par conséquent, après la migration, vérifiez la liste d'autorisation d'adresses IP et les autorisations des comptes de base de données du cluster PolarDB.
-
Accédez à la page d'achat du cluster PolarDB. Définissez la méthode de création sur Migrate from RDS, puis spécifiez la version et l'instance de l'instance RDS source pour acheter un cluster PolarDB. Une fois l'achat effectué, le système procède à l'initialisation, à la pré-vérification et à la synchronisation complète des données. Durant cette phase, le statut du cluster est Creating. Veuillez patienter.
RemarqueLors d'une migration logique (synchronisation des données DTS), une erreur telle que Precheck Failed peut survenir. Résolvez l'erreur en vous basant sur le Error Message. Une fois l'erreur corrigée, cliquez sur Continue pour reprendre le processus de mise à niveau en un clic. Si la résolution de l'erreur impacte vos services en ligne, vous pouvez cliquer sur Abandon Migration pour arrêter le processus de mise à niveau.
-
(Facultatif) Ajoutez les endpoints manquants
La fonctionnalité de basculement avec conservation des endpoints maintient les points de connexion de la base de données d'origine. Cela permet à vos applications de basculer vers le cluster PolarDB sans modifier les paramètres de connexion. Toutefois, seuls les endpoints présents à la fois sur l'instance RDS et sur le cluster PolarDB peuvent faire l'objet d'un basculement.
Ajoutez, si nécessaire, les endpoints de base de données requis sur le cluster PolarDB.
Vérifiez l'état du chiffrement SSL des endpoints de base de données. Le statut SSL doit être identique pour les endpoints de l'instance RDS et du cluster PolarDB.
-
Lorsque la Replication Latency du cluster PolarDB est inférieure à 60 secondes, vous pouvez procéder au basculement de vos services. Cliquez sur Switch Over. Cette action inverse les statuts lecture/écriture de l'instance RDS et du cluster PolarDB. L'instance RDS passe en statut lecture seule et le cluster PolarDB passe en statut lecture/écriture. La direction de la réplication des données est également inversée : les nouvelles données du cluster PolarDB sont synchronisées vers l'instance RDS.
ImportantSi vous utilisez le basculement avec conservation des endpoints, lisez attentivement les remarques relatives au basculement avec conservation des endpoints. Notez qu'une interruption de service de 1 à 5 minutes peut survenir durant le basculement.
Après le basculement, si vous constatez des anomalies de données ou d'autres problèmes, vous pouvez effectuer un retour arrière de la migration pour revenir rapidement à l'état antérieur à la mise à niveau. Vous pouvez ensuite annuler la migration pour restaurer l'état précédant le basculement.
-
(Facultatif) Basculez la tâche DTS de l'instance source
Si l'instance RDS possède un lien Data Transmission Service (DTS) associé, autre que celui utilisé pour la migration logique dans ce processus de mise à niveau, vous pouvez utiliser cette fonctionnalité. Elle permet de modifier l'instance source ou destination de la tâche de synchronisation ou de migration DTS afin de basculer les services associés en toute transparence.
-
Une fois vos données migrées et vos services stables sur le cluster PolarDB, vous pouvez mettre fin au processus de mise à niveau. Si la synchronisation des données n'est plus nécessaire, cliquez sur Complete Migration.
-
(Facultatif) Désabonnez-vous ou libérez l'instance RDS
Si vos services fonctionnent de manière stable sur le cluster PolarDB et que l'instance RDS n'est plus nécessaire, désabonnez-vous ou libérez l'instance RDS.
Opérations API
Cette section décrit le processus de mise à niveau en un clic. Consultez les étapes de mise à niveau.
-
(Facultatif) Vérifiez la liste d'autorisation d'adresses IP
Si votre instance RDS comporte des instances en lecture seule dont les listes d'autorisation d'adresses IP diffèrent de celle de l'instance principale, fusionnez les listes des instances en lecture seule avec celle de l'instance principale. Cette opération garantit la synchronisation automatique des listes d'autorisation vers le cluster PolarDB.
RemarqueLa liste d'autorisation d'adresses IP d'un cluster PolarDB s'applique à l'ensemble du cluster. Il est impossible de configurer des listes distinctes pour chaque nœud. Par conséquent, après la migration, vérifiez la liste d'autorisation d'adresses IP et les autorisations des comptes de base de données du cluster PolarDB.
-
CreateDBCluster - Créez un cluster PolarDB
Lors de l'appel à l'API de création de cluster, définissez le paramètre SourceResourceId sur la région où se trouve l'instance RDS source, le paramètre CreationOption sur MigrationFromRDS et le paramètre SourceResourceId sur l'ID de l'instance RDS source. Une fois l'appel effectué, le système procède à l'initialisation, à la pré-vérification et à la synchronisation complète des données. Durant cette phase, le statut du cluster est Precheck Failed. Veuillez patienter.
-
Interrogez le statut de migration du cluster PolarDB
Lorsque le paramètre MigrationStatus renvoyé est RDS2PolarDB_SYNCING, cela indique que le système a terminé la synchronisation complète des données et effectue désormais la synchronisation incrémentielle.
RemarqueLors d'une migration logique (synchronisation des données DTS), une erreur telle que Error Message peut survenir. Dans ce cas, le paramètre MigrationStatus est défini sur PRE_CHECK_FAIL. Vous devez résoudre l'erreur en vous basant sur le Error Message.
-
ModifyDBClusterMigration - Effectuez le basculement d'une tâche de migration
Lorsque le paramètre DelayedSeconds renvoyé par DescribeDBClusterMigration est inférieur à 60 secondes, vous pouvez procéder au basculement métier. Inversez les statuts lecture/écriture de l'instance RDS et du cluster PolarDB (définissez l'instance RDS en lecture seule et le cluster PolarDB en lecture/écriture) et modifiez la direction de la réplication des données (synchronisez les nouvelles données du cluster PolarDB vers l'instance RDS).
ImportantSi vous utilisez le basculement avec conservation des endpoints, lisez attentivement les remarques relatives au basculement avec conservation des endpoints. Notez qu'une interruption de service de 1 à 5 minutes peut survenir durant le basculement.
Une fois le basculement de la migration terminé, si vous constatez des incohérences de données ou d'autres problèmes, vous pouvez appeler ModifyDBClusterMigration pour annuler la tâche de migration et restaurer rapidement l'état antérieur à la mise à niveau. Ensuite, vous pouvez également appeler CloseDBClusterMigration pour annuler la migration et restaurer l'état précédant le basculement.
-
Si votre instance RDS possède un lien DTS associé (autre qu'un lien de synchronisation des données DTS pour la migration logique dans un processus de mise à niveau en un clic), vous pouvez modifier (remplacer) l'instance de base de données source ou destination de la tâche de synchronisation ou de migration DTS afin de basculer les services associés en toute transparence.
-
CloseDBClusterMigration - Terminez la migration
Une fois la migration des données métier terminée et vos services stables sur le cluster PolarDB, vous pouvez mettre fin au processus de mise à niveau en un clic si la synchronisation des données n'est plus requise.
-
(Facultatif) Désabonnez-vous ou libérez l'instance RDS
Si vos services fonctionnent de manière stable sur le cluster PolarDB et que l'instance RDS n'est plus nécessaire, désabonnez-vous ou libérez l'instance RDS.
3. Ajustez la politique de sauvegarde
Les politiques de sauvegarde de RDS et de PolarDB sont différentes. Après la migration, vous pouvez modifier la politique de sauvegarde dans la console selon vos besoins.
Informations connexes
Description de la politique de sauvegarde
Basculement avec conservation des endpoints
Lors de la mise à niveau, sélectionnez la fonctionnalité de basculement avec conservation des endpoints pour échanger automatiquement les points de connexion entre l'instance RDS et le cluster PolarDB. Cela permet à vos applications de se connecter automatiquement au cluster PolarDB sans aucune modification de configuration.
Avant de procéder au basculement des endpoints, confirmez la correspondance des points de connexion entre l'instance RDS et le cluster PolarDB. Cela permet d'éviter toute perturbation métier.
Schéma de basculement des points de connexion
Le schéma suivant illustre la correspondance par défaut pour le basculement des points de connexion entre une instance RDS et un cluster PolarDB. Vous pouvez ajuster cette correspondance dans la console lors du processus de basculement.
Le point de connexion en lecture seule d'une instance RDS inclut le point de connexion en lecture seule du proxy de base de données et le point de connexion de l'instance en lecture seule.
Remarques
La fonctionnalité de basculement avec conservation des endpoints ne prend pas en charge le basculement des adresses IPv6.
La fonctionnalité de basculement avec conservation des endpoints échange uniquement les noms de domaine des points de connexion de l'instance RDS et du cluster PolarDB. Les configurations telles que les commutateurs virtuels (vSwitches) et les adresses IP virtuelles (VIPs) ne sont pas échangées.
Seuls les points de connexion présents à la fois sur l'instance RDS et sur le cluster PolarDB peuvent être échangés. Par défaut, un cluster PolarDB crée uniquement un endpoint principal privé et un endpoint de cluster privé. Si l'instance RDS compte plus de deux points de connexion, vous devez créer les points de connexion correspondants sur le cluster PolarDB avant le basculement. Sinon, les endpoints ne seront pas échangés.
Lorsque vous utilisez la fonctionnalité de basculement avec conservation des endpoints, l'endpoint principal de l'instance RDS peut être échangé avec l'endpoint principal ou l'endpoint de cluster par défaut du cluster PolarDB. L'endpoint du proxy de base de données de l'instance RDS peut être échangé avec l'endpoint de cluster par défaut et les endpoints personnalisés du cluster PolarDB. Vous pouvez également choisir de ne pas les échanger ou d'échanger plusieurs groupes. Un cluster PolarDB pouvant comporter jusqu'à sept endpoints de cluster, vous pouvez échanger au maximum sept endpoints de proxy de base de données provenant de l'instance RDS.
Le basculement n'est actuellement pas pris en charge pour le point de connexion en lecture seule du cluster et le point de connexion direct au nœud des instances RDS Cluster Edition.
Avant d'utiliser la fonctionnalité de basculement avec conservation des endpoints pour échanger des endpoints privés, assurez-vous que l'instance RDS et le cluster PolarDB se trouvent dans le même VPC. Sinon, vos services existants ne pourront pas se connecter après le basculement.
Une fois la synchronisation incrémentielle terminée, le statut du cluster PolarDB passe à Running. Avant de procéder au basculement des endpoints, vous pouvez effectuer des opérations telles que la configuration des paramètres, l'ajout de nœuds en lecture seule et l'ajout d'endpoints.
Après l'échange des noms de domaine des points de connexion, si vous devez vous connecter au cluster PolarDB via Data Management (DMS), assurez-vous d'avoir configuré l'ID de cluster ou la chaîne de connexion correcte.
Après l'échange des noms de domaine des points de connexion, des problèmes de cache de résolution DNS peuvent survenir. Avant l'expiration du cache, il se peut que vous ne puissiez pas vous connecter au cluster PolarDB ou que le cluster PolarDB ne prenne en charge que les opérations de lecture et non d'écriture. Videz le cache DNS de votre serveur.