PolarDB:FAQ

Q : Qu'est-ce que PolarDB ?

R : est un service de base de données relationnelle basé sur le cloud. Il est déployé dans des centres de données répartis dans plus de 10 régions à travers le monde et propose des services de base de données en ligne prêts à l'emploi. PolarDB est compatible à 100 % avec PostgreSQL. Par défaut, la capacité de stockage peut atteindre jusqu'à 500 To.

Q : Pourquoi PolarDB surpasse-t-il les bases de données traditionnelles ?

R : Par rapport aux bases de données traditionnelles, PolarDB peut stocker des centaines de téraoctets de données. Elle offre également une haute disponibilité, une fiabilité élevée, des mises à niveau et rétrogradations élastiques rapides, ainsi que des sauvegardes sans verrouillage. Pour plus d'informations, consultez la section Avantages.

Q : Quand PolarDB a-t-elle été lancée ? Quand est-elle devenue disponible commercialement ?

R : PolarDB a été lancée en aperçu public en septembre 2017 et est devenue disponible commercialement en mars 2018.

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

R : PolarDBCluster Edition utilise une architecture de cluster multinœud. 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. Les clusters sont gérés et facturés par cluster. Pour plus d'informations, consultez le .

Q : Quels langages de programmation sont pris en charge ?

A : PolarDB prend en charge des langages de programmation tels que Java, Python, PHP, Golang, C, C++, .NET et Node.js.

Q : Quels moteurs de stockage sont pris en charge ?

Q : Les instances secondaires autogérées sont-elles prises en charge ? Existe-t-il une implémentation recommandée ?

R : Oui, les instances secondaires autogérées sont prises en charge. Après avoir activé la journalisation binaire, vous pouvez synchroniser avec d'autres bases de données MySQL pour mettre en place une architecture primaire/secondaire. Pour simplifier la maintenance continue, utilisez Data Transmission Service (DTS). Pour plus d'informations sur l'utilisation de DTS pour synchroniser les données, consultez la section Synchroniser les données d'un cluster PolarDB for MySQL vers une instance ApsaraDB RDS for MySQL.

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

R : Oui, PolarDB est un cluster de stockage distribué basé sur le protocole de cohérence Parallel Raft. Le moteur de calcul se compose de 1 à 16 nœuds de calcul répartis sur différents serveurs. Un cluster prend en charge une capacité de stockage maximale de 200 To, ainsi qu'un maximum de 88 cœurs et 710 Go de mémoire. Vous pouvez augmenter dynamiquement les ressources de stockage et de calcul en ligne, et cette mise à l'échelle n'affecte pas le fonctionnement normal de vos services.

Q : Après l'achat de PolarDB, dois-je toujours acheter le middleware de base de données PolarDB-X pour implémenter le sharding ?

R : Oui.

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

R : Oui, le partitionnement des tables est pris en charge.

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

R : PolarDB implémente le partitionnement au niveau de la couche de stockage. Cela est transparent et imperceptible pour les utilisateurs.

Q : Par rapport à MySQL natif, quelle est la quantité maximale de données qu'une seule table dans PolarDB peut stocker ?

R : PolarDB ne limite pas la taille d'une table individuelle. Toutefois, la taille d'une table individuelle est limitée par l'espace disque. Pour plus d'informations, consultez la section Limites.

Q : Quels sont les éléments facturables de PolarDB ?

R : Les éléments facturables incluent l'espace de stockage, les nœuds de calcul, la sauvegarde des données (avec un quota gratuit) et SQL Explorer (en option). Pour plus d'informations, consultez les sections Spécifications et tarifs.

Q : Quels contenus sont inclus dans l'espace de stockage facturable ?

R : L'espace de stockage facturable inclut les fichiers de table de base de données, les fichiers d'index, les fichiers de journal undo, les fichiers de journal redo, les fichiers de journal des requêtes lentes et un petit nombre de fichiers système. Pour plus d'informations, consultez la section Spécifications et tarifs.

Q : Comment implémenter la répartition lecture/écriture dans PolarDB ?

R : Il vous suffit d'utiliser un endpoint de cluster dans votre application pour implémenter la répartition lecture/écriture en fonction du mode lecture/écriture configuré. Pour plus d'informations, consultez la section Configurer PolarProxy.

Q : Quel est le nombre maximal de nœuds en lecture seule qu'un cluster PolarDB prend en charge ?

R : PolarDB utilise une architecture de cluster distribué. Un cluster se compose d'un nœud principal et de 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 sont-elles déséquilibrées entre plusieurs nœuds en lecture seule ?

R : Les charges peuvent être déséquilibrées entre les nœuds en lecture seule pour les raisons suivantes : un nœud en lecture seule possède un petit nombre de connexions, ou un nœud en lecture seule n'est pas inclus lors de l'allocation d'un endpoint de cluster personnalisé.

Q : Quelles sont les causes des charges lourdes ou légères sur le nœud principal ?

R : Des charges lourdes sur le nœud principal (base de données principale) peuvent être causées par les raisons suivantes : les applications se connectent directement à l'endpoint principal, la base de données principale accepte des requêtes de lecture, un grand nombre de requêtes de transaction existent, un délai de réplication primaire/secondaire élevé entraîne le routage des requêtes vers la base de données principale, ou des exceptions sur les nœuds en lecture seule provoquent le routage des requêtes de lecture vers la base de données principale.

Une charge légère sur le nœud principal peut être causée par l'option de déchargement des lectures depuis le nœud principal activée sur la base de données principale.

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

Q : Pourquoi ne puis-je pas lire les données qui viennent d'être insérées ?

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 ? Différents endpoints permettent-ils l'isolation ?

R : Oui, vous pouvez créer plusieurs endpoints personnalisés pour différents services. Si les nœuds sous-jacents sont différents, les endpoints personnalisés fournissent une isolation et ne s'affectent pas mutuellement. Pour plus d'informations sur la création d'un endpoint personnalisé, consultez la section Configurer PolarProxy.

Q : Si plusieurs nœuds en lecture seule existent, comment créer séparément un endpoint de nœud unique pour l'un des nœuds en lecture seule ?

Q : Quel est le nombre maximal d'endpoints de nœud unique pouvant être créés dans un cluster ?

R : Si votre cluster comporte trois nœuds, vous pouvez créer un endpoint de nœud unique pour un seul des nœuds en lecture seule. Si votre cluster comporte quatre nœuds, vous pouvez créer un endpoint de nœud unique pour chacun des deux nœuds en lecture seule. Des règles similaires s'appliquent aux clusters comportant plus de nœuds.

Q : J'utilise uniquement l'endpoint principal, mais je constate que les nœuds en lecture seule ont également des charges. L'endpoint principal prend-il en charge la répartition lecture/écriture ?

R : Non, l'endpoint principal ne prend pas en charge la répartition lecture/écriture et est toujours connecté uniquement au nœud principal. Un petit nombre de requêtes par seconde (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 : Vous pouvez utiliser des outils tels que le DDL en ligne natif, pt-osc et gh-ost. Le DDL en ligne natif est recommandé.

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

R : Oui, la fonctionnalité d'insertion groupée est prise en charge.

Q : Si les données sont écrites uniquement sur un nœud en écriture seule, l'insertion groupée est-elle prise en charge ? Quel est le nombre maximal de valeurs pouvant être insérées en une seule fois ?

R : Oui, l'insertion groupée est prise en charge. Le nombre maximal de valeurs pouvant être insérées en une seule fois est déterminé par la valeur du paramètre max_allowed_packet. Pour plus d'informations, consultez Replication and max_allowed_packet.

Q : Puis-je effectuer des opérations d'insertion groupée via un endpoint de cluster ?

R : Oui, vous pouvez effectuer des opérations d'insertion groupée via un endpoint de cluster.

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

R : Oui, un délai de réplication de quelques millisecondes existe entre eux.

Q : Dans quels scénarios le délai de réplication augmente-t-il ?

Q : Comment garantir la cohérence des requêtes lorsqu'un délai de réplication existe ?

R : Vous pouvez utiliser un endpoint de cluster et sélectionner un niveau de cohérence approprié. Les niveaux de cohérence, classés par ordre décroissant, sont les suivants : cohérence de session et cohérence à terme. Pour plus d'informations, consultez Configurer PolarProxy.

Q : L'objectif de point de récupération (RPO) peut-il être garanti à zéro en cas de défaillance d'un seul nœud ?

R : Lorsque les paramètres du cluster de base de données utilisent les paramètres par défaut, le RPO n'est pas nul. Vous pouvez modifier la valeur du paramètre sychronous_commit pour garantir que le RPO soit nul. Pour plus d'informations sur les valeurs par défaut de certains paramètres, consultez Valeurs par défaut des paramètres du cluster.

Q : Comment une mise à niveau des spécifications (par exemple, de 2 cœurs et 8 Go de mémoire à 4 cœurs et 16 Go de mémoire) est-elle implémentée en arrière-plan ? Quels sont les impacts sur mes services ?

R : Le proxy PolarDB et les nœuds de base de données doivent être mis à niveau vers les dernières configurations. Une méthode de mise à niveau progressive est utilisée pour mettre à niveau plusieurs nœuds afin de minimiser les impacts sur vos services. Actuellement, chaque mise à niveau prend environ 10 à 15 minutes. Les impacts sur vos services durent au maximum 30 secondes, période durant laquelle une à trois erreurs de connexion transitoires peuvent se produire. Pour plus d'informations, consultez Modifier la configuration.

Q : Combien de temps faut-il pour ajouter un nœud ? Mes services sont-ils affectés ?

Q : Combien de temps faut-il pour mettre à niveau vers la dernière version de révision ? Mes services sont-ils affectés ?

R : PolarDB utilise une méthode de mise à niveau progressive pour plusieurs nœuds afin de minimiser les impacts 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 de base de données est redémarré, ce qui peut provoquer des erreurs de connexion transitoires à la base de données. Effectuez la mise à niveau pendant les heures creuses et assurez-vous que votre application prend en charge la reconnexion automatique. Pour plus d'informations, consultez .

Q : Comment un basculement automatique est-il implémenté ?

R : PolarDB utilise une architecture haute disponibilité actif-actif. Un basculement automatique est effectué entre le nœud primaire prenant en charge la lecture et l'écriture et les nœuds en lecture seule, et le système élit automatiquement un nouveau nœud primaire.PolarDB Chaque nœud possède une priorité de basculement, qui détermine la probabilité que le nœud soit élu comme nœud primaire lors d'un basculement. Lorsque plusieurs nœuds ont la même priorité, ils ont la même probabilité d'être élus comme nœud primaire. Pour plus d'informations, consultez .

Q : Quelle est l'architecture du proxy de base de données, quel est son mécanisme de basculement et comment sa haute disponibilité est-elle assurée ?

R : Le proxy de base de données utilise une architecture haute disponibilité à deux nœuds et répartit uniformément le trafic entre les deux nœuds proxy selon un ratio 1:1. Le système vérifie continuellement l'état de santé des nœuds proxy. Si un nœud tombe en panne, le système déconnecte proactivement les connexions sur ce nœud. Le nœud sain restant prend automatiquement en charge tout le trafic afin que le service ne soit pas interrompu. Le système reconstruit et restaure également automatiquement le nœud proxy défaillant. L'ensemble du processus prend généralement environ 2 minutes et le cluster de base de données reste accessible pendant cette période.

Dans de rares cas, les connexions sur un nœud défaillant ne sont pas déconnectées à temps, mais le nœud ne peut plus répondre aux requêtes. Pour gérer cela, configurez des politiques de délai d'expiration appropriées sur le client, telles que les paramètres JDBC socketTimeout et connectTimeout, afin que la couche application puisse détecter et terminer rapidement les connexions suspendues. Cela améliore encore la tolérance aux pannes et l'efficacité de réponse du système.

Q : Quelle méthode de sauvegarde PolarDB utilise-t-il ?

R : PolarDB utilise des snapshots pour sauvegarder les données. Pour plus d'informations, consultez .

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

R : Actuellement, la vitesse de restauration (clonage) d'une base de données basée sur un ensemble de sauvegarde (snapshot) est de 40 minutes par To. Si vous restaurez les données à un point précis dans le temps, le temps nécessaire pour rejouer les journaux redo doit être inclus. La vitesse de rejeu est d'environ 20 à 70 secondes par Go. Le temps total de récupération est la somme de ces deux parties.

Q : Pourquoi ne montre-t-il pas d'améliorations significatives des performances par rapport à ApsaraDB RDS for MySQL ?

Les résultats de comparaison des performances entre et ApsaraDB RDS for MySQL sont décrits dans Comparaison des performances : PolarDB for MySQL vs. ApsaraDB RDS for MySQL.

Q : Pourquoi une base de données supprimée occupe-t-elle encore une grande quantité d'espace de stockage ?

R : Cela est dû au fait que les fichiers de journaux redo occupent de l'espace de stockage. Dans la plupart des cas, les fichiers de journaux redo occupent entre 2 Go et 11 Go d'espace de stockage. Un maximum de 11 Go est occupé, ce qui comprend les huit fichiers de journaux redo dans le pool de tampons (8 Go), le fichier de journal redo en cours d'écriture (1 Go), le fichier de journal redo précréé (1 Go) et le dernier fichier de journal redo (1 Go).

Le nombre de fichiers de journaux redo dans le pool de tampons est contrôlé par le paramètre loose_innodb_polar_log_file_max_reuse. La valeur par défaut est 8. Vous pouvez modifier ce paramètre pour réduire l'espace de stockage occupé par les fichiers journaux. Cependant, sous de fortes charges, de légères fluctuations périodiques des performances peuvent se produire.

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

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

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

R : En général, si une instruction SQL de requête peut être confinée à une partition spécifique, les performances peuvent être améliorées.

Q : PolarDB prend-il en charge la création de 10 000 bases de données ? Quel est le nombre maximal de bases de données ?

R : PolarDB prend en charge la création de 10 000 bases de données. Le nombre maximal de bases de données est limité par le nombre de fichiers. Pour plus d'informations, consultez Limites.

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

R : Le nombre de nœuds en lecture seule n'a aucun lien avec le nombre maximal de connexions. Le nombre maximal de connexions de PolarDB est déterminé par les spécifications du nœud. Pour plus d'informations, consultez . Si vous avez besoin de plus de connexions, mettez à niveau les spécifications.

Q : Comment les opérations d'entrée/sortie par seconde (IOPS) sont-elles limitées et isolées ? Plusieurs nœuds d'un cluster PolarDB entrent-ils en concurrence pour les ressources E/S ?

R : Chaque nœud d'un cluster PolarDB a ses IOPS configurées en fonction des spécifications du nœud. Les IOPS de chaque nœud sont isolées indépendamment et n'affectent pas les autres.

Q : Le nœud primaire est-il affecté si les performances des nœuds en lecture seule ralentissent ?

R : Lorsque la charge sur les nœuds en lecture seule est excessivement élevée et que le délai de réplication augmente, la consommation de mémoire du nœud primaire peut légèrement augmenter.

Q : Quel est l'impact sur les performances après l'activation de la journalisation binaire ?

R : L'activation de la journalisation binaire n'affecte pas les performances des requêtes (SELECT). Elle affecte uniquement les performances d'écriture et de mise à jour (INSERT, UPDATE et DELETE). En général, pour une base de données où les requêtes de lecture et d'écriture sont équilibrées, l'activation de la journalisation binaire affecte les performances de moins de 10 %.

Q : Quel est l'impact sur les performances après l'activation de SQL Explorer (audit complet des journaux SQL) ?

R : Il n'y a aucun impact.

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

R : Les nœuds de calcul et de stockage de la base de données PolarDB, ainsi que les multiples réplicas des données stockées, utilisent tous la technologie RDMA double 25 Gbps pour offrir de solides performances E/S avec une faible latence et un débit élevé.

Q : Quelle est la bande passante maximale pour que PolarDB se connecte via Internet ?

R : La bande passante maximale pour que PolarDB se connecte via Internet est de 10 Gbit/s.

Q : Que faire si le redémarrage d'un nœud prend beaucoup de temps ?

R : Plus il y a de fichiers dans votre cluster, plus le redémarrage d'un nœud prend de temps. Dans ce cas, vous pouvez définir le paramètre innodb_fast_startup sur ON pour accélérer le redémarrage. Pour plus d'informations sur la modification des paramètres, consultez Définir les paramètres du cluster et des nœuds.