Mysql Errcode:28 "No space left on device"
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.
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
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 -
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.
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)
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.
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
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
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.