Hvordan fjerne eller reparere en korrupt INNODB-tabell?

[magicgunnar]

Jeg prøver:

 

mysql> drop table korrupt;

ERROR 1051 (42S02): Unknown table 'korrupt'

mysql> repair table korrupt;

+-----------------------------+--------+----------+---------------------------------------------------+

| Table | Op | Msg_type | Msg_text |

+-----------------------------+--------+----------+---------------------------------------------------+

| db.korrupt | repair | Error | Table 'db.korrupt' doesn't exist |

| db.korrupt | repair | error | Corrupt |

+-----------------------------+--------+----------+---------------------------------------------------+

2 rows in set (0.01 sec)

(check table korrupt gir samme svar.)

 

mysql> create table korrupt (id int NOT NULL);

ERROR 1050 (42S01): Table 'korrupt' already exists

mysql> drop table korrupt;

ERROR 1051 (42S02): Unknown table 'korrupt'

mysql> create table detteerentest (id int NOT NULL);

Query OK, 0 rows affected (0.05 sec)

 

Så jeg har en tabell, tror jeg, som jeg ikke får fjernet. Er det noen som vet hvordan jeg kan fjerne den?

[quantum]

Det står noen tips her, men hvis MySQL faktisk klarer å kjøre er det ikke sikkert du trenger å gå så drastisk til verks.

 

http://www.softwareprojects.com/resources/...nnodb-1634.html

[blackbrrd]

[offtopic]

Det står noen tips her, men hvis MySQL faktisk klarer å kjøre er det ikke sikkert du trenger å gå så drastisk til verks.

 

http://www.softwareprojects.com/resources/...nnodb-1634.html

Litt ironisk at det i linken er snakk om korrupte InnoDB tabeller... Så mye for ACID compliance!

[/offtopic]

[quantum]

[offtopic]

Det står noen tips her, men hvis MySQL faktisk klarer å kjøre er det ikke sikkert du trenger å gå så drastisk til verks.

 

http://www.softwareprojects.com/resources/...nnodb-1634.html

Litt ironisk at det i linken er snakk om korrupte InnoDB tabeller... Så mye for ACID compliance!

[/offtopic]

 

Hvis du synes dét var morsomt, så vent til du leser denne http://www.google.no/search?q=corrupt+table+postgresql

 

Ja, ACID er visst noe ræl?

 

Tror kanskje det også er på sin plass å gjenta at jeg pleier å avskrive MySQL lenge *før* jeg kommer til de teknisk/implementasjonsmessige tingene som har med stabilitet og driftssikkerhet å gjøre jeg da. Her er mine tre favoritter:

 

1. Kaotisk og uforutsigbare organisatoriske forhold

2. Manglende standards conformance ...

a) der hvor man faktisk har featuren implementert har man gjort det på en ikkestandard måte

b) har alltid ligget laaaangt etter konkurrentene mht. å implementere helt vanlige RDBMS-features

3. If-a-bug-is-known-we-don't-need-to-fix-it-strategien

 

... men nå er det jo ikke alltid man er så heldig å kunne velge da. Og det er vel hevet over tvil at MySQL faktisk brukes i en del tunge sammenhenger hvor man helt fint klarer å overkomme de problemene MySQL har. Like it or not.

[siDDis]

Hvis du synes dét var morsomt, så vent til du leser denne http://www.google.no/search?q=corrupt+table+postgresql

 

Flott du henviser til eit googlesøk der folk poster om tilfeller der dei "trur" at tabellen er korrupt, som regel skyldes det at tabellen er låst eller indeksen må reindekseres.

Endret 10. desember 2009 av siDDIs

[quantum]

Flott du henviser til eit googlesøk der folk poster om tilfeller der dei "trur" at tabellen er korrupt, som regel skyldes det at tabellen er låst eller indeksen må reindekseres.

Foreslår enten

 

1. les alle 105 000 treffene

 

eller

 

2. tenk før du poster

 

eller hvorfor ikke begge ... :o)

[blackbrrd]

Angående de som foreslår å restarte databasen for å løse opp i locks, så finnes det enklere måter, som f.eks å kjøre en spørring som cancler alle spørringer. (Evt bare de aktuelle - kommer an på hvor langt det har gått i lockingen...)

[blackbrrd]

[offtopic]

Det står noen tips her, men hvis MySQL faktisk klarer å kjøre er det ikke sikkert du trenger å gå så drastisk til verks.

 

http://www.softwareprojects.com/resources/...nnodb-1634.html

Litt ironisk at det i linken er snakk om korrupte InnoDB tabeller... Så mye for ACID compliance!

[/offtopic]

 

Hvis du synes dét var morsomt, så vent til du leser denne http://www.google.no/search?q=corrupt+table+postgresql

 

Ja, ACID er visst noe ræl?

 

Eid!

 

Vel, tenkte ikke spes over det ettersom jeg har hatt endel hw failure, strømbrudd uten UPS osv uten noensinne å ha fått korrupte data. (Har UPS og bedre hw generellt nå.)

[blackbrrd]

Flott du henviser til eit googlesøk der folk poster om tilfeller der dei "trur" at tabellen er korrupt, som regel skyldes det at tabellen er låst eller indeksen må reindekseres.

Foreslår enten

 

1. les alle 105 000 treffene

 

eller

 

2. tenk før du poster

 

eller hvorfor ikke begge ... :o)

 

Mange av de 105.000 treffene er nok forresten pga indeksene (som såvidt jeg kan skjønne ikke er ACID compliant), og locking issues.

[quantum]

Eid!

 

Vel, tenkte ikke spes over det ettersom jeg har hatt endel hw failure, strømbrudd uten UPS osv uten noensinne å ha fått korrupte data. (Har UPS og bedre hw generellt nå.)

det er vel ikke akkurat veldig rart iom. at postgresql-utviklerne hele tiden har fokusert på å lage en rdbms og ikke en fast-track cowboydatabase ... men jeg vil jo samtidig gjette at oddsene for at google faktisk har klart å indeksere opp minst en beskrivelse av reell tablecorruption i postgresql er brukbare. vi får bare vente og se hva siDDIs kommer opp med :o)

[blackbrrd]

Jeg tror første treffet var tablecorruption.

 

Det er basically to muligheter for korrupte data i postgres:

- Bugs i postgres

- Hardwarefailure

 

Såvidt jeg vet er det ingen kjente bugs i siste versjon av postgres (8.1.x, 8.2.x, osv)

 

Hardwarefailure som f.eks to døde/døende disker i et raid 1, raid-kontroller som skriver feil data, osv er nok vanligste grunnen til hardwarefailure... Noen ide-disker sa ifra til OS-et at de var ferdig med å skrive før de var ferdige - også en mulighet for korrupte data...

[quantum]

Såvidt jeg vet er det ingen kjente bugs i siste versjon av postgres (8.1.x, 8.2.x, osv)

 

Ja, det følger jo logisk av en gitt release-schedule; Man fikser kjente bugs, og så releaser man en bugfix-release. Og så gjør man seg kjent med de nye bugs'ene ...

[siDDis]

Sjølvsagt så får ein korrupt data på einkvar database om det er feil på hardware, heldigvis så har Sun og Oracle gjort store forbetringer i filsystemer for å eliminere dette. Idag skal det være umogleg å få korrupt data med ZFS.

 

Eg har heller aldri lest på mailing-lista til PostgreSQL at databasen er skyld i korrupt data.

 

Så om ein får korrupt data så må det være ein bug i databasen, operativsystemet eller filsystemet.

 

Til MySQL er saken biff, her er eit av mange eksempler på korrupt data grunnet feil i databasen http://bugs.mysql.com/bug.php?id=39090

[quantum]

@siDDIs og blackbrrd

 

Skjønner at det er fascinerende med repeterende innslåing av åpne dører ... men har dere også et poeng med alt dere skriver?

[siDDis]

du får forklare kva du meiner litt nærmare

[magicgunnar]

Det står noen tips her, men hvis MySQL faktisk klarer å kjøre er det ikke sikkert du trenger å gå så drastisk til verks.

 

http://www.softwareprojects.com/resources/...nnodb-1634.html

Takk for hjelp! Jeg trengte ikke gjøre alt som stod i linken, siden databasen min fortsatt kjørte, men hvis jeg prøvde å opprette en INNODB-tabell, eller endre en tabell til INNODB så mistet jeg kontakten med den.

Det holdt å dumpe databasen til en fil, slette databasekatalogen, opprette ny databasekatalog, opprette standard databasetabeller og importere den lagrede databasen.

 

Det jeg gjorde i kommandoer, sånn cirka:

mysqldump --force --compress --triggers --routines --create-options -uUSERNAME -pPASSWORD --all-databases > /usr/alldb.sql 
mysqladmin -uUSERNAME -pPASSWORD shutdown 
mv /var/lib/mysql /var/lib/old_mysql 
mkdir /var/lib/mysql
chown -R mysql:mysql /var/lib/mysql
/usr/local/bin/mysql_install_db
chown -R mysql:mysql /var/lib/mysql 
mysql -uroot --compress < /usr/alldb.sql

[quantum]

du får forklare kva du meiner litt nærmare

Er det dere poster argumenter mot noe jeg har skrevet, eller er det en tilfeldig opplisting av fakta relatert til dataintegritet? I tilfelle det siste så hopper jeg av her og nå tror jeg ... :-)