Scuola di Ingegneria e Architettura, Bologna, 17 Marzo 2015 Studio di tecniche di alta disponibilità e replicazione di DBMS e applicazioni in ambiente PostgreSQL. Candidato: Simone Dalla Relatore: Prof. Marco Prandini 

ALTA DISPONIBILITÁÁ assicurare la continuità del servizio a fronte di fallimenti di componenti del sistema REPLICAZIONE migliorare la fault-tolerance, la sicurezza del dato e l’affidabilità dell’intero sistema 

PostgreSQL ● relational database management system ● offre molte delle funzionalità dei DBMS ● open source ● diffusione http://db-engines.com/en/ranking 

PostgreSQL @ Comune di Zola Predosa ● usato dal 2007 con ottimi risultati ● gestisce l’80% delle basi di dati ● database dei gestionali principali: ○ servizi demografici ○ servizi tributari ○ protocollo ○ atti comunali, determine e delibere ○ sito web trasparenza ○ tutti gli applicativi web based sviluppati internamente 

Alta Disponibilità @ Comune di Zola Predosa Vmware vSphere Vmware HA Vmware DRS Vmware vMotion http://www.vmware.com/files/pdf/VMware-High-Availability-DS-EN.pdf CLUSTER VMWARE 3 Server Fisici 1 SAN Fiber Channel ~8TB NAS ~20TB BACKUP BACKUP 

Obiettivo della tesi CLUSTER VMWARE POSTGRESQL CLUSTER POSTGRESQL ALTA DISPONBILITÁ e REPLICAZIONE a LIVELLO APPLICATIVO POSTGRESQL POSTGRESQL 

TRANSACTION LOG TRANSACTION LOG DATA FILES CONFIG FILES LOG SHIPPING (spedizione del log) DATA FILES CONFIG FILES PostgreSQL Master PostgreSQL Slave STANDBY ● struttura dati più importante più importante di PostgreSQL ● può essere visto come nastro di modifiche binarie ● le modifiche sono scritte SEMPRE PRIMA nel transaction log e POI nelle tabelle (file system) Transaction Log e Replicazione 

Replicazione, Log Shipping ● Asincrona File-Based ● Asincrona Streaming ● Sincrona Streaming 

Slave Hot Standby LOG SHIPPING PostgreSQL Master PostgreSQL Slave HOT STANDBY REPLICA QUERY LETTURA (SELECT) QUERY SOLA LETTURA (SELECT) QUERY SCRITTURA (INSERT, UPDATE, CREATE..) LOAD BALANCING MANUALE 

Failover LOG SHIPPING PostgreSQL Master PostgreSQL Hot Standby QUERY LETTURA (SELECT) QUERY SOLA LETTURA (SELECT) QUERY SCRITTURA (INSERT, UPDATE, CREATE..) 1) FALLIMENTO MASTER 2) PROMOZIONE 3) MASTER 4) QUERY SCRITTURA (INSERT, UPDATE, CREATE..) Processo di Promozione: - pg_ctl promote - trigger file 

Scenario Capitolo 6 ● Replicazione sincrona streaming ● Finestra perdita dati ~ 0 ● Failover manuale (trigger file) ● Load balacing query manuale ● Recovery/Failback manuale Scenario Capitolo 8 ● Alta disponibilità ● Replicazione asincrona streaming ● Finestra perdita dati ~ multiplo di 8Kb ● Failover automatico ● Connection pooling ● Load balacing query automatico ● Hot Recovery gestito ● Failback gestito (potenzialmente automatizzabile) Scenario Capitolo 5 ● Replicazione asincrona streaming ● Finestra perdita dati ~ multiplo di 8Kb ● Failover manuale (trigger file) ● Load balacing query manuale ● Recovery/Failback manuale Evoluzione degli scenari Scenario Capitolo 4 ● Replicazione asincrona file-based ● Finestra perdita dati ~ multiplo di 16Mb ● Failover manuale (trigger file) ● Load balacing query manuale ● Recovery/Failback manuale 

Scenario Capitolo 4 PostgreSQL Master hostname: pg4master ip: 192.168.59.201 PostgreSQL Hot Standby hostname: pg4slave ip: 192.168.59.202 archivio XLOG: /home/postgres/archive/ transaction log cp transaction log restoring XLOG... RSYNC - LOG SHIPPING: REPLICAZIONE ASINCRONA FILE-BASED - FAILOVER (TRIGGER FILE) - RECOVERING/FAILBACK MANUALE - LOAD BALANCING QUERY MANUALE Finestra perdita dati ~ multiplo di 16Mb 

Scenario Capitolo 5 PostgreSQL Master hostname: pg5master ip: 192.168.59.201 PostgreSQL Hot Standby hostname: pg5slave ip: 192.168.59.202 - LOG SHIPPING: REPLICAZIONE ASINCRONA STREAMING - FAILOVER (TRIGGER FILE) - RECOVERING/FAILBACK MANUALE - LOAD BALANCING QUERY MANUALE transaction log processo WAL SENDER processo WAL RECEIVER transaction log connessione tcp restoring XLOG... Finestra perdita dati ~ multiplo di 8KB 

Scenario Capitolo 6 PostgreSQL Master hostname: pg6master ip: 192.168.59.201 - LOG SHIPPING: REPLICAZIONE SINCRONA STREAMING - FAILOVER (TRIGGER FILE) - RECOVERING/FAILBACK MANUALE - LOAD BALANCING QUERY MANUALE transaction log processo WAL SENDER processo WAL RECEIVER transaction log PostgreSQL Hot Standby hostname: pg6slave1 ip: 192.168.59.211 transaction log processo WAL RECEIVER PostgreSQL Hot Standby hostname: pg6slave2 ip: 192.168.59.212 processo WAL SENDER conferma del commit connessione tcp Finestra perdita dati ~ 0 connessione tcp 

PgPoll-II ● middleware tra i client ed i server PostgreSQL ● connection pooling ● integrazione con replicazione streaming ● gestione del load balancing ● failover automatico di server hot standby ● online recovery di server hot standby ● alta disponibilità con watchdog ● open source 

Scenario Capitolo 8 

Conclusioni Scenario 8 @ Comune di Zola Predosa ● uso di macchine virtuali (suddivisione dei servizi) ● NO replicazione sincrona (problemi di prestazioni e storage!!!) ● SI replicazione asincrona (ottime prestazioni, completa integrazione per implementare replica asincrona a cascata in un secondo sito di disaster recovery, incremento sicurezza del dato) ● alta disponibilità (continuità di servizio ed eliminazione dei “single point of failure” ) ● load balacing (incremento prestazioni) ● pooling delle connessioni (riduzione carico sui server PostgreSQL e incremento prestazioni) ● failover automatico e recovery “a caldo” (aumento della fault-tolerance) 

Grazie dell’attenzione!