Løs fejlen: innodb_forced_recovery > 0

Pludselig er din hjemmeside nede. I stedet for dit velkendte indhold mødes du og dine besøgende af en kryptisk og alarmerende fejlmeddelelse: "1881 – Operation not allowed when innodb_forced_recovery > 0." Panikken kan hurtigt melde sig, men tag det roligt. Denne fejl, selvom den virker teknisk og skræmmende, er ofte et tegn på en tidligere redningsaktion og er heldigvis i de fleste tilfælde ligetil at løse. Fejlen er ikke et tegn på, at din hjemmeside er blevet hacket eller er gået i stykker for evigt. Det er simpelthen din database, der fortæller dig, at den er blevet sat i en særlig beskyttelsestilstand, som forhindrer normal drift.

I denne artikel vil vi dykke ned i, hvad `innodb_force_recovery` præcist er, hvorfor denne fejl opstår, og vigtigst af alt, hvordan du trin-for-trin kan deaktivere denne indstilling og få din hjemmeside tilbage online. Vi vil også se på de forskellige niveauer af denne gendannelsestilstand, så du er rustet til at håndtere en ægte database-nødsituation, hvis den skulle opstå.

Hvad er `innodb_force_recovery`?

Forestil dig `innodb_force_recovery` som en slags nødbremse for din MySQL- eller MariaDB-database. Det er en avanceret konfigurationsparameter, der udelukkende er designet til brug i en nødsituation, typisk efter et servernedbrud, strømsvigt eller en anden hændelse, der har efterladt databasen i en inkonsekvent eller korrupt tilstand. Dens primære formål er ikke at reparere databasen. I stedet er dens funktion at tvinge databasen til at starte op i en begrænset tilstand, hvor visse sikkerhedstjek og baggrundsprocesser er deaktiveret. Dette giver en systemadministrator mulighed for at få adgang til dataene og eksportere dem (f.eks. ved hjælp af et værktøj som mysqldump), selvom databasen er beskadiget.

Denne indstilling findes i databasens centrale konfigurationsfil, som normalt hedder `my.cnf` på Linux-systemer eller `my.ini` på Windows. Når `innodb_force_recovery` er sat til en værdi større end 0, fortæller du i bund og grund databasen: "Jeg ved, du måske er i stykker, men start alligevel op, og ignorer visse fejl, så jeg kan redde mine data."

Hvorfor opstår fejlen "Operation not allowed"?

En moderne hjemmeside, bygget på systemer som Joomla, WordPress eller Drupal, er i konstant dialog med sin database. Hver gang en side indlæses, en bruger logger ind, en kommentar skrives, eller en formular udfyldes, udføres der skrivehandlinger til databasen. Disse handlinger kan være `INSERT`, `UPDATE` eller `DELETE` forespørgsler.

Når `innodb_force_recovery` er aktiv (med en værdi fra 1 til 6), sættes databasen i en skrivebeskyttet eller stærkt begrænset tilstand for at forhindre yderligere skade. Den tillader typisk kun `SELECT`-forespørgsler, som bruges til at læse data. Når din hjemmeside så forsøger at udføre en af sine rutinemæssige skrivehandlinger – f.eks. at opdatere en sessionstabel for en besøgende – blokerer databasen operationen og returnerer fejlen: "Operation not allowed".

Den mest almindelige årsag til, at man ser denne fejl, er menneskelig forglemmelse. Et typisk scenarie er:

1. Databasen går ned på grund af et problem.
2. En serveradministrator aktiverer `innodb_force_recovery` for at undersøge problemet og redde data.
3. Gendannelsen lykkes, og dataene bliver reddet, eller problemet løser sig selv ved genstart.
4. Administratoren glemmer at fjerne eller deaktivere `innodb_force_recovery`-linjen i konfigurationsfilen.

Resultatet er, at databasen starter op i denne begrænsede tilstand hver gang, og hjemmesiden kan ikke fungere korrekt.

Trin-for-trin guide: Sådan løser du problemet

At løse dette problem kræver adgang til din servers kommandolinje (typisk via SSH). Hvis du ikke er komfortabel med dette, bør du kontakte din hostingudbyder eller en udvikler.

1. Få adgang til din server: Log ind på din server som root-bruger eller en bruger med sudo-privilegier ved hjælp af SSH.
2. Find konfigurationsfilen: MySQL's konfigurationsfil er oftest placeret i `/etc/my.cnf` eller `/etc/mysql/my.cnf`. På nogle systemer kan den være i `/etc/mysql/mariadb.conf.d/50-server.cnf`. Du kan bruge kommandoen `find /etc -name "my.cnf"` for at lede efter den.
3. Rediger filen: Åbn filen med en teksteditor som `nano` eller `vi`. For eksempel: `sudo nano /etc/my.cnf`
4. Deaktiver indstillingen: Gennemse filen for en linje, der ligner `innodb_force_recovery = X`, hvor X er et tal fra 1 til 6. Den er typisk placeret under `[mysqld]`-sektionen.
5. Kommenter linjen ud: Den sikreste metode er at "udkommentere" linjen ved at sætte et #-tegn foran den. Dette deaktiverer indstillingen, men bevarer den i filen, så du kan huske, at den har været brugt. Linjen skal se sådan ud: `#innodb_force_recovery = 2`. Alternativt kan du slette hele linjen.
6. Gem og luk filen: I `nano` gøres dette ved at trykke `Ctrl+X`, derefter `Y` for at bekræfte, og `Enter`.
7. Genstart MySQL-tjenesten: For at ændringerne kan træde i kraft, skal databasetjenesten genstartes. Dette er et kritisk skridt. Brug en af følgende kommandoer afhængigt af dit system:
   • `sudo systemctl restart mysql`
   • `sudo systemctl restart mariadb`
   • `sudo service mysql restart`
8. Test din hjemmeside: Gå til din hjemmeside i browseren. Hvis fejlen skyldtes den glemte indstilling, skulle siden nu indlæses korrekt.

Forstå de forskellige gendannelsesniveauer

Selvom du sandsynligvis kun har brug for at deaktivere indstillingen, er det værdifuldt at forstå, hvad de forskellige niveauer betyder, hvis du en dag står over for reel datakorruption. Man bør altid starte med det lavest mulige niveau og kun øge det, hvis databasen nægter at starte.

Den korrekte procedure for datagendannelse

Hvis din database rent faktisk er korrupt, og du har brug for at bruge `innodb_force_recovery` til sit egentlige formål, er her den korrekte fremgangsmåde. Husk, målet er at udtrække data, ikke at reparere den kørende database.

1. Tag en fuld backup! Før du gør noget som helst, skal du stoppe MySQL og tage en kopi af hele din datamappe (typisk `/var/lib/mysql`). Dette er din livline, hvis noget går galt.
2. Aktivér `innodb_force_recovery = 1` i din `my.cnf`-fil.
3. Prøv at starte MySQL-tjenesten. Hvis den ikke starter, så stop den, øg værdien til 2, og prøv igen. Fortsæt denne proces, indtil serveren starter.
4. Så snart serveren kører, skal du bruge `mysqldump` til at eksportere alle dine databaser til en SQL-fil. Eksempel: `mysqldump --all-databases -u root -p > /path/to/your/fuld_backup.sql`
5. Verificer, at din backup-fil er blevet oprettet og ikke er tom.
6. Stop MySQL-tjenesten igen.
7. Fjern eller omdøb din gamle datamappe.
8. Deaktiver `innodb_force_recovery` i `my.cnf`-filen (sæt den til 0 eller udkommenter den).
9. Start MySQL-tjenesten. Den vil nu oprette en ny, ren datamappe.
10. Gendan dine data fra den SQL-fil, du oprettede: `mysql -u root -p < /path/to/your/fuld_backup.sql`

Denne proces sikrer, at du ender med en frisk, ukorrupt database, der indeholder alle de data, der kunne reddes.

Ofte Stillede Spørgsmål (FAQ)

Reparerer `innodb_force_recovery` min database?

Nej, og dette er et meget vigtigt punkt. Værktøjet reparerer intet. Det er en midlertidig løsning, der ignorerer fejl for at give dig læseadgang. De korrupte datafiler forbliver korrupte. Den eneste rigtige reparation er at dumpe dataene og genindlæse dem i en ny database.

Jeg har sat `innodb_force_recovery=0`, men fejlen er der stadig. Hvad gør jeg?

Det mest almindelige er, at du har glemt at genstart MySQL-tjenesten. Ændringer i `my.cnf` træder først i kraft efter en genstart. Tjek også, at du har redigeret den korrekte `my.cnf`-fil. Nogle systemer har flere konfigurationsfiler, og en anden fil kan overskrive din ændring.

Hvilket niveau skal jeg bruge til gendannelse?

Start altid med niveau 1. Det er det mindst invasive. Gå kun et niveau op ad gangen, hvis databasen nægter at starte. Undgå niveauerne 4, 5 og 6, medmindre det er absolut sidste udvej, og du er fuldt ud klar over risikoen for datatab.

Er det sikkert at slette `ibdata1`-filen?

Absolut ikke, medmindre du har en fuld, verificeret `mysqldump` af alle dine data. `ibdata1`-filen er ofte hjertet i InnoDB-lagermotoren og indeholder data, indekser og systemtabeller. At slette den uden en SQL-backup svarer til at slette hele din database permanent.