Bekijk Volledige Versie : Hardeschijf vol
ErikKosters
04/10/07, 00:07
Beste WHT-ers,
Ik heb vandaag wat gehad met DirectAdmin dat ik graag met jullie wil delen aangezien ik dit wel intressant genoeg vondt om een topic te starten/howto te starten.
Dit alles naar aanleiding van een e-mail welke ik kreeg per e-mail, het zou zijn dat 1 van mijn DirectAdmin servers bijna vol was (80GB hardeschijf). Deze mail ontving ik:
Subject: Warning: The disk usage for one or more of your partitions is running low Today at 16:22
This is an automated message notifying you that the following partition(s) have exceeded the 95% threshold:
95% - /
================================
Automated Message Generated by DirectAdmin
Nougoed dit kan gebeuren dacht ik, maar naar nader onderzoek leek het niet helemaal pluis te zijn. Ben toen maar even gaan zoeken naar grote bestanden met het commando:
find / -type f -size +20000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'
Deze gaf al snel vele resultaten welke tot mijn verbazing zich bevonden in /var/log/ en /var/lib/mysql. Al gauw kwam ik tot de conclussie dat het aan de rotatie logfiles en die van mysql lag. Ben toen even gaan kijken welke files er allemaal stonden, bij /etc/log/ heb ik even alle bestanden met .1, .2, etc. verwijderd aangezien dat oudere logs zijn.
Daarna nog even gekeken in /var/lib/mysql, bleek dat er meerdere files (stuk of 20 als ik me niet vergis) van 1gb per stuk in stonden welke als log diende voor mysql. Naar al deze bestanden te hebben verwijderd werkte alles naar behoren en had ik tot mijn grote verbazing ineens 50GB vrij (zo'n 45GB vrijgemaakt dus). Ik ben hierna even gaan rondkijken op google waardoor die bin files werden aangemaakt, deze bestanden lijken niet echt nodig te zijn en je kon de config wijzigen om mysql deze bestanden niet te laten aanmaken.
nano /etc/my.cnf
zet nu # voor log-bin en sla het bestand op
Ik hoop dat jullie hier wat aan hebben, het scheeld sowieso om om de zoveel tijd even te kijken naar grote files welke geen nut hebben.
Succes!
Let wel.. die log-bin bestanden zijn *wel* nodig als je MySQL replicatie gebruikt.
Om de MySQL logs automatisch te verwijderen (zie parameter in het script hoeveel je er wilt bewaren):
#!/usr/bin/perl -w
## Purge the replication logs if there are too many
## sitting around sucking up disk space.
use strict;
use DBIx::DWIW;
my $MIN_LOGS = 4; ## <-- keep main log plus three old binary logs around
my $conn = DBIx::DWIW->Connect(
DB => "mysql",
User => "root",
Pass => "password",
Host => 'localhost',
);
die "Couldn't connect to database!" if not $conn;
## see if there are enough to bother, exit if not
my @logs = $conn->FlatArray("SHOW MASTER LOGS");
exit if (@logs < $MIN_LOGS);
## if so, figure out what the last one we want to keep is, then purge
## the rest
my $last_log = $logs[-$MIN_LOGS];
print "last log is $last_log\n" unless $ENV{CRON};
$conn->Execute("PURGE MASTER LOGS TO '$last_log'");
exit;
Altijd interessant, ga hem opslaan.
ErikKosters
04/10/07, 00:31
Let wel.. die log-bin bestanden zijn *wel* nodig als je MySQL replicatie gebruikt.
Om de MySQL logs automatisch te verwijderen (zie parameter in het script hoeveel je er wilt bewaren):
#!/usr/bin/perl -w
## Purge the replication logs if there are too many
## sitting around sucking up disk space.
use strict;
use DBIx::DWIW;
my $MIN_LOGS = 4; ## <-- keep main log plus three old binary logs around
my $conn = DBIx::DWIW->Connect(
DB => "mysql",
User => "root",
Pass => "password",
Host => 'localhost',
);
die "Couldn't connect to database!" if not $conn;
## see if there are enough to bother, exit if not
my @logs = $conn->FlatArray("SHOW MASTER LOGS");
exit if (@logs < $MIN_LOGS);
## if so, figure out what the last one we want to keep is, then purge
## the rest
my $last_log = $logs[-$MIN_LOGS];
print "last log is $last_log\n" unless $ENV{CRON};
$conn->Execute("PURGE MASTER LOGS TO '$last_log'");
exit;
Bedankt voor de toevoeging, dit klopt inderdaad. Verder kan men ook nog de oude exim logs verwijderen, deze staan in /var/log/exim/. Hier kan met dus *.1, .2 etc weghalen. Wel jammer dat al die logs en dergelijke zoveel schijfruimte opslurpen, uiteraard is het aan de andere kant altijd wel handig dat logs gemaakt worden :).
.bin files zijn naast replicatie ook nuttig voor crash recovery.
ErikKosters
04/10/07, 07:34
Ik mag toch aannemen dat men backups maakt.
crazycoder
04/10/07, 07:55
Ik mag toch aannemen dat men backups maakt.
Dat denkt men ook van de hoster :p
Een stukje regelmatig systeembeheer omvat toch ook wel preventief controleren en zodra iets dergelijks gaat dreigen log je via de mysql client in en smijt je een stapel van die bestanden wel.
Op een server die goed in is gericht is dat niet eens zo gek vaak nodig.. moet je natuurlijk wel voldoende schijfruimte hebben..
ErikKosters
04/10/07, 08:06
Het ging hier bij mij toevallig om een dedicated server van een klant waarvan ik het beheer deed. Dit was een budget server en daar zat een 80GB hardeschijf in, daarom ;).
BTW, een aantal logfiles oke.. maar ik had in totaal like 45GB aan die zooi ;).
Zelf met backup's zijn mysqlbin's vrij nuttig in het recoveren (stuk tussen je backup en het moment dat je sql kapot is gegaan).
Verder ook heel handig voor performance tweaking.
Dus niet zomaar weggooien!
Het is beter om
expire_logs_days=14
in je my.cnf op te nemen dan ipv
# log-bin
Eventueel kan de log days korter in gestelt worden, bijvoorbeeld 3 dagen ofzo. Dan heb je nog wel een paar van die log files staan, maar worden de files automatisch voor je opgeruimt.
Zoals hierboven al gemeld is het soms handig om nog enkele van deze log-bin files te hebben bij een recovery.
ErikKosters
04/10/07, 21:57
Bedankt, als een mod even dit in de beginpost wil zetten zou dat mooi zijn.
En als je dan nog verder wil, kijk meteen in de /etc/logrotate.conf (centos) file. Pas daar het volgende aan:
# keep 4 weeks worth of backlogs
rotate 4
Naar een lager getal, en dan heeft die ook minder .1 .2 .3 .4 (in dit geval) aan files.
Eventueel is ook
# uncomment this if you want your log files compressed
#compress
te enablen. Dan compressed (.tar.gz) die de history files.
Ik mag toch aannemen dat men backups maakt.
Nuttig en goed dat je dit soort zaken even plaatst.
De meeste hosters maken gebruik van mysqldump voor backups, maar binary logs en archive logs zijn bij de grote databases (oracle) heel gebruikelijk. Je kunt dan een point in time recovery maken. Deze vorm van logging heeft natuurlijk geen nut als je het op dezelfde server plaatst op dezelfde hardeschijf...
Daarnaast is het soms te zwaar om mysqldumps te maken.
Je kan er dan voor kiezen 1x per week een mysqldump te doen en voor de rest op de binlog's te vertrouwen.
Je kan met die binlogs dan je hele database "replayen" tot op het punt waar het fout ging.
Dat kan je een hele hoop performance schelen!
ErikKosters
06/10/07, 01:11
Misschien handig dat iemand hier een howto neerzet hoe dit makkelijk is terug te zetten, hier hebben meer mensen wat aan denk ik.
Ik ben hierna even gaan rondkijken op google waardoor die bin files werden aangemaakt, deze bestanden lijken niet echt nodig te zijn en je kon de config wijzigen om mysql deze bestanden niet te laten aanmaken.
"Deze lijken" niet echt nodig. Jammer dat je niet aangeeft waarom ze volgens jou niet nodig lijken te zijn. Nu geef je in je openings post een oplossing voor iets waarvan je eigenlijk niet weet of het goed is. Het lijkt goed te gaan, maar dan wel specifiek in jou situatie... Resultaten op korte termijn zeggen nooit wat voor de resulaten op de lange termijn of in geheel andere situaties.
Gelukkig zijn de hoe, wat en waaroms al in dit topic gegeven. En een howto.. dit behoord een beetje standaard mysql (van de bin files) en standaard linux (van de rotatie files) kennis te zijn. Les 2 en Les 3 van de linux cursus.
Misschien handig dat iemand hier een howto neerzet hoe dit makkelijk is terug te zetten, hier hebben meer mensen wat aan denk ik.Waarom moet alles via howto's? Is er wat mis met zelf iets uitzoeken?
Want als je zelf iets uitzoekt, kom je toch nog vaak (misschien op dat moment irrelevant) zaken tegen die je niet wist!
crazycoder
06/10/07, 14:16
Waarom moet alles via howto's? Is er wat mis met zelf iets uitzoeken?
Laten we daar maar niet over gaan speculeren :)
Misschien handig dat iemand hier een howto neerzet hoe dit makkelijk is terug te zetten, hier hebben meer mensen wat aan denk ik.
Alstu:
http://dev.mysql.com/doc/refman/5.1/en/mysqlbinlog.html
Nog meer? Gelijk sambal erbij?
http://www.mysql.com/search/?q=manual+bin+files&charset=
Speel maar wat met de zoekmogelijkheden om meer te vinden over je specifieke versie.
Kroepoek moet je zelf maar halen :p
Want als je zelf iets uitzoekt, kom je toch nog vaak (misschien op dat moment irrelevant) zaken tegen die je niet wist!
Als je net begin is het geen gek idee om een goed boek te kopen en dat helemaal lezen en met tenminste 1 server en 1 desktop gewoon aan de slag gaan.
Daar leer je tenminste van..