Lorsque le trafic en lecture augmente, un nœud primaire unique devient un goulot d'étranglement. Les clusters PolarDB for PostgreSQL intègrent nativement la séparation des lectures et écritures via PolarProxy : lors d'une connexion par un endpoint de cluster configuré en mode Read and Write (Automatic Read-write Splitting), le cluster dirige automatiquement les requêtes d'écriture vers le nœud primaire et les requêtes de lecture vers les nœuds en lecture seule, sans modification de l'application.
Cas d'usage
Volume élevé de lectures : Déchargez les requêtes analytiques, les tâches de reporting et les opérations de recherche sur les nœuds en lecture seule pour libérer le nœud primaire dédié aux écritures.
Mise à l'échelle élastique : Ajoutez des nœuds en lecture seule afin d'augmenter le débit de lecture sans modifier votre application ni vos chaînes de connexion.
Cohérence des lectures au sein d'une session : Assurez-vous que les lectures d'une même session reflètent les dernières écritures validées, même si les requêtes sont réparties sur plusieurs nœuds.
Fonctionnement du routage
PolarProxy intercepte tout le trafic transitant par l'endpoint de cluster et achemine chaque requête selon son type :
| Type de requête | Destination |
|---|---|
| Instructions d'écriture (INSERT, UPDATE, DELETE, DDL) | Nœud primaire |
| Instructions de lecture (SELECT) | Nœud en lecture seule |
| Instructions au sein d'une transaction | Nœud primaire |
| Fonctions comportant des écritures ou des opérations mixtes | Nœud primaire |
| Fonctions en lecture seule, y compris personnalisées | Nœud en lecture seule |
| Instructions PREPARE avec écritures + EXECUTE associées | Nœud primaire uniquement |
| Instructions PREPARE en lecture seule | Diffusion à tous les nœuds ; EXECUTE acheminé selon la charge |
Composant natif du cluster, PolarProxy induit moins de latence qu'un proxy externe ou qu'une solution middleware tierce.
Cohérence des lectures au niveau de la session
Au cours d'une session, PolarProxy sélectionne un nœud selon l'état de synchronisation des données de chacun, garantissant ainsi que les lectures reflètent toujours les dernières écritures validées. L'équilibrage de charge entre les nœuds reprend ensuite normalement durant la session.
Vérifications de l'état des nœuds
PolarProxy surveille en permanence l'ensemble des nœuds. Si un nœud tombe en panne ou si sa latence dépasse le seuil configuré, PolarProxy cesse de lui envoyer des requêtes de lecture et redistribue le trafic d'écriture et de lecture vers les nœuds sains. Le cluster reste accessible même en cas d'indisponibilité d'un nœud en lecture seule. Dès son rétablissement, PolarProxy réintègre automatiquement le nœud dans le pool de routage.
Remplacer le routage par des hints SQL
Ajoutez /*FORCE_MASTER*/ ou /*FORCE_SLAVE*/ immédiatement avant une instruction SQL pour outrepasser le routage par défaut :
-- Default: routed to a read-only node
SELECT * FROM test;
-- Force to primary node
/*FORCE_MASTER*/ SELECT * FROM test;
-- Force to a read-only node
/*FORCE_SLAVE*/ SELECT * FROM test;Limites
Méthode de connexion non prise en charge :
L'endpoint de cluster ne prend pas en charge la connexion via la méthode en mode réplication. Pour mettre en place un cluster à deux nœuds basé sur une architecture de réplication primaire/secondaire, utilisez directement l'endpoint du nœud primaire.
Ressources temporaires créées par des fonctions :
L'interrogation d'une table temporaire créée au sein d'une fonction peut renvoyer une erreur indiquant que la table n'existe pas.
Si une fonction contient une instruction PREPARE, l'exécution de l'instruction EXECUTE associée peut générer une erreur signalant que le nom de l'instruction PREPARE est introuvable.
Syntaxe non prise en charge :
L'utilisation du nom d'une table temporaire pour déclarer l'attribut %ROWTYPE n'est pas prise en charge. Exemple :
CREATE TEMP TABLE fullname (first text, last text);
SELECT '(Joe,von Blow)'::fullname, '(Joe,d''Blow)'::fullname;Routage des transactions :
Toutes les instructions d'une transaction sont acheminées vers le nœud primaire. L'équilibrage de charge reprend une fois la transaction terminée.
Configurer un endpoint de cluster
Pour créer un endpoint de cluster personnalisé, consultez Configurer PolarProxy.
Pour modifier un endpoint de cluster existant, consultez Configurer PolarProxy.
Une fois l'endpoint de cluster créé, configurez-le dans votre application pour activer la séparation automatique des lectures et écritures. Aucune autre modification côté application n'est nécessaire.
Étapes suivantes
Séparation des transactions — contrôlez la répartition des transactions entre les nœuds
Niveaux de cohérence — configurez la garantie de cohérence adaptée à votre charge de travail
Référence API
| API | Description |
|---|---|
| CreateDBEndpointAddress | Crée un endpoint public pour un cluster PolarDB |
| DescribeDBClusterEndpoints | Interroge les informations relatives aux endpoints d'un cluster PolarDB |
| ModifyDBClusterEndpoint | Modifie la configuration d'un endpoint de cluster |
| ModifyDBEndpointAddress | Modifie un endpoint d'un cluster PolarDB |
| DeleteDBEndpointAddress | Libère l'endpoint public de l'endpoint primaire, de l'endpoint de cluster par défaut ou d'un endpoint de cluster personnalisé pour un cluster PolarDB |