Vilka varningssignaler tyder på att en databaskontainer har skadats av ett strömavbrott?
Misstänk korruption när databasen inte kan slutföra normal kraschåterställning eller därefter rapporterar felaktiga kontrollsummor, sidor, loggsekvenser, tabeller eller index.
En okontrollerad avstängning innebär inte automatiskt att databasen är korrupt. PostgreSQL, MySQL, MariaDB och liknande databasmotorer använder journaler eller skrivföreloggar specifikt för att återställa bekräftade tillstånd. Varningsgränsen nås när återställningen upprepas, databasmotorn avslutas, samma fråga träffar ogiltiga sidor, kontrollsummor misslyckas, tabeller försvinner, index motsäger tabelldata eller säkerhetskopior och integritetskontroller inte kan läsa klustret konsekvent.
Skilj normal kraschåterställning från en återställningsloop
Spara den första startloggen efter att strömmen återkommit. Notera om databasmotorn spelar upp loggarna en gång och blir klar, eller om den startar om upprepade gånger, går in i tvingad återställning eller stannar vid samma post eller sida.
InnoDB kan rapportera återställning av möjliga delvis skrivna sidor efter ett avbrutet skrivförlopp. Meddelandet visar att motorn försöker genomföra en säker kraschåterställning, men upprepade fel kan tyda på InnoDB-fel efter ett strömavbrott.
En enda lyckad återställning följd av normala kontroller är inget bevis på korruption. En loop, ett allvarligt påstående, en upprepad signal eller oförmåga att nå klart läge är en stoppsignal för att kopiera råfiler och testa säkerhetskopior innan fler skrivningar sker.
Leta efter fel på kontrollsummor och ogiltiga sidor
Sök i loggarna efter kontrollsummemismatch, misslyckad sidverifiering, ogiltig sida i block, korrupt sida, kort läsning, felaktigt magiskt tal eller oväntat slut på filen. Notera den angivna relationen, tabellen, blocket eller tabellrymden.
pganalyze visar hur PostgreSQL-korruption uppträder som fel på sidkontrollsummor följt av ett fel om ogiltig sida när det skadade blocket läses.
Tysta inte felet och nollställ inte skadade sidor innan du har bevarat bevis och bekräftat täckningen i säkerhetskopiorna. Att samma block misslyckas efter flera omstarter är starkare bevis än en tidsgräns som överskrids i programmet vid ett enda tillfälle.
Var uppmärksam på frågor som bara misslyckas för vissa rader eller tabeller
Kör skrivskyddade kontroller mot de tabeller och frågor som programmet normalt använder. Korruption kan förbli dold tills en genomsökning, vakuumkörning, säkerhetskopiering eller begäran vidrör en skadad sida.
En PostgreSQL-analys förklarar att en kontrollsummemismatch pekar mot ett problem under databasen, medan en ogiltig sida utan en kontrollsummevarning fortfarande kan bero på lagring, minne, filsystem eller oavsiktlig filskada. Det praktiska symtomet är en upprepningsbar läsning av en ogiltig sida vid vanliga frågor.
Notera exakt vilken fråga och vilket objekt som misslyckas. Låt inte programmet fortsätta med omfattande skrivningar medan bara delar av databasen går att läsa, eftersom nya tillstånd kan försvåra återställning och säkerhetskopiering.
Kontrollera inkonsekvenser i index, transaktioner och metadata
Varningstecken omfattar dubblettnycklar som bryter mot ett unikt index, saknade rader som kan nås via en åtkomstväg men inte en annan, ogiltiga transaktions-ID:n, trasiga TOAST- eller delar för stora värden samt index som inte klarar valideringen.
Credativs granskning av korruption påpekar att kluster utan datakontrollsummor kan visa skador genom lågnivåfel som ogiltiga sidor, problem med transaktions-ID:n, TOAST-inkonsekvenser eller krascher i backend. Vissa säkerhetskopior som skapas genom filkopiering kan bevara korrupta sidor utan att upptäcka dem.
Kör integritets- och indexkontroller som stöds på en kopia eller under ett kontrollerat underhållsfönster. Omindexering kan reparera ett skadat härlett index, men reparerar inte korrupta tabelldata eller den underliggande lagringen.
Relatera databasfel till varningar från filsystem och lagring
Inspektera loggarna från värddatorns kärna, filsystem, lagringspool, enheter, styrenhet, UPS och containerkörmiljö kring avbrottet. Leta efter I/O-fel, återställningar, kontrollsummefel, ominmonteringar i skrivskyddat läge, degraderade pooler samt förlorade eller avkortade filer.
En guide för databasåterställning noterar att strömavbrott och dåligt minne kan orsaka korrupta sid skrivningar, särskilt när lagringens beteende inte stämmer överens med databasens antaganden om beständighet. Dessa händelser på värdnivå hjälper till att skilja InnoDB-sidkorruption från en normal omstart av programmet.
Åtgärda lagringsvägen innan du återställer en ren databas till den. En lyckad logisk återställning till felande medier kan upprepa incidenten eller i tysthet skada ersättningen.
Stoppa skrivningar och bevisa återställning från en ren säkerhetskopia
När korruptionstecknen kan upprepas ska du stoppa beroende program, ta en ögonblicksbild av eller klona den berörda volymen om det är säkert, och bevara loggar och konfiguration. Testa den senaste säkerhetskopian på separat lagring innan du ändrar det ursprungliga klustret.
ZimaSpaces checklista för säkerhetskopiering av Docker-programtillstånd definierar vad som måste finnas innan ett destruktivt försök att återställa databasen påbörjas.
Systemet är tillförlitligt först när den återställda databasen startar utan fel, integritetskontrollerna godkänns, representativa frågor och skrivningar lyckas, säkerhetskopieringarna slutförs och värdlagringen inte rapporterar några nya fel. Lägen för tvingad återställning ska användas för räddning enligt en dokumenterad återställningsplan, inte i normal drift.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
