ERROR: The partition with /var/lib/mysql is too full!

[MarkieMenn]

Beste Lezer,

Ik draai hier zarafa.

Nu wil deze helaas niet meer starten.
na het nodige uitgezocht te hebben ben ik erachter gekomen dat mysql niet meer start.

Als ik het command etc/init.d/mysql restart geef krijg ik de melding
ERROR: The partition with /var/lib/mysql is too full!

na wat gegoogled te hebben schijnt dus dat de map te groot is en dat daarom mysql niet start.
ik heb alleen te weinig verstand van het systeem om zomaar te weten wat er weg kan.

hieronder een overzicht van wat zich allemaal in de map staat.
kunnen jullie mij alstublieft helpen met wat er weg kan, en hoe het probleem op te lossen.
ik word er helemaal gek van.

code:

root@zarafa1:/var/lib/mysql# ls -lah
total 254G
drwxr-xr-x  4 mysql mysql 4,0K 2010-08-01 13:30 .
drwxr-xr-x 37 root  root  4,0K 2010-08-01 13:27 ..
-rw-r--r--  1 mysql mysql    0 2010-02-18 16:56 debian-5.0.flag
-rw-rw----  1 mysql mysql 253G 2010-08-01 12:54 ibdata1
-rw-r--r--  1 mysql mysql 5,0M 2010-08-01 12:54 ib_logfile0
-rw-r--r--  1 mysql mysql 5,0M 2010-08-01 12:53 ib_logfile1
-rw-rw----  1 mysql mysql   54 2009-09-28 14:28 master.info
drwxr-xr-x  2 mysql mysql 4,0K 2010-02-18 16:56 mysql
-rw-r--r--  1 mysql mysql  26K 2009-09-01 05:42 mysqld-bin.000001
-rw-r--r--  1 mysql mysql 9,2K 2009-09-02 05:47 mysqld-bin.000002
-rw-r--r--  1 mysql mysql 155K 2009-09-02 14:13 mysqld-bin.000003
-rw-r--r--  1 mysql mysql 6,5K 2009-09-02 14:25 mysqld-bin.000004
-rw-r--r--  1 mysql mysql  39K 2009-09-03 05:53 mysqld-bin.000005
-rw-r--r--  1 mysql mysql  93K 2009-09-04 05:37 mysqld-bin.000006
-rw-r--r--  1 mysql mysql  24K 2009-09-04 14:13 mysqld-bin.000007
-rw-rw----  1 mysql mysql 4,1K 2009-09-06 06:31 mysqld-bin.000008
-rw-rw----  1 mysql mysql 4,1K 2009-09-07 06:54 mysqld-bin.000009
-rw-rw----  1 mysql mysql  21K 2009-09-07 13:19 mysqld-bin.000010
-rw-r--r--  1 mysql mysql  140 2009-09-04 05:37 mysqld-bin.index
-rw-rw----  1 mysql mysql  117 2009-09-28 14:35 mysqld-relay-bin.000036
-rw-rw----  1 mysql mysql   26 2009-09-28 14:28 mysqld-relay-bin.index
-rw-r--r--  1 mysql mysql    7 2009-08-26 11:59 mysql_upgrade_info
-rw-rw----  1 mysql mysql   33 2009-09-28 14:28 relay-log.info
drwxr-xr-x  2 mysql mysql 4,0K 2009-12-14 10:06 zarafa

Bij voorbaat dank,

[ Voor 0% gewijzigd door blaataaps op 01-08-2010 13:47 . Reden: leesbaarheid met code-tags ]

[CyBeR]

na wat gegoogled te hebben schijnt dus dat de map te groot is en dat daarom mysql niet start.

Dat is letterlijk de foutmelding. Dat had je niet hoeven googlen.

Anyway, je disk zit dus vol. Je zult ofwel data weg moeten gooien, ofwel je diskspace moeten uitbreiden. D'r is niets in die directory wat weg kan en zoden aan de dijk zet.

[ Voor 10% gewijzigd door CyBeR op 01-08-2010 13:48 ]

[blaataaps]

CyBeR schreef op zondag 01 augustus 2010 @ 13:48:
[...]


Dat is letterlijk de foutmelding. Dat had je niet hoeven googlen.

Anyway, je disk zit dus vol. Je zult ofwel data weg moeten gooien, ofwel je diskspace moeten uitbreiden. D'r is niets in die directory wat weg kan en zoden aan de dijk zet.

code:

 253G 2010-08-01 12:54 ibdata1

Vind ik anders wel een goede kandidaat om ruimte te reclaimen (afhankelijk van de huidige data-set). Niet om weg te gooien, maar dit bestand groeit alleen maar, als er dingen verwijderd worden, blijft de vrijkomende ruimte gereserveerd, en niet teruggegeven aan het filesystem.

Hoe groot is je database? Hoe groot is je filesystem? Hoe groot is de zarafa directory?

[odysseus]

De vraag is wel of dat bestand 'ibdata1' zo groot moet zijn. Ik kan me lastig voorstellen dat je een database van ruim 250GB beheert en niet weet wat je met de genoemde foutmelding moet, dus misschien gaat er iets mis met je Zarafa-installatie waardoor er plotseling zo veel ruimte gebruikt wordt?

Overigens is de oplossing dus niet om dat bestand gewoon te verwijderen, voor de duidelijkheid .

[MarkieMenn]

de ibdata1 is inderdaad 250gb dat klopt.

Filesystem Size Used Avail Use% Mounted on
/dev/cciss/c0d0p1 532G 507G 0 100% /
varrun 7,9G 88K 7,9G 1% /var/run
varlock 7,9G 0 7,9G 0% /var/lock
udev 7,9G 44K 7,9G 1% /dev
devshm 7,9G 0 7,9G 0% /dev/shm
overflow 1,0M 0 1,0M 0% /tmp


verder krijg ik dit.

[odysseus]

De vraag is waarom dat bestand zo groot is. Klopt dat? Sla je inderdaad voor 250GB aan belangrijke data op? Zo ja, dan zal je gewoon je schijfruimte moeten uitbreiden. Zo niet, dan is de vraag wat voor data er dan opgeslagen wordt die niet belangrijk is. Kan de database opgeruimd worden op een of andere manier? Hoe kan je voorkomen dat hij weer zo groot wordt?

[MarkieMenn]

er word inderdaad 250gb aan belangrijke data opgeslagen.
er zal dus inderdaad schijfruimte bij moeten komen.

is er misschien ook een tijdelijke oplossing om hem weer aan de praat te krijgen.

[blaataaps]

Als er 250 gigabyte aan belangrijke data is opgeslagen, waarom is er dan ruim 500 in gebruik? En natuurlijk is er een tijdelijke oplossing, dingen weggooien
Misschien staat /var/log/ wel vol met dingen, of her en der nog database-backups, maar die kunnen we vanaf hier niet zien

[CyBeR]

blaataaps schreef op zondag 01 augustus 2010 @ 13:52:
[...]

code:

 253G 2010-08-01 12:54 ibdata1

Vind ik anders wel een goede kandidaat om ruimte te reclaimen (afhankelijk van de huidige data-set). Niet om weg te gooien, maar dit bestand groeit alleen maar, als er dingen verwijderd worden, blijft de vrijkomende ruimte gereserveerd, en niet teruggegeven aan het filesystem.

Ja, dat kan dus niet Maar aangezien ibdata files alleen groeien als er data bij moet (als ze 'loze ruimte' bevatten wordt die eerst opgevuld) mag je er vanuit gaan dat dat ding ook echt vol zit. En dan moet er dus extra disk space bij. Of, inderdaad en dat was nog niet bekend hierboven, er moet wat van die ~ 230 andere gigabytes weggegooid worden.

[ Voor 7% gewijzigd door CyBeR op 01-08-2010 14:22 ]

[MarkieMenn]

Ik denk dat ik het probleem gevonden hebt.
Zo te zien is de back-up verkeerd weggeschreven.
waardoor er nu een extra back-up van 220 gb erbij staat.

als ik deze verplaats naar een externe hd zou het weer moeten werken toch?


root@zarafa1:/backup/zarafa# ls -lah
total 220G
drwxr-xr-x 2 root root 4,0K 2010-08-01 01:00 .
drwxrwxrwx 4 root root 4,0K 2010-08-01 13:12 ..
-rw-r--r-- 1 root root 220G 2010-08-01 11:11 2010-08-01-zarafa.dump

[Kees]

MarkieMenn schreef op zondag 01 augustus 2010 @ 14:21:
Ik denk dat ik het probleem gevonden hebt.
Zo te zien is de back-up verkeerd weggeschreven.
waardoor er nu een extra back-up van 220 gb erbij staat.

als ik deze verplaats naar een externe hd zou het weer moeten werken toch?


root@zarafa1:/backup/zarafa# ls -lah
total 220G
drwxr-xr-x 2 root root 4,0K 2010-08-01 01:00 .
drwxrwxrwx 4 root root 4,0K 2010-08-01 13:12 ..
-rw-r--r-- 1 root root 220G 2010-08-01 11:11 2010-08-01-zarafa.dump

Je krijgt een error dat je schijf te vol is, je vraagt hier of het gaat helpen als je die schijf leger maakt. Wat denk je zelf?.

[Rainmaker]

Geen volume manager of niks?

Eventueel kun je nog proberen om je / partitie te vergroten.

Hoe groot zijn de disken erin?

code:

hpacucli controller slot=0 physicaldrive all show

[DiedX]

Kees schreef op zondag 01 augustus 2010 @ 15:10:
[...]

Je krijgt een error dat je schijf te vol is, je vraagt hier of het gaat helpen als je die schijf leger maakt. Wat denk je zelf?.

Kees' antwoord is dus ja.

In het kort:

* MySQL platgooien
* Backup naar externe disk gooien, backup weggooien op lokale schijf
* MySQL Starten, Zarafa restarten (vermoed ik)
* Uitzoeken of die database zo groot moet zijn (220GB aan mail is *VEEL*).

Eerder is het al gezegd: MySQL gooit geen data in fysieke bestanden weg (eigenlijk *DE* reden waarom ik een hekel heb aan MySQL). Naar mijn weten is de enige manier om te reclaimen te dumpen naar SQL, database weg te gooien, en te importen. Als de laatste zin je niets zegt, neem dan in godsnaam een professional in dienst...

[CyBeR]

DiedX schreef op vrijdag 06 augustus 2010 @ 14:55:
[...]
Naar mijn weten is de enige manier om te reclaimen te dumpen naar SQL, database weg te gooien, en te importen.

Sowieso geldt dat naar mijn weten alvast niet voor MyISAM tabellen. Maar met InnoDB kun je, als je de innodb_file_per_table setting op 1 zet, wel degelijk tablespace reclaimen. Dat kan door een lege ALTER TABLE <tabel> Type=InnoDB te doen. De file wordt dan herschreven.

[Rainmaker]

Toch even nuanceren:

Het is niet /var/lib/mysql die vol zit. Het is je root FS, waar, op jouw server, ook /var/lib/mysql ondervalt.

Kijk nog even verder dan deze directory, want voor hetzelfde geld moet je gewoon logrotate aanzetten...

[CyBeR]

Rainmaker schreef op vrijdag 06 augustus 2010 @ 22:29:
Toch even nuanceren:

Het is niet /var/lib/mysql die vol zit. Het is je root FS, waar, op jouw server, ook /var/lib/mysql ondervalt.

Dat staat er ook:

ERROR: The partition with /var/lib/mysql is too full!

[DiedX]

CyBeR schreef op vrijdag 06 augustus 2010 @ 15:59:
[...]


Sowieso geldt dat naar mijn weten alvast niet voor MyISAM tabellen. Maar met InnoDB kun je, als je de innodb_file_per_table setting op 1 zet, wel degelijk tablespace reclaimen. Dat kan door een lege ALTER TABLE <tabel> Type=InnoDB te doen. De file wordt dan herschreven.

Ok! Dan heb ik ook wat erbij geleerd

En /var staat inderdaad in /, maar dat veranderd niets aan de zaak (behalve dat hij best instabiel is)

[Rainmaker]

DiedX schreef op vrijdag 06 augustus 2010 @ 23:26:
[...]

En /var staat inderdaad in /, maar dat veranderd niets aan de zaak (behalve dat hij best instabiel is)

Mijn punt was; de TS heeft een root volume van 532GB.

In /var/lib/mysql staat "maar" 254GB.
In /backup/zafara staat 220GB

Bij elkaar 470GB.

Dan zou er nog zo'n 60GB ergens anders heen zijn. Zeg 20-30GB voor het OS, is nog "ergens" waar je 30GB op kan besparen.

Vandaar; kijk even verder dan deze directories.

[DiedX]

Rainmaker schreef op zaterdag 07 augustus 2010 @ 12:15:
[...]

Vandaar; kijk even verder dan deze directories.

Valide punt.

TS:

cd /
du -hs *

[Snow_King]

Ander punt voor de volgende keer: Partities zijn er niet voor niets Deel dat filesystem op in meerdere losse partities. Als je iets niet wil is dat je database danwel mailqueue ruimte te kort komen bij het wegschrijven.

[CyBeR]

Snow_King schreef op zaterdag 07 augustus 2010 @ 14:54:
Ander punt voor de volgende keer: Partities zijn er niet voor niets Deel dat filesystem op in meerdere losse partities. Als je iets niet wil is dat je database danwel mailqueue ruimte te kort komen bij het wegschrijven.

Precies. Dan loop je tenminste nog eerder tegen je limieten aan, en heb je tenminste niet de mogelijkheid om wat data heen en weer te schuiven om disk ruimte vrij te maken.

[ Voor 11% gewijzigd door CyBeR op 07-08-2010 14:57 ]

[GlowMouse]

CyBeR schreef op vrijdag 06 augustus 2010 @ 15:59:
[...]


Sowieso geldt dat naar mijn weten alvast niet voor MyISAM tabellen. Maar met InnoDB kun je, als je de innodb_file_per_table setting op 1 zet, wel degelijk tablespace reclaimen. Dat kan door een lege ALTER TABLE <tabel> Type=InnoDB te doen. De file wordt dan herschreven.

Daar krimpt ibdata1 niet van hoor, alleen de file waar die tabel in terechtkomt nadat die setting aan staat.

[CyBeR]

GlowMouse schreef op zaterdag 07 augustus 2010 @ 15:00:
[...]

Daar krimpt ibdata1 niet van hoor, alleen de file waar die tabel in terechtkomt nadat die setting aan staat.

Klopt, die setting moet je dan ook al in het begin aan hebben gezet.

Learned that the hard way, trouwens.

[ Voor 6% gewijzigd door CyBeR op 07-08-2010 15:02 ]

[Snow_King]

CyBeR schreef op zaterdag 07 augustus 2010 @ 14:56:
[...]


Precies. Dan loop je tenminste nog eerder tegen je limieten aan, en heb je tenminste niet de mogelijkheid om wat data heen en weer te schuiven om disk ruimte vrij te maken.

Sorry, maar is deze post sarcastisch bedoeld? Ik volg je even niet.

Uiteraard is het slim om je MySQL en mailqueue op een Zarafa systeem aparte partities te geven, zeker als je daar onder LVM gebruikt.

Dan kan een backup op je systeem of een rogue logfile er nooit voor zorgen dat je service in de problemen komt.

En met LVM en een modern filesystem als ext4 (al kan ext3 het ook) kan je ook nog eens shrinken en growen waar nodig.

[Verwijderd]

Wat een onzin om daar losse partities voor te gebruiken. Dat je een losse partitie gebruik zodat je die met andere flags kunt mounten, ok. Maar tegen het vollopen van partities helpt andere partitionering niet. Monitoring helpt wel. Je hoort er veel eerder achter te komen dat er iets misgaat.

Overigens ben ik het eens met odysseus. Als de TS een systeem met een database met 250 GB aan belangrijke data beheert, is het tijd om iemand te zoeken die dat wél kan.

[CyBeR]

Snow_King schreef op zaterdag 07 augustus 2010 @ 15:10:
[...]
Sorry, maar is deze post sarcastisch bedoeld? Ik volg je even niet.

Uiteraard is het slim om je MySQL en mailqueue op een Zarafa systeem aparte partities te geven, zeker als je daar onder LVM gebruikt.

Dan kan een backup op je systeem of een rogue logfile er nooit voor zorgen dat je service in de problemen komt.

En in plaats daarvan heb je geen back-up of geen logging meer. Beide belangrijke zaken.

Zoals cheetah zegt: monitoring is wat je nodig hebt.

En met LVM en een modern filesystem als ext4 (al kan ext3 het ook) kan je ook nog eens shrinken en growen waar nodig.

LVM is kut, maar daar gaat 't hier niet over.

[Snow_King]

Verwijderd schreef op zaterdag 07 augustus 2010 @ 15:19:
Wat een onzin om daar losse partities voor te gebruiken. Dat je een losse partitie gebruik zodat je die met andere flags kunt mounten, ok. Maar tegen het vollopen van partities helpt andere partitionering niet. Monitoring helpt wel. Je hoort er veel eerder achter te komen dat er iets misgaat.

Stukje nuance mag wel, om het direct als "onzin" af te schrijven is zeker niet zo.

Uiteraard, monitoring is nummer #1 hier, maar losse partities hebben wel zeker zin als je systeem meerdere services draait. Want soms kan je ergens niet snel genoeg bij zijn en dan wil je niet dat je MySQL server je Postfix om zeep kan helpen of vise-versa.

Voor alles is wat te zeggen, maar losse partities zijn er niet voor niets. (En ja, ze zijn er ook voor multi-fs filesystem, andere flags, etc, etc).

[lamko]

CyBeR is ook kut

[Verwijderd]

Snow_King schreef op zaterdag 07 augustus 2010 @ 15:28:
Stukje nuance mag wel, om het direct als "onzin" af te schrijven is zeker niet zo.

Ik vind het ook geen onderwerp om genuanceerd over te gaan doen. Serverbeheer is een serieus vak, echter sluipt het gemakzucht van de onervaren mensen steeds overal tussendoor. Die denken het ook wel even te kunnen, maar missen de ervaring om problemen te voorkomen.

Uiteraard, monitoring is nummer #1 hier, maar losse partities hebben wel zeker zin als je systeem meerdere services draait. Want soms kan je ergens niet snel genoeg bij zijn en dan wil je niet dat je MySQL server je Postfix om zeep kan helpen of vise-versa.

Dit is dus die onzin. Als MySQL en Postfix met reden op dezelfde machine staan zijn ze even belangrijk. Als er een partitie volloopt is dat een serieus probleem en kan dat vele andere problemen veroorzaken. Door te gaan onderverdelen heb je het risico dat de problemen invloed hebben op alle andere services verkleind, maar het risico voor elke individuele service vergroot. Er zijn andere manieren om het allesomvattende probleem te voorkomen. Quota instellen bijvoorbeeld. Dat zorgt er ook voor dat een partitie niet kan vollopen door een te grote mailqueue of een backup. En je bent wel iets flexibeler dan met losse partities.

Voor alles is wat te zeggen, maar losse partities zijn er niet voor niets. (En ja, ze zijn er ook voor multi-fs filesystem, andere flags, etc, etc).

Losse partities zijn er inderdaad met een reden. Als je niet wilt dat iets een partitie kan volproppen moet je dáár iets aan doen. Je moet proberen het daadwerkelijke probleem te vinden. Het aanmaken van extra partities zorgt voor lastiger beheer, minder opties in geval van problemen.

[Kees]

Snow_King schreef op zaterdag 07 augustus 2010 @ 15:28:
[...]
Stukje nuance mag wel, om het direct als "onzin" af te schrijven is zeker niet zo.

Uiteraard, monitoring is nummer #1 hier, maar losse partities hebben wel zeker zin als je systeem meerdere services draait. Want soms kan je ergens niet snel genoeg bij zijn en dan wil je niet dat je MySQL server je Postfix om zeep kan helpen of vise-versa.

Voor alles is wat te zeggen, maar losse partities zijn er niet voor niets. (En ja, ze zijn er ook voor multi-fs filesystem, andere flags, etc, etc).

Losse partities zijn voornamelijk een PITA voor als je data legitiem groter wordt dan wat je in eerste instantie ervoor geallocceerd hebt, en de tools om ze te shrinken/growen zijn gewoon gevaarlijk over het algemeen, en zorgen iig voor downtime op het systeem.

Daarom ben ik ook zo gecharmeert van nieuwe FS'en alla zfs en btrfs, die dat soort dingen veel beter geregeld hebben.

Aparte partities heb ik nog nooit een goede reden voor gezien, alleen maar excuses, en ik gebruik het alleen maar om hardware te scheiden (bv raid-1 op een paar kleine disks voor je OS, en een raid-xx op een stel ssd's voor je data).

[Snow_King]

Verwijderd schreef op zaterdag 07 augustus 2010 @ 15:49:
[...]

Ik vind het ook geen onderwerp om genuanceerd over te gaan doen. Serverbeheer is een serieus vak, echter sluipt het gemakzucht van de onervaren mensen steeds overal tussendoor. Die denken het ook wel even te kunnen, maar missen de ervaring om problemen te voorkomen.

Jammer dat er met jou geen discussie te voeren valt. Jij vindt dat hoe jij er over denkt dé manier is, want jij bent immers de pro en de gene die weet hoe alles precies moet.

Er zijn meerdere wegen naar Rome en voor elke weg is iets te zeggen.

[blaataaps]

Snow_King schreef op zaterdag 07 augustus 2010 @ 16:17:
[...]
Jammer dat er met jou geen discussie te voeren valt. Jij vindt dat hoe jij er over denkt dé manier is, want jij bent immers de pro en de gene die weet hoe alles precies moet.

Er valt toch prima over te discussieren? Hij en Kees geven prima argumenten waarom losse partities meestal gewoon een slecht idee is?

[Snow_King]

blaataaps schreef op zaterdag 07 augustus 2010 @ 16:40:
[...]

Er valt toch prima over te discussieren? Hij en Kees geven prima argumenten waarom losse partities meestal gewoon een slecht idee is?

Bij een discussie begin je niet met "onzin" en de ander afschrijven als een "amateur" (Wat niet in directe woorden gebeurde).

Kees komt gewoon netjes met een onderbouwde post, zonder daarbij direct te flamen.

Blijkbaar denken er mensen anders over dit onderwerp (paritionering), maar laat elkaar dan wel in waarde en zie elkaars argumenten en begin zeker niet over het ervarings-niveau van iemand, aangezien je dat niet kan weten.

Want het is eigenlijk een erg interessant punt, waar van alles over te zeggen is, waar imho voor elk punt iets te zeggen is en het ook helemaal afhankelijk van de situatie en de wensen is.

[Keeper of the Keys]

Om nog even terug te komen op wat er op de vorige pagina is gezegd:
Volgens een post in MySQL bug#1287 kun je als de InnoDB tabellen zijn gescheiden in apparte bestanden OPTIMIZE TABLE gebruiken om de individuele tabellen opnieuw te laten bouwen en de ruimte te reclaimen.

Er van uitgaande dat het root-fs een vrij standaard ext3 of ext4 setup is:
Zou het niet kunnen dat een deel van de "verdwenen" 60/30 GB de voor root-only gereserveerde fs blokken zijn? Als het fs standaard is ingesteld is dat 5% en 5% van 532 GB is ca. 26 GB.
Als de MySQL server of de Zarafa server als een eigen gebruiker draaien dan kunnen ze niet aan die 25GB zitten als ik me niet vergis.

Het verkleinen van de reserved blocks is sowieso bij zulke grote partities meestal een goed idee met 1% heb je nog steeds ca. 5 GB gereserveerd en heb je in een keer ruim 20 GB 'terug'.

tune2fs is dan de tool die je wil.

Met du vind ik het altijd handig om --max-depth=1 of 2 te gebruiken ipv. du -sh *

[Verwijderd]

Hey MarkyMenn,

Volgens mij laat je zarafa ook nog eens de attachments in de db opslaan. Dit kan je ook eruit halen want die binaire data is de database is kost je meer ruimte dan wanneer de data gewoon als files zijn opgeslagen!

[Rainmaker]

Verwijderd schreef op woensdag 11 augustus 2010 @ 21:42:
Hey MarkyMenn,

Volgens mij laat je zarafa ook nog eens de attachments in de db opslaan. Dit kan je ook eruit halen want die binaire data is de database is kost je meer ruimte dan wanneer de data gewoon als files zijn opgeslagen!

Want geruikers hebben die attachements op hun mail toch niet nodig?

[Verwijderd]

Zarafa heeft de mogelijkheid je attachments als blobs in de db op te slaan, of als files ergens op het filesystem.