MySQL binlog und relaylog

[peterpan]

Hallo,

ich habe ein merkwürdiges Phänomen bei meinen MySQL Logs.

Das Master-Logfile (mysql-bin.nnnnnn) wächst recht schnell, weshalb ich die "max_binlog_size" auf "100M" gesetzt habe. Nun legt MySQL nach erreichen dieser Grenze brav ein neues File an. In der Index-Datei (mysql-bin.index) findet sich nun aber ein Verweis auf alle Logfiles:

Code: Select all

./mysql-bin.000001
./mysql-bin.000002
./mysql-bin.000003
./mysql-bin.000004
./mysql-bin.000005

Ich kann die "alten" Logs also nicht gefahrlos löschen, da meine Replikation sonst nicht mehr problemlos funktioniert.

Das Relay-Log (relay-bin.nnnnnn) auf dem selben Server verhält sich hingegen "normal". Die Nummer "nnnnnn" zählt hoch und es existiert im Index-File immer nur ein Verweis auf das aktuelle relay-log-File.

Starte ich MySQL neu, so wird von Datei "mysql-bin" eine neue Datei angelegt (es entstehen mehrere Dateien), die datei "relay-bin" wird hochgezählt und durch eine aktuelle Datei ersetzt (es bleibt immer bei einer Datei).

Ich möchte, daß für die "mysql-bin" Datei auch immer nur eine Datei angelegt wird und daß die alten Daten nach erreichen der 100M Grenze verworfen werden.

Hast jemand einen Tipp für mich, wie ich das hinbekomme?

[ephigenie]

da 100M log vorhalten meines erachtens zu wenig sind, würde ich vielleicht 24h nehmen also in der my.cnf

max_binlog_size = 100M
expire_logs_days = 1

[isotopp]

Das Master-Logfile (mysql-bin.nnnnnn) wächst recht schnell, weshalb ich die "max_binlog_size" auf "100M" gesetzt habe. Nun legt MySQL nach erreichen dieser Grenze brav ein neues File an.

Das ist auch Sinn der Sache. Das Binlog wird in Stücke von max_binlog_size zerteilt, damit man alte Stücke löschen kann.

Man kann das mit "PURGE MASTER LOGS BEFORE now() - INTERVAL 7 DAY" tun, wenn man etwa 7 Tage aufbewahren will, oder man setzt einfach "expire_log_days = 7" in der [mysqld]-Sektion der my.cnf, um diese Löschung automatisch zu bekommen.

Ich kann die "alten" Logs also nicht gefahrlos löschen, da meine Replikation sonst nicht mehr problemlos funktioniert.

Dein Slave könnte report-host und report-port konfiguriert haben. Dann könntest Du auf dem Master mit SHOW SLAVE HOSTS sehen, wo Deine Slaves stehen und welche Binlogs nicht mehr benötigt werden. Du kannst dann passende PURGE MASTER LOGS Statement absetzen.

Das Relay-Log (relay-bin.nnnnnn) auf dem selben Server verhält sich hingegen "normal".

Es wird max_relay_log_size gross, dann wird ein neues angefangen. Wenn der SQL_THREAD es abgearbeitet hat, wird es gelöscht. Das kann man durch relay_log_purge=0 abschalten.

Wenn Du "STOP SLAVE SQL_THREAD" machst, wird der IO_THREAD weiter Daten ins Relay Log pumpen, und das (die) Relay Logs werden weiter wachsen, bis das relay_log_space_limit erschöpft ist (oder Du den START SLAVE SQL_THREAD machst).

Starte ich MySQL neu, so wird von Datei "mysql-bin" eine neue Datei angelegt (es entstehen mehrere Dateien), die datei "relay-bin" wird hochgezählt und durch eine aktuelle Datei ersetzt (es bleibt immer bei einer Datei).

Eine neue Binlog-Datei wird angelegt, wenn Du FLUSH LOGS sendest, wenn der Server startet oder wenn max_binlog_size überschritten wird.

Ich möchte, daß für die "mysql-bin" Datei auch immer nur eine Datei angelegt wird und daß die alten Daten nach erreichen der 100M Grenze verworfen werden.

Diese Strategie ist falsch. Das Binlog wird immer weiter fortgeschrieben. Es kann gelöscht werden, wenn es nicht mehr gebraucht wird.

Binlogs werden nicht mehr gebraucht, wenn sie älter als ein Full Dump sind UND wenn kein Slave mehr dieses Binlog liest. Du kannst es dann löschen.

{quote]Hast jemand einen Tipp für mich, wie ich das hinbekomme?[/quote]

1. Verstehen was ein Binlog ist und wozu es verwendet wird.
2. Eine Strategie für Point In Time Recovery und Replikation haben.
3. Das Binlog dazu passend verwalten.

[peterpan]

Das ist auch Sinn der Sache. Das Binlog wird in Stücke von max_binlog_size zerteilt, damit man alte Stücke löschen kann.

Ja, das habe ich verstanden.

oder man setzt einfach "expire_log_days = 7" in der [mysqld]-Sektion der my.cnf, um diese Löschung automatisch zu bekommen.

Danke, diesen Switch hatte ich noch nicht entdeckt.

Dein Slave könnte report-host und report-port konfiguriert haben. Dann könntest Du auf dem Master mit SHOW SLAVE HOSTS sehen, wo Deine Slaves stehen und welche Binlogs nicht mehr benötigt werden. Du kannst dann passende PURGE MASTER LOGS Statement absetzen.

Ja, habe ich bei beiden:

Code: Select all

# node A
[mysqld]
server-id                       = 10
log-bin                         = mysql-bin
log-slave-updates
replicate-same-server-id        = 0
auto_increment_increment        = 10
auto_increment_offset           = 1
master-host                     = ip.von.node.b
master-user                     = user
master-password                 = pass
report-host                     = localhost

# Node B
[mysqld]
server-id                       = 20
log-bin                         = mysql-bin
log-slave-updates
replicate-same-server-id        = 0
auto_increment_increment        = 10
auto_increment_offset           = 2
master-host                     = ip.von.node.a
master-user                     = user
master-password                 = pass
report-host                     = localhost

Es wird max_relay_log_size gross, dann wird ein neues angefangen. Wenn der SQL_THREAD es abgearbeitet hat, wird es gelöscht.

Da beide Hosts innerhalb von Millisekunden auf dem selben Stand sind, sollte es demnach ja eigentlich nicht sehr groß werden. Wird es aber trotzdem. Zumindest wird es offensichtlich von Zeit zu Zeit zurückgesetzt bzw. automatisch verworfen.

Eine neue Binlog-Datei wird angelegt, wenn Du FLUSH LOGS sendest, wenn der Server startet oder wenn max_binlog_size überschritten wird.

Ja, das habe ich ebenfalls verstanden.

Ich möchte, daß für die "mysql-bin" Datei auch immer nur eine Datei angelegt wird und daß die alten Daten nach erreichen der 100M Grenze verworfen werden.

Diese Strategie ist falsch. Das Binlog wird immer weiter fortgeschrieben. Es kann gelöscht werden, wenn es nicht mehr gebraucht wird.

Binlogs werden nicht mehr gebraucht, wenn sie älter als ein Full Dump sind UND wenn kein Slave mehr dieses Binlog liest. Du kannst es dann löschen.

Und genau das ist der Punkt, den ich trotz intensiver Bemühungen nicht verstehe: Jeder Host ist Master und Slave des jeweils anderen, wie Du oben sehen kannst. Normalerweise sollte das Logfile doch nur merkbar groß werden, wenn ich beispielsweise einen der Server neustarte, MySQL stoppe o.ä. - also, wenn die beiden nicht miteinander kommunizieren können.

Dennoch hebt der jeweilige Master seine Logs bis zum St.Nimmerleinstag auf, obwohl beide Server sich ständig abgleichen.

1. Verstehen was ein Binlog ist und wozu es verwendet wird.
2. Eine Strategie für Point In Time Recovery und Replikation haben.
3. Das Binlog dazu passend verwalten.

Ich bemühe mich.

[isotopp]

Code: Select all

report-host                     = localhost

Das ist natürlich so eher untermittelsinnvoll.

Es wird max_relay_log_size gross, dann wird ein neues angefangen. Wenn der SQL_THREAD es abgearbeitet hat, wird es gelöscht.

Da beide Hosts innerhalb von Millisekunden auf dem selben Stand sind, sollte es demnach ja eigentlich nicht sehr groß werden. Wird es aber trotzdem. Zumindest wird es offensichtlich von Zeit zu Zeit zurückgesetzt bzw. automatisch verworfen.

Ich glaube, Du hörst nicht richtig zu.

Es wird max_relay_log_size gross. Ist max_relay_log_size = 0 (Default), wird es max_binlog_size gross (Default 1 GB).

Es wird gelöscht, wenn der SQL_THREAD es nicht mehr liest (also ein neues angefangen wurde, das vom IO_THREAD beschrieben wird, und der SQL_THREAD es durchgelesen hat).

Und genau das ist der Punkt, den ich trotz intensiver Bemühungen nicht verstehe: Jeder Host ist Master und Slave des jeweils anderen, wie Du oben sehen kannst. Normalerweise sollte das Logfile doch nur merkbar groß werden, wenn ich beispielsweise einen der Server neustarte, MySQL stoppe o.ä. - also, wenn die beiden nicht miteinander kommunizieren können.

Noch einmal:

Ein Binlog wird, wenn Du am Server nicht rumfummelst, genau max_binlog_size gross. Ein Relaylog wird, wenn Du am Server nix anderes konfigurierst, genau max_binlog_size gross. Das ist jeweils 1 GB.

Ein Binlog wird, wenn Du nix anderes konfigurierst, niemals automatisch gelöscht.

Ein Relaylog wird, wenn Du nix anderes konfigurierst, automatisch gelöscht, wenn der IO_THREAD das nächste Relaylog angefangen hat (es also größer als 1 GB geworden wäre) und der SQL_THREAD damit fertig ist (es also bis zum letzten Byte des GB durchgelesen hat).

Und das hat ganz genau gar nix damit zu tun, wie Du Master und Slave ineinander kabelst oder ob die überhaupt laufen oder nicht.

[peterpan]

Code: Select all

report-host                     = localhost

Das ist natürlich so eher untermittelsinnvoll.

Danke, ich habe tatsächlich eben erst gesehen, daß die ganze Zeit brav lokal reportet wurde.

Ich glaube, Du hörst nicht richtig zu.

Doch, ich habe zugehört. Manchmal dauert es aber, bis ich etwas verstehe.

Es wird max_relay_log_size gross. Ist max_relay_log_size = 0 (Default), wird es max_binlog_size gross (Default 1 GB).

Es wird gelöscht, wenn der SQL_THREAD es nicht mehr liest (also ein neues angefangen wurde, das vom IO_THREAD beschrieben wird, und der SQL_THREAD es durchgelesen hat).

Ok.

Ein Binlog wird, wenn Du am Server nicht rumfummelst, genau max_binlog_size gross. Ein Relaylog wird, wenn Du am Server nix anderes konfigurierst, genau max_binlog_size gross. Das ist jeweils 1 GB.

Ok.

Ein Binlog wird, wenn Du nix anderes konfigurierst, niemals automatisch gelöscht.

Danke, das war für mich die zentrale Frage. Ich habe nun "expire_logs_days" gesetzt.

Mich wundert allerdings, daß ich bei "SHOW SLAVE HOSTS" beide Server sehe. Ich wäre davon ausgegangen, daß ich da auf jedem Server immer nur den jeweils anderen sehe.

Code: Select all

mysql> SHOW SLAVE HOSTS;
+-----------+----------------+------+-------------------+-----------+
| Server_id | Host           | Port | Rpl_recovery_rank | Master_id |
+-----------+----------------+------+-------------------+-----------+
|        20 | ip.von.node.b  | 3306 |                 0 |        10 |
|        10 | ip.von.node.a  | 3306 |                 0 |        20 |
+-----------+----------------+------+-------------------+-----------+

[peterpan]

Ich überlege die ganze Zeit, wie ich da auf localhost gekommen bin. Im Artikel auf onlamp ist das offensichtlich ebenfalls falsch:

http://www.onlamp.com/pub/a/onlamp/2006 ... tml?page=2

Er schreibt dort:

In this broader schema, water is the master of air and slave of earth, which is slave of fire; and this last is in turn slave of air, thus completing the circle.

Code: Select all

# node A - water
report-host                     = nodeA

# Node B - air
report-host                     = nodeB

# Node C - fire
report-host                     = nodeC

# Node D - earth
report-host                     = nodeD

Richtig wäre hier doch:

Code: Select all

# node A - water
report-host                     = nodeD

# Node B - air
report-host                     = nodeA

# Node C - fire
report-host                     = nodeB

# Node D - earth
report-host                     = nodeC

[isotopp]

Code: Select all

# node A - water
report-host                     = nodeA

# Node B - air
report-host                     = nodeB

# Node C - fire
report-host                     = nodeC

# Node D - earth
report-host                     = nodeD

Und so ist das auch richtig. Reported wird AN master-host, reported wird der Name report-host.

[peterpan]

Und so ist das auch richtig. Reported wird AN master-host, reported wird der Name report-host.

Ok. Also der qualifizierte Hostname oder die externe IP des LOKALEN Rechners.

[peterpan]

Ich habe dazu noch eine Frage. In der Prozessliste habe ich folgende Einträge:

Code: Select all

 
mysql> SHOW PROCESSLIST;
+--------+-----------------+-----------------------------+------------+-------------+--------+-----------------------------------------------------------------------+------------------+
| Id     | User            | Host                        | db         | Command     | Time   | State                                                  | Info             |
+--------+-----------------+-----------------------------+------------+-------------+--------+-----------------------------------------------------------------------+------------------+
|      1 | system user     |                             | NULL       | Connect     | 172116 | Waiting for master to send event                                      | NULL             |
|      2 | system user     |                             | NULL       | Connect     |      0 | Has read all relay log; waiting for the slave I/O thread to update it | NULL             |
|      3 | event_scheduler | localhost                   | NULL       | Connect     | 172116 | Suspended                                                  | NULL             |
|      5 | repl            | www2.meinedomain.de:50610 | NULL       | Binlog Dump | 172112 | Has sent all binlogto slave; waiting for binlog to be updated        | NULL             |
| 308807 | root            | localhost                   | NULL       | Query       |      0 | NULL                                                  | SHOW PROCESSLIST |
+--------+-----------------+-----------------------------+------------+-------------+--------+-----------------------------------------------------------------------+------------------+
6 rows in set (0.00 sec)

Id 5 macht mich etwas stutzig: "Has sent all binlogto slave; waiting for binlog to be updated". Kann jemand spekulieren, weshalb er darauf so lange wartet?

[peterpan]

Entschuldigt bitte, daß ich mit meinen Fragen so persistent rumnerve. Hier die Antwort für alle, die darüber ebenfalls stolpern, da ich bei MySQL auf der Seite keine Erklärung für die unterschiedlichen States gefunden habe:

Code: Select all

Has sent all binlog to slave; waiting for binlog to be updated

The thread has read all binary log files and is idle. It is waiting for new events to appear in the binary log as a result of new update queries being executed on the master.

http://mysqld.active-venture.com/Replic ... tails.html