MySQL-Upgrade - wie geht's?? (Debian 5.02)

[Wurstpelle]

Hallo,

die Debian-Versionen 5.02 und 5.03 verwenden standardmäßig die MySQL-Server Version 5.0.51a-24+lenny2-log.

Momentan verhagelt mir ein Bug in MySQL (s.u.) gehörig ein Projekt, wobei die einzig sinnvolle Lösung wohl ein MySQL-Upgrade (>5.0.54) ist. Was mir dabei Kopfschmerzen macht ist die Tatsache, dass ich mich bisher komplett auf die Debian-Standardpakete verlassen konnte, ohne irgendwo tricksen, patchen oder kompilieren zu müssen. Diesen Komfort muss ich nun wohl mit einem Upgrade aufgeben :-/

Da sich der Server bereits im Live-Betrieb befindet, möchte ich gerne das MySQL-Upgrade so "sanft" und Debian-konform wie möglich reinbringen, damit ich mir durch irgendwelche Seiteneffekte nicht noch andere Baustellen aufreiße. Kann mir hier jemand einen ganz konkreten Tipp geben, wie ich das anstellen soll?

merci,
Michael


-----------------------------------------------------------------------------------
[19 Dec 2007 6:19] Paul DuBois
Noted in 5.0.54, 5.1.23, 6.0.5 changelogs.
For comparisons of the form date_col OP datetime_const (where OP is
=, <, >, <=, or >=), the comparison is done using DATETIME values,
per the fix for Bug#27590. However that fix caused any index on
date_col not to be used and compromised performance. Now the index is
used again.

[Cologne4711]

Hallo,

Du kannst ja auch den Server (5.1.37-2) aus den Backports nehmen.

http://packages.debian.org/de/lenny-backports/database/

MfG

[Wurstpelle]

Hallo,

Du kannst ja auch den Server (5.1.37-2) aus den Backports nehmen.

http://packages.debian.org/de/lenny-backports/database/

MfG

D.h.? Wie genau stelle ich das an? Muss ich diese "Backports" in die sources.list von apt eintragen oder kann/soll ich das manuell runterladen und installieren (wenn ja wie?) ? Sorry, kenne mich mit dem Paket-Handling über den "apt-get install" nur wenig aus.

[Cologne4711]

erste von google

http://www.tim-bormann.de/debian-lenny-backports/

MfG

[hikaru]

contrib und non-free brauchst du dafür allerdings nicht.

[Wurstpelle]

Mhhh... die Installation des Backport-Pakets macht aber wenig Mut:

Code: Alles auswählen

myhost:~# aptitude -t lenny-backports install mysql-server-5.1
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Lese Status-Informationen ein... Fertig
Lese erweiterte Statusinformationen
Initialisiere Paketstatus... Fertig
Lese Task-Beschreibungen... Fertig
Die folgenden Pakete sind KAPUTT:
  mysql-server-5.0 mysql-server-5.1
Die folgenden NEUEN Pakete werden zusätzlich installiert:
  libmysqlclient16{a} mysql-client-5.1{a}
Die folgenden Pakete werden ENTFERNT:
  mysql-client-5.0{a}
Die folgenden Pakete werden aktualisiert:
  mysql-common
1 Pakete aktualisiert, 3 zusätzlich installiert, 1 werden entfernt und 39 nicht aktualisiert.
Muss 21,9MB an Archiven herunterladen. Nach dem Entpacken werden 36,5MB zusätzlich belegt sein.
Die folgenden Pakete haben verletzte Abhängigkeiten:
  mysql-server-5.0: Hängt ab: mysql-client-5.0 (>= 5.0.51a-24+lenny2) ist aber nicht installationsfähig
  mysql-server-5.1: Kollidiert: mysql-server (< 5.1.37-2~bpo50+1) aber 5.0.51a-24+lenny2 ist installiert und wird zurückgehalten.
Die folgenden Aktionen werden diese Abhängigkeiten auflösen:

Entferne die folgenden Pakete:
mysql-server-5.0

Aktualisieren der folgenden Pakete:
mysql-server [5.0.51a-24+lenny2 (stable, stable, stable, stable, now) -> 5.1.37-2~bpo50+1 (lenny-backports)]

Bewertungsnote beträgt -171

Diese Lösung akzeptieren? [Y/n/q/?]

Soll ich das Teil nun mit Y bestätigen oder verbirgt sich in dieser Meldung ein größeres Risiko? (Vor allem - wie soll ich den Spruch mit "KAPUTT" bewerten???)

[rendegast]

Die Fehlermeldung gibt es, da mysql-server (lenny) -> mysql-server-5.0 <-conflict-> mysql-server-5.1,
was er duch das Upgrade

Aktualisieren der folgenden Pakete:
mysql-server [5.0.51a-24+lenny2 (stable, stable, stable, stable, now) -> 5.1.37-2~bpo50+1 (lenny-backports)]

zu lösen versucht.

Weniger Fehlermeldungen sollte es geben mit:

Code: Alles auswählen

aptitude -t lenny-backports install mysql-server

Da dies ein major-Upgrade ist, vorher die db dumpen.
Das wird eigentlich auch durch das update-Skript veranlaßt (zBsp 'mysqlcheck'), aber sicher ist sicher.
http://dev.mysql.com/doc/refman/5.1/en/upgrade.html
http://dev.mysql.com/doc/refman/5.1/en/ ... eries.html


-----------------
Die backports-Quelle auf preferences-priority 100 (oder weniger?) setzen,
/etc/apt/preferences :

Code: Alles auswählen

Package: *
Pin: release o=Backports.org archive, a=lenny-backports, l=Backports.org archive
Pin-Priority: 100

[Wurstpelle]

ok, merci. Stimmt, wenn ich das "5.1" im aptitude weglasse schaut's nicht mehr so dramatisch aus.
Ich lese mir jetzt noch mal alle Upgrade-Infos durch. Ich denke, mit einem frischen Dump als Sicherheit sollte dann nix mehr schiefgehen...
Tausend Dank an alle Tippgeber
Michael

[Wurstpelle]

SHIT, nu ist genau das passiert was ich unbedingt vermeiden wollte: der neue Server startet nicht mehr. Hier die Ausgabe von aptitude:

Code: Alles auswählen

Konfigurationsdatei »/etc/mysql/my.cnf«
 ==> Modifiziert (von Ihnen oder einem Skript) seit der Installation.
 ==> Paketverteiler hat eine aktualisierte Version herausgegeben.
   Was möchten Sie damit machen? Ihre Wahlmöglichkeiten sind:
    Y oder I : Die Version des Paket-Betreuers installieren
    N oder O : Die momentan installierte Version beibehalten
       D     : Die Unterschiede zwischen den Versionen anzeigen
       Z     : Prozess in den Hintergrund, um die Situation zu begutachten
 Der Standardweg ist das Beibehalten der momentanen Version.
*** my.cnf (Y/I/N/O/D/Z) [Vorgabe=N] ?
Wähle vormals abgewähltes Paket mysql-server-5.1.
(Lese Datenbank ... 41965 Dateien und Verzeichnisse sind derzeit installiert.)
Entpacke mysql-server-5.1 (aus .../mysql-server-5.1_5.1.37-2~bpo50+1_amd64.deb) ...
Verarbeite Trigger für man-db ...
Richte libmysqlclient16 ein (5.1.37-2~bpo50+1) ...
Richte mysql-client-5.1 ein (5.1.37-2~bpo50+1) ...
Richte mysql-server-5.1 ein (5.1.37-2~bpo50+1) ...
Installiere neue Version der Konfigurationsdatei /etc/init.d/mysql ...
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!
invoke-rc.d: initscript mysql, action "start" failed.
dpkg: Fehler beim Bearbeiten von mysql-server-5.1 (--configure):
 Unterprozess post-installation script gab den Fehlerwert 1 zurück
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von mysql-server:
 mysql-server hängt ab von mysql-server-5.1; aber:
  Paket mysql-server-5.1 ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten von mysql-server (--configure):
 Abhängigkeitsprobleme - lasse es unkonfiguriert
Fehler traten auf beim Bearbeiten von:
 mysql-server-5.1
 mysql-server
E: Sub-process /usr/bin/dpkg returned an error code (1)
Ein Paket konnte nicht installiert werden. Versuche zu lösen:
Richte mysql-server-5.1 ein (5.1.37-2~bpo50+1) ...
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!
invoke-rc.d: initscript mysql, action "start" failed.
dpkg: Fehler beim Bearbeiten von mysql-server-5.1 (--configure):
 Unterprozess post-installation script gab den Fehlerwert 1 zurück
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von mysql-server:
 mysql-server hängt ab von mysql-server-5.1; aber:
  Paket mysql-server-5.1 ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten von mysql-server (--configure):
 Abhängigkeitsprobleme - lasse es unkonfiguriert
Fehler traten auf beim Bearbeiten von:
 mysql-server-5.1
 mysql-server
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Lese Status-Informationen ein... Fertig
Lese erweiterte Statusinformationen
Initialisiere Paketstatus... Fertig
Schreibe erweiterte Statusinformationen... Fertig
Lese Task-Beschreibungen... Fertig

Aktueller Status: 38 Aktualisierungen [-2].

Mein grösstes Problem hierbei ist, dass mir mysql beim vergeblichen Startversuch (/etc/init.d/mysql start) scheinbar nirgendwo eine Logdatei schreibt. In /var/log/mysql liegen nur 0-Byte logfiles.

[Wurstpelle]

In der daemon.log bin ich fündig geworden

[Wurstpelle]

ok, das Problem wäre gelöst: Entfernen von "skip-bdb" aus der my.cnf hat den 5.1er zum Leben erweckt

Mein letztes Problem ist vielleicht eher unkritsch, aber ich frage trotzdem mal in die Runde, weil mir die Backport-Pakete hier nicht weiter helfen konnten. Der phpMyAdmin gibt mir nun stets folgende Warnung aus:

Code: Alles auswählen

Die Version der verwendeten PHP MySQL Bibliothek 5.0.51a unterscheidet sich von der Version des MySQL Servers 5.1.37. Dies kann zu unerwartetem Verhalten führen.

Kann ich bestätigen - immerhin ist ja noch das (alte) Paket "php5-mysql" installiert. Hat mir jemand nen Tipp, wie ich hier nachziehen kann?

[rendegast]

Ups, Post war noch in Arbeit und bezieht sich auf

In der daemon.log bin ich fündig geworden

(oben, ist jetzt entfernt)
------------------------------------------------------------------------------------------

Nov 2 18:32:34 struppi mysqld: /usr/sbin/mysqld: Table 'mysql.plugin' doesn't exist
Nov 2 18:32:34 struppi mysqld: 091102 18:32:34 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.

naja, steht ja da.

Nov 2 18:32:40 struppi mysqld: 091102 18:32:40 [ERROR] /usr/sbin/mysqld: unknown option '--skip-bdb'

5.0 ist nicht richtig deinstalliert worden, im 5.1-Paket taucht dieser String nicht auf:

$ grep -rl skip-bdb mysql-server-5.0
mysql-server-5.0/postinst
mysql-server-5.0/usr/share/doc/mysql-server-5.0/examples/my-small.cnf
mysql-server-5.0/usr/share/mysql/mysql-test/mtr
mysql-server-5.0/usr/share/mysql/mysql-test/mysql-test-run
mysql-server-5.0/usr/share/mysql/mysql-test/mysql-test-run.pl
mysql-server-5.0/usr/share/mysql/mysql-test/mysql-test-run-shell
mysql-server-5.0/usr/share/mysql/mysql-test/r/im_utils.result
mysql-server-5.0/usr/sbin/mysqld
mysql-server-5.0/usr/bin/mysql_install_db

$ grep -rl skip-bdb mysql-server-5.1
grep: mysql-server-5.1/usr/share/mysql/mysql-test/mysql-test-run: Datei oder Verzeichnis nicht gefunden
grep: mysql-server-5.1/usr/share/mysql/mysql-test/mtr: Datei oder Verzeichnis nicht gefunden

->

Code: Alles auswählen

dpkg -l | grep mysql

Leider ist auch das Start-Skript mysqld_safe sehr unterschiedlich.

/tmp$ du -sh mysql-*
18M mysql-client-5.0
20M mysql-client-5.1
81M mysql-server-5.0
25M mysql-server-5.1

/tmp$ du -sm mysql-server-5.*/usr/*
34 mysql-server-5.0/usr/bin
13 mysql-server-5.0/usr/sbin
34 mysql-server-5.0/usr/share
14 mysql-server-5.1/usr/bin
9 mysql-server-5.1/usr/sbin
3 mysql-server-5.1/usr/share

Datenbank und Konf sichern.
Alles mysql mittels PURGE entfernen.
5.1 installieren, Konf anpassen.
Läuft?
Gegebenenfalls die Update-Funktionen ('mysql_upgrade' usw.) für die db manuell durchführen.
http://dev.mysql.com/doc/refman/5.1/en/ ... eries.html




----------------------------------

Aktueller Status: 38 Aktualisierungen [-2].

Vorher (ohne die backports-Quellen) kein (full-|dist-)upgrade gemacht?

[rendegast]

Wegen

Die Version der verwendeten PHP MySQL Bibliothek 5.0.51a unterscheidet sich von der Version des MySQL Servers 5.1.37.

-----------

lenny:
Package: php5-mysql (5.2.6.dfsg.1-1+lenny3)
....
dep: libmysqlclient15off (>= 5.0.51a)
MySQL database client library
....
dep: php5-common (= 5.2.6.dfsg.1-1+lenny3)
Common files for packages built from the php5 source




squeeze:
Package: php5-mysql (5.2.11.dfsg.1-1)
....
dep: libmysqlclient16 (>= 5.1.21-1) [not amd64]
MySQL database client library

dep: libmysqlclient16 (>= 5.1.36) [amd64]
....
dep: php5-common (= 5.2.11.dfsg.1-1)
Common files for packages built from the php5 source

Package libmysqlclient15off
....
* lenny (stable) (libs): MySQL database client library
5.0.51a-24+lenny2: alpha amd64 arm armel hppa i386 ia64 mips mipsel powerpc s390 sparc
* squeeze (testing) (libs): MySQL database client library
5.0.51a-24+lenny2: amd64 armel hppa i386 ia64 mips mipsel powerpc s390 sparc

Package libmysqlclient16
....
* lenny-backports (libs): MySQL database client library
5.1.37-2~bpo50+1 [backports]: alpha amd64 arm armel hppa i386 s390 sparc
* squeeze (testing) (libs): MySQL database client library
5.1.37-2: amd64 armel hppa i386 ia64 mips mipsel powerpc s390 sparc

/usr/lib/libmysqlclient.so.15 <-> /usr/lib/libmysqlclient.so.16 ?
Was vielleicht ginge, wäre
- die Meldung nicht zu beachten und erstmal eine Weile das Verhalten beobachten.
- php5-mysql aus lenny beibehalten,
ein equivs-dummy libmysqlclient15off ("dep. libmysqlclient16") erstellen,
und libmysqlclient16 aus lenny-backports zu installieren.
Oder es einfach so installieren, vielleicht wird es ja automatisch verwendet?
- php5-mysql aus squeeze installieren -> libmysqlclient16 aus backports oder squeeze.

Das zweite könnte noch funktionieren
(vielleicht noch mit einem Link /usr/lib/libmysqlclient.so.15 -> /usr/lib/libmysqlclient.so.16?).
Das dritte könnte in eine Abhängigkeits"hölle" für php5 / phpmyadmin / gcc-4.4 aus squeeze / backports führen,
da eine Abhängigkeit auf php5-common und libgcc1 mit Versionsangabe besteht.

[Wurstpelle]

Erstmal danke, rendegast, für die ausführlichen Infos.

Bei der Installation wurde ich gefragt, ob ich die alte my.cnf beibehalten möchte, was ich bejaht hatte. Drum gabe's da noch diese Option. Ich hoffe mal, ich habe ansonsten keine wichtige Konfigurationsänderung verpasst, drum lasse ich den (nun funktionierenden) Server besser wie er ist. läuft ja...

Auch in Sachen php-client kann ich wohl mit dem Versionsunterschied leben (ich denke, eine niedrige MySQL-Version wäre schlimmer...). Zumindest treten bis jetzt keine Fehler auf.

[rendegast]

Bei der Installation wurde ich gefragt, ob ich die alte my.cnf beibehalten möchte, was ich bejaht hatte.

Entsprechend verbleibt dann eine Datei.dpkg-new oder Datei.dpkg-old,
die nach dem Upgrade zu Vergleich und Anpassung herangezogen werden sollte.

Auch in Sachen php-client kann ich wohl mit dem Versionsunterschied leben (ich denke, eine niedrige MySQL-Version wäre schlimmer...). Zumindest treten bis jetzt keine Fehler auf.

Immer im Hinterkopf behalten,
falls bei Konfiguration des mysql über phpmyadmin unerklärliches Verhalten auftreten sollte.
Insbesondere dann bei Forenfragen.

[Wurstpelle]

Ich hab die letzte Nacht übrigens noch ewig mit der innodb-Konfiguration gehadert. So funktioniert es nun:

Code: Alles auswählen

# Uncomment the following if you are using InnoDB tables
innodb_data_home_dir = /var/lib/mysql/
# innodb_data_file_path = ibdata1:1000M;ibdata2:10M:autoextend
# innodb_log_group_home_dir = /var/lib/mysql/
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
innodb_buffer_pool_size = 2096M
innodb_additional_mem_pool_size = 80M
# Set .._log_file_size to 25 % of buffer pool size
# innodb_log_file_size = 100M
# innodb_log_buffer_size = 32M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50

aber wehe ich entkommentiere "innodb_data_file_path" oder "innodb_log_file_size" - dann geht ga rnix mehr! Frag mich nicht wie oft ich gestern die ibdatas und iblogfiles gelöscht, die Datenbanken gelöscht, Tabellenfixes gestartet und alles immer wieder neu gestartet hatte - innodb war zu keiner Mitarbeit bereit. Nur in der dargestellten Konfiguration funktioniert die Datenbank mit innodb (und überlebt sogar einen reboot).

(Hatte ich "innodb_data_file_path" dabei, dann hat der Server beim starten zwar die ibdata erzeugt, sich aber immer mit einem Failstart verabschiedet und hing dann noch als Prozess im Speicher, der nur per kill zu beenden war. Das killen hatte dann wohl auch die innodb-struktur immer unbrauchbar gemacht).