Fragen zum Relay-Log

S

s24!

Registered User
Hi,

ich bin mir unsicher, ob ich Sinn und Zweck des Relay-Logs eines MySQL-Slaves richtig verstanden habe. Wenn ich es aktiviert habe und auf dem Master geschrieben wird, läuft das meinem Verständnis nach so ab:

MySQL-Schreibzugriff -> Binlog des Masters -> Relay-Log des Slaves -> Datenbank auf dem Slave - Richtig?

Ohne Relay-Log liest der Slave alles "live" aus dem Master-Binlog. Auch richtig?

Nachteil ist natürlich eine höhere Schreiblast auf den Platten des Slaves. Bei den Vorteilen bin ich jetzt verwirrt: Der eigentliche Sinn dürfte sein, dass beim Ausfall des Masters der Slave schon (möglichst) alles im Relay-Log hat und anschließend in die DB(s) schreiben kann. Praktisch dürfte es doch performanter sein, direkt in die Datenbanken zu schreiben? Gibt es Szenarien, in denen ein Relay-Log sinnvoll oder eben nicht sinnvoll ist?

Wer kann mich aufklären? ^^ Danke vorab.


Viele Grüße
Tim
 
Vereinfacht ausgedrückt ist das Relay-Log ein Cache, der die gesendeten Daten vom Master zwischenspeichert, bis der Slave diese vollständig in seine DBs geschrieben hat.
Ohne diesen Cache würden Netzwerkschwankungen, Verbindungsabbrüche, langsame Writes/Locks beim Slave und andere Probleme zu inkonsistenten Daten oder gar Datenverlusten führen.

Es macht also absolut keinen Sinn, das Relay-Log zu deaktivieren, da dadurch auch der Sinn eines Slave als solcher hinfällig wird.
 
Besten Dank für deine Erläuterungen, dann bleibt das natürlich an. (War es auch bisher immer, hatte mich nur bislang nie wirklich mit dem Kontext befasst.)

Jetzt habe ich in einem neu aufgebauten Master/Slave-Setup folgendes Problem, nachdem der Slave gecrasht ist (ist einer der neuen EX40-SSD von Hetzner.. sollte nun dank BIOS-Update stabil sein):

Code: 
mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: h13
                  Master_User: replicate
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.001122
          Read_Master_Log_Pos: 952918187
               Relay_Log_File: mysqld-relay-bin.000025
                Relay_Log_Pos: 70642853
        Relay_Master_Log_File: mysql-bin.001115
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 1594
                   Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 70642707
              Relay_Log_Space: 7019944032
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1594
               Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 2

Das Relay-Log kann ich fehlerfrei öffnen, insofern weiß ich nicht, was genau sein Problem ist - aber irgendeins gibt es wohl. Wie kann ich nun vorgehen? Dem Master geht es ja blendend und die Binlogs existieren noch - kann ich ihn einfach wieder auf eine "frühere" Position stellen und die Relay-Logs löschen? Dann sollte er ja - vorausgetzt ich sage ihm, dass er Duplicate Entries ignorieren soll - einfach wieder seinen Abstand aufholen.

Gibt es bessere / elegantere Methoden?

Oder muss ich davon ausgehen, dass die einzige Möglichkeit, einen derart gecrashten Slave wieder hinzukriegen (konsistent und ohne Datenverlust versteht sich), der Neuaufbau der Replikation ist?


Viele Grüße
TIm
 
Last edited by a moderator:
Oha, das war einfacher als gedacht - deutlich einfacher. Besten Dank auch dafür!

Ich warte dann mal ab:
Code: 
        Seconds_Behind_Master: 265018

Und das Ganze ist danach wirklich wieder zu 100% konsistent? Magic. :D
 
So, er hat seinen Abstand aufgeholt - und das sieht echt gut aus. Hätte ich nicht gedacht. :)

Nun ist das Ziel, wieder ein Master/Master-Setup aufzubauen (läuft aktuell schon, aber eben auf älteren Servern). Dieses soll Abstürze eines Servers, beispielsweise wegen Stromausfall oder Hardwaredefekt, problemlos überstehen.

Bei einem Single-Server-Setup würde ich im Hinblick auf maximale Konsistenz und "Crash-Resistenz" so Sachen machen wie:

- Write-Cache der Platten deaktivieren
- "gefährliche" Mountoptionen wie data=writeback (ext4) entfernen
- innodb_flush_log_at_trx_commit = 1
- sync_binlog = 1

Jetzt habe ich aber wie gesagt sowieso jeweils einen Slave, der sich die Daten ja sofort holt und sich diese auch nicht schneller holen kann, wenn ich oben genannte Änderungen vornehme. Insofern erscheinen mir diese Performancefresser gar nicht notwendig zu sein.

Wie seht ihr das? :)


Viele Grüße
Tim
 
You must log in or register to reply here.
Back
Top