Wat zijn de waarschuwingssignalen dat een databasecontainer door stroomuitval is beschadigd?

Vermoed corruptie wanneer de database normale crashherstelprocedures niet kan voltooien of daarna checksum-, pagina-, logreeks-, tabel- of indexinconsistenties meldt.

Een onjuiste afsluiting betekent niet automatisch dat de database beschadigd is; PostgreSQL, MySQL, MariaDB en vergelijkbare engines gebruiken journals of write-ahead logs specifiek om de bevestigde status te herstellen. De waarschuwingsgrens wordt bereikt wanneer herstel zich herhaalt, de engine afsluit, dezelfde query ongeldige pagina's raakt, checksums mislukken, tabellen verdwijnen, indexen niet overeenkomen met tabelgegevens of back-ups en integriteitscontroles het cluster niet consistent kunnen lezen.

Maak onderscheid tussen normaal crashherstel en een herstel-lus

Bewaar het eerste opstartlog nadat de stroom is teruggekeerd. Noteer of de engine de logs eenmaal afspeelt en gereed komt, of steeds opnieuw opstart, gedwongen herstel uitvoert of op dezelfde record of pagina stopt.

InnoDB kan melden dat mogelijk halfgeschreven pagina's na een onderbroken schrijfactie worden hersteld; dit betekent dat de engine veilig crashherstel probeert uit te voeren, maar herhaalde fouten kunnen wijzen op InnoDB-fouten na een stroomstoring.

Eén geslaagd herstel, gevolgd door normale controles, is geen bewijs dat er corruptie is. Een lus, fatale assertion, herhaald signaal of het niet bereiken van de gereedstatus is een stopteken: kopieer de onbewerkte bestanden en test back-ups voordat er meer schrijfacties plaatsvinden.

Let op checksum- en fouten met ongeldige pagina's

Zoek in de logs naar checksum mismatch, page verification failed, invalid page in block, corrupt page, short read, bad magic number of unexpected end-of-file. Noteer de genoemde relatie, tabel, block of tablespace.

pganalyze laat zien dat PostgreSQL-corruptie aan het licht komt als checksumfouten op pagina's, gevolgd door een fout met een ongeldige pagina wanneer het beschadigde block wordt gelezen.

Onderdruk de fout niet en maak beschadigde pagina's niet leeg voordat je bewijs hebt veiliggesteld en hebt bevestigd dat er een back-up beschikbaar is. Hetzelfde block dat bij elke herstart faalt, is sterker bewijs dan een eenmalige time-out van de applicatie.

Let op queries die alleen op specifieke rijen of tabellen mislukken

Voer alleen-lezencontroles uit op tabellen en queries die de applicatie normaal gebruikt. Corruptie kan onopgemerkt blijven totdat een scan, vacuum, back-up of verzoek een beschadigde pagina raakt.

Een PostgreSQL-analyse legt uit dat een checksumverschil wijst op een probleem onder de database, terwijl een ongeldige pagina zonder checksumwaarschuwing nog steeds het gevolg kan zijn van opslag, geheugen, het bestandssysteem of onopzettelijke bestandsschade. Het praktische symptoom is een herhaaldelijke leesfout met een ongeldige pagina tijdens normale queries.

Noteer precies welke query en welk object falen. Laat de applicatie geen grootschalige schrijfacties voortzetten zolang slechts een deel van de database leesbaar is, omdat nieuwe status het herstel en de back-ups kan bemoeilijken.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Controleer op inconsistenties in indexen, transacties en metagegevens

Waarschuwingssignalen zijn onder meer dubbele sleutels die een unieke index schenden, ontbrekende rijen die via het ene toegangspad wel en via het andere niet bereikbaar zijn, ongeldige transactiekenmerken, beschadigde TOAST- of fragmenten met grote waarden en indexen die validatie niet doorstaan.

Credativs beoordeling van corruptie vermeldt dat clusters zonder gegevenschecksums schade kunnen tonen via fouten op laag niveau, zoals ongeldige pagina's, problemen met transactie-ID's, TOAST-inconsistenties of crashes van backends. Sommige back-ups op basis van bestandskopieën kunnen beschadigde pagina's behouden zonder dit te detecteren.

Voer ondersteunde integriteits- en indexcontroles uit op een kopie of tijdens een gecontroleerd onderhoudsvenster. Herindexeren kan een beschadigde afgeleide index herstellen, maar repareert geen beschadigde tabelgegevens of onderliggende opslag.

Breng databasefouten in verband met waarschuwingen van het bestandssysteem en de opslag

Controleer de logs van de hostkernel, het bestandssysteem, de pool, schijf, controller, UPS en containerruntime rond de storing. Zoek naar I/O-fouten, resets, checksumfouten, opnieuw als alleen-lezen aangekoppelde bestandssystemen, gedegradeerde pools en verdwenen of afgeknotte bestanden.

Een handleiding voor databaseherstel vermeldt dat stroomstoringen en defect geheugen beschadigde paginawrites kunnen veroorzaken, vooral wanneer het opslaggedrag niet overeenkomt met de duurzaamheidaannames van de database. Deze gebeurtenissen op hostniveau helpen om InnoDB-paginacorruptie te onderscheiden van een normale herstart van de applicatie.

Herstel het opslagpad voordat je een schone database daarop terugzet. Een geslaagd logisch herstel op falende media kan het incident opnieuw veroorzaken of de vervanging ongemerkt beschadigen.

Stop schrijfacties en bewijs herstel uit een schone back-up

Stop bij herhaaldelijke tekenen van corruptie de afhankelijke applicaties, maak indien veilig een snapshot of kloon van het getroffen volume en bewaar logs en configuratie. Test de meest recente back-up op afzonderlijke opslag voordat je het oorspronkelijke cluster wijzigt.

De ZimaSpace-checklist voor het back-uppen van de status van Docker-applicaties beschrijft wat aanwezig moet zijn voordat je een destructieve databaseherstelpoging uitvoert.

Het systeem is alleen betrouwbaar wanneer de herstelde database schoon opstart, integriteitscontroles slagen, representatieve queries en schrijfacties succesvol zijn, back-ups worden voltooid en de opslag van de host geen nieuwe fouten meldt. Modi voor gedwongen herstel mogen worden gebruikt voor salvage volgens een gedocumenteerd herstelplan, maar niet als normale werking.