Mysql Errcode:28 "No space left on device"

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Daniel van Seggelen

Daniel van Seggelen

11/09/2019 11:52:23
Quote Anchor link
Probleem met schijfruimte directadmin tmp
Als ik df -h doe dan krijg ik een lijst part partities van de schijf.

ik zie /dev/mapper/vg_directadmin-lv_tmp van 9.8GB mounted on /tmp

Ik krijg met mysql altijd de error : "Error writing file '/tmp/MYTPomv' (Errcode:28 "No space left on device") ".
Ik heb 548 GB en maar 29% is in gebruik.

Snap niet hoe ik dit kan oplossen.
 
PHP hulp

PHP hulp

15/09/2019 17:08:00
 
Sylvester vader

sylvester vader

11/09/2019 13:40:27
Quote Anchor link
ok uhm misschien zeg ik dit fout hoor maar er zijn dan wel anderen die mij corrigeren

ik noem gewoon random even wat dingen op die je kunt checken
check je logs na deze worden vaak ook in tmp gezet en kunnen heeeeeeel groot worden
ook de mysql binary logs
deze kan je eventueel een beetje opschonen
haal je hele log leeg en
ik raad aan om in je
/etc/mysql/my.cnf
even deze line te zetten
expire_logs_days = 3
scheeld heel veel ellende


staat je tmp misschien op een partitie?
indien zo dan kan je eventueel in dezelfde file ook een andere locatie kiezen voor je tmp van mysql
 
Daniel van Seggelen

Daniel van Seggelen

12/09/2019 00:29:47
Quote Anchor link
ik heb 9.8GB en df -h geeft aan dat er 0%in gebruik is?
De /tmp folder is leeg. Dus hoe kan deze vol zijn?

http://www.globalwebdevelopment.net/df.png

Ik heb /etc/mysql/my.cnf in /etc/mysql.cnf staan

Dit is de screenshot:
http://www.globalwebdevelopment.net/mysql.png

Bedankt voor de tip om deze regel erin te zetten wat ik gedaan heb: expire_logs_days = 3
Gewijzigd op 12/09/2019 00:41:49 door - Ariën -
 
Willem vp

Willem vp

12/09/2019 09:36:03
Quote Anchor link
Ik zou sowieso adviseren om de tmpdir van MySQL op hetzelfde filesystem te zetten als je datadir. Daar heb ik twee -voor mezelf- belangrijke redenen voor:

1) Tabellen hebben bij mij de neiging om groter te worden dan de ruimte die in /tmp beschikbaar is (ik heb er tabellen van 400 GB tussen zitten) en als MySQL zo'n tabel moet optimaliseren of zo, maakt 'ie eerst een kopie van die tabel in de geconfigureerde tmpdir. Het is wel handig als daar voldoende ruimte is.

2) Als MySQL eenmaal die tabel in tmpdir heeft opgebouwd, moet 'ie verplaatst worden naar de datadir. Als de tmpdir op hetzelfde volume staat, is dat een kwestie van een paar milliseonden. Staat de nieuwe tabel op een ander volume (zoals /tmp) dan moet het gehele bestand worden gekopieerd en dat duurt veel langer.

In jouw geval (datadir=/var/lib/mysql) zou je de tmpdir naar /var/tmp kunnen zetten. Met een beetje geluk ben je dan ook meteen van je oorspronkelijke probleem bevrijd.

Op basis van de informatie die ik nu heb, kan ik niet direct een oorzaak geven voor die 'No space left'-meldingen, maar ik heb wel een paar ideeën.

- Een dergelijke melding bij voldoende diskruimte kan komen, doordat alle inodes in gebruik zijn. Dat kan gebeuren als er in /tmp een heleboel mappen of lege bestanden worden aangemaakt. Netto wordt er dan geen diskruimte gebruikt, maar het aantal bestanden dat je op een volume kan aanmaken heeft een limiet. Sommige software is net als mijn kinderen: ze maken rommel, maar opruimen vergeten ze nogal eens. Met het commando 'df -i' kun je per volume zien hoeveel inodes er nog beschikbaar zijn.

- Soms kan een 'no space left' worden veroorzaakt doordat een programma gewoon geen rechten heeft om in een bepaalde map te schrijven (is meestal het gevolg van een foutafhandeling die erg kort door de bocht is). In /tmp zou dat eigenlijk niet mogen voorkomen, maar misschien zijn door een tikfoutje de toegangsrechten van /tmp verkeerd komen te staan.
 
Thomas van den Heuvel

Thomas van den Heuvel

12/09/2019 12:26:44
Quote Anchor link
Sylvester vader op 11/09/2019 13:40:27:
expire_logs_days = 3

Afhankelijk van je MySQL versie is dat mogelijk niet genoeg.

Indien je databases alle de InnoDB engine gebruiken moet je mogelijk ook expliciet het volgende instellen:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
innodb_file_per_table=1

Maar ook dat is mogelijk niet afdoende want de data-files die voor caching zijn gebouwd bestaan reeds, en zullen ook alleen maar groeien. De enige remedie daarvoor, en ook om met een schone nieuwe lei te beginnen met deze nieuwe instellingen, is het dumpen van de databases, het verwijderen ervan, en het opnieuw aanmaken en importeren van de dumpbestanden.
 
Daniel van Seggelen

Daniel van Seggelen

13/09/2019 05:04:50
Quote Anchor link
Quote:
het dumpen van de databases, het verwijderen ervan, en het opnieuw aanmaken en importeren van de dumpbestanden.


Maar wat is de achterliggende bron hiervan? Waarom kunnen deze updates niet doorgevoerd worden zonder alles eerst te verwijderen?

Mijn /tmp file is neit leeg en heb nu 9.8 GB een tmp space. Ik heb deze regel geplaatst: expire_logs_days = 3 en lijkt te werken
 
Sylvester vader

sylvester vader

13/09/2019 12:07:18
Quote Anchor link
ja dan is het een cache probleem
ik zou als ik jouw was even je logs nakijken, waar wordt het meeste een log van gemaakt?!
misschien is er ergens een fout waardoor log snel vol loopt
 
Thomas van den Heuvel

Thomas van den Heuvel

13/09/2019 17:41:40
Quote Anchor link
Ik denk dat het eerst een zaak is dat je in kaart brengt waar de melding nu precies vandaan komt. Pas dan kun je gaan werken aan een oplossing. Waarom vindt MySQL dat er geen ruimte is? Lijkt me een redelijk cruciale vraag voor het formuleren van een oplossingsstrategie.

Misschien zou je cache bestanden via MySQL zelf kunnen purgen, maar wederom, dan ben je al met een oplossing bezig terwijl je de mogelijke oorzaak niet hebt weggenomen, en dan heb je over een tijd weer, of liever gezegd nog steeds, hetzelfde probleem.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.