MySQL Replikation BIN-Log

Trashi

New Member
Hallo.

Ich habe zwischen 2 Servern eine Master <> Slave Replikation eingerichtet. Auf dem Slave habe ich beim Starten die aktuelle Bin-Log Datei des Masters angeben müssen, sowie die Log-Position. Nun sind die binären Logs des Masters allerdings via max_binlog_size auf eine bestimmte Größe begrenzt. Habe ich die MySQL Doku richtig verstanden, wird bis zu diesem Wert x in den jeweiligen BIN-Log geschrieben und dannach eine mysql-bin.000002,3,4.. angelegt. Im Slave habe ich jetzt allerdings mysql-bin.000001 als Master_Log_File definieren müssen, um die ganze Sache zum rollen zu bringen. Während sich die oben erwähnte Positionsnummer mitlerweile verändert/vergrößert hat, bin ich sehr gespannt auf das bin-log-file. Was passiert wenn die eingestellt Größe x des bin-log-Files auf dem Master erreicht wird und auf die nächste Datei ausgewichen wird. Das wäre doch dann mysql-bin.000002?! Rafft der Slave das von alleine und ändert das genauso automatisch wie die Positionsnummer oder wie ist das zu regeln? Leider habe ich in der Doku keine bestätigenden/verneinenden Aussagen gefunden.

Daaanke ;)
 
Angefangen hat bei mir die Replikation beim Log 0004, jetzt bin ich bei 0217 und es funktioniert immer noch wie geschmiert ;)
Der Wechsel auf eine neue Binlog-Datei geschieht also automatisch.
 
Ok das beruhigt mich fürs Erste ;)

Ich habe jedoch noch eine weitere Frage bzgl. der "expire_logs_days" Variable.
http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_expire_logs_days said:
The number of days for automatic binary log file removal. The default is 0, which means “no automatic removal.” Possible removals happen at startup and when the binary log is flushed. Log flushing occurs as indicated in Section 5.2, “MySQL Server Logs”.
Was ist wenn die max_binlog_size zu diesem Zeitpunkt noch nicht erreicht ist. Wird das aktuelle Logfile (in welches der Master ATM schreibt und der Slave liest) gelöscht und sofort neu angelegt? Falls ja, wäre das ja garnicht so doof: Dann stell ich expire_logs_days einfach auf 1 und schau da nie wieder rein. An einem Tag mach ich durchschnittlich 500 MB BIN-Logs. Meine max_binlog_size liegt ebenfalls bei 500 MB. Es kann also sein das er an einem Tag 2 Logfiles brauch und die LOG-Files der Vergangenheit interessieren mich nun wirklich nicht.
 
Meine max_binlog_size liegt ebenfalls bei 500 MB.
Und wie oft replizieren sich die Datenbanken? Müssen die sich ständig durch 500 MB Logfiles durch graben?
Mein Tipp zur Performance-Verbesserung: nimm einen kleineren binlog-size.

Und beim expire-logs solltest Du bedenken dass evtl. eine Maschine mal kurz(fristig|zeitig) ausfallen kann. Wenn dieser Ausfall länger als ein Tag ist verlierst Du Daten.
Und wenn Du so große Bin-Logs hast, wird ein DB-Dump auch nicht gerade klein sein und Zeit kosten bis der wieder eingespielt ist.

Ergo: Gönne MySQL entsprechend Platz sich aus zu toben. Festplattenplatz kostet doch heute nichts mehr.

huschi.
 
Du hast recht. Selbst bei einer Master-Slave Replikation wäre es ungünstig wenn die bin-logs weg sind, weil der Master mal 24 Stunden ausgefallen ist. Ich entscheide mich also für eine etwas größere Zahl. Ich schätze mal eine Woche ist angebracht und verkraftbar.

Das ganze aus der Sicht der Performance habe ich natürlich noch nicht gesehen. Völlig nachvollziehbar deine Argumentation, allerdings frage ich mich was denn eine passende Größe wäre. Die maximal produzierte Bin-Log-Größe pro Tag liegt bei ca. 500 MB. Ob der nun ein Bin-Log-Datei am Tag erstellt oder 300, ist mir ehrlich gesagt total Wurst ;) Aber zu klein ist sicher auch nicht gut? Also wieviel? 10 MB? 50 MB? 100MB? ;)

Daaaanke ;)

\\ Edit: Habe jetzt nach einigem hin und her überlegen die max file size auf 250 mb ... Expire log days liegt bei 7 Tagen. Ich komme in diesem Zeitraum auf maximal 3 GB was bei 80 gb hdd wohl mehr als verkraftbar sein sollte.
 
Last edited by a moderator:
Back
Top