Wechsel auf MySQL-5.7

unter Online ▸ Stichwort Databases

Diesen Beitrag schrieb ich 8 Jahre und 5 Monate zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.

Geschätzte Lesezeit: 2 Minuten

Am 21. April erschien Ubuntu-16.04 LTS, und diesmal war ich so wahnsinnig, das Upgrade zeitnah auszuführen. Im ersten Moment liefen Webseite und Owncloud überhaupt nicht mehr, und meine Begeisterung hielt sich schwer in Grenzen. MySQL entpuppte sich als wahrer Störenfried – deshalb hier einige meiner Notizen.

Startpunkt Neuinstallation

Ein sehr grundsätzliches Problem bestand darin, dass ich überhaupt keinen MySQL mehr hatte. Das do-release-upgrade hatte mir meinen mysql-5.6 deinstalliert, allerdings nichts Neues ins System eingebracht. Mittels apt-get install mysql-server-5.7 installierte ich also erstmal den Dienst; die Daten in /var/lib/mysql waren zum Glück unversehrt.

Konfiguration und Upgrade

Allerdings zeigte sich mysql-5.7 recht unerfreut von meiner altbewährten my.cnf. Ja, auch hier hantieren wir nun mit conf.d und !includedir herum – eine wahre Pest ohne Mehrwert, meine Meinung. Ich häkelte mir Konfigurationsdateien, die problemlos geparsed werden können, und sorgte dafür, dass auch apparmor auf alles die benötigten Rechte eingeräumt werden. Nun konnte der Dienst erstmals anlaufen, und automatisch wurde mysql_upgrade ausgeführt, um alle Tabellen auf den neuesten Stand zu bringen. Anschließend meckerte er jedoch über Inkompatibilitäten, so dass ich den Aufruf ein zweites Mal von Hand initiierte:

$ mysql_upgrade -u root -p

Deprecated?

Parallel beobachtete ich das Log-File, das an manchen Stellen ein deprecated anmeckerte. Hier zum Beispiel musste ich meine Konfiguration um die Zeile explicit_defaults_for_timestamp = 1 erweitern, um den folgenden Fehler zu eliminieren:

[Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use –explicit_defaults_for_timestamp server option (see documentation for more details).

Function already exists

Fehler: Apr 26 14:18:08 spiller mysqld[7362]: 2016-04-26T12:18:08.723872Z 0 [Note] Plugin 'FEDERATED' is disabled.
Apr 26 14:18:08 spiller mysqld[7362]: 2016-04-26T12:18:08.984967Z 0 [Warning] System table 'plugin' is expected to be transactional.
Apr 26 14:18:09 spiller mysqld[7362]: 2016-04-26T12:18:09.006671Z 0 [ERROR] Function 'innodb' already exists
Apr 26 14:18:09 spiller mysqld[7362]: 2016-04-26T12:18:09.006700Z 0 [Warning] Couldn't load plugin named 'innodb' with soname 'ha_innodb.so'.
Apr 26 14:18:09 spiller mysqld[7362]: 2016-04-26T12:18:09.006709Z 0 [ERROR] Function 'federated' already exists
Apr 26 14:18:09 spiller mysqld[7362]: 2016-04-26T12:18:09.006714Z 0 [Warning] Couldn't load plugin named 'federated' with soname 'ha_federated.so'.
Apr 26 14:18:09 spiller mysqld[7362]: 2016-04-26T12:18:09.006720Z 0 [ERROR] Function 'blackhole' already exists
Apr 26 14:18:09 spiller mysqld[7362]: 2016-04-26T12:18:09.006725Z 0 [Warning] Couldn't load plugin named 'blackhole' with soname 'ha_blackhole.so'.
Apr 26 14:18:09 spiller mysqld[7362]: 2016-04-26T12:18:09.006731Z 0 [ERROR] Function 'archive' already exists
Apr 26 14:18:09 spiller mysqld[7362]: 2016-04-26T12:18:09.006735Z 0 [Warning] Couldn't load plugin named 'archive' with soname 'ha_archive.so'.

In der MySQL-Konsole habe ich mir die Plugins mal ausgeben lassen, und siehe da: es waren genau die, die beim Starten des Dienstes angemault wurden:

$ mysql -u root -p -e "SELECT * FROM mysql.plugin;"

Altlasten, in meinem Fall; mittels DELETE from mysql.plugin WHERE name='...'; löschte ich sie einfach raus, und damit gehörten dann auch diese Fehlermeldungen der Geschichte an.

Changed limits

Richtig ärgerlich war, dass mysql-5.7 plötzlich nicht mehr die ihm zugewiesenen Limits ausschöpfen konnte:

Apr 26 14:18:06 spiller mysqld[7362]: 2016-04-26T12:18:05.833138Z 0 [Warning] Changed limits: max_open_files: 1024 (requested 4096)
Apr 26 14:18:06 spiller mysqld[7362]: 2016-04-26T12:18:05.833187Z 0 [Warning] Changed limits: table_open_cache: 431 (requested 8192)

Um dem Dienst korrigierte Limits zuzuweisen sind zweierlei Änderungen nötig:

## /etc/security/limits.conf
...
mysql hard nofile 65535
mysql soft nofile 65535

## /lib/systemd/system/mysql.service
...
[service]
LimitNOFILE=65535
...

An dieser Stelle hielt ich dann einen Reboot für angebracht – und seither läuft der Dienst wieder sauber durch… Und die aktuelle Version des mysqltuner.pl hilft dabei, das Finetuning auf den Weg zu bringen und Flaschenhälse zu beheben.

Fazit

Fazit kann ich mir noch keines erlauben – dazu sind die Änderungen zu gravierend und viel zu frisch ;-) Wie sieht’s bei euch aus – habt ihr das Upgrade schon gewagt? Wie zufrieden seid ihr?

Alle Bilder dieser Seite: © Marianne Spiller – Alle Rechte vorbehalten
Hintergrundbild: Bild genauer anschauen – © Marianne Spiller – Alle Rechte vorbehalten

Eure Gedanken zu „Wechsel auf MySQL-5.7“

Ich freue mich über jeden Kommentar, es sei denn, er ist blöd. Deshalb behalte ich mir auch vor, die richtig blöden kurzerhand wieder zu löschen. Die Kommentarfunktion ist über GitHub realisiert, weshalb ihr euch zunächst dort einloggen und „utterances“ bestätigen müsst. Die Kommentare selbst werden im Issue-Tracker und mit dem Label „✨💬✨ comment“ erfasst – jeder Blogartikel ist ein eigenes Issue. Über GitHub könnt ihr eure Kommentare somit jederzeit bearbeiten oder löschen.