Archive

Archive for June, 2011

FreeBSD Disklabel wiederherstellen

June 24th, 2011 Comments off

Das will niemand: Alle Disklabel sind weg! Gut zu erkennen an folgender Ausgabe:

sudo disklabel /dev/da0s1
# /dev/da0s1:
#        size   offset    fstype   [fsize bsize bps/cpg]
c: 286734208        0    unused        0     0         # “raw” part, don’t edit

Es ist also nur noch die Raw-Disk “c” übrig, somit kann kein Dateisystem von dieser Disk mehr gemountet werden. Die Konsequenz: Nichts geht mehr. Zum Glück gibt es in den Ports ein Tool, um die Disklabel wiederherzustellen: sysutils/scan_ffs. Der Aufruf ist dann ganz einfach:

scan_ffs -l /dev/da0s1Watch Full Movie Online Streaming Online and Download

Das Tool stellt die Disklabel nicht automatisch wieder her, sondern zeigt sie nur an. Wer dann noch Schwierigkeiten haben sollte, mit diesen Infos wieder ein Disklabel zu erzeugen, kann hier weiterlesen.

Kaputtes MySQL Relay Log reparieren

June 14th, 2011 1 comment

Heute hatte ich den Fall, dass ein MySQL Slave in einer Master-Master Replikation sein Relay Log nicht mehr lesen konnte:

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.

Daraufhin bin ich der Empfehlung aus der Fehlermeldung gefolgt und habe das Relay Log manuell geprüft:

$ mysqlbinlog db02-relay-bin.000636
[Inhalt vom Relay Log]
ERROR: Error in Log_event::read_log_event(): ‘Sanity check failed’, data_len: 170, event_type: 80
ERROR: Could not read entry at offset 13712544: Error in log format or read error.

Es stimmt also: mein Relay Log ist wirklich kaputt. Was nun? Diesmal kam der entscheidende Hinweis nicht aus der exzellenten MySQL Dokumentation, sondern wieder aus einem Blog. Die Lösung ist ganz logisch: wir zwingen den Slave, das Binary Log nochmal vom Master abzurufen.

Dazu muss zunächst SHOW SLAVE STATUS\G; in der MySQL Konsole ausgeführt werden. Wichtig: Die Werte für Relay_Master_Log_File und Exec_Master_Log_Pos notieren, da wir sie später benötigen. Dann STOP SLAVE; in der MySQL Konsole ausführen, um die Replikation anzuhalten. Jetzt kann das Binary Log neu geholt werden:

mysql> CHANGE MASTER TO master_log_file='<Wert von Relay_Master_Log_File>’, master_log_pos=<Wert von Exec_Master_Log_Pos>;

Danach die Replikation mit START SLAVE; wieder in Gang setzen. Letztendlich sollte beim Aufruf von SHOW SLAVE STATUS\G; die Replikation wieder fehlerfrei arbeiten.

Categories: [DE] Tech Tags: , , , , ,
css.php