Haute disponibilité PostgreSQL
PostgreSQL 10 doit synchroniser ses données sur tous les noeuds pour que chaque noeud soit à jour lorsqu'il reçoit des requêtes de lecture ou d'écriture. Pour éliminer les problèmes de synchronisation potentiels, il n'existe pas une solution unique. C'est pourquoi vous avez l'embarras du choix en matière d'options HA. Une table de comparaison des solutions HA pour PostgreSQL 10 est accessible à l'adresse suivante :
https://www.postgresql.org/docs/10/different-replication-solutions.htmll.
Le diagramme suivant illustre la configuration recommandée de PTC pour un déploiement de PostgreSQL haute disponibilité.
PostgreSQL
ThingWorx peut écrire une grande quantité de contenu dans sa base de données et il est important que la séquence d'écriture demeure intacte sur tous les noeuds PostgreSQL. PTC vous recommande de configurer tous les noeuds PostgreSQL pour la réplication synchrone dans une architecture de réplication en cascade, en respectant les limitations imposées par la réplication synchrone. Cette option présente les exigences suivantes :
• Trois noeuds de serveur PostgreSQL de taille égale doivent être déployés.
◦ Un noeud maître auquel les requêtes d'écriture sont adressées. Le noeud maître transmet les enregistrements WAL à un noeud de secours et ne committent les transactions qu'après confirmation du noeud de secours.
◦ Un noeud de secours pour recevoir le contenu transmis par le maître. Il transmet également son contenu à un deuxième noeud de secours.
◦ Un noeud de secours supplémentaire pour recevoir le contenu transmis par le premier noeud de secours. En cas de défaillance ou de déconnexion d'un noeud, ce deuxième noeud de secours sera l'un des deux noeuds restants et poursuivra le processus de confirmation de la transmission de données du noeud maître au noeud de secours.
Pgpool-II
Pour terminer la configuration de PostgreSQL haute disponibilité, les requêtes d'écriture et de lecture doivent être dirigées vers le noeud approprié, l'intégrité des noeuds doit être surveillée et les noeuds non sains doivent être mis hors ligne et réparés. PTC recommande d'utiliser Pgpool-II pour effectuer ces tâches. Cette option présente les exigences suivantes :
• Deux noeuds de serveur Pgpool de taille égale doivent être déployés avec un fonctionnement actif/passif.
◦ Un noeud doit être désigné maître. Il dirige le trafic d'écriture vers le noeud maître PostgreSQL et le trafic de lecture vers le noeud de secours PostgreSQL.
◦ Un noeud doit être désigné comme noeud de secours. Il prend en charge la distribution du trafic en cas de défaillance du noeud maître Pgpool.
• Une adresse IP virtuelle doit être gérée par les noeuds Pgpool-II. Le maître utilise cette adresse pour recevoir le trafic PostgreSQL des clients.
Notes sur Pgpool-II :
• Pgpool-II n'est pas pris en charge dans un environnement Windows.
• Les implémentations Cloud de PostgreSQL peuvent utiliser un mécanisme de basculement DNS direct au lieu de Pgpool-II.
• Vous pouvez exécuter un processus Pgpool-II sur le même serveur que l'application ThingWorx pour réduire le nombre total de serveurs dans un environnement HA.
• PTC ne recommande pas l'utilisation de Pgpool-II pour la gestion de la réplication PostgreSQL. Les instructions fournies dans ce document utilisent la réplication en streaming de PostgreSQL et Pgpool-II pour le routage du trafic, le contrôle de l'intégrité des noeuds et l'automatisation du basculement.