Quali sono i segnali di avvertimento che indicano che un container di database è stato danneggiato da un’interruzione di corrente?
Sospetta una corruzione quando il database non riesce a completare il normale ripristino dopo un arresto anomalo o segnala successivamente incongruenze relative a checksum, pagine, sequenze di log, tabelle o indici.
Un arresto non corretto non significa automaticamente che il database sia corrotto; PostgreSQL, MySQL, MariaDB e motori simili utilizzano journal o log write-ahead proprio per recuperare lo stato sottoposto a commit. Il limite di allerta si presenta quando il ripristino si ripete, il motore si chiude, la stessa query raggiunge pagine non valide, i checksum non corrispondono, le tabelle scompaiono, gli indici contraddicono i dati delle tabelle oppure i backup e i controlli di integrità non riescono a leggere il cluster in modo coerente.
Distingui il normale ripristino dopo un arresto anomalo da un ciclo di ripristino
Conserva il primo log di avvio dopo il ritorno dell'alimentazione. Registra se il motore riproduce i log una sola volta e diventa pronto, oppure se si riavvia continuamente, entra in modalità di ripristino forzato o si arresta sempre sullo stesso record o sulla stessa pagina.
InnoDB può segnalare il ripristino di possibili pagine scritte solo parzialmente dopo un'interruzione della scrittura; il messaggio indica che il motore sta tentando un ripristino sicuro dopo un arresto anomalo, ma gli errori ripetuti possono indicare errori InnoDB successivi a un'interruzione di corrente.
Un singolo ripristino riuscito seguito da controlli normali non dimostra che ci sia una corruzione. Un ciclo, un'asserzione fatale, un segnale ripetuto o l'impossibilità di raggiungere lo stato pronto sono segnali per interrompere la copia dei file grezzi e verificare i backup prima che vengano effettuate altre scritture.
Cerca errori relativi a checksum e pagine non valide
Cerca nei log termini come mancata corrispondenza del checksum, verifica della pagina non riuscita, pagina non valida nel blocco, pagina corrotta, lettura breve, numero magico errato o fine file inattesa. Registra la relazione, la tabella, il blocco o lo spazio delle tabelle indicato.
pganalyze mostra la corruzione di PostgreSQL come errori di checksum delle pagine seguiti da un errore di pagina non valida quando viene letto il blocco danneggiato.
Non ignorare l'errore e non azzerare le pagine danneggiate prima di aver conservato le prove e confermato la copertura dei backup. Il fallimento dello stesso blocco dopo diversi riavvii è una prova più forte rispetto a un timeout dell'applicazione verificatosi una sola volta.
Controlla le query che falliscono solo su righe o tabelle specifiche
Esegui controlli in sola lettura sulle tabelle e sulle query normalmente utilizzate dall'applicazione. La corruzione può rimanere nascosta finché una scansione, un vacuum, un backup o una richiesta non accede a una pagina danneggiata.
Un'analisi di PostgreSQL spiega che una mancata corrispondenza del checksum indica un problema probabilmente sottostante al database, mentre una pagina non valida senza un avviso relativo al checksum può comunque riflettere problemi di archiviazione, memoria, filesystem o danni accidentali ai file. Il sintomo pratico è una lettura ripetibile di una pagina non valida durante le query ordinarie.
Registra esattamente quale query e quale oggetto falliscono. Non permettere all'applicazione di continuare a eseguire scritture estese mentre solo una parte del database rimane leggibile, perché i nuovi dati possono complicare il ripristino e i backup.
Verifica le incongruenze di indici, transazioni e metadati
I segnali di avvertimento includono chiavi duplicate che violano un indice univoco, righe mancanti raggiungibili tramite un percorso di accesso ma non tramite un altro, ID di transazione non validi, blocchi TOAST o di valori di grandi dimensioni danneggiati e indici che non superano la convalida.
La revisione della corruzione di Credativ osserva che i cluster privi di checksum dei dati possono rivelare danni attraverso errori di basso livello come pagine non valide, problemi relativi agli ID di transazione, incongruenze TOAST o arresti anomali del backend. Alcuni backup ottenuti copiando i file possono conservare pagine corrotte senza rilevarle.
Esegui i controlli di integrità e degli indici supportati su una copia o durante una finestra di manutenzione controllata. La ricostruzione degli indici può riparare un indice derivato danneggiato, ma non ripara i dati corrotti delle tabelle né lo spazio di archiviazione sottostante.
Metti in relazione gli errori del database con gli avvisi del filesystem e dello spazio di archiviazione
Esamina i log del kernel dell'host, del filesystem, del pool, dell'unità, del controller, dell'UPS e del runtime dei container relativi al periodo dell'interruzione. Cerca errori di I/O, reset, errori di checksum, rimontaggi in sola lettura, pool degradati e file persi o troncati.
Una guida al ripristino dei database osserva che le interruzioni di corrente e la memoria difettosa possono produrre scritture di pagine corrotte, soprattutto quando il comportamento dello spazio di archiviazione non corrisponde alle ipotesi di durabilità del database. Questi eventi a livello dell'host aiutano a distinguere la corruzione delle pagine InnoDB da un normale riavvio dell'applicazione.
Risolvi il problema del percorso di archiviazione prima di ripristinarvi un database integro. Un ripristino logico riuscito su supporti in errore può ripetere l'incidente o danneggiare silenziosamente la sostituzione.
Interrompi le scritture e dimostra il ripristino da un backup integro
Quando i segnali di corruzione sono ripetibili, arresta le applicazioni dipendenti, crea uno snapshot o un clone del volume interessato se è sicuro farlo e conserva log e configurazione. Verifica il backup più recente su uno spazio di archiviazione separato prima di modificare il cluster originale.
La checklist di ZimaSpace per il backup dello stato delle applicazioni Docker definisce cosa deve essere disponibile prima di tentare un ripristino distruttivo del database.
Il sistema è affidabile solo quando il database ripristinato si avvia correttamente, i controlli di integrità hanno esito positivo, le query e le scritture rappresentative funzionano, i backup vengono completati e lo spazio di archiviazione dell'host non segnala nuovi errori. Le modalità di ripristino forzato devono essere utilizzate per il recupero dei dati nell'ambito di un piano documentato, non come funzionamento normale.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
