In PostgreSQL non esiste alcun comando o strumento di controllo della coerenza incorporato.
L'opinione generale è che non dovrebbe essere necessario, poiché corruzione e incoerenza non dovrebbero essere possibili su uno stack hardware / software di qualità. Se sorgono problemi, non vi è alcuna garanzia che qualsiasi tipo di controllo di coerenza li trovi, quindi creerebbe un falso senso di sicurezza. Non sono d'accordo con quel sentimento, ma è ciò che sembra emergere quando questo viene periodicamente discusso su pgsql-hacker.
Come al solito, il problema di fondo è che nessuno ha particolarmente bisogno di uno strumento di controllo della coerenza per soddisfare i propri bisogni immediati, quindi nessuno sta spendendo il tempo per scriverne uno per grattarsi un prurito e nessuno sta finanziando lo sviluppo di uno su un contratto commerciale o interno. Volontariato? : p
PostgreSQL (fino alla 9.3) non supportava checksum a livello di blocco. Quindi una delle cose principali che sei abituato a verificare non esisteva e quindi non poteva essere verificata. Uno strumento per scansionare tutte le relazioni e validare i checksum non esiste in PostgreSQL 9.3, ma sarebbe desiderabile aggiungerlo e potrebbe apparire in una versione futura. Nel frattempo tutto ciò che puoi fare è SELECT *individualmente da ogni relazione, ma a causa del fatto che PostgreSQL utilizza la cache del buffer del sistema operativo per le letture, non esiste alcuna garanzia che forzerà comunque una lettura del blocco del disco sottostante. Per fare questo sarebbe necessario un nuovo strumento.
PostgreSQL tende a evitare la memorizzazione ridondante di informazioni laddove possibile, quindi spesso non c'è nulla da controllare, solo una singola fonte autorevole. Un controllo di coerenza non può fare molto a meno che le stesse informazioni non vengano visualizzate o derivino da più luoghi diversi.
È anche molto difficile eseguire qualsiasi tipo di controllo utile contemporaneamente, su un database che è ancora occupato e attivo. La maggior parte delle installazioni non sarà disposta a bloccare l'intero database, o almeno diverse relazioni importanti alla volta, per eseguire una sorta di controllo di coerenza. Pertanto, il correttore dovrebbe essere in grado di operare su un database soggetto a modifiche simultanee, rendendo ancora più difficile la scrittura e in grado di rilevare meno problemi in modo affidabile.
C'è ancora molto che uno strumento di validazione potrebbe fare se uno fosse scritto, specialmente se gli fosse permesso di eseguire blocchi esclusivi con più relazioni:
Verificare che tutti i tablespace siano presenti sul disco.
Verificare che ogni pg_classvoce abbia file corrispondenti al suo relfilenodenello spazio tabella corretto.
Ispeziona mappe di visibilità, mappe dello spazio libero, ecc., Assicurandoti che siano presenti quando dovrebbero essere, leggibili e che sembrino corrispondere alla relazione a cui sono associati.
Segnala nodi di file su disco orfani. (Questi sono normali a causa di DDL transazionale e scollegamento pigro, ma un controllore potrebbe forzare lo scollegamento desideroso e bloccare tutte le relazioni prima di eseguire il controllo).
Leggi ogni blocco di ogni relazione e cerca ovvi problemi. Per le relazioni heap che sarebbero cose come:
- un
xminmaggiore di xmax(dopo aver considerato xid avvolgente)
- Tuple create dalle transazioni in futuro
- catene HOT rotte / catene ctid rotte
- tuple strutture che non corrispondono agli attributi della tabella
- qualsiasi Datum che non effettua il round trip
_ine _outfunziona invariato o genera un errore
NULLcampi bitmap impostati sugli NOT NULLattributi di tabella- La riesecuzione dei
CHECKvincoli non riesce
Ricontrollare i vincoli di esclusione e chiave esterna dopo aver bloccato tutte le tabelle interessate
... e probabilmente molto di più che non conosco abbastanza a fondo del fegato di Pg da capire, come tentativi di rilevare pagine strappate, convalida della struttura b-tree, controllo di integrità GIN e indici GiST, controllo di integrità pg_controle altro che non vorrei sapere da dove cominciare.
Se sei interessato ad avere uno strumento del genere, la cosa migliore da fare è imparare abbastanza da elaborare una proposta concreta su come dovrebbe funzionare e trovare il tempo per lavorarci su o per finanziare gli altri per trascorrere del tempo sviluppo.
Personalmente sarei davvero abbastanza felice di avere qualcosa che potesse controllare un cluster di database arrestato usando una modalità di avvio speciale per il postgresback - end, quindi potrei (in qualche modo) convalidare le copie del database fisico prese con pg_basebackup, con pg_start_backup(), rsync e pg_stop_backup, con il livello del file system istantanee atomiche, ecc.
In alternativa, puoi fare ciò che fanno la maggior parte degli altri: assicurati che lo stack hardware e software sia solido e correttamente configurato, mantenga buoni backup e monitori i tuoi registri. Non c'è sostituto per il corretto test dell'intero stack prima della messa in servizio di un server e per buoni backup, sia fisici (streaming / PITR) che logici (dump). Esegui test plug-pull su un database caricato - ripetutamente - prima di andare in diretta per assicurarti che il tuo sottosistema I / O apparentemente affidabile lo sia davvero. Utilizzare più forme di backup.