:strip_exif()/i/2003683020.png?f=thumbmini)
:strip_icc():strip_exif()/u/30425/crop5906f20a03bb0_cropped.jpeg?f=community)
Door een softwareupdate is mijn VPS defect geraakt (Debian 9). Mijn webhost heeft een oude standaard image over de server heen gezet, omdat er systeembestanden ontbraken. Daarmee startte de VPS weer op en kon ik wat bestanden veiligstellen, waaronder de .ibd en .frm-bestanden van mijn MariaDB database (mariadb 10.1).
Nu heb ik helaas niet het bestand ibdata1 veiliggesteld; ik wist niet dat deze ook relevant was. Als ik het goed begrijp, wordt in dat bestand data over de tabellen in de onderliggende databases bijgehouden. Na enig zoekwerk blijkt dit niet zeer cruciaal te zijn. Ik heb een actuele structuur-export van de database, dus ik kon deze truc uithalen:
- nieuwe, blanco database maken;
- CREATE-query's draaien;
- de table-spaces verwijderen met "ALTER TABLE filename DISCARD TABLESPACE";
- de oude .ibd-bestanden in de data-map plaatsen;
- de table-spaces importeren met "ALTER TABLE finename IMPORT TABLESPACE";
Zo heb ik 19 van de 20 tabellen zonder moeite weer werkend gekregen. Maar één tabel weigert dienst. En dat is helaas de meest cruciale van allemaal.
Bij het importeren van de tablespace krijg ik de volgende foutmelding:
Geweldig: een corrupte page. Hier eindigt mijn kennis van databases...
Dat bevestigt eigenlijk alleen maar wat al bekend was uit de docker-log.
Bij deze stackexchange wordt voor het repareren of repliceren van de data verwezen naar undrop-for-innodb. De online dienst bestaat al ruim twee jaar niet meer, de ontwikkelaar wil er niets meer mee te maken hebben en de tool is ook nooit goed gedocumenteerd. Daar raak ik dus ook niet wijzer van...
* Thijsmans staat op het punt om de handdoek in de ring te gooien.
Of heeft iemand nog een idee om de tabel te recoveren?
Nu heb ik helaas niet het bestand ibdata1 veiliggesteld; ik wist niet dat deze ook relevant was. Als ik het goed begrijp, wordt in dat bestand data over de tabellen in de onderliggende databases bijgehouden. Na enig zoekwerk blijkt dit niet zeer cruciaal te zijn. Ik heb een actuele structuur-export van de database, dus ik kon deze truc uithalen:
- nieuwe, blanco database maken;
- CREATE-query's draaien;
- de table-spaces verwijderen met "ALTER TABLE filename DISCARD TABLESPACE";
- de oude .ibd-bestanden in de data-map plaatsen;
- de table-spaces importeren met "ALTER TABLE finename IMPORT TABLESPACE";
Zo heb ik 19 van de 20 tabellen zonder moeite weer werkend gekregen. Maar één tabel weigert dienst. En dat is helaas de meest cruciale van allemaal.
Bij het importeren van de tablespace krijg ik de volgende foutmelding:
Mariadb draait in een docker-container. De logs van de container vermelden:#1034 - Verkeerde zoeksleutel file voor tabel: 'b_ebooks'; probeer het te repareren
code:
1
2
| 2020-07-26 12:24:37 139683723880192 [Warning] InnoDB: ./boogsy_nl/b_ebooks.ibd: Page 11072 at offset 181403648 looks corrupted., 2020-07-26 12:24:37 139683723880192 [Note] InnoDB: Discarding tablespace of table "boogsy_nl"."b_ebooks": Data structure corruption |
Geweldig: een corrupte page. Hier eindigt mijn kennis van databases...
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| root@...:/var/lib/mysql/boogsy_nl# innochecksum -v b_ebooks.ibd
Variables (--variable-name=value)
and boolean options {FALSE|TRUE} Value (after reading options)
--------------------------------- ----------------------------------------
verbose TRUE
count FALSE
start-page 0
end-page 0
page 0
strict-check crc32
no-check FALSE
allow-mismatches 0
write crc32
page-type-summary FALSE
page-type-dump (No default value)
per-page-details FALSE
log (No default value)
leaf FALSE
merge 0
Fail: page::11085 invalid
Exceeded the maximum allowed checksum mismatch count::1 current::0 |
Dat bevestigt eigenlijk alleen maar wat al bekend was uit de docker-log.
Bij deze stackexchange wordt voor het repareren of repliceren van de data verwezen naar undrop-for-innodb. De online dienst bestaat al ruim twee jaar niet meer, de ontwikkelaar wil er niets meer mee te maken hebben en de tool is ook nooit goed gedocumenteerd. Daar raak ik dus ook niet wijzer van...
* Thijsmans staat op het punt om de handdoek in de ring te gooien.
Of heeft iemand nog een idee om de tabel te recoveren?
Privacy-adepten vinden op AVGtekst.nl de Nederlandse AVG-tekst voorzien van uitspraken en besluiten.
/u/8830/crop5df8eadcd55ca_cropped.png?f=community)
:strip_icc():strip_exif()/u/53213/crop57ace20969734.jpeg?f=community)
Anderzijds: zij hebben besloten tot de kernelupgrade die dit probleem heeft veroorzaakt.