Onderwerp: Hardeschijf vol

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):

Code:

#!/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.

Oorspronkelijk geplaatst door royen99

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):

Code:

#!/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.

Ik mag toch aannemen dat men backups maakt.

Oorspronkelijk geplaatst door ErikKosters

Ik mag toch aannemen dat men backups maakt.

Dat denkt men ook van de hoster

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..

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

Code:

expire_logs_days=14

in je my.cnf op te nemen dan ipv

Code:

 # 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.

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:

Code:

# 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

Code:

# uncomment this if you want your log files compressed
#compress

te enablen. Dan compressed (.tar.gz) die de history files.

Oorspronkelijk geplaatst door ErikKosters

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!

Misschien handig dat iemand hier een howto neerzet hoe dit makkelijk is terug te zetten, hier hebben meer mensen wat aan denk ik.