Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Studio di tecniche di alta disponibilità e repl...

Studio di tecniche di alta disponibilità e replicazione di DBMS e applicazioni in ambiente PostgreSQL.

Presentazione illustrata il 17/03/2015 durante la discussione della tesi di laurea "Studio di tecniche di alta disponibilità e replicazione di DBMS e applicazioni in ambiente PostgreSQL."

Simone Dalla

March 17, 2015
Tweet

More Decks by Simone Dalla

Other Decks in Technology

Transcript

  1. 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
  2. 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
  3. PostgreSQL • relational database management system • offre molte delle

    funzionalità dei DBMS • open source • diffusione http://db-engines.com/en/ranking
  4. 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
  5. 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
  6. Obiettivo della tesi CLUSTER VMWARE POSTGRESQL CLUSTER POSTGRESQL ALTA DISPONBILITÁ

    e REPLICAZIONE a LIVELLO APPLICATIVO POSTGRESQL POSTGRESQL
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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)