Archive

Posts Tagged ‘MySQL’

PHP 5.3 und alte MySQL Passwörter

February 12th, 2013 Comments off

Nach der Migration eines alten Webservers von PHP 5.2 auf PHP 5.3 funktionierte eine uralte PHP-Anwendung nicht mehr. Sie verweigerte den Dienst mit folgender Meldung:

mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication. Please use an administration tool to reset your password with the command SET PASSWORD = PASSWORD(‘your_existing_password’). This will store a new, and more secure, hash value in mysql.user. If this user is used in other scripts executed by PHP 5.2 or earlier you might need to remove the old-passwords flag from your my.cnf

Das ist natürlich ein alter Hut. Wir einnern uns: Mit MySQL 4.1 wurde ein neues sichereres Passwortformat eingeführt. Das war lange Zeit kein Problem, denn auf einem neuen MySQL Server konnte seither mit der Option old-passwords die Unterstützung für das alte Format beibehalten werden.

Und mit PHP 5.3 endete die Unterstützung für das vorherige unsichere Passwortformat. Offenbar endgültig, denn der Zugriff funktioniert weder mit mysql noch mit mysqli (obwohl dies von manchen als Lösung angegeben wird).

Also muss jeder in den sauren Apfel beißen und das fragliche Passwort neu setzen, genauso wie es die PHP-Fehlermeldung bereits vorgeschlagen hatte:

SELECT user, Length(Password) FROM mysql.user WHERE user=’username’;
UPDATE mysql.user SET Password=PASSWORD(‘altesPasswort’) WHERE user=’username’;
SELECT user, Length(Password) FROM mysql.user WHERE user=’username’;
FLUSH PRIVILEGES;

Der Zugriff mit PHP 5.3+ sollte ab sofort möglich sein.

Categories: [DE] Tech Tags: , , ,

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: , , , , ,

MySQL Logs unter FreeBSD mit newsyslog rollieren

May 25th, 2011 Comments off

Praktisch überall lassen sich falsche Informationen zum Thema “Rollierung von MySQL Logdateien” finden. Die meisten Erklärungen sehen vor, ein spezielles Skript namens mysql-log-rotate in den Rollierungsprozess einzubinden. Alternativ darf auch manuell der Befehl mysqladmin flush-logs ausgeführt werden. Alles Quatsch. Es genügt folgender Eintrag in /etc/newsyslog.conf:

/usr/log/mysql/general.log    mysql:mysql    640    7    *    $D0     J     /var/db/mysql/hostname.pid

Natürlich müssen die Pfade noch den tatsächlichen Gegebenheiten angepasst werden. Aber danach wird das Log jede Nacht rolliert und MySQL geht es trotzdem gut. Warum ist das auch ohne das zuvor genannte Skript kein Problem? Weil MySQL automatisch ein FLUSH LOGS und FLUSH PRIVILEGES ausführt, wenn es ein SIGHUP empfängt. Genau dieses Signal schickt newsyslog bei der Rollierung der Logs.

Danke an Bram Schoenmakers, der diese Informationen in seinem Blog gepostet hat.

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