ApsaraDB RDS:FAQ sur le proxy de base de données

Contenu

• Qu'est-ce qu'un proxy de base de données ?

• Quelle est la différence entre les proxies généralistes et dédiés ?

• Un proxy de base de données utilise-t-il les QPS ou TPS de l'instance principale ?

• Un endpoint de proxy de base de données est-il identique à un endpoint d'instance classique ?

• Après avoir activé le proxy de base de données, les endpoints d'origine des instances principales et en lecture seule sont-ils récupérés ?

• Le type de réseau interne d'un proxy de base de données est-il le même que celui de l'instance principale ?

• Quelle architecture les proxies de base de données utilisent-ils ? Le basculement est-il pris en charge ?

• Quelle est la relation entre la spécification du proxy et la spécification du nœud de proxy ?

• Quelle est la relation entre le nombre de nœuds de proxy et la spécification du proxy ?

• Quelles sont les limites relatives aux spécifications des nœuds de proxy ?

• Existe-t-il une relation entre le nombre de nœuds de proxy et le nombre d'endpoints de proxy ?

• Les performances d'un proxy de base de données s'améliorent-elles si j'ajoute davantage d'endpoints de proxy ?

• Un proxy de base de données limite-t-il le nombre de connexions utilisateur ?

• Que faire en cas d'erreur de délai d'expiration lors de la connexion via un endpoint de proxy de base de données ?

• Puis-je modifier un endpoint de proxy de base de données (endpoint de répartition lecture/écriture) ?

• Si l'instance principale présente une faible fréquence d'écriture, les requêtes de lecture peuvent-elles lui être envoyées ?

• La répartition lecture/écriture prend-elle en charge les indices (hints) ?

• Pourquoi la charge de chaque nœud ne correspond-elle pas aux poids de lecture configurés ?

• Si le proxy de base de données est désactivé, puis-je toujours configurer les poids de lecture pour les instances en lecture seule ?

• Si une instance en lecture seule devient indisponible, les nouvelles connexions sont acheminées vers les instances en lecture seule saines. Les connexions existantes vers l'instance défaillante basculeront-elles automatiquement ?

• Après avoir activé le proxy de base de données, comment vérifier la répartition lecture/écriture ?

• Après avoir acheté une instance en lecture seule pour la répartition lecture/écriture, les données historiques de l'instance principale sont-elles automatiquement synchronisées avec l'instance en lecture seule ?

• Quelle est la différence entre le pool de connexions dans un proxy de base de données et celui dans une application ? Comment doivent-ils être utilisés conjointement ?

• Pourquoi mes requêtes renvoient-elles des caractères illisibles ?

• Les opérations DDL sont-elles automatiquement synchronisées de l'instance principale vers les instances secondaires ?

• Si je migre des nœuds de proxy entre des zones de disponibilité, la fonctionnalité d'accès le plus proche devient-elle indisponible ?

• Puis-je modifier la zone de disponibilité lorsque je modifie la configuration du proxy ?

• Comment résoudre l'erreur « All connection endpoints' vSwitchId must be in the destination availability zone » lors du passage d'un déploiement bi-zone à un déploiement mono-zone ?

Qu'est-ce qu'un proxy de base de données ?

Un proxy de base de données est un service de proxy réseau situé entre votre base de données et vos serveurs d'application. Il transfère toutes les requêtes de votre application vers la base de données et fournit des fonctionnalités avancées telles que la répartition automatique lecture/écriture, la division des transactions, les pools de connexions et la persistance des connexions. Il est conçu pour offrir une haute disponibilité, des performances élevées ainsi qu'une utilisation et une maintenance simplifiées.

Quelle est la différence entre les proxies généralistes et dédiés ?

• general-purpose : partage les ressources CPU physiques, ce qui en fait une option économique. La spécification maximale du proxy est de 16 cœurs CPU (8 nœuds de proxy) et ce type est gratuit.

• dedicated : utilise des ressources CPU physiques exclusives, offrant une stabilité des performances accrue. La spécification maximale du proxy est de 64 cœurs CPU (32 nœuds de proxy) et ce type est facturé selon le modèle de paiement à l'utilisation.

Pour plus d'informations, consultez les rubriques Proxies généralistes et dédiés, Relation entre le nombre de nœuds de proxy et la spécification du proxy et Frais liés au proxy de base de données.

Le proxy de base de données utilise-t-il les QPS ou les TPS de l'instance principale ?

Non.

Un endpoint de proxy de base de données est-il identique à un endpoint d'instance classique ?

Non.

• Un endpoint d'instance classique achemine toutes les requêtes vers cette instance spécifique.

• Un endpoint de proxy de base de données identifie automatiquement les requêtes en lecture et en écriture en fonction de vos instructions SQL. Il transfère les requêtes en écriture vers l'instance principale et les requêtes en lecture vers les instances en lecture seule. Ce processus permet la répartition lecture/écriture et réduit la charge sur l'instance principale.

Après avoir activé le proxy de base de données, les endpoints d'origine des instances principales et en lecture seule sont-ils récupérés ?

Non.

Le type de réseau interne d'un proxy de base de données est-il identique à celui de l'instance principale ?

Le réseau interne d'un proxy de base de données est toujours un VPC.

Quelle architecture les proxys de base de données utilisent-ils ? Le basculement est-il pris en charge ?

Le proxy de base de données utilise une architecture haute disponibilité à deux nœuds principaux. Le trafic est réparti entre les deux nœuds dans un ratio de 1:1. Si un nœud tombe en panne, l'autre nœud prend en charge tout le trafic. Une tâche est automatiquement déclenchée pour reconstruire le nœud défaillant afin de maintenir la haute disponibilité.

Pour plus d'informations sur l'architecture de déploiement, consultez Architecture de déploiement du proxy.

Relation entre le proxy et les spécifications des nœuds

spécification du proxy = Somme de toutes les spécifications des nœuds de proxy

Par exemple, un proxy dédié est déployé dans une configuration à deux zones (zone de disponibilité A et zone de disponibilité B). Dans la zone de disponibilité A, il y a deux nœuds de proxy, et la spécification de chaque nœud de proxy est de 1 cœur CPU. Dans la zone de disponibilité B, il y a deux nœuds de proxy, et la spécification de chaque nœud de proxy est de 2 cœurs CPU. La spécification totale du proxy est calculée comme suit : (1 cœur CPU × 2) + (2 cœurs CPU × 2) = 2 cœurs CPU + 4 cœurs CPU = 6 cœurs CPU.

Relation entre les nœuds de proxy et la spécification

nombre de nœuds de proxy = spécification du proxy / Spécification par unité, où la spécification par unité est fixée à 2 cœurs CPU.

Par exemple, si la spécification du proxy est de 6 cœurs CPU, le nombre de nœuds de proxy est de 3 (6 / 2).

Limites des spécifications des nœuds de proxy

• La spécification d'un seul nœud de proxy varie de 1 à 8 cœurs CPU pour le type généraliste et de 1 à 16 cœurs CPU pour le type dédié.

• Tous les nœuds de proxy au sein de la même zone de disponibilité doivent avoir la même spécification.

• Dans un déploiement à deux zones avec deux nœuds, les deux nœuds doivent avoir la même spécification.

• Les nœuds de proxy dans différentes zones de disponibilité peuvent avoir des spécifications différentes. Pour les proxys généralistes, nous recommandons que les nœuds de proxy dans différentes zones de disponibilité utilisent la même spécification.

Relation entre les nœuds de proxy et les endpoints

Non.

Après avoir activé le proxy de base de données pour une instance RDS, vous pouvez créer un à sept endpoints de proxy. Pour chaque endpoint de proxy, vous pouvez créer un endpoint interne et un endpoint public. Pour plus d'informations, consultez Ajouter un endpoint de proxy.

L'ajout d'endpoints de proxy améliore-t-il les performances ?

Non.

Les performances d'un proxy de base de données dépendent du nombre d'instances en lecture seule et du nombre de nœuds de proxy (spécification du proxy) pour les instances RDS High-availability Edition. Pour les instances RDS Cluster Edition, les performances dépendent du nombre d'instances secondaires et du nombre de nœuds de proxy (spécification du proxy).

• L'augmentation du nombre d'instances en lecture seule (pour High-availability Edition) ou d'instances secondaires (pour Cluster Edition) améliore la capacité de traitement en lecture du proxy de base de données.

• L'augmentation du nombre de nœuds de proxy (spécification du proxy) améliore les performances globales du proxy de base de données.

Limites de connexion du proxy de base de données

Le proxy de base de données ne limite pas le nombre maximal de connexions. Les spécifications des nœuds de calcul de votre base de données déterminent cette limite.

Gestion des erreurs de délai d'expiration de connexion

Augmentez la valeur du paramètre wait_timeout et essayez de vous reconnecter. Pour plus d'informations sur la modification des paramètres d'instance, consultez Définir les paramètres d'une instance ApsaraDB RDS for MySQL.

Modification d'un endpoint de proxy

Oui.

Vous pouvez modifier un endpoint de proxy de base de données (endpoint de répartition lecture/écriture). Pour plus d'informations, consultez Modifier un endpoint de proxy.

Envoi de requêtes en lecture vers l'instance principale

Oui.

Vous pouvez attribuer un poids de lecture à l'instance principale lors de la configuration de la distribution des poids de lecture. Pour plus d'informations sur l'attribution d'un poids de lecture à l'instance principale, consultez Activer la fonctionnalité de proxy de base de données pour une instance ApsaraDB RDS for MySQL.

Support des hints pour la répartition lecture/écriture

Oui. Vous pouvez utiliser un hint pour forcer l'exécution d'une requête sur l'instance principale. Pour plus d'informations sur les formats de hints pris en charge par la répartition lecture/écriture RDS, consultez la section « Utiliser un hint pour spécifier si une instruction SQL doit être envoyée à une instance principale ou en lecture seule » de Règles d'allocation par défaut des poids de lecture.

Les poids de lecture modifiés ne prennent pas effet

Après avoir modifié les poids de lecture, seules les nouvelles connexions sont distribuées selon les nouveaux poids. Les connexions existantes ne sont pas affectées.

Déséquilibre de charge avec les poids de lecture

Si la distribution de la charge entre les nœuds ne correspond pas aux poids de lecture configurés, vérifiez les points suivants :

• Vérifiez si vos requêtes font partie d'une transaction. Toutes les requêtes au sein d'une transaction sont acheminées vers l'instance principale. Vous pouvez activer le fractionnement des transactions pour réduire la charge sur l'instance principale.

• Assurez-vous que vous vous connectez exclusivement via un endpoint de proxy de base de données. Les connexions établies à l'aide des endpoints d'instance principale ou en lecture seule contournent la distribution des poids de lecture.

Configuration des pondérations de lecture sans proxy de base de données

Si le proxy de base de données est désactivé, vous ne pouvez pas configurer les pondérations de lecture pour les instances en lecture seule. Toutefois, vous pouvez toujours mettre en œuvre la répartition lecture/écriture et l'équilibrage de charge en utilisant les endpoints distincts des instances principales et en lecture seule directement dans le code de votre application.

Basculement de connexion pour les instances en lecture seule indisponibles

Non, les connexions existantes vers l'instance défaillante ne basculent pas automatiquement. Une nouvelle connexion vers une instance saine n'est établie qu'après l'expiration du délai de la connexion défaillante.

Comment vérifier la répartition lecture/écriture après avoir activé le service de proxy de base de données ?

Consultez la rubrique Vérification de la répartition lecture/écriture.

Synchronisation automatique des données vers les nouvelles instances en lecture seule

Oui. Lorsque vous activez le proxy de base de données pour la répartition lecture/écriture, les données historiques sont automatiquement synchronisées de l'instance principale vers l'instance en lecture seule. Aucune intervention manuelle n'est requise.

Pool de connexions du proxy par rapport au pool de connexions de l'application

Le proxy de base de données fournit un pool de connexions au niveau du proxy, indépendant du pool côté client de votre application. Si votre application utilise déjà un pool de connexions, l'utilisation du pool de connexions du proxy est inutile. Pour plus d'informations sur le pool de connexions du proxy de base de données, consultez la rubrique Configuration d'un pool de connexions.

Gestion des caractères illisibles dans les résultats de requête

Exécutez la commande suivante pour vérifier si les jeux de caractères utilisés par l'instance principale et les instances en lecture seule sont cohérents :

select 
@@global.character_set_results, 
@@global.character_set_client, 
@@global.character_set_connection, 
@@global.character_set_server;

Si les jeux de caractères ne sont pas cohérents, des caractères illisibles peuvent apparaître. Vous pouvez modifier le jeu de caractères de l'instance principale ou d'une instance en lecture seule afin d'assurer leur cohérence. Pour plus d'informations sur la modification des jeux de caractères des instances, consultez la rubrique Jeux de caractères des instances ApsaraDB RDS for MySQL.

Synchronisation automatique des instructions DDL

Oui. Toutes les opérations DDL, telles que la création ou la suppression de bases de données et de tables, la modification des structures de table et la mise à jour des autorisations, sont automatiquement synchronisées de l'instance principale vers ses instances secondaires.

Affichage de l'ID VPC et de l'ID vSwitch

Sur la page Database proxy de votre instance, accédez à la section Connection information . Pour afficher les informations, placez le pointeur sur l'icône située à droite du champ Port , comme illustré dans la figure suivante.

Impact de la migration inter-zones sur l'instance principale

La migration des nœuds de proxy entre zones de disponibilité affecte uniquement les charges de travail qui utilisent un endpoint de proxy de base de données. Les connexions établies via l'endpoint de l'instance principale, un endpoint d'instance en lecture seule, un endpoint de cluster en lecture/écriture, un endpoint de cluster en lecture seule ou un endpoint au niveau du nœud ne sont pas affectées. Pour minimiser l'impact, basculez vos charges de travail vers un endpoint non affecté et effectuez la migration pendant les heures creuses.

Impact de la migration inter-zones du proxy

Lorsque vous migrez un proxy entre zones de disponibilité, les connexions utilisant le proxy de base de données peuvent subir une déconnexion transitoire d'environ 30 secondes. La durée réelle de l'impact dépend de votre charge de travail. Pour minimiser l'impact, basculez vos charges de travail vers un endpoint non affecté et effectuez la migration pendant les heures creuses. Pour plus d'informations, consultez la rubrique Migration des proxys de base de données entre zones.

Impact de la migration inter-zones sur l'accès le plus proche

Cette fonctionnalité peut devenir indisponible.

Modification de la zone de disponibilité lors de la configuration

Non.

Si vous devez migrer vers une autre zone de disponibilité, consultez la rubrique Migration des proxys de base de données entre zones.

Résolution de l'erreur vSwitchId dans un déploiement mono-zone

Lors du passage d'un déploiement bi-zone (par exemple, dans la zone de disponibilité 1 et la zone de disponibilité 2) à un déploiement mono-zone (par exemple, dans la zone de disponibilité 1), vous devez d'abord supprimer l'endpoint du proxy de base de données dans la zone de disponibilité 2. Pour plus d'informations, consultez la rubrique Modification d'un endpoint de proxy.

Les adresses IP résolues du proxy sont-elles fixes ?

Non. Utilisez toujours l'endpoint du proxy de base de données (par exemple, d3pswqe3jk9xwc5d****-rw4rm.rwlb.rds.aliyuncs.com) pour vous connecter, et non l'adresse IP résolue.

Vérification des connexions via un endpoint de proxy

Vous pouvez identifier la méthode de connexion grâce à l'ID de session. Un ID de session inférieur à 16777215 indique une connexion via un endpoint d'instance. Un ID supérieur indique une connexion via un endpoint de proxy de base de données.

Les ID de session sont visibles dans la section Gestion des sessions.

Données non visibles immédiatement après les écritures

Cause courante : ce phénomène se produit lorsque le proxy achemine votre requête de lecture vers une instance en lecture seule dont la réplication accuse un retard par rapport à l'instance principale.

Solutions :

• Utilisation d'un indice : pour les requêtes nécessitant une forte cohérence en lecture, utilisez l'indice /*FORCE_MASTER*/ pour acheminer la requête vers l'instance principale.

• Désactivation du fractionnement des transactions et encapsulation des requêtes nécessitant une forte cohérence en lecture au sein d'une transaction.

• Définition du niveau de cohérence sur la cohérence globale.