“È paradossale, ma vero, dire che più sappiamo, più diventiamo ignoranti in senso assoluto, perché è solo attraverso l'illuminazione che diventiamo consapevoli dei nostri limiti. Proprio uno dei risultati più gratificanti dell'evoluzione intellettuale è la continua apertura di nuove e maggiori prospettive». Nikola Tesla
PostgreSQL è un progetto fantastico e si evolve a un ritmo incredibile. Ci concentreremo sull'evoluzione delle capacità di tolleranza agli errori in PostgreSQL in tutte le sue versioni con una serie di post sul blog.
PostgreSQL in breve
PostgreSQL è tollerante ai guasti per sua natura. Innanzitutto, è un avanzato sistema di gestione di database open source e quest'anno festeggerà il suo 20° compleanno. Quindi è una tecnologia collaudata e ha una comunità attiva, grazie alla quale ha un rapido progresso di sviluppo.
PostgreSQL è conforme a SQL (SQL:2011) e completamente conforme ad ACID (atomicità, consistenza, isolamento, durabilità).
PostgreSQL consente la replica fisica e logica e dispone di soluzioni di replica fisica e logica integrate. Parleremo dei metodi di replica (nei prossimi post del blog) in PostgreSQL per quanto riguarda la tolleranza agli errori.
PostgreSQL consente transazioni sincrone e asincrone, PITR (Point-in-time Recovery) e MVCC (controllo della concorrenza multiversione). Tutti questi concetti sono legati alla tolleranza agli errori a un certo livello e cercherò di spiegare i loro effetti mentre spiego i termini necessari e le loro applicazioni in PostgreSQL.
PostgreSQL è robusto!
Tutte le azioni sul database vengono eseguite all'interno di transazioni , protetto da un registro delle transazioni che eseguirà il ripristino automatico del crash in caso di errore del software.
I database possono essere creati facoltativamente con checksum dei blocchi di dati per aiutare a diagnosticare i guasti hardware. Esistono più meccanismi di backup, con PITR completo e dettagliato, in caso di necessità di un ripristino dettagliato. Sono disponibili numerosi strumenti diagnostici.
La replica del database è supportata in modo nativo. Replica sincrona può fornire più di "5 Nines" (99,999 percento) disponibilità e protezione dei dati, se opportunamente configurati e gestiti.
Considerando i fatti sopra, possiamo facilmente affermare che PostgreSQL è robusto!
Tolleranza agli errori di PostgreSQL:WAL
La registrazione in anticipo è il principale sistema di tolleranza agli errori per PostgreSQL.
Il WAL consiste in una serie di file binari scritti nella sottodirectory pg_xlog della directory dei dati di PostgreSQL. Ogni modifica apportata al database viene prima registrata in WAL, da cui il nome log “write-ahead”, sinonimo di “log delle transazioni”. Quando viene eseguito il commit di una transazione, il comportamento predefinito e sicuro consiste nel forzare i record WAL su disco.
In caso di arresto anomalo di PostgreSQL, verrà riprodotto il WAL, che riporta il database al punto dell'ultima transazione impegnata e garantisce quindi la durabilità di eventuali modifiche al database.
Transazione? Impegnarsi?
Le modifiche al database stesse non vengono scritte su disco al momento del commit della transazione. Tali modifiche vengono scritte su disco in un secondo momento dall'autore in background o dal checkpointer su un server ben ottimizzato. (Controlla la descrizione WAL sopra. )
Le transazioni sono un concetto fondamentale di tutti i sistemi di database. Il punto essenziale di una transazione è che raggruppa più passaggi in un'unica operazione "tutto o niente".
Gli stati intermedi tra i passaggi non sono visibili ad altre transazioni simultanee e se si verifica un errore che impedisce il completamento della transazione, nessuno dei passaggi influisce affatto sul database. PostgreSQL non supporta letture sporche (transazione legge i dati scritti da una transazione simultanea non impegnata ).
Punto di controllo
Il ripristino da crash riproduce il WAL, ma da quale punto inizia il ripristino?
Il ripristino inizia da punti nel WAL noti come punti di controllo . La durata del ripristino in caso di arresto anomalo dipende dal numero di modifiche nel registro delle transazioni dall'ultimo checkpoint. Un checkpoint è un punto di partenza sicuro noto per il ripristino, poiché garantisce che tutte le modifiche precedenti al database siano già state scritte su disco.
Un checkpoint può essere immediato o programmato . I checkpoint immediati vengono attivati da qualche azione di un superutente, come il CHECKPOINT comando o altro; i checkpoint programmati vengono decisi automaticamente da PostgreSQL.
Conclusione
In questo post del blog abbiamo elencato importanti funzionalità di PostgreSQL correlate alla tolleranza agli errori in PostgreSQL. Abbiamo menzionato la registrazione write-ahead, la transazione, il commit, i livelli di isolamento, i checkpoint e il ripristino da crash. Continueremo con la replica PostgreSQL nel prossimo post del blog.
Riferimenti:
Documentazione PostgreSQL
Ricettario amministrativo di PostgreSQL 9 – Seconda edizione
