mysql-5.7 munin

wall < "Wechsel auf mysql-5.7"

Broadcast message from spillerm@unixe.de (pts/1) (Do Mai 05 12:01:14 2016):
4
Diesen Beitrag schrieb ich vor 3 Jahren. Behalte das beim Lesen bitte im Hinterkopf.

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.

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.

Konfig 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 geparst 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

UnterschriftFazit 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?

4
  1. alter nach 3 Tage Kampf endlich eine Lösung gefunden!!! Danke!!

  2. Danke, an der Baustelle habe ich auch gerade geschraubt. Dazu noch folgende Optimierungsmöglichkeiten:

    Die Anpassung in /etc/security/limits.conf ist nicht notwendig; dortige Einstellungen wirken nur für interaktive logins.

    Ich habe dann die mysql.service nicht direkt in /lib/systemd/system editiert, sondern nach /etc/systemd/system kopiert und dort angepasst. Vorteile: ich habe /lib/systemd/system/mysql.service in Ruhe gelassen, und die angepasste Datei in /etc/systemd/system wird von etckeeper verwaltet. Nachteil: man muss – wenn man nicht rebooten möchte – einmal „systemctl daemon-reload“ machen, damit systemd die Datei in /etc/systemd/system zur Kenntnis nimmt.

  3. Klaus Maria Pfeiffer

    warum nicht gleich mariadb?

  4. Bo Sch

    ich hab mysql durch mariadb ersetzt. macht einiges überschaubarer

Keine weitere Reaktionen mehr möglich.