Skip navigation links
2.10.2 Upgrade auf eine andere Architektur »
Section Navigation      [Toggle]

2.10.1. Upgrade von MySQL 5.0

Wenn Sie von einer 5.0-Installation auf 5.0.10 oder höher aktualisieren, beachten Sie, dass es unumgänglich ist, Ihre Grant-Tabellen zu aktualisieren. Andernfalls wird die Erstellung gespeicherter Prozeduren und Funktionen unter Umständen nicht funktionieren. Die entsprechende Vorgehensweise ist in Abschnitt 5.6, „mysql_fix_privilege_tables — Upgrade von MySQL-Systemtabellen“, beschrieben.

Hinweis: Es ist gängige Praxis, Ihre Daten vor der Installation einer neuen Softwareversion zu sichern. Auch wenn MySQL mit Eifer daran arbeitet, ein möglichst hohes Qualitätsniveau zu erzielen, sollten Sie Ihre Daten immer schützen, indem Sie eine Sicherungskopie erstellen. MySQL empfiehlt in der Regel, dass Sie Ihre Tabellen aus vorherigen Versionen speichern und dann neu laden, um auf 5.1 zu aktualisieren.

Generell sollten Sie beim Upgrade von MySQL 5.0 auf 5.1 Folgendes tun:

  • Überprüfen Sie die Einträge in den weiter unten in diesem Abschnitt vorhandenen Änderungslisten darauf, ob Ihre Anwendungen hierdurch auf irgendeine Weise betroffen sein könnten. Achten Sie dabei insbesondere auf solche Änderungen, die mit dem Vermerk Inkompatible Änderung versehen sind. Diese führen zu Inkompatibilitäten mit früheren MySQL-Versionen und können Ihre Aufmerksamkeit bereits vor Durchführung des Upgrades erfordern.

  • Lesen Sie die Änderungshistorie von MySQL 5.1 im Hinblick auf die wesentlichen neuen Funktionen, die Sie in Version 5.1 verwenden können. Siehe auch Abschnitt D.1, „Änderungen in Release 5.1.x (Entwicklung)“.

  • Wenn Sie MySQL Server unter Windows betreiben, lesen Sie Abschnitt 2.3.15, „Upgrade von MySQL unter Windows“.

  • Wenn Sie die Replikation nutzen, finden Sie in Abschnitt 6.7, „Upgrade eines Replikationssetups“, weitere Informationen zur Aktualisierung Ihrer Replikationskonfiguration.

Die nachfolgenden Listen beschreiben Änderungen, die unter Umständen Anwendungen betreffen können und die Sie beachten sollten, wenn Sie auf Version 5.1 aktualisieren.

Änderungen beim Server:

  • Inkompatible Änderung: MySQL 5.1 implementiert die Unterstützung einer sehr flexiblen Plug-In-API, die das Laden und Entladen verschiedener Komponenten während der Laufzeit gestattet, ohne dass der Server neu gestartet werden müsste. Siehe auch Abschnitt 26.2, „Die MySQL-Plug-In-Schnittstelle“. Die Plug-In-API benötigt die Tabelle mysql.plugin. Wenn Sie von einer älteren MySQL-Version aktualisieren, sollten Sie den Befehl mysql_fix_privilege_tables ausführen, um diese Tabelle zu erstellen. Siehe auch Abschnitt 5.6, „mysql_fix_privilege_tables — Upgrade von MySQL-Systemtabellen“.

    Plug-Ins werden in das Verzeichnis installiert, welches in der Systemvariablen plugin_dir spezifiziert ist. Diese Variable steuert auch die Position, von der der Server benutzerdefinierte Funktionen (User-Defined Functions, UDFs) lädt; dies stellt eine Änderung zu früheren Versionen von MySQL dar. Mithin müssen alle UDF-Bibliotheksdateien von jetzt an in das Plug-In-Verzeichnis installiert werden. Wenn Sie von einer älteren MySQL-Version aktualisieren, müssen Sie Ihre UDF-Dateien in das Plug-In-Verzeichnis migrieren.

  • Die Systemvariable table_cache wurde umbenannt in table_open_cache. Skripten, die table_cache verwenden, sollten so angepasst werden, dass sie den neuen Namen benutzen.

  • Inkompatible Änderung: Die Struktur der FULLTEXT-Indizes wurde in MySQL 5.1.6 geändert. Nach der Aktualisierung auf MySQL 5.1.6 oder höher müssen Sie die REPAIR TABLE-Anweisung für jede Tabelle aufrufen, die FULLTEXT-Indizes enthält.

SQL-Änderungen

  • Inkompatible Änderung: Der Namespace für Trigger wurde in MySQL 5.0.10 geändert. Vorher mussten Trigger-Namen je Tabelle eindeutig sein. Nun muss eine Eindeutigkeit innerhalb des Schemas (Datenbank) gegeben sein. Eine Auswirkung dieser Änderung besteht darin, dass die Syntax DROP TRIGGER nun statt eines Tabellennamens einen Schemanamen verwendet (wobei dieser Schemaname optional ist; wird er weggelassen, dann wird das aktuelle Schema verwendet).

    Wenn Sie von einer vorherigen Version von MySQL 5 auf MySQL 5.0.10 oder höher aktualisieren, müssen Sie alle Trigger löschen und sie neu erstellen; andernfalls wird DROP TRIGGER nach dem Upgrade nicht funktionieren. Gehen Sie am besten wie folgt vor:

    1. Aktualisieren Sie auf MySQL 5.0.10 oder höher, um auf die Trigger-Daten in der Tabelle INFORMATION_SCHEMA.TRIGGERS zugreifen zu können. (Dies sollte auch für Trigger aus Versionen vor 5.0.10 funktionieren.)

    2. Speichern Sie alle Trigger-Definitionen mithilfe der folgenden SELECT-Anweisung: 

      SELECT CONCAT('CREATE TRIGGER ', t.TRIGGER_SCHEMA, '.', t.TRIGGER_NAME,
              ' ', t.ACTION_TIMING, ' ', t.EVENT_MANIPULATION, ' ON ',
              t.EVENT_OBJECT_SCHEMA, '.', t.EVENT_OBJECT_TABLE,
              ' FOR EACH ROW ', t.ACTION_STATEMENT, '//' )
INTO OUTFILE '/tmp/triggers.sql'
FROM INFORMATION_SCHEMA.TRIGGERS AS t;

      Die Anweisung verwendet INTO OUTFILE, d. h., Sie müssen die Berechtigung FILE haben. Die Datei wird auf dem Serverhost erstellt; wenn Sie wollen, können Sie einen anderen Dateinamen verwenden. Um hundertprozentig sicher zu sein, überprüfen Sie die Trigger-Definitionen in der Datei triggers.sql und fertigen unter Umständen eine Sicherung der Datei an.

    3. Beenden Sie den Server und löschen Sie alle Trigger, indem Sie sämtliche .TRG-Dateien in Ihren Datenbankverzeichnissen entfernen. Wechseln Sie dann in Ihr Datenverzeichnis und setzen Sie folgenden Befehl ab: 

      shell> rm */*.TRG

    4. Starten Sie den Server und erstellen Sie alle Trigger mithilfe der triggers.sql-Datei neu: In meinem Fall sah dies beispielsweise so aus: 

      mysql> delimiter // ;
mysql> source /tmp/triggers.sql //

    5. Vergewissern Sie sich, dass alle Trigger mit der SHOW TRIGGERS-Anweisung erfolgreich erstellt wurden.

  • Inkompatible Änderung: MySQL 5.1.6 hat die Berechtigung TRIGGER neu eingeführt. Zuvor benötigte man die Berechtigung SUPER zum Erstellen oder Löschen von Triggern. Jetzt ist für derartige Vorgänge die Berechtigung TRIGGER erforderlich. Dies ist eine Sicherheitsoptimierung, da Sie Benutzern nun nicht länger die Berechtigung SUPER gewähren müssen, damit diese Trigger erstellen können. Allerdings wurde die Anforderung, dass das Konto, welches in der DEFINER-Klausel eines Triggers genannt wird, die Berechtigung SUPER haben muss, dadurch ersetzt, dass das Konto nun die Berechtigung TRIGGER erfordert. Wenn Sie von einer früheren MySQL 5-Version auf MySQL 5.1.6 oder höher aktualisieren, sollten Sie überprüfen, welche Konten in der DEFINER-Klausel vorhandener Trigger aufgeführt sind, und sicherstellen, dass diese Konten die Berechtigung TRIGGER haben. Andernfalls werden sie bei Aktivierung fehlschlagen. Mit der folgenden Anweisung können Sie ermitteln, welche Konten in den DEFINER-Klauseln aufgeführt sind: 

    SELECT DISTINCT DEFINER FROM INFORMATION_SCHEMA.TRIGGERS;

    Wenn Sie diesen Konten die Berechtigung TRIGGER gewährt haben, können Sie die Berechtigung SUPER für diejenigen Konten widerrufen, die Sie nicht anderweitig benötigen.

  • Einige Schlüsselwörter sind in MySQL 5.1 reserviert, bei denen dies in MySQL 5.0 nicht der Fall war. Siehe auch Abschnitt 9.5, „Ist MySQL pingelig hinsichtlich reservierter Wörter?“.

  • Die Anweisungen INSTALL PLUGIN und UNINSTALL PLUGIN, die für die Plug-In-API verwendet werden, sind neu. Gleiches gilt für die Klausel WITH PARSER der FULLTEXT-Indexerstellung, die ein Parser-Plug-In mit einem Volltextindex verknüpft. Abschnitt 26.2, „Die MySQL-Plug-In-Schnittstelle“.

Dies ist eine Übersetzung des MySQL-Referenzhandbuchs, das sich auf dev.mysql.com befindet. Das ursprüngliche Referenzhandbuch ist auf Englisch, und diese Übersetzung ist nicht notwendigerweise so aktuell wie die englische Ausgabe. Das vorliegende deutschsprachige Handbuch behandelt MySQL bis zur Version 5.1.