2
MySQL Upgrade 80015 auf 80016 Fehler
Hallo Mysql User,
mit dem neuesten Upgrade von Version 80015 auf 80016 wurde der automatische Upgrade Vorgang von Oracle geändert. Dazu nutzt die MySQL nicht mehr das Paket "mysql_upgrade", sondern den Upgrade-Prozess in der Kernanwendung des "mysqld"-Daemon. Dieser sorgt allerdings in der aktuellen Version für viele Probleme und Fehler, so das nach dem automatischen Update die Datenbank nicht mehr hochfährt.
Bei uns lag das Problem bei der Datei /var/lib/mysql/mysql_upgrade_info im Verzeichnis /var/lib/mysql. Vom vorherigen Upgrade-Prozess wurde die Datei mit Root-Rechten erzeugt. Das kann der mysqld Prozess aber nicht lesen. Also müsst ihr per Hand dieser Datei die mysqld-Rechte vergeben:
Danach muss der Service neu gestartet werden
Oder alternativ MySQL im Debug-Modus starten:
Jetzt sollte die Datenbank wieder starten.
Andere User brauchten noch zusätzliche Änderungen für einen erfolgreichen Neustart in der my.cnf:
Weitere Änderung in Version 800016:
Aktuell gibt es leider keine "mysqlnd" Variante innerhalb von PHP die "caching_sha2_password" unterstützt und man muss das "alte" Verfahren "mysql_native_password" nutzen.
mit dem neuesten Upgrade von Version 80015 auf 80016 wurde der automatische Upgrade Vorgang von Oracle geändert. Dazu nutzt die MySQL nicht mehr das Paket "mysql_upgrade", sondern den Upgrade-Prozess in der Kernanwendung des "mysqld"-Daemon. Dieser sorgt allerdings in der aktuellen Version für viele Probleme und Fehler, so das nach dem automatischen Update die Datenbank nicht mehr hochfährt.
Bei uns lag das Problem bei der Datei /var/lib/mysql/mysql_upgrade_info im Verzeichnis /var/lib/mysql. Vom vorherigen Upgrade-Prozess wurde die Datei mit Root-Rechten erzeugt. Das kann der mysqld Prozess aber nicht lesen. Also müsst ihr per Hand dieser Datei die mysqld-Rechte vergeben:
chown mysql:mysql /var/lib/mysql/mysql_upgrade_infoservice mysql start$sudo /usr/sbin/mysqld-debug --user=mysql --log-error-verbosity=3Jetzt sollte die Datenbank wieder starten.
Andere User brauchten noch zusätzliche Änderungen für einen erfolgreichen Neustart in der my.cnf:
[client]
default-character-set=utf8mb4
[mysql]
default-character-set=utf8mb4
[mysqld]
collation-server = utf8mb4_unicode_ci
character-set-server = utf8mb4Weitere Änderung in Version 800016:
- sha256_password is deprecated (Logfile kann mit den Warnungen volllaufen!)
Aktuell gibt es leider keine "mysqlnd" Variante innerhalb von PHP die "caching_sha2_password" unterstützt und man muss das "alte" Verfahren "mysql_native_password" nutzen.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 446000
Url: https://administrator.de/contentid/446000
Printed on: April 18, 2024 at 10:04 o'clock
2 Comments
Latest comment
Hat man eben gemerkt... "Uuups Verbindung zur Datenbank wech... 
Ja sorry, ich hatte das MySQL-Update in der Entwicklungsumgebung vor ein paar Tagen ausprobiert und da gab es den Fehler nicht. Ich hatte dort nie auf Version 80015 aktualisiert (war noch auf 80014). Der Fehler tritt wohl nur auf, wenn man das Upgrade auf 80015 durchgeführt hat. Das mit dem "utf8mb4" hatte ich schon vor Wochen umgestellt und war daher überzeugt, dass es keinen Ausfall gibt. Tja, was sind die letzen Worte eines Admins zu seiner virtuellen Frau - ich mach mal eben noch schnell ein Update ...
Generell ärgert mich das Vorgehen von Oracle. Sie ändern viele Dinge, ohne es genau zu testen. In der letzten Zeit mehren sich die Fehler innerhalb des Update-Prozesses von MySQL. Auch habe ich das Gefühl, die DB wird immer langsamer.
Generell bin ich aber dabei, die ganze Datenbank hin zu MongoDB zu migrieren. Das ist zwar sehr aufwendig, aber die MongoDB hat z.B. mit mehreren tausenden Verbindnungen gleichzeitig keine bis kaum Probleme. Bei MySQL wird es schon bei über 500 Verbindungen eng. Daher sind für mich solche Probleme nur noch temporär.
Auch die Ignoranz von Oracle mal eben das Standard-Passwort Verfahren auf "caching_sha2_password" zu setzten, obwohl ihnen bekannt ist, dass es keine PHP Unterstützung dazu gibt. Aktuell gibt es keine "mysqlnd" Variante innerhalb von PHP die "caching_sha2_password" unterstützt und man muss das "alte" Verfahren "mysql_native_password" nutzen. Gerade mit PHP ist diese Datenbank groß geworden und Oracle macht keine Anstalten PHP zu berücksichtigen. Sie hätten dem PHP-Projekt auch helfen können, dass zu implementieren.
Gruß
Frank
Generell ärgert mich das Vorgehen von Oracle. Sie ändern viele Dinge, ohne es genau zu testen. In der letzten Zeit mehren sich die Fehler innerhalb des Update-Prozesses von MySQL. Auch habe ich das Gefühl, die DB wird immer langsamer.
Generell bin ich aber dabei, die ganze Datenbank hin zu MongoDB zu migrieren. Das ist zwar sehr aufwendig, aber die MongoDB hat z.B. mit mehreren tausenden Verbindnungen gleichzeitig keine bis kaum Probleme. Bei MySQL wird es schon bei über 500 Verbindungen eng. Daher sind für mich solche Probleme nur noch temporär.
Auch die Ignoranz von Oracle mal eben das Standard-Passwort Verfahren auf "caching_sha2_password" zu setzten, obwohl ihnen bekannt ist, dass es keine PHP Unterstützung dazu gibt. Aktuell gibt es keine "mysqlnd" Variante innerhalb von PHP die "caching_sha2_password" unterstützt und man muss das "alte" Verfahren "mysql_native_password" nutzen. Gerade mit PHP ist diese Datenbank groß geworden und Oracle macht keine Anstalten PHP zu berücksichtigen. Sie hätten dem PHP-Projekt auch helfen können, dass zu implementieren.
Gruß
Frank
