mysql-log und allgemeine Anregung

[sebezahn]

Hallo alle miteinander,

ich war schon immer begeistert vom Vorgänger von isp-control, jetzt bin ich es erst recht. Respekt, ihr habt da mächtig was auf die Beine gestellt! Zur eigentlichen Frage:

Der Ordner /var/log/mysql/ steht mächtig unter Stress. Eine Domain - und das ist kein Programmierfehler, sondern liegt einfach an den zahlreichen Seitenaufrufen - verursacht Abfragen an der DB noch und nöcher, und die scheinen alle dort geloggt zu werden. Ich finde das ja grundsätzlich gut, aber knapp 1GB innerhalb 24 Stunden an Logs machen mir etwas Angst. Ich kann das jetzt automatisieren, so dass immer nur die letzten paar Tage geloggt werden, aber vielleicht ist das ja bereits vorgesehen, und ich möchte nicht, dass sich die Scripts in die Quere kommen. Daher die Frage, ist dafür gesorgt?

Dann eine Anregung: Die Installation ist super beschrieben, allerdings ist man beim nachträglichen Tuning sehr auf Trial, Error und Forensuche angewiesen. Es wäre nicht schlecht, wenn man eine Wiki-Page Tuning aufmachen würde und dort mögliche Lösungen sammelt, sozusagen als Tuning-Guide und die verschiedenen Szenarien dort umreißt. Dann hätte man eine Art Leitfaden, über was man sich auf jeden Fall Gedanken machen sollte.

Dahinein kämen dann beispielsweise die Tatsache, dass Postfix für SMTP kein Plaintext-Kennwort zulässt, das hat mir ein paar nervöse Stunden beschehrt. Oder aber, dass man sich irgendwie um die Logfiles kümmern muss.

Ich habe im aktuellen Wiki dazu nichts gefunden und möchte da jetzt auch nicht einfach drin rumkritzeln. Was meint ihr dazu? Wie gesagt, zum Logging der mysql wäre eine Aussage auch schön...

Gruß
Sebezahn

[joximu]

Hi Sebezahn

zum MySQL: das dürfte Standard sein von der Distribution, da ispCP nichts and der MySQL-server Config ändert.
schau mal in /etc/mysql/my.cnf (Debian) rein, da gibt's diesen Block:

Quote:# The following can be used as easy to replay backup logs or for replication.
#server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
# WARNING: Using expire_logs_days without bin_log crashes the server! See README.Debian!
expire_logs_days = 10
max_binlog_size = 100M
#binlog_do_db = include_database_name
#binlog_ignore_db = include_database_name

das sollte eigtnlich alles regeln in sachen MySQL-Log - wenn du die log_bin-Zeile kommentierst (und auch die expire - siehe Text darber :-) und MySQL restartest, dann sollte das Loggen ganz verschwinden.

Log_Bin loggt nur INSERTs und UPDATEs - für eine DB Replikation... wenn eine Website jedoch dauernd updatet, dann nervt das (allerdings würde ich mich fragen, ob das wirklich notwendig ist...)

Gruss Joxi

[sebezahn]

Hi,

danke für die schnelle Antwort. Ja, das ist richtig, er nimmt nur Updates bzw. Inserts, aber da ein Bannerserver mitläuft, ist das auch leider notwendig. Egal, ich werde das mal im Auge behalten, noch ist die Festplatte groß genug :-). Ich wollte jetzt nur nicht mit eigenen Hausmitteln um etwas kümmern, was von ISP-Control eventuell bereits erledigt wird und bestenfalls auch noch dem ganzen in die Quere kommen.

Was ist mit dem Vorschlag einer Tuning-Section?

Gruß und Dank,
Sebezahn

[joximu]

Tuning Section find ich gut - ich dene, das Doku Team wird da gerne mitgestalten...

Auf der anderen Seite sollte auch aufgepasst werden, dass sich die Infos nicht noch mehr verstreuen. Howtos, FAQ, Tuning-Tipps, etc etc... ein gutes Inhalts/Stichwortverzeichnis wäre bald sehr hilfreich...

[ZooL]

[OFFtopic] jo das sehe ich leider auch so ein unwissender weiss nix zu finden bis man ihn
den richtigen weg weisst

war doch schön geschrieben oder