PostgreSQL in ambienti a disponibilità elevata
PostgreSQL 10 deve sincronizzare i dati in tutti i nodi per ciascun nodo in modo che siano correnti quando riceve le richieste di lettura o scrittura. Non esiste una soluzione singola per eliminare i potenziali problemi di sincronizzazione, pertanto è necessario considerare molti aspetti legati alla disponibilità elevata. Un confronto delle soluzioni a disponibilità elevata per PostgreSQL 10 è disponibile come elenco in formato tabella qui:
https://www.postgresql.org/docs/10/different-replication-solutions.html.
Nel diagramma riportato di seguito viene illustrata la configurazione di PTC consigliata per una distribuzione a disponibilità elevata di PostgreSQL.
PostgreSQL
ThingWorx può scrivere una grande quantità di contenuto nel proprio database ed è importante mantenere inalterata la sequenza di scrittura in tutti i nodi PostgreSQL. PTC consiglia di configurare tutti i nodi PostgreSQL per la replica sincrona all'interno di un'architettura di replica a cascata, utilizzando le limitazioni imposte alla replica sincrona. Questa opzione presenta i requisiti indicati di seguito.
• È necessario distribuire tre nodi server PostgreSQL di dimensioni uguali.
◦ Un nodo, che deve essere il master, a cui sono indirizzate le richieste di scrittura. Il master trasmette i record WAL a un nodo di standby ed esegue il commit delle transazioni solo quando il nodo di standby lo riconosce.
◦ Un nodo di standby per ricevere il contenuto trasmesso dal master. Anche questo nodo trasmette il contenuto a un secondo nodo di standby.
◦ Un nodo di standby aggiuntivo per ricevere il contenuto trasmesso dal primo nodo di standby. In caso di errore di un nodo o se un nodo passa in modalità non in linea, questo nodo sarà uno dei due rimanenti e completerà comunque il processo di streaming master-standby riconosciuto.
Pgpool-II
Per completare la configurazione a disponibilità elevata di PostgreSQL, è necessario indirizzare le richieste di scrittura e di lettura al nodo appropriato, monitorare lo stato di integrità dei nodi e mantenere non in linea i nodi non integri per ripararli. PTC consiglia a Pgpool-II di eseguire questi task. Questa opzione presenta i requisiti indicati di seguito.
• È necessario distribuire due nodi server Pgpool di dimensioni uguali. Tali nodi operano in modalità attiva/passiva.
◦ Un nodo funziona come master. Indirizza il traffico di scrittura al nodo master di PostgreSQL e legge il traffico al nodo di standby di PostgreSQL.
◦ Un nodo da utilizzare come standby. In caso di errore del nodo master Pgpool, si occupa della distribuzione del traffico.
• Un indirizzo IP virtuale che deve essere gestito dai nodi Pgpool-II. Il master utilizzerà questo indirizzo per ricevere il traffico PostgreSQL dai client.
Note su Pgpool-II
• Pgpool-II non è supportato in un ambiente Windows.
• Le implementazioni cloud di PostgreSQL possono utilizzare un meccanismo di failover DNS diretto anziché pgpool-II.
• È possibile eseguire un processo Pgpool-II sullo stesso server dell'applicazione ThingWorx per ridurre il numero totale di server in un ambiente a disponibilità elevata.
• PTC sconsiglia l'uso di Pgpool-II per la gestione della replica PostgreSQL. Le indicazioni fornite in questo documento utilizzano la replica di streaming di PostgreSQL e Pgpool-II per l'instradamento del traffico, il monitoraggio dello stato dei nodi e l'automazione del failover.