Terugkerende MySQL InnoDB-corruptie op Ubuntu VPS

[m-m]

Lieve Mona,

Op onze Ubuntu productieserver (Feisty), draaiend op een VPS heeft sindskort last van een erg vervelend probleem: onze database blijft corrupt raken.

Vanuit het niets kregen we de volgende melding:

code:

Jun 23 09:13:03 webserver mysqld[3025]: InnoDB: Database page corruption on disk or a failed
Jun 23 09:13:04 webserver mysqld[3025]: InnoDB: file read of page 16605.
Jun 23 09:13:04 webserver mysqld[3025]: InnoDB: You may have to recover from a backup.
* page dump*

Meer log

Maw, wat normaliter zou moeten gebeuren (transactie terugdraaien) lukt niet. Dat kan eens gebeuren, maar niet meermaals in 2 dagen. MySQL raakt in een loop in een poging het te her stellen, en start dus steeds opnieuw (zonder resultaat) op.

De boel krijgen we ook niet handmatig gerepareerd: wat lukt is met force_recovery = 4 opstarten en zo een dump trekken. Het enige dat vervolgens lukt is de hele boel weggooien en opnieuw importeren. Daarna draait de boel weer.

Inmiddels hebben we onze database dumps geimporteerd op een externe server van de hoster, die we tijdelijk kunnen gebruiken. Deze is (tot nu toe ) feilloos blijven draaien, dus er zit niet iets heel raars in onze SQL-dumps of iets dat een applicatie doet.

Als ik de internets mag geloven, hoort dit eigenlijk niet te gebeuren, tenzij er sprake is van hardwarefaillure. De andere VPS-en op de machine hebben echter nergens last van en wij zien ook geen verdere problemen in onze VPS (geen filesystemproblemen, geen rare crashes/corruptie in andere processen). De hardware lijkt dus in orde te zijn.

Mijn collega heeft dit allemaal afgehandeld, dus ik kan wat details missen in m'n post (ik ben namelijk vrij deze week.). Kan dit uiteraard wel vanuit thuis bij die machine.

Rest mij te zeggen dat, voor zover we weten, er niets raars gebeurd is met onze machine: geen nieuwe versies van libraries of mysql, geen reboots, geen config veranderd. Het gaat out of the blue ineens mis

Weet iemand hier iets zinnigs over te zeggen?

[Keeper of the Keys]

Het is mij niet helemaal duidelijk is het absollut uitgesloten dat je harde schijf niet een paar badblocks heeft waar de db wordt opgeslagen?

[gertvdijk]

Welk filesystem?
Filesystem check gedaan?
MySQL up to date?

[m-m]

Keeper of the Keys schreef op woensdag 25 juni 2008 @ 18:51:
Het is mij niet helemaal duidelijk is het absollut uitgesloten dat je harde schijf niet een paar badblocks heeft waar de db wordt opgeslagen?

Dan zouden we (als het goed is) errors moeten zien. Filesystem check geeft ook geen errors vziw.

gertvdijk schreef op woensdag 25 juni 2008 @ 18:53:
Welk filesystem?

ext3

Filesystem check gedaan?

Jup, geen vuiltje aan de lucht.Bak is gereboot en toen is bij booten een fsck gedaan. Heb zelf het resultaat niet gezien, maar zou goed moeten zijn.

MySQL up to date?

Nieuwste versie die de heren van Canocial vertrouwd vinden iig. (mysqld Ver 5.0.38-Ubuntu_0ubuntu1.4-log for pc-linux-gnu on i486 (Ubuntu 7.04 distribution))

[ Voor 44% gewijzigd door m-m op 25-06-2008 19:47 ]

[BoAC]

Heb je al een memcheck uitgevoerd?

[m-m]

Volgens mij is dat vrij nietszeggend binnen onze VPS (niet dat we console-toegang hebben, dus we kunnen het niet doen), dus ze zouden het hele platform incl. alle overige klanten plat moeten gooien en vervolgens memtest draaien. Daar zit men, vermoed ik, niet echt op te wachten. Zeker niet gezien het feit dat wij de enigen met klachten zijn.

[igmar]

Welke kernel, en 32 of 64bits ? D'r is recent een bug gefixed die ervoor zorgde dat er pages corrupt raakten, maar die ging maar een aantal specifieke gevallen op.

[m-m]

Kernel is 2.6.19-4-server (ubuntu stock kernel). De architectuur is i686, 32-bits dus.

De hoster lijkt er redelijk van overtuigd te zijn dat de hardware in orde is,

[m-m]

Op internet vind ik iemand met een vergelijkbaar probleem. Alwaar vervolgens de combinatie MySQL en Xen in twijfel wordt getrokken. Nu was dat 2005, maar toch.

Daar wordt in ieder geval aangeraden om een MySQL-vriendelijke versie van de libc te installeren, dat bleek bij ons om onduidelijke redenen inderdaad niet het geval. Dit heb ik rechtgezet (package libc6-xen geinstalleerd). Hierna mysql gestopt en weer trachten te starten: dit wou niet ivm. wederom corruptie. Zelfs met force-recovery, kon hij er geen chocola meer van maken. Met een verse /var/lib/mysql en opnieuw geimporteerde backups draaien we nu weer.

[Zwerver]

m-m schreef op donderdag 26 juni 2008 @ 14:59:
Op internet vind ik iemand met een vergelijkbaar probleem. Alwaar vervolgens de combinatie MySQL en Xen in twijfel wordt getrokken. Nu was dat 2005, maar toch.

Daar wordt in ieder geval aangeraden om een MySQL-vriendelijke versie van de libc te installeren, dat bleek bij ons om onduidelijke redenen inderdaad niet het geval. Dit heb ik rechtgezet (package libc6-xen geinstalleerd). Hierna mysql gestopt en weer trachten te starten: dit wou niet ivm. wederom corruptie. Zelfs met force-recovery, kon hij er geen chocola meer van maken. Met een verse /var/lib/mysql en opnieuw geimporteerde backups draaien we nu weer.

Dan zouden wij er ook problemen mee moeten hebben:

Linux cp.a61.nl 2.6.18-6-xen-vserver-686 #1 SMP Thu May 8 12:02:29 UTC 2008 i686 GNU/Linux

Server version: 5.0.51a-log MySQL Community Server (GPL)

[TD-er]

Zou het kunnen dat jullie VPS een soft-limit heeft qua geheugengebruik?
Oftewel je hebt een gegarandeerd minimum vrij geheugen, maar als de rest het niet gebruikt kun je het gebruiken.
Is het trouwens een VPS (Dus met Virtuozo enz), of is het een XEN gebaseerde oplossing?
Bij XEN heb je vziw. namelijk per Dom-U een vaste hoeveelheid geheugen, terwijl je bij die Virtuozo-omgevingen dus ineens minder geheugen kunt hebben.
Wij hebben ook wel eens meegemaakt dat onze gehuurde VPS (bij Flexservers) ineens processen begon af te schieten. Gelukkig geen dataloss door gehad, maar fijn was anders. Leek wel op hoe Linux zich gedraagt wanneer het systeem claustrofobisch begint te doen als het geheugen op is. (incl swap)

[Beaves]

Je hebt ook OpenVZ, zeg maar een open-source tree (die wel achterloopt) op Virtuozzo. Echter blijft het principe natuurlijk hetzelfde, namelijk overboeking van geheugen en CPU.

Zeker als de hoster qua geheugen toewijzing zijn huiswerk niet goed gedaan heeft kan je inderdaad zeer vreemde resultaten krijgen zoals TD-er beschrijft.

[gertvdijk]

Zelf heb ik een Virtuozzo VPS en MySQL is al een paar keer gestorven zonder goede reden. Die tracebacks (of hoe heten die foutmeldingen) leveren mij ook niks nuttigs op. Het gebeurde wel telkens als er een piek in het geheugengebruik optrad en er een claustrofobische (leuke term in deze context) panieksituatie ontstaat, zo lijkt het. Ik was ook telkens bang voor dataverlies, maar gelukkig werd het telkens automatisch hersteld.
Maar voor zover ik weet heeft Xen deze exotische vorm van dynamische geheugentoewijzing helemaal niet dus lijkt het me ook niet zo van toepassing. Het is juist de reden waarom ik over wil naar een Xen VPS.

[Beaves]

Bij Xen heb je inderdaad non-overbooked geheugen. Nadeel is dan dus wel dat je voor elke host het geheugen wat je daaraan toewijst dan ook kwijt bent.