Bekijk Volledige Versie : /var voor 95% vol
Ik kreeg vandaag de melding dat mijn /var voor 95% vol zit. Ik kwam hier een oud bericht tegen http://www.webhostingtalk.nl/directadmin/125162-hardeschijf-vol.html#axzz2ChMniIII
Ik wil dit uitvoeren, maar heb geen ervaring met een perl bestand. Hoe wijzig ik dat? of moet je die zelf aanmaken?
Wel heb ik al het volgende in mijn my.cnf aangepast en mysql opnieuw gestart:
expire_logs_days=14
Wie kan me wat meer vertellen?
Post de output van "du -h --max-depth=0 /var/*" eens? En heb je logrotate goed ingesteld?
Ik zou eerst eens kijken waar het ruimte gebrek door ontstaat. Onderstaande commando geeft je een opsomming van alle bestanden groter dan 20mb in /var
find /var -type f -size +20000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'
@SF-Jeroen
12K /var/account
18M /var/cache
28K /var/db
32K /var/empty
8,0K /var/games
1017M /var/lib
8,0K /var/local
32K /var/lock
588M /var/log
8,0K /var/logs
16K /var/lost+found
4,0K /var/mail
116K /var/named
8,0K /var/nis
8,0K /var/opt
8,0K /var/preserve
8,0K /var/racoon
364K /var/run
612K /var/spool
8,0K /var/tmp
335M /var/www
24K /var/yp
Maar dat wil ik dus weten hoe je die logrotate goed instelt.
@DiederickL
Er stonden allemaal bestanden van 1 GB van mysql-bin.000015 en .00016 enz.
Na het toevoegen van die regel in my.cnf zijn die grote regel weg. Er staan er nu nog 2 van 381M en 175M verder nog een /log/btmp van 497M
Dank
MySQL replicatie / binlog uitzetten als het om een standalone server gaat. Wanneer je LVM gebruikt (Wat is de output van "df -h"?) zou je nog wat kunnen schuiven met partities. Mocht de nood echt hoog zijn kun je altijd nog de 5% reserve aanspreken met "tune2fs -m 1 /dev/DEVICE" en snel 4% winnen. Vaak geeft je dat wat tijd om zaken permanent op te lossen zonder dat je SQL data corrupt wordt door een volle disk.
SebastiaanStok
20/11/12, 09:20
MySQL binlog zomaar uitzetten is nou niet zo handig :)
http://dev.mysql.com/doc/refman/5.0/en/binary-log.html
Het word ook gebruikt voor recovery, aangezien je niet elke 1 seconde een back-up maakt houd de binlog bij welke wijzigingen er zijn uitgevoerd en kan ze zo bij een crash weer overdoen. Aangezien de disk bijna vol is en MySQL volledig in de soep loopt met een volle disk zou ik dit niet zomaar uitschakelen.
Als je disk nu vol is kan je te minste nog je data redden, zonder binlog ben je overgeleverd aan de goden.
Binlog word alleen gebruikt voor InoDB, en is één van de redenen waarom dit een betere storage is dan MyISAM.
Binlog volledig weghalen kan groten gevolgen hebben.
InnoDB werkt met transacties en Foreign keys, deze zijn alleen te vertrouwen met een goed logboek dat bijhoud wat er precies is of word gewijzigd.
Als je database crasht tijdens een transactie weet je of data wel veilig is ja of nee en of er al gedeeltelijk is geschreven.
Verwijder ze dus niet zomaar.
http://systems.takizo.com/2009/08/23/how-to-remove-mysql-binary-log/
http://www.mysqlperformanceblog.com/2009/05/14/why-mysqls-binlog-do-db-option-is-dangerous/
Verwijder alleen binlogs die ouder zijn dan de laatste back-up.
Okee dus de ene zegt wel uitzetten, de andere niet.
Maar ondertussen weet ik nog niet hoe ik die logrotate nu in moet stellen.
Je /var partitie is gewoon veel te klein (2GB?). Kun je beter vergroten, of, als je niet zeker bent van je zaak en de boel niet te lang offline mag, een symlink maken voor /var/lib/mysql naar je grootste partitie.
Uhmm Hij is 20 GB
/dev/mapper/VolGroup00-LogVol00
7935392 679480 6846312 10% /
/dev/sda6 988088 22340 914744 3% /tmp
/dev/sda5 11904588 1695672 9594432 16% /usr
/dev/sda3 19840924 2416376 16400408 13% /var
/dev/sda2 897400740 246555328 604524396 29% /home
/dev/sda1 101086 18437 77430 20% /boot
tmpfs 1947936 0 1947936 0% /dev/shm
Op dat overzicht staat dat er maar 13% van de partitie in gebruik is? Maar wat betreft logrotate, ik kan nu wel een lang verhaal gaan typen hoe het werkt, maar het staat gewoon hier: http://linux.die.net/man/8/logrotate