PolarDB:FAQ

Q : Qu'est-ce que PolarDB ?

R : PolarDB est un service cloud de base de données relationnelle déployé dans des centres de données répartis dans plus de 10 régions du monde, offrant une expérience prête à l'emploi. PolarDB prend en charge trois moteurs indépendants : l'un est 100 % compatible avec MySQL, un autre est 100 % compatible avec PostgreSQL, et le troisième offre une haute compatibilité avec la syntaxe Oracle. Il fournit une capacité de stockage allant jusqu'à 200 To. Pour plus d'informations, consultez Qu'est-ce que PolarDB for MySQL Enterprise Edition ?, ou .

Q : Pourquoi PolarDB constitue-t-il un meilleur choix que les bases de données traditionnelles ?

R : Par rapport aux bases de données traditionnelles, PolarDB permet de stocker des centaines de téraoctets de données et offre des fonctionnalités telles que la haute disponibilité, la grande fiabilité, la mise à l'échelle élastique rapide et les sauvegardes sans verrouillage. Pour plus d'informations, consultez Avantages, ou .

Q : Quand PolarDB a-t-il été publié et quand est-il devenu disponible commercialement ?

R : PolarDB a été lancé en préversion publique en septembre 2017 et est devenu disponible commercialement en mars 2018.

Q : Que sont les clusters et les nœuds ?

R : L'édition PolarDB Cluster Edition repose sur une architecture multi-nœuds. Un cluster comprend un nœud principal et plusieurs nœuds en lecture seule. Un seul cluster PolarDB peut être déployé sur plusieurs zones, mais pas sur plusieurs régions. Le service est géré et facturé au niveau du cluster. Pour plus d'informations, consultez Termes, ou .

Q : Quels langages de programmation sont pris en charge ?

R : PolarDB prend en charge divers langages de programmation, notamment Java, Python, PHP, Go, C, C++, .NET et Node.js. Tout langage de programmation compatible avec MySQL natif fonctionne avec PolarDB for MySQL. Pour plus d'informations, visitez le site officiel de MySQL.

Q : Quels moteurs de stockage sont pris en charge ?

Q : PolarDB est-il une base de données distribuée ?

R : Oui. PolarDB est un cluster de stockage distribué basé sur le protocole de consensus Parallel Raft. Son moteur de calcul se compose de 1 à 16 nœuds de calcul répartis sur différents serveurs. Le cluster offre une capacité de stockage maximale de 200 To et prend en charge jusqu'à 88 cœurs CPU et 710 Go de mémoire. Vous pouvez mettre à l'échelle dynamiquement les ressources de stockage et de calcul en ligne sans affecter vos charges de travail.

Q : Après l'achat d'un cluster PolarDB, dois-je également acheter le middleware de base de données PolarDB-X pour mettre en œuvre le sharding ?

R : Oui.

Q : PolarDB prend-il en charge le partitionnement des tables ?

R : Oui.

Q : Puis-je changer la région d'un cluster PolarDB après son achat ?

R : Non, il est impossible de modifier la région d'un cluster après l'achat.

Q : PolarDB inclut-il automatiquement un mécanisme de partitionnement ?

R : Oui. PolarDB effectue le partitionnement au niveau de la couche de stockage, ce qui est transparent pour les utilisateurs.

Q : Comment un cluster à nœud unique assure-t-il la disponibilité du service et la fiabilité des données ?

R : Un cluster à nœud unique s'exécute sur un seul nœud de calcul pour des besoins spécifiques. Bien qu'il ne comporte qu'un seul nœud, un cluster à nœud unique tire parti de technologies telles que la planification instantanée des calculs et le stockage distribué multi-réplicas pour garantir une haute disponibilité du service et une grande fiabilité des données.

Q : Comment acheter un cluster PolarDB à nœud unique ?

R : La série de produits à nœud unique n'est plus disponible. Toutefois, vous pouvez créer un cluster fonctionnant comme un cluster à nœud unique en définissant le nombre de nœuds en lecture seule à 0 lors de l'achat d'un cluster PolarDB.

Q : PolarDB est-il compatible avec MySQL Community Edition ?

R : PolarDB for MySQL est 100 % compatible avec MySQL Community Edition.

Q : Quels niveaux d'isolation des transactions sont pris en charge ?

R : PolarDB for MySQL prend en charge les niveaux d'isolation READ-UNCOMMITTED, READ-COMMITTED (par défaut) et REPEATABLE-READ. Le niveau d'isolation SERIALIZABLE n'est pas pris en charge.

Q : La sortie de SHOW PROCESSLIST diffère-t-elle de celle de MySQL Community Edition ?

R : Si vous vous connectez au cluster via l'endpoint principal, la sortie est identique. Si vous utilisez l'endpoint de cluster, la sortie est légèrement différente. Vous trouverez plusieurs enregistrements ayant le même ID de thread, chacun correspondant à un nœud du cluster PolarDB for MySQL.

Q : Le mécanisme de verrouillage des métadonnées (MDL) dans PolarDB for MySQL diffère-t-il de celui de MySQL Community Edition ?

R : Non, le mécanisme MDL dans PolarDB for MySQL est identique à celui de MySQL Community Edition. Cependant, comme les nœuds PolarDB for MySQL utilisent une architecture de stockage partagé, lorsque vous effectuez une opération DDL sur le nœud principal, les nœuds en lecture seule peuvent lire des données intermédiaires issues de cette opération, ce qui entraîne une incohérence des données. Pour éviter cela, PolarDB for MySQL synchronise les MDL exclusifs impliqués dans l'opération DDL vers les nœuds en lecture seule via les journaux redo. Cela empêche les autres threads utilisateurs sur les nœuds en lecture seule d'accéder à la table pendant l'opération DDL. Dans certains cas, cela peut bloquer l'opération DDL. Exécutez la commande SHOW PROCESSLIST pour consulter l'état d'exécution de l'opération DDL. Si l'état est Wait for syncing with replicas, cela indique qu'un blocage s'est produit. Pour plus d'informations sur la résolution de ce problème, consultez Afficher l'état d'exécution des instructions DDL et l'état MDL.

Q : Le format binlog diffère-t-il du format MySQL natif ?

R : Non, il n'y a aucune différence.

Q : Les schémas performance et sys sont-ils pris en charge ?

R : Oui.

Q : Le mécanisme de collecte des statistiques de table diffère-t-il de celui de MySQL Community Edition ?

R : Les statistiques de table sur le nœud principal d'un cluster PolarDB for MySQL sont cohérentes avec celles de MySQL Community Edition. Pour garantir des plans d'exécution cohérents entre le nœud principal et les nœuds en lecture seule, chaque mise à jour des statistiques sur le nœud principal est synchronisée vers les nœuds en lecture seule. De plus, exécutez la commande ANALYZE TABLE sur les nœuds en lecture seule pour charger proactivement les dernières statistiques depuis le disque.

Q : PolarDB prend-il en charge les transactions XA ? Y a-t-il des différences avec l'implémentation officielle de MySQL ?

R : Oui, PolarDB prend en charge les transactions XA, sans aucune différence par rapport à l'implémentation officielle de MySQL.

Q : PolarDB prend-il en charge la recherche en texte intégral ?

Q : Percona Toolkit est-il pris en charge ?

R : Oui, mais nous vous recommandons d'utiliser le DDL en ligne.

Q : gh-ost est-il pris en charge ?

R : Oui, mais nous vous recommandons d'utiliser le DDL en ligne.

Q : Quels sont les éléments facturables d'un cluster PolarDB ?

R : Les éléments facturables comprennent l'espace de stockage, les nœuds de calcul, les sauvegardes (avec un quota gratuit) et SQL Explorer (en option). Pour plus d'informations, consultez Éléments facturables, ou .

Q : Que comprend l'espace de stockage facturé ?

R : L'espace de stockage facturé comprend les fichiers de tables de base de données, les fichiers d'index, les fichiers de journaux undo, les fichiers de journaux redo, les fichiers binlog, les fichiers de journaux lents et un petit nombre de fichiers système. Pour plus d'informations, consultez Vue d'ensemble, ou .

Q : Comment suis-je facturé si j'ajoute un nœud en lecture seule ?

R : Le prix d'un nœud en lecture seule est identique à celui d'un nœud principal. Pour plus d'informations, consultez Détails de la tarification des nœuds de calcul, ou .

Q : Si j'ajoute un nœud en lecture seule, la capacité de stockage est-elle doublée ?

R : Non. PolarDB utilise une architecture qui découple le calcul et le stockage. Lorsque vous achetez un nœud en lecture seule, vous ajoutez une ressource de calcul, ce qui n'augmente pas la capacité de stockage.

L'espace de stockage est serverless, vous n'avez donc pas besoin de sélectionner une capacité lors de l'achat. Il s'adapte automatiquement à la croissance de vos données, et vous n'êtes facturé que pour la quantité de données utilisée. Chaque spécification de cluster possède une capacité de stockage maximale. Pour augmenter la limite de stockage, mettez à niveau les spécifications du cluster, ou .

Q : Comment arrêter les frais pour un cluster à l'utilisation ?

R : Si vous n'avez plus besoin du cluster, libérez-le. La libération du cluster arrête tous les frais futurs.

Q : Puis-je modifier les spécifications d'un cluster lors d'une mise à niveau temporaire ?

R : Pendant une mise à niveau temporaire, tant que le statut du cluster est Running, vous pouvez mettre à niveau manuellement les spécifications. Cependant, vous ne pouvez pas effectuer de rétrogradation manuelle, activer la mise à l'échelle automatique, ni ajouter ou supprimer des nœuds.

Q : Quelle est la bande passante publique de PolarDB et y a-t-il des coûts associés ?

R : PolarDB lui-même n'a pas de limite de bande passante publique. La bande passante dépend principalement du service Server Load Balancer (SLB) que vous utilisez. PolarDB ne facture pas les connexions publiques.

Q : Pourquoi vois-je encore des frais quotidiens pour un cluster par abonnement ?

R : Les éléments facturables pour PolarDB incluent les nœuds de calcul (nœuds principaux et en lecture seule), l'espace de stockage, les sauvegardes de données (facturées uniquement lorsque le quota gratuit est dépassé), SQL Explorer (en option) et Global Database Network (GDN) (en option). Pour plus d'informations, consultez Éléments facturables. Le mode de facturation par abonnement exige que vous prépayiez les nœuds de calcul lors de la création du cluster, mais il ne couvre pas les coûts de l'espace de stockage, des sauvegardes de données et de SQL Explorer. Les frais pour ces éléments à l'utilisation sont déduits de votre compte sur une base horaire. Par conséquent, même avec un abonnement, vous recevrez toujours des factures à l'utilisation.

Q : Y a-t-il des frais supplémentaires pour la migration en un clic d'ApsaraDB RDS for MySQL vers PolarDB ?

R : Le processus de migration en un clic est gratuit. Seuls l'instance ApsaraDB RDS for MySQL et le cluster PolarDB lui-même sont facturés.

Q : Pourquoi suis-je toujours facturé pour l'espace de stockage après avoir supprimé des données d'une table PolarDB à l'aide de la commande DELETE ?

R : La commande DELETE marque uniquement les lignes pour suppression. Elle ne libère pas l'espace de la table.

Q : Comment mettre en œuvre la séparation lecture/écriture dans PolarDB ?

R : Utilisez simplement l'endpoint de cluster dans votre application. La séparation lecture/écriture est alors mise en œuvre en fonction du mode lecture/écriture configuré. Pour plus d'informations, consultez Configurer le proxy de base de données, ou .

Q : Quel est le nombre maximal de nœuds en lecture seule pris en charge dans un cluster PolarDB ?

R : PolarDB utilise une architecture de cluster distribué. Un cluster contient un nœud principal et jusqu'à 15 nœuds en lecture seule. Au moins un nœud en lecture seule est requis pour garantir la haute disponibilité.

Q : Pourquoi les charges de travail sont-elles déséquilibrées entre plusieurs nœuds en lecture seule ?

R : Un déséquilibre de charge entre les nœuds en lecture seule peut être causé par un faible nombre de connexions aux nœuds ou par un endpoint de cluster personnalisé dont la configuration n'inclut pas tous les nœuds en lecture seule.

Q : Qu'est-ce qui provoque une charge élevée ou faible sur le nœud principal ?

R : Une charge élevée sur le nœud principal peut résulter de plusieurs facteurs : connexions directes à l'endpoint principal, acceptation des requêtes de lecture par le nœud principal, grand nombre de requêtes transactionnelles, latence de réplication élevée entraînant le routage des requêtes vers le nœud principal, ou défaillance d'un nœud en lecture seule provoquant le routage des requêtes de lecture vers le nœud principal.

Une charge faible sur le nœud principal peut survenir si l'option d'acceptation des requêtes de lecture sur le nœud principal est désactivée.

Q : Comment réduire la charge sur le nœud principal ?

Q : Pourquoi ne puis-je pas lire les données immédiatement après leur insertion ?

Q : Comment forcer l'exécution d'une instruction SQL sur le nœud principal ?

Q : Puis-je attribuer différents endpoints à différents services ? Ces endpoints peuvent-ils fournir une isolation entre les services ?

R : Oui, créez plusieurs endpoints personnalisés pour différents services. Si ces endpoints utilisent des nœuds sous-jacents différents, ils fournissent une isolation et ne s'affectent pas mutuellement. Pour savoir comment créer un endpoint personnalisé, consultez Créer un endpoint de cluster personnalisé, ou .

Q : Si j'ai plusieurs nœuds en lecture seule, comment créer un endpoint dédié à nœud unique pour l'un d'eux ?

Q : Quel est le nombre maximal d'endpoints à nœud unique que je peux créer dans un cluster ?

R : Si votre cluster comporte trois nœuds, créez un endpoint à nœud unique pour un seul nœud en lecture seule. Si votre cluster comporte quatre nœuds, créez des endpoints à nœud unique distincts pour deux des nœuds en lecture seule. Ce schéma se poursuit à mesure que le nombre de nœuds augmente.

Q : J'utilise uniquement l'endpoint principal, mais je constate une charge sur les nœuds en lecture seule. L'endpoint principal prend-il également en charge la séparation lecture/écriture ?

R : Non, l'endpoint principal ne prend pas en charge la séparation lecture/écriture. Il se connecte toujours uniquement au nœud principal. Un petit nombre de QPS sur les nœuds en lecture seule est normal et n'est pas lié à l'endpoint principal.

Q : Comment ajouter des champs et des index en ligne ?

R : Utilisez le DDL en ligne natif ou des outils comme pt-online-schema-change et gh-ost. Nous vous recommandons d'utiliser les opérations DDL en ligne natives.

Q : La fonctionnalité d'insertion en masse est-elle prise en charge ?

R : Oui.

Q : L'insertion en masse est-elle prise en charge si j'écris des données uniquement sur le nœud principal ? Quel est le nombre maximal de valeurs que je peux insérer à la fois ?

R : Oui, elle est prise en charge. Le nombre maximal de valeurs que vous pouvez insérer à la fois est déterminé par la valeur du paramètre max_allowed_packet. Pour plus d'informations, consultez Réplication et max_allowed_packet.

Q : Puis-je effectuer une opération d'insertion en masse via l'endpoint de cluster ?

R : Oui.

Q : Existe-t-il un délai de réplication entre le nœud principal et les nœuds en lecture seule ?

R : Oui, un délai de l'ordre de la milliseconde existe entre eux.

Q : Qu'est-ce qui peut provoquer une augmentation du délai de réplication ?

Q : S'il y a un délai de réplication, comment garantir la cohérence des requêtes ?

R : Utilisez un endpoint de cluster et sélectionnez un niveau de cohérence approprié. Les niveaux de cohérence disponibles, du plus élevé au plus bas, sont la cohérence globale (cohérence forte), la cohérence de session et la cohérence à terme. Pour plus d'informations, consultez Niveaux de cohérence, ou .

Q : Un objectif de point de reprise (RPO) de 0 peut-il être garanti en cas de défaillance d'un seul nœud ?

R : Oui.

Q : Comment les mises à niveau de spécifications (par exemple, de 2 cœurs et 8 Go de mémoire à 4 cœurs et 16 Go) sont-elles implémentées en arrière-plan ? Quel est l'impact sur les services ?

R : PolarDB effectue une mise à niveau progressive sur le proxy et les nœuds de base de données afin de minimiser l'impact sur le service. Une mise à niveau prend généralement de 10 à 15 minutes, avec un impact sur le service ne dépassant pas 30 secondes. Durant cette période, une à trois erreurs de connexion transitoires peuvent survenir. Pour plus d'informations, consultez Mise à l'échelle manuelle, ou .

Q : Combien de temps faut-il pour ajouter un nœud ? Cela affecte-t-il mes services ?

Q : Combien de temps faut-il pour passer à la dernière version de révision ? Cela affecte-t-il mes services ?

R : PolarDB utilise une méthode de mise à niveau progressive sur plusieurs nœuds pour minimiser l'impact sur vos services. Une mise à niveau de version prend généralement moins de 30 minutes. Pendant la mise à niveau, le proxy de base de données ou le moteur noyau DB est redémarré, ce qui peut provoquer des erreurs de connexion transitoires. Effectuez la mise à niveau pendant les heures creuses et assurez-vous que votre application dispose d'un mécanisme de reconnexion automatique. Pour plus d'informations, consultez Gestion des versions mineures, ou .

Q : Comment fonctionne le basculement automatique ?

R : PolarDB utilise une architecture de cluster haute disponibilité Active-Active. Le basculement automatique s'effectue entre le nœud principal en lecture-écriture et les nœuds en lecture seule. Le système élit automatiquement un nouveau nœud principal. Chaque nœud d'un cluster PolarDB possède une priorité de basculement, qui détermine sa probabilité d'être élu comme nouveau nœud principal lors d'un basculement. Si plusieurs nœuds ont la même priorité, ils ont la même probabilité d'être élus. Pour plus d'informations, consultez Basculement automatique et manuel des nœuds principal/secondaire, ou .

Q : Quelles permissions sont requises pour terminer une connexion dans un cluster PolarDB for MySQL ?

R : Dans MySQL, des permissions spécifiques sont nécessaires pour terminer une connexion à l'aide de la commande KILL. Plus précisément, pour terminer la connexion d'un autre utilisateur standard, vous devez disposer de la permission PROCESS.

Q : Mon journal d'exécution affiche une erreur [ERROR] InnoDB: fil_space_extend space_name:xxx. Cela affecte-t-il mes services actuels ?

R : Non, cela n'affecte pas vos services. Cette entrée de journal indique qu'après l'extension de la taille du fichier sur le nœud lecture-écriture du cluster PolarDB, le nœud en lecture seule synchronise les informations de taille de fichier dans sa mémoire. Dans les clusters exécutant MySQL 5.7, le niveau de journalisation pour ce message n'est pas ajusté et reste à ERROR. Sur les nœuds en lecture seule, considérez ceci comme un message de niveau INFO. Cela n'affecte pas vos services.

Q : Quelle est l'architecture du proxy de base de données ? Dispose-t-il d'un mécanisme de basculement ? Comment sa haute disponibilité est-elle assurée ?

R : Le proxy de base de données utilise une architecture haute disponibilité à deux nœuds, répartissant le trafic équitablement entre les deux nœuds proxy. Le système vérifie en permanence l'état de santé des nœuds proxy. Si une défaillance de nœud est détectée, le système déconnecte proactivement les connexions sur ce nœud, et le nœud sain restant reprend automatiquement tout le trafic pour assurer un service ininterrompu. Parallèlement, le système reconstruit et restaure automatiquement le nœud proxy défaillant. Ce processus est généralement terminé en environ 2 minutes. Pendant ce temps, le cluster de base de données reste accessible.

Dans de rares cas, les connexions à un nœud défaillant peuvent ne pas être déconnectées en temps voulu et devenir inopérantes. Pour gérer de telles situations, configurez des politiques de délai d'attente appropriées côté client, telles que socketTimeout et connectTimeout de JDBC. Cela permet à la couche applicative de détecter et de terminer rapidement les connexions suspendues, améliorant ainsi la tolérance aux pannes et l'efficacité de réponse du système.

Q : Comment consulter les journaux d'erreurs d'un cluster PolarDB for MySQL ?

R : Accédez à la console PolarDB. Sur la page de détails du cluster, allez dans Diagnostics and Optimization > Log Management dans le volet de navigation de gauche. Sous l'onglet Running Logs, consultez les journaux d'erreurs.

Q : PolarDB for MySQL crée-t-il automatiquement une clé primaire masquée pour une table sans clé primaire ?

R : Oui. Par défaut, PolarDB for MySQL crée une clé primaire implicite pour toute table sans clé primaire.

Afficher la clé primaire implicite

Connectez-vous au cluster et exécutez SET show_ipk_info = 1. Ensuite, affichez la clé en exécutant la commande SHOW CREATE TABLE.

-- Set the parameter to display the implicit primary key.
SET show_ipk_info = 1;
-- View the table schema.
SHOW CREATE TABLE t;

Consultez le schéma de la table. La colonne __#alibaba_rds_row_id#__ correspond à la clé primaire implicite.

+-------+------------------------------------------------------------------------------------------------------------+
| Table | Create Table                                                                                               |
+-------+------------------------------------------------------------------------------------------------------------+
| t     | CREATE TABLE `t` (
  `id` int(11) DEFAULT NULL,
  `__#alibaba_rds_row_id#__` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'Implicit Primary Key by RDS',
  KEY `__#alibaba_rds_row_id#__` (`__#alibaba_rds_row_id#__`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
+-------+------------------------------------------------------------------------------------------------------------+

Q : Pourquoi vois-je une erreur Lock wait timeout exceeded et trouve une transaction avec un trx_mysql_thread_id égal à 0 ?

MySQL xxx > select * from information_schema.innodb_trx\G
*************************** 1. row ***************************
                    trx_id: 3317965
                 trx_state: RUNNING
               trx_started: 2025-12-23 11:29:17
      trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 3
       trx_mysql_thread_id: 0
                 trx_query: NULL

Pourquoi différents clusters PolarDB for MySQL 8.0 présentent-ils un comportement de gestion des erreurs incohérent lors de la comparaison de types de date et d'heure invalides ?

• Description du problème : Les clusters PolarDB for MySQL 8.0 sont disponibles en deux versions, MySQL 8.0.1 et MySQL 8.0.2, qui sont entièrement compatibles avec MySQL 8.0.13 et MySQL 8.0.18 respectivement. Cependant, ces deux versions gèrent les types de date et d'heure invalides de manière incohérente.

  Plus précisément, lorsqu'un littéral de chaîne est comparé à une valeur de type heure, une tentative de conversion de la chaîne en type heure est effectuée. Si la chaîne est une date invalide, la conversion échoue. Le comportement en cas d'échec de conversion diffère entre les deux versions. La version compatible 8.0.13 émet seulement un WARNING, tandis que la version compatible 8.0.18 renvoie une erreur ER_WRONG_VALUE. Par conséquent, lors de la comparaison de dates invalides et de champs d'heure, ces deux versions de clusters PolarDB for MySQL présentent un comportement de signalement d'erreurs incohérent.

• Solution : Pour garantir des résultats d'exécution SQL cohérents (soit tous réussis, soit tous échoués), plusieurs clusters PolarDB for MySQL doivent utiliser la même version majeure du noyau, soit tous MySQL 8.0.1, soit tous MySQL 8.0.2.

Q : Comment PolarDB sauvegarde-t-il les données ?

R : PolarDB utilise des snapshots pour sauvegarder les données. Pour plus d'informations, consultez Méthode de sauvegarde 1 : Sauvegarde automatique et Méthode de sauvegarde 2 : Sauvegarde manuelle, ou .

Q : À quelle vitesse une base de données peut-elle être restaurée ?

R : La restauration d'une base de données à partir d'un ensemble de sauvegarde (snapshot) ou le clonage d'une base de données prend environ 40 minutes par To. Si vous restaurez des données à un point précis dans le temps, le temps nécessaire pour appliquer les journaux redo est également inclus. L'application des journaux redo prend environ 20 à 70 secondes par Go. Le temps total de restauration est la somme de ces deux parties.

Q : Pourquoi les performances de PolarDB for MySQL ne sont-elles pas nettement supérieures à celles d'ApsaraDB RDS for MySQL ?

Pour une comparaison des performances entre PolarDB for MySQL et ApsaraDB RDS for MySQL, consultez Comparaison des performances : PolarDB for MySQL vs. ApsaraDB RDS for MySQL.

Q : Quel est le nombre maximal de tables ? À quel moment les performances peuvent-elles se dégrader ?

R : Le nombre maximal de tables est limité par le nombre de fichiers. Pour plus d'informations, consultez Limites, ou .

Q : Le partitionnement des tables peut-il améliorer les performances des requêtes de PolarDB ?

R : Généralement, oui. Si une requête peut être limitée à une partition spécifique, les performances peuvent être améliorées.

Q : Puis-je créer 10 000 bases de données dans un cluster PolarDB ? Quel est le nombre maximal de bases de données ?

R : Oui, créez jusqu'à 10 000 bases de données dans un cluster PolarDB. Le nombre maximal de bases de données est limité par le nombre de fichiers. Pour plus d'informations, consultez Limites, ou .

Q : Le nombre maximal de connexions est-il lié au nombre de nœuds en lecture seule ? Puis-je augmenter le nombre maximal de connexions en ajoutant des nœuds en lecture seule ?

R : Non, le nombre de nœuds en lecture seule n'est pas lié au nombre maximal de connexions. Le nombre maximal de connexions dans PolarDB est déterminé par les spécifications du nœud. Pour plus d'informations, consultez Limites. Si vous avez besoin de plus de connexions, mettez à niveau les spécifications.

Q : Comment les IOPS sont-ils limités et isolés ? Une contention d'E/S peut-elle se produire entre plusieurs nœuds de cluster PolarDB ?

R : Dans un cluster PolarDB, chaque nœud a une limite d'IOPS basée sur ses spécifications. Les IOPS de chaque nœud sont isolés et n'affectent pas les autres nœuds.

Q : Les performances d'un nœud en lecture seule lent peuvent-elles affecter le nœud principal ?

R : Oui. Si un nœud en lecture seule a une charge élevée ou un délai de réplication accru, cela peut augmenter légèrement la consommation de mémoire du nœud principal.

Q : Quel est l'impact sur les performances de l'activation du binlog ?

R : L'activation du binlog n'affecte pas les performances des requêtes (SELECT), mais elle affecte les opérations d'écriture (INSERT, UPDATE, DELETE). Dans une base de données avec une charge de travail lecture-écriture équilibrée, l'activation du binlog impacte généralement les performances de moins de 10 %.

Q : Quel est l'impact sur les performances de l'activation de SQL Explorer ?

R : Il n'y a aucun impact sur les performances.

Q : Quel protocole réseau haut débit PolarDB utilise-t-il ?

R : PolarDB utilise la technologie RDMA double 25 Gbps pour la communication entre ses nœuds de calcul et de stockage, ainsi qu'entre ses réplicas de données de stockage. Cela offre de puissantes performances d'E/S avec une faible latence et un débit élevé.

Q : Quelle est la bande passante maximale pour les connexions externes à PolarDB ?

R : La bande passante maximale pour les connexions externes à PolarDB est de 10 Gbit/s.

Q : Quels sont les avantages du stockage de tables volumineuses dans PolarDB for MySQL par rapport aux bases de données traditionnelles utilisant des disques locaux ?

R : Dans PolarDB for MySQL, une table unique est physiquement divisée et stockée sur plusieurs serveurs de stockage. Par conséquent, les opérations d'E/S sur la table sont réparties entre plusieurs disques de stockage. Le débit global de lecture E/S, bien que non la latence E/S, est bien supérieur à celui des bases de données centralisées utilisant des disques locaux.

Q : Comment optimiser les tables volumineuses ?

R : Nous vous recommandons d'utiliser des tables partitionnées.

Q : Quand est-il approprié d'utiliser des tables partitionnées ?

R : Les tables partitionnées conviennent aux scénarios où vous devez élaguer de grandes tables pour contrôler la quantité de données accessibles par les requêtes, et où vous souhaitez que cet élagage soit transparent pour votre code métier sans nécessiter de modifications. Par exemple, utilisez des tables partitionnées pour nettoyer périodiquement les données métier historiques, par exemple en supprimant la partition du mois le plus ancien et en créant une nouvelle pour le mois suivant afin de ne conserver que les six derniers mois de données.

Q : Quelle est la meilleure façon de copier une très grande table (par exemple, copier la table A vers la table B) au sein de la même base de données PolarDB for MySQL ?

CREATE TABLE B AS SELECT * FROM A;

Q : Puis-je optimiser les connexions PHP de courte durée dans des scénarios à haute concurrence ?

R : Oui. Optimisez-les en activant le pool de connexions au niveau de la session dans les paramètres de l'endpoint de cluster. Pour plus d'informations, consultez Configurer l'endpoint de cluster, ou .

Q : Comment empêcher quelques requêtes SQL inefficaces de dégrader l'ensemble de la base de données ?

R : Si votre cluster PolarDB for MySQL est en version 5.6 ou 8.0, utilisez la fonctionnalité de Contrôle de concurrence pour appliquer une limitation de débit à des instructions spécifiques.

Q : PolarDB prend-il en charge un délai d'expiration de session inactive ?

R : Oui. Personnalisez le délai d'expiration des sessions inactives en modifiant le paramètre wait_timeout. Pour les étapes détaillées, consultez Spécifier les paramètres de cluster et de nœud.

Q : Comment trouver les requêtes SQL lentes ?

Q : Comment terminer une requête SQL lente ?

mysql> KILL 33554499;
Query OK, 0 rows affected (0.01 sec)