Manuals > MySQL-Referenzhandbuch für Version 4.1.1-alpha - 3 Installation von MySQL

3 Installation von MySQL

Dieses Kapitel beschreibt, woher man MySQL bezieht und wie man MySQL installiert:

• Eine Liste der Site, von denen Sie MySQL beziehen können, finden Sie unter section 3.2.1 Wie man MySQL erhält.
• Um festzustellen, welche Plattformen unterstützt werden, siehe section 3.2.2 Betriebssysteme, die von MySQL unterstützt werden. Beachten Sie bitte, dass nicht alle unterstützten Systeme gleich gut sind, um MySQL laufen zu lassen. Auf einigen läuft es sehr viel robuster und effizienter als auf anderen - siehe section 3.2.2 Betriebssysteme, die von MySQL unterstützt werden für Details.
• Mehrere Versionen von MySQL sind sowohl als Binär- als auch als Quellcode-Distributionen erhältlich. Wir stellen auch öffentlichen Zugriff auf unseren aktuellen Quellcode-Baum für diejenigen zur Verfügung, die die aktuellsten Entwicklungen sehen und uns helfen wollen, neuen Code zu testen. Um festzustellen, welche Version und welche Art von Distribution Sie benutzen sollten, siehe section 3.2.3 Welche MySQL-Version Sie benutzen sollten. Im Zweifelsfall benutzen Sie die Binärdistribution.
• Installationsanleitungen für Binär- und Quelldistributionen sind beschrieben in section 3.2.6 MySQL-Binärdistributionen, die von MySQL AB kompiliert wurden und section 3.3 Installation der Quelldistribution. Jede Anleitung enthält einen Abschnitt über System-spezifische Probleme, denen Sie begegnen können.
• Prozeduren, die nach der Installation durchgeführt werden sollen / müssen, finden Sie unter section 3.4 Einstellungen und Tests nach der Installation. Diese Prozeduren gelten, egal ob Sie MySQL von einer Binär- oder einer Quellcode-Distribution installieren.

3.1 Schnelle Standard-Installation von MySQL

3.1.1 MySQL auf Linux installieren

Die empfohlene Vorgehensweise für die Installation von MySQL auf Linux ist die Benutzung einer RPM-Datei. Die MySQL-RPMs werden aktuell auf einer RedHat-Version 6.2 gebaut, sollten aber auch auf anderen Linux-Versionen funktionieren, die rpm unterstützen und glibc benutzen.

Wenn Sie Probleme mit einer RPM-Datei haben, wenn Sie beispielsweise den Fehler ``Sorry, the host 'xxxx' could not be looked up'' erhalten, sehen Sie bitte unter section 3.1.1 MySQL auf Linux installieren nach.

Die RPM-Dateien, die Sie benutzen sollten, sind:

• MySQL-VERSION.i386.rpm Der MySQL-Server. Sie brauchen diese, es sei denn, Sie wollen sich lediglich mit einem MySQL-Server verbinden, der auf einer anderen Maschine läuft.
• MySQL-client-VERSION.i386.rpm Die Standard-MySQL-Client-Programme. Dieses Paket sollten Sie wohl immer installieren.
• MySQL-bench-VERSION.i386.rpm Tests und Benchmarks. Erfordert Perl und msql-mysql-modules RPMs.
• MySQL-devel-VERSION.i386.rpm Bibliotheken und Include-Dateien, die benötigt werden, wenn Sie andere MySQL-Clients kompilieren wollen, beispielsweise Perl-Module.
• MySQL-VERSION.src.rpm Dieses Paket enthält den Quelltext für alle obigen Pakete. Es kann auch dazu benutzt werden, um RPMs für andere Architekturen zu bauen (zum Beispiel für Alpha oder SPARC).

Um alle Dateien in einem RPM-Paket zu sehen, geben Sie folgendes ein: shell> rpm -qpl MySQL-VERSION.i386.rpm

Um eine minimale Standard-Installation durchzuführen, geben Sie folgendes ein:

Um nur das Client-Paket zu installieren, geben Sie folgendes ein:

Das RPM legt Dateien in `/var/lib/mysql' ab. Ausserdem erzeugt das RPM die entsprechenden Einträge in `/etc/rc.d/', um den Server beim Booten automatisch zu starten. (Falls Sie bereits vorher eine Installation durchgeführt haben, bedeutet das, dass Sie eine Kopie Ihrer vorher installierten MySQL-Startdateien machen sollten, falls Sie darin Änderungen vorgenommen haben, damit Sie diese Änderungen nicht verlieren.)

Nach der Installation der RPM-Datei(en) sollte der mysqld-Daemon laufen und Sie sollten jetzt in der Lage sein, mit der Benutzung von MySQL zu beginnen. See section 3.4 Einstellungen und Tests nach der Installation.

Wenn etwas schief geht, finden Sie weitere Informationen im Kapitel über die Binär-Installationen. See section 3.2.6 MySQL-Binärdistributionen, die von MySQL AB kompiliert wurden.

3.1.2 Installation von MySQL unter Windows

Der MySQL-Server für Windows ist in zwei Distributionstypen erhältlich:

1. Die Binärdistribution enthält ein Setup-Programm, das alles Benötigte installiert, so dass Sie den Server sofort starten können.
2. Die Quelldistribution enthält den gesamten Code und Unterstützungsdateien, um die ausführbaren Dateien unter Benutzung des VC++-6.0-Kompilers zu bauen. See section 3.3.7 Windows-Quelldistribution.

Im Allgemeinen sollten Sie die Binärdistribution benutzen.

Sie benötigen folgendes:

• Ein Windows-32-Bit-Betriebssystem der Familien Windows 9x, ME, NT oder Windows 2000. Die NT-Familie gestattet, den MySQL-Server als Systemdienst laufen zu lassen. See section 3.6.2.2 MySQL auf Windows NT oder Windows 2000 starten. Wenn Sie Tabellen benutzen, die größer als 4 GB sind, sollten Sie MySQL auf NTFS oder einem neueren Dateisystem installieren. Vergessen Sie bei der Erzeugung der Tabellen nicht, MAX_ROWS und AVG_ROW_LENGTH zu benutzen. See section 7.5.3 CREATE TABLE-Syntax.
• TCP/IP-Protokollunterstützung.
• Die MySQL-Binär- oder Quelldistribution für Windows kann von http://www.mysql.com/downloads/ herunter geladen werden. Hinweis: Die Distributionsdateien werden in einem komprimierten Format zur Verfügung gestellt. Wir empfehlen die Benutzung eines FTP-Clients, der in der Lage ist, abgebrochene FTP-Downloads wieder aufzunehmen (resume).
• Ein ZIP-Programm, um die Distributionsdatei zu entpacken.
• Genug Platz auf der Festplatte, um die Datenbanken entsprechend Ihren Anforderungen zu entpacken, zu installieren und zu erzeugen.
• Wenn Sie planen, sich über ODBC mit dem MySQL-Server zu verbinden, benötigen Sie zusätzlich den MyODBC-Treiber. See section 9.3 MySQL-ODBC-Unterstützung.

3.1.2.1 Binärdateien installieren

1. Wenn Sie auf einem NT- oder Windows-2000-Server arbeiten, melden Sie sich als Benutzer mit Administrationsrechten an.
2. Wenn Sie ein Upgrade einer früheren MySQL-Installation durchführen, müssen Sie den Server anhalten. Wenn Sie den Server als Systemdienst laufen lassen, geben Sie ein: C:\> NET STOP MySQL Ansonsten geben Sie folgendes ein: C:\mysql\bin> mysqladmin -u root shutdown
3. Auf NT-/Windows-2000-Maschinen müssen Sie auch den Systemdienst entfernen, wenn Sie die ausführbare Datei des Servers (z. B. -max or -nt) austauschen wollen: C:\mysql\bin> mysqld-max-nt --remove
4. Entpacken Sie die Distributionsdatei in ein temporäres Verzeichnis.
5. Starten Sie `setup.exe', um den Installationsprozess zu beginnen. Wenn Sie in ein anderes Verzeichnis als das vorgabemäßige (`c:\mysql') installieren wollen, legen Sie mit der Schaltfläche Durchsuchen das gewünschte Verzeichnis fest.
6. Beenden Sie den Installationsprozess.

Seit MySQL 3.23.38 enthält die Windows-Distribution sowohl die normalen als auch die MySQL-Max-Binärdateien. Der wichtigste Vorteil der Benutzung der normalen mysqld.exe-Binärdatei liegt darin, dass sie etwas schneller ist und weniger Ressourcen belegt.

Hier ist eine Liste der unterschiedlichen MySQL-Server, die Sie benutzen können:

mysqld	Kompiliert mit komplettem Debugging und automatischer Überprüfung der Speicherzuordnung (memory allocation), symbolischen Links, InnoDB- und BDB-Tabellen.
mysqld-opt	Optimierte Binärdistribution ohne Unterstützung von Transaktionstabellen.
mysqld-nt	Optimierte Binärdatei für NT mit Unterstützung von Named Pipes. Man kann diese Version auf Windows 98 laufen lassen, aber in diesem Fall werden keine Named Pipes angelegt und man muss TCP/IP installiert haben.
mysqld-max	Optimierte Binärdistribution mit Unterstützung symbolischer Links, InnoDB und BDB-Tabellen.
mysqld-max-nt	Wie mysqld-max, aber mit Unterstützung von Named Pipes kompiliert.

Alle genannten Binärdistributionen sind für den Pentium Pro Prozessor optimiert, sollten aber auf jedem Intel-Prozessor >= 386 laufen.

ACHTUNG: Wenn Sie InnoDB-Tabellen benutzen wollen, müssen Sie bestimmte Start-Optionen in Ihrer `my.ini'-Datei festlegen! See section 8.5.2 Mit InnoDB anfangen - Optionen.

3.2 Allgemeine Installationsthemen

3.2.1 Wie man MySQL erhält

Sehen Sie wegen Informationen zur aktuellen Version und für Download-Anweisungen auf MySQL home page nach.

Unser Haupt-Mirror-Server für den Download ist hier:

http://mirrors.sunsite.dk/mysql/

Wenn Sie Interesse haben, eine MySQL-Mirror-Site beizusteuern, können Sie anonymes rsync mit rsync://sunsite.dk/ftp/mirrors/mysql/ machen. Schicken Sie bitte eine E-Mail an webmaster@mysql.com und geben Sie uns Bescheid, wo Ihr Mirror liegt, damit wir ihn der unten stehenden Liste hinzufügen können.

Wenn Sie Probleme beim Download von unserer Hauptseite aus haben, probieren Sie eine der unten stehenden Mirror-Sites.

Geben Sie bitte webmaster@mysql.com Bescheid, wenn Sie auf schlechte oder veraltete Mirror-Sites stoßen.

3.2.2 Betriebssysteme, die von MySQL unterstützt werden

Wir benutzen GNU Autoconf, daher ist es möglich, MySQL auf alle modernen Betriebssysteme zu portieren, auf denen Posix-Threads und ein C++-Kompiler funktionieren. (Um nur den Client-Code zu kompilieren, wir lediglich ein C++-Kompiler benötigt.) Wir benutzen und entwickeln die Software selbst hauptsächlich auf Sun Solaris (Versionen 2.5 - 2.7) und SuSE Linux Version 7.x.

Beachten Sie, dass die native Thread-Unterstützung für viele Betriebssysteme nur mit den neuesten Versionen funktioniert. Es wurde berichtet, dass MySQL erfolgreich auf folgenden Betriebssystemen / Thread-Paket-Kombinationen kompiliert wurde:

• AIX 4.x mit nativen Threads. See section 3.6.6.4 Anmerkungen zu IBM-AIX.
• Amiga.
• BSDI 2.x mit enthaltenem MIT-pThreads-Paket. See section 3.6.4.6 Anmerkungen zu BSD/OS.
• BSDI 3.0, 3.1 und 4.x mit nativen Threads. See section 3.6.4.6 Anmerkungen zu BSD/OS.
• DEC Unix 4.x mit nativen Threads. See section 3.6.6.6 Anmerkungen zu Alpha-DEC-UNIX (Tru64).
• FreeBSD 2.x mit enthaltenem MIT-pThreads-Paket. See section 3.6.4.1 Anmerkungen zu FreeBSD.
• FreeBSD 3.x und 4.x mit nativen Threads. See section 3.6.4.1 Anmerkungen zu FreeBSD.
• HP-UX 10.20 mit enthaltenem MIT-pThreads-Paket. See section 3.6.6.2 Anmerkungen zu HP-UX Version 10.20.
• HP-UX 11.x mit nativen Threads. See section 3.6.6.3 Anmerkungen zu HP-UX Version 11.x.
• Linux 2.0+ mit LinuxThreads 0.7.1+ oder glibc 2.0.7+. See section 3.6.1 Linux (alle Linux-Versionen).
• Mac OS X Server. See section 3.6.5 Anmerkungen zu Mac OS X.
• NetBSD 1.3/1.4 Intel und NetBSD 1.3 Alpha (benötigt GNU make). See section 3.6.4.2 Anmerkungen zu NetBSD.
• OpenBSD > 2.5 mit nativen Threads. OpenBSD < 2.5 mit enthaltenem MIT-pThreads-Paket. See section 3.6.4.3 Anmerkungen zu OpenBSD.
• OS/2 Warp 3, FixPack 29 und OS/2 Warp 4, FixPack 4. See section 3.6.7 Anmerkungen zu OS/2.
• SGI Irix 6.x mit nativen Threads. See section 3.6.6.8 Anmerkungen zu SGI Irix.
• Solaris 2.5 und höher mit nativen Threads auf SPARC und x86. See section 3.6.3 Anmerkungen zu Solaris.
• SunOS 4.x mit enthaltenem MIT-pThreads-Paket. See section 3.6.3 Anmerkungen zu Solaris.
• Caldera (SCO) OpenServer mit einem aktuellen Port des FSU-PThreads-Pakets. See section 3.6.6.9 Anmerkungen zu Caldera.
• Caldera (SCO) UnixWare 7.0.1. See section 3.6.6.10 Anmerkungen zu Caldera Unixware Version 7.0.
• Tru64 Unix
• Windows 95, Windows 98, NT und Windows 2000. See section 3.6.2 Anmerkungen zu Windows.

Beachten Sie, dass nicht alle Plattformen gleichermaßen gut geeignet sind, um MySQL laufen zu lassen. Wie gut eine bestimmte Plattform für hohe Last und geschäftskritische Anwendungen geeignet ist, hängt von folgenden Faktoren ab:

• Allgemeine Stabilität der Thread-Bibliothek. Eine Plattform mag in anderer Hinsicht einen exzellenten Ruf haben, aber wenn die Thread-Bibliothek unstabil ist, die von MySQL aufgerufen wird, läuft MySQL nur so stabil wie die Thread-Bibliothek, selbst wenn alles Sonstige perfekt ist.
• Fähigkeit des Kernels und / oder der Thread-Bibliothek, die Vorteile von SMP auf Mehrprozessor-Systemen wahrzunehmen. Mit anderen Worten: Wenn ein Prozess einen Thread anlegen, sollte es für diesen Thread möglich sein, auf anderen Prozessoren zu laufen als der Original-Prozess.
• Fähigkeit des Kernels und / oder der Thread-Bibliothek, viele Threads laufen zu lassen, die häufig einen Mutex über eine kurze, kritische Region anlegen / lösen können ohne exzessive Kontext-Umschaltungen. Mit anderen Worten: Wenn die Implementation von pThread_mutex_lock() zu sehr darauf bedacht ist, CPU zu erlangen, wird das MySQL gewaltig schmerzen. Wenn man sich dieser Tatsache nicht bewusst ist, machen zusätzliche Prozessoren MySQL in der Tat langsamer.
• Allgemeine Stabilität und Performance des Dateisystems.
• Fähigkeit des Dateisystems, überhaupt mit großen Dateien umgehend zu können, und zwar effizient, wenn Ihre Tabellen Groß sind.
• Unser Grad von Erfahrung, hier bei MySQL AB, mit der Plattform. Wenn wir eine Plattform gut kennen, setzen wir plattformspezifische Optimierungen / Verbesserungen (Fixes) ein, die zur Kompilierzeit aktiv werden. Darüber hinaus können wir Sie beraten, wie Sie Ihr System optimal für MySQL konfigurieren.
• Umfang des Testens ähnlicher Konfigurationen, das wir intern durchgeführt haben.
• Anzahl von Benutzern, die MySQL auf dieser Plattform erfolgreich mit ähnlichen Konfigurationen haben laufen lassen. Wenn diese Zahl Groß ist, ist die Wahrscheinlichkeit viel geringer, plattformspezifische Überraschungen zu erleben.

Nach den genannten Kriterien sind die besten Plattformen für MySQL bislang x86 mit SuSE Linux 7.1, 2.4 Kernel und ReiserFS (oder jede ähnliche Linux-Distribution) und Sparc mit Solaris 2.7 oder 2.8. FreeBSD kommt als drittes, aber wir hoffen wirklich, dass es zur Spitze aufschließt, sobald erst einmal die Thread-Bibliothek verbessert ist. Wir hoffen auch, dass wir alle anderen Plattformen, auf denen MySQL kompiliert werden kann und korrekt läuft, die aber nicht ganz denselben Grad an Stabilität und Performance aufweisen, in die Spitzenkategorie aufnehmen können. Das erfordert von unserer Seite aus einige Kooperationsbemühungen mit den Entwicklern der Betriebssystem-Bibliothek-Komponenten, von denen MySQL abhängt. Wenn Sie Interesse daran haben, eine dieser Komponenten zu verbessern und in der Lage sind, ihre Entwicklung zu beeinflussen, und detailliertere Informationen darüber brauchen, was MySQL benötigt, um besser zu laufen, schicken Sie eine E-Mail an internals@lists.mysql.com.

Beachten Sie bitte auch, dass der obige Vergleich nichts darüber aussagen will, dass ein Betriebssystem allgemein besser oder schlechter als ein anderes sei. Wir reden hier über die Auswahl eines bestimmten Betriebssystems für einen ganz bestimmten Zweck - nämlich, MySQL laufen zu lassen, und vergleichen die Betriebssysteme nur in dieser Hinsicht. Folglich wäre das Ergebnis dieses Vergleichs ein anderes, wenn wir weitere Belange berücksichtigen würden. In manchen Fällen liegt der Grund, warum ein Betriebssystem besser als ein anderes geeignet ist, schlicht darin, dass wir auf dieser speziellen Plattform mehr Tests und Optimierungen durchgeführt haben. Wir stellen hier nur unsere Beobachtungen dar, um Ihnen bei der Entscheidung zu helfen, auf welcher Plattform Sie MySQL benutzen sollten.

3.2.3 Welche MySQL-Version Sie benutzen sollten

Zunächst müssen Sie entscheiden, ob Sie das letzte Entwicklungs-Release oder das letzte stabile Release benutzen wollen:

• Normalerweise, wenn Sie MySQL zum ersten Mal benutzen, oder wenn Sie versuchen, MySQL auf ein System zu portieren, für das es keine Binärdistribution gibt, empfehlen wir, das stabile Release zu nehmen (aktuell Version 4.1.1-alpha). Beachten Sie, dass alle MySQL-Releases mit den MySQL-Benchmarks und einer umfassenden Test-Suite getestet sind, bevor das Release heraus gegeben wird.
• Wenn Sie ein altes System laufen lassen und es aktualisieren möchten, aber nicht riskieren wollen, dass ein Update nicht reibungslos klappt, sollten Sie zur aktuellsten Version des Zweiges aktualisieren, den Sie benutzen (bei dem nur die letzte Versionsnummer neuer ist als Ihre, also z. B. von 3.23.36 auf 3.23.44, wenn 3.23.44 die neueste Version des Zweigs ist). Wir haben uns innerhalb der Versions-Zweige bemüht, nur schwere Fehler zu beseitigen und kleine, relativ sichere Änderungen zu machen.

Als nächstes müssen Sie entscheiden, ob Sie eine Quelldistribution oder eine Binärdistribution nehmen wollen. In den meisten Fällen ist es ratsam, eine Binärdistribution zu nehmen, wenn eine für Ihre Plattform existiert, weil sich diese im Allgemeinen leichter installieren läßt als eine Quelldistribution.

In folgenden Fällen fahren Sie mit einer Quellinstallation wahrscheinlich besser:

• Wenn Sie MySQL an einer ganz bestimmten Stelle installieren wollen. (Die Standard-Binärdistributionen sind an jeder Stelle lauffähig, aber vielleicht wollen Sie noch mehr Flexibilität haben.)
• Um unterschiedlichen Bedürfnissen von Benutzern entgegen zu kommen, stellen wir zwei unterschiedliche Binärversionen zur Verfügung: Eine, die mit den nicht transaktionalen Tabellen-Handlern kompiliert ist (eine kleine, schnelle Binärdatei), sowie eine, die mit den wichtigsten erweiterten Optionen wie transaktionssicheren Tabellen kompiliert ist. Beide Versionen sind aus derselben Quelldistribution kompiliert. Alle nativen MySQL-Clients können sich mit beiden MySQL-Versionen verbinden. Die erweiterte MySQL-Binärdistribution ist mit dem -max-Suffix gekennzeichnet und ist mit denselben Optionen konfiguriert wie mysqld-max. See section 5.7.5 mysqld-max, ein erweiterter mysqld-Server. Wenn Sie das MySQL-Max-RPM benutzen wollen, müssen Sie zuerst das Standard-MySQL-RPM installieren.
• Wenn Sie mysqld mit einigen zusätzlichen Features konfigurieren wollen, die NICHT in den Standard-Binärdistributionen enthalten sind. Hier ist eine Liste der gebräuchlichsten Zusatzoptionen, die Sie vielleicht nutzen wollen:
  • --with-berkeley-db
  • --with-innodb
  • --with-raid
  • --with-libwrap
  • --with-named-z-lib (ist in einigen Binärdateien enthalten)
  • --with-debug[=full]
• Die vorgabemäßige Binärdistribution wird normalerweise mit Unterstützung für alle Zeichensätze kompiliert und sollte auf einer Vielzahl von Prozessoren derselben Prozessorfamilie laufen. Wenn Sie einen schnelleren MySQL-Server erhalten wollen, können Sie ihn erneut kompilieren und nur die Zeichensätze benutzen, die Sie brauchen. Sie können auch einen besseren Kompiler (wie pgcc) oder andere Kompilieroptionen benutzen, die besser auf Ihren Prozessor optimiert sind.
• Wenn Sie einen Bug gefunden und dem MySQL-Entwicklungsteam mitgeteilt haben, werden Sie wahrscheinlich einen Patch erhalten, den Sie mit der Quelldistribution verwenden müssen, um den Bug zu beheben.
• Wenn Sie den C- und C++-Code lesen (und / oder ändern) wollen, aus dem MySQL besteht, müssten Sie eine Quelldistribution laden. Der Quellcode ist immer das ''letzte Handbuch''. Quelldistributionen enthalten auch mehr Tests und Beispiele als Binärdistributionen.

Das MySQL Benennungsschema benutzt Release-Nummern, die aus drei Zahlen und einem Suffix bestehen. Ein Release-Name wie mysql-3.21.17-beta zum Beispiel wird wie folgt interpretiert:

• Die erste Zahl (3) beschreibt das Dateiformat. Alle Version-3-Releases haben dasselbe Dateiformat.
• Die zweite Zahl (21) ist die Release-Ebene (Level). Normalerweise kann man hier zwischen zweien auswählen. Einer ist der stabile Zweig des Releases (aktuell 23), der andere ist der Entwicklungs-Zweig (aktuell 4.0). Normalerweise sind beide stabil, aber die Entwicklungsversion kann Macken oder fehlende Dokumentation neuer Features haben oder sich auf einigen Systemen nicht kompilieren lassen.
• Die dritte Zahl (17) ist die Versionsnummer innerhalb der Release-Ebene. Diese wird für jede neue Distribution hochgezählt. Üblicherweise werden Sie die neueste Version der Release-Ebene einsetzen wollen, die Sie gewählt haben.
• Das Suffix (beta) zeigt den Stabilitätsgrad des Releases an. Mögliche Suffixe sind:
  • alpha zeigt an, dass das Release größere Abschnitte von neuem Code enthält, der noch nicht zu 100% getestet wurde. Bekannte Bugs (üblicherweise gibt es keine) sind im News-Abschnitt dokumentiert. See section D MySQL-Änderungsverlauf (Change History). In den meisten Alpha-Releases gibt es neue Befehle und Erweiterungen. Bei einem Alpha-Release können durch aktive Weiterentwicklung größere Code-Änderungen vorkommen, aber alles wird getestet, bevor ein Release veröffentlicht wird. Es sollte in keinem MySQL-Release bekannte Bugs geben.
  • beta bedeutet, dass jeglicher neue Code getestet wurde. Es wurden keine neuen Features hinzugefügt, die bei altem Code Probleme verursachen könnten. Es sollte keine bekannten Bugs geben. Eine Version wird von Alpha auf Beta gesetzt, wenn innerhalb der Alpha-Version mindestens einen Monat lang keine schweren Fehler mehr berichtet wurden. Wir planen für eine solche Version dann keine neuen Features mehr, die einen alten Befehl unzuverlässiger machen könnten.
  • gamma ist eine Beta-Version, die eine ganze Weile draussen war und offensichtlich gut funktioniert. Nur kleinere Problembehebungen wurden hinzugefügt. So etwas nennen viele andere Unternehmen ein Release.
  • Wenn eine Version kein Suffix besitzt, bedeutet das, dass diese Version schon eine ganze Weile auf vielen unterschiedlichen Sites eingesetzt wird, wobei keine Bugs ausser plattformspezifischen Bugs berichtet wurden. Für ein solches Release werden nur kritische Fehlerbehebungen durchgeführt. So etwas nennen wir ein stabiles Release.

Alle Versionen von MySQL laufen durch unsere Standard-Tests und -Benchmarks, um sicherzustellen, dass man sie relativ sicher benutzen kann. Weil die Standard-Tests im Laufe der Zeit erweitert werden, um auf alle früher gefundenen Bugs zu prüfen, wird die Test-Suite immer besser.

Beachten Sie, dass alle Releases mindestens wie folgt getestet wurden:

Mit der internen Test-Suite

Diese ist Teil unseres Produktionssystems für einen Kunden. Sie besitzt viele Tabellen mit Hunderten Megabytes an Daten.

Mit der MySQL-Benchmark-Suite

Diese läßt eine Reihe gebräuchlicher Anfragen laufen. Das ist zusätzlich ein Test darauf, ob die letzten Optimierungen den Code tatsächlich schneller gemacht haben. See section 6.1.4 Die MySQL-Benchmark-Suite.

Mit dem crash-me-Test

Dieser Test versucht festzustellen, welche Features die Datenbank unterstützt und was ihre Fähigkeiten und Beschränkungen sind. See section 6.1.4 Die MySQL-Benchmark-Suite.

Ein weiterer Test besteht darin, dass wir die neueste MySQL-Version in unserer internen Entwicklungsumgebung einsetzen, mindestens auf einer Maschine. Wir arbeiten hierbei mit mehr als 100 Gigabytes an Daten.

3.2.4 Installationslayouts

Dieser Abschnitt beschreibt das vorgabemäßige Layout der Verzeichnisse, die durch die Installation von Binär- und Quelldistributionen angelegt werden.

Eine Binärdistribution wird installiert, indem sie an die Installationsstelle entpackt wird, die Sie auswählen (typischer Weise `/usr/local/mysql'). Die Installation erstellt folgende Verzeichnisse an dieser Stelle:

Eine Quelldistribution wird installiert, nachdem Sie sie konfiguriert und kompiliert haben. Vorgabemäßig werden Dateien unter `/usr/local' installiert, und zwar in den folgenden Unterverzeichnissen:

Innerhalb eines Installationsverzeichnisses weicht das Layout einer Quellinstallation von dem einer Binärinstallation wie folgt ab:

• Der mysqld-Server wird in das `libexec'-Verzeichnis installiert und nicht in das `bin'-Verzeichnis.
• Das Daten-Verzeichnis ist `var' und nicht `data'.
• mysql_install_db wird in das `/usr/local/bin' Verzeichnis installiert und nicht in `/usr/local/mysql/Skripts'.
• Die Header-Datei und Bibliotheksverzeichnisse sind `include/mysql' und `lib/mysql' und nicht `include' und `lib'.

Sie können Ihre eigene Binärinstallation aus einer kompilierten Quelldistribution erzeugen, indem Sie das Skript `Skripts/make_binary_Distribution' ausführen.

3.2.5 Wann und wie Updates veröffentlicht werden

MySQL entwickelt sich ziemlich schnell hier bei MySQL AB und wir wollen, dass andere MySQL-Benutzer daran teilhaben. Wir versuchen, immer dann ein neues Release heraus zu bringen, wenn wir sehr nützliche Features haben, für die offensichtlich ein Bedarf besteht.

Auch versuchen wir, unseren Benutzern zu helfen, wenn Sie nach Features anfragen, die einfach zu implementieren sind. Wir notieren, was unsere lizensierten Nutzer haben wollen, und insbesondere, was unsere Benutzer mit erweitertem E-Mail-Support haben wollen, und versuchen ihnen, eben das zu bieten.

Niemand muss einen neuen Release herunter laden. Im News-Abschnitt steht stets, ob das neue Release etwas beinhaltet, was Sie wirklich brauchen. See section D MySQL-Änderungsverlauf (Change History).

Wenn wir MySQL aktualisieren, fahren wir folgende Politik:

• Bei kleineren Updates wird die letzte Zahl (von rechts) in der Versionsnummer herauf gezählt (Minor Release). Wenn es größere neue Features gibt oder kleinere Inkompatibilitäten mit vorherigen Versionen, wird die zweite Zahl der Versionsnummer herauf gezählt (Major Release). Wenn sich das Dateiformat ändert, wird die erste Zahl herauf gezählt.
• have to do with "small bugs" => minor releases? Stable tested releases are meant to appear about 1-2 times a year, but if small bugs are found, a release mit only bug fixes will be released. Als stabil getestete Releases sollten etwa ein- bis zweimal im Jahr erscheinen, aber wenn kleinere Fehler gefunden werden, wird nur ein Release mit Bug-Fixes heraus gegeben.
• Funktionierende Releases sollten etwa alle 1 bis 8 Wochen erscheinen.
• Binärdistributionen für einige Plattformen werden von uns für größere Releases (Major) heraus gegeben. Andere Leute stellen vielleicht auch Binärdistributionen für andere Systeme her, aber nicht so häufig.
• Patches stellen wir üblicherweise zur Verfügung, sobald wir kleinere Bugs ausfindig gemacht und behoben haben.
• Für nicht kritische, aber störende Bugs machen wir Patches verfügbar, wenn sie uns zugesandt werden. Ansonsten kombinieren wir mehrere davon in einem größeren Patch.
• Wenn durch unglückliche Umstände ein Release einen schweren Fehler enthält, erstellen wir sobald wie möglich ein neues Release. Das würden wir auch gern bei anderen Unternehmen so sehen.

The current stable release ist Version 3.23; We have already moved active Entwicklung to Version 4.0. Bugs will still be fixed in the stable version. We don't believe in a complete freeze, as this also leaves out bug fixes und things that ``must be done.'' ``Somewhat frozen'' means that we may add small things that ``almost surely will not affect anything that's already working.''

3.2.6 MySQL-Binärdistributionen, die von MySQL AB kompiliert wurden

Als Service stellen wir bei MySQL AB einen Satz von Binärdistributionen von MySQL zur Verfügung, die auf unserer Site kompiliert wurden oder auf Sites von Kunden, die uns freundlicherweise Zugang zu Ihren Maschinen gewährt haben.

Diese Distributionen werden mit Skripts/make_binary_distribution erzeugt und mit folgenden Kompilern und Optionen konfiguriert:

SunOS 4.1.4 2 sun4c mit gcc 2.7.2.1

CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors" ./configure --prefix=/usr/local/mysql --disable-shared --with-extra-charsets=complex --enable-assembler

SunOS 5.5.1 (und höher) sun4u mit egcs 1.0.3a oder 2.90.27 oder gcc 2.95.2 und neuer

CC=gcc CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-low-memory --with-extra-charsets=complex --enable-assembler

SunOS 5.6 i86pc mit gcc 2.8.1

CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql --with-low-memory --with-extra-charsets=complex

Linux 2.0.33 i386 mit pgcc 2.90.29 (egcs 1.0.3a)

CFLAGS="-O3 -mpentium -mstack-align-double" CXX=gcc CXXFLAGS="-O3 -mpentium -mstack-align-double -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static --with-extra-charsets=complex

Linux 2.2.x mit x686 mit gcc 2.95.2

CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static --disable-shared --with-extra-charset=complex

SCO 3.2v5.0.4 i386 mit gcc 2.7-95q4

CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex

AIX 2 4 mit gcc 2.7.2.2

CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex

OSF1 V4.0 564 alpha mit gcc 2.8.1

CC=gcc CFLAGS=-O CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql --with-low-memory --with-extra-charsets=complex

Irix 6.3 IP32 mit gcc 2.8.0

CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex

BSDI BSD/OS 3.1 i386 mit gcc 2.7.2.1

CC=gcc CXX=gcc CXXFLAGS=-O ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex

BSDI BSD/OS 2.1 i386 mit gcc 2.7.2

CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex

Wenn jemand optimalere Optionen für die obigen Konfigurationen hat, können diese jederzeit der Entwickler-Mailing-Liste unter internals@lists.mysql.com mitgeteilt werden.

RPM-Distributionen von MySQL-Version 3.22 wurden durch Benutzer beigesteuert. Ab Version 3.22 werden die RPMs von uns bei MySQL AB erzeugt.

Wenn Sie eine Debug-Version von MySQL kompilieren wollen, müssen Sie den oben genannten Kompilierzeilen --with-debug oder --with-debug=full hinzufügen und jegliche -fomit-frame-pointer-Optionen entfernen.

3.3 Installation der Quelldistribution

Bevor Sie mit der Quellinstallation fortfahren, sehen Sie nach, ob eine Binärdistribution für Ihre Plattform verfügbar ist, die so wie Sie wollen funktioniert. Wir geben uns viel Mühe, die Binärdistributionen mit den bestmöglichen Optionen zu bauen.

Sie benötigen folgende Werkzeuge, um MySQL aus der Quelldistribution zu bauen und zu installieren:

• GNU gunzip, um die Distribution zu entpacken.
• Ein vernünftiges tar, um die Distribution zu entpacken. Von GNU tar ist bekannt, dass es funktioniert. Sun tar ist dafür bekannt, dass es Probleme verursacht.
• Einen funktionierenden ANSI-C++-Kompiler. gcc >= 2.95.2, egcs >= 1.0.2 oder egcs 2.91.66, SGI C++ und SunPro C++ sind einige der Kompiler, von denen bekannt ist, dass sie funktionieren. libg++ wird nicht benötigt, wenn Sie gcc benutzen. gcc 2.7.x hat einen Bug, der es verunmöglicht, einige perfekt der vorgeschriebenen Form entsprechende C++-Dateien zu kompilieren, zum Beispiel `sql/sql_base.cc'. Wenn Sie nur gcc 2.7.x zur Verfügung haben, müssen Sie Ihren gcc aktualisieren, um MySQL kompilieren zu können. gcc 2.8.1 ist ebenfalls für Probleme auf einigen Plattformen bekannt, daher sollten Sie auch diesen vermeiden, wenn Sie einen neueren Kompiler für diese Plattform zur Verfügung haben. gcc >= 2.95.2 wird für das Kompilieren von MySQL-Versionen 3.23.x empfohlen.
• Ein gutes make-Programm. GNU make wird stets empfohlen und ist manchmal erforderlich. Wenn Sie Probleme bekommen, empfehlen wir, es mit GNU make 3.75 oder neuer zu versuchen.

Wenn Sie eine aktuelle Version von gcc verwenden (aktuell genug, um die -fno-exceptions-Option zu verstehen), ist es SEHR WICHTIG, dass Sie diese Option benutzen. Ansonsten könnte es sein, dass Sie eine Binärdatei kompilieren, die zu zufälligen Zeitpunkten abstürzt. Wir empfehlen zusätzlich, dass Sie -felide-contructors und -fno-rtti zusammen mit -fno-exceptions benutzen. Im Zweifel gehen Sie wie folgt vor:

Für die meisten Systeme werden Sie dadurch eine schnelle, stabile Binärinstallation erhalten.

Wenn Sie Probleme bekommen, BITTE BENUTZEN SIE IMMER mysqlbug zum Fragenstellen die Liste mysql@lists.mysql.com. Selbst wenn das Problem kein Bug ist, sammelt mysqlbug Systeminformationen, die anderen helfen werden, Ihr Problem zu lösen. Wenn Sie mysqlbug nicht benutzen, verringern Sie die Möglichkeit, eine Lösung Ihres Problems zu bekommen! mysqlbug finden Sie im `scripts'-Verzeichnis, nachdem Sie die Distribution entpackt haben. See section 2.6.2.3 Wie man Bugs oder Probleme berichtet.

3.3.1 Schnellinstallation, Überblick

Die grundlegenden Befehle, die Sie ausführen müssen, um eine MySQL-Quelldistribution zu installieren, sind:

Wenn Sie Unterstützung für InnoDB-Tabellen haben wollen, sollten Sie die Datei /etc/my.cnf editieren und die `#'-Zeichen vor den Parametern entfernen, der mit innodb_... beginnen. See section 5.1.2 my.cnf-Optionsdateien. See section 8.5.2 Mit InnoDB anfangen - Optionen.

Wenn Sie mit einem Quell-RPM anfangen, gehen Sie wie folgt vor:

Das erzeugt ein Binär-RPM, das Sie installieren können.

Sie können neue Benutzer hinzufügen, indem Sie das bin/mysql_setpermission-Skript benutzen, falls Sie die DBI- und Msql-Mysql-modules-Perl-Module installieren.

Eine detailliertere Beschreibung folgt.

Um eine Quelldistribution zu installieren, führen Sie die unten stehenden Schritte aus und gehen dann weiter zu section 3.4 Einstellungen und Tests nach der Installation, um die Schritte nach der Installation und ein paar Tests durchzuführen.

1. Wählen Sie das Verzeichnis, in dem Sie die Distribution entpacken wollen, und wechseln Sie dort hinein.
2. Holen Sie sich eine Distributionsdatei von einer der Sites, die unter section 3.2.1 Wie man MySQL erhält aufgelistet sind.
3. Wenn Sie Berkeley-DB-Tabellen mit MySQL verwenden wollen, müssen Sie sich eine gepatchte Version des Berkeley-DB-Quellcodes besorgen. Bitte lesen Sie das Kapitel über Berkeley-DB-Tabellen, bevor Sie fortfahren. See section 8.6 BDB- oder Berkeley_db-Tabellen. MySQL-Quelldistributionen stehen als komprimierte tar-Archive zur Verfügung und haben Namen wie `mysql-VERSION.tar.gz', wobei VERSION eine Zahl ist, wie 4.1.1-alpha.
4. Fügen Sie einen Benutzer (User) und eine Gruppe (Group) hinzu, unter dem / der mysqld laufen soll: shell> groupadd mysql shell> useradd -g mysql mysql Diese Befehle fügen den Benutzer mysql und die Gruppe mysql hinzu. Die Syntax für useradd und groupadd kann sich auf unterschiedlichen Unix-Systemen geringfügig unterscheiden. Die Befehle können adduser und addgroup heißen. Wenn Sie wollen, können Sie Benutzer und Gruppe auch anders nennen als mysql.
5. Entpacken Sie die Distribution ins aktuelle Verzeichnis: shell> gunzip < /pfad/zu/mysql-VERSION.tar.gz | tar xvf - Dieser Befehl erzeugt ein Verzeichnis namens `mysql-VERSION'.
6. Wechseln Sie in das oberste Verzeichnis der entpackten Distribution: shell> cd mysql-VERSION Beachten Sie, dass Sie aktuell MySQL aus diesem obersten Verzeichnis konfigurieren und bauen müssen. Sie können MySQL nicht in ein anderes Verzeichnis bauen.
7. Konfigurieren Sie das Release und kompilieren Sie alles: shell> ./configure --prefix=/usr/local/mysql shell> make Wenn Sie configure laufen lassen, können Sie dabei einige Optionen angeben. Geben Sie ./configure --help ein, um eine Liste von Optionen zu erhalten. section 3.3.3 Typische configure-Optionen erörtert einige der nützlicheren Optionen. Wenn configure fehlschlägt und Sie sich wegen Hilfe an mysql@lists.mysql.com wenden, geben Sie bitte alle Zeilen aus `config.log' an, von denen Sie annehmen, dass sie bei der Problembehebung hilfreich sein könnten. Fügen Sie auch die letzten Zeilen der Ausgabe von configure hinzu, wenn configure abbricht. Schicken Sie den Bug-Bericht ein, indem Sie das mysqlbug-Skript benutzen. See section 2.6.2.3 Wie man Bugs oder Probleme berichtet. Wenn das Kompilieren fehlschlägt, sehen Sie unter section 3.3.5 Probleme beim Kompilieren? nach, was bei einer Reihe geläufiger Probleme hilft.
8. Installieren Sie alles: shell> make install Eventuell müssen Sie diesen Befehl als root ausführen.
9. Erzeugen Sie die MySQL-Berechtigungstabellen (Grant Tables, nur notwendig, wenn Sie MySQL noch nie vorher installiert haben): shell> scripts/mysql_install_db Beachten Sie, dass bei MySQL-Versionen vor Version 3.22.10 der MySQL-Server startet, wenn Sie mysql_install_db laufen lassen. Das gilt für neuere Versionen nicht mehr!
10. Ändern Sie den Besitzer der Binärdateien zu root und den Besitzer des Daten-Verzeichnisses zu dem Benutzer, unter dem Sie mysqld laufen lassen wollen: shell> chown -R root /usr/local/mysql shell> chown -R mysql /usr/local/mysql/var shell> chgrp -R mysql /usr/local/mysql Der erste Befehl ändert die owner-Attribute der Dateien auf den Benutzer root, der zweite ändert die owner-Attribute des Daten-Verzeichnisses auf den Benutzer mysql und der dritte ändert die group-Attribute auf die Gruppe mysql.
11. Wenn Sie die Unterstützung für die Perl-DBI/DBD-Schnittstelle hinzufügen wollen, sehen Sie unter section 9.2 MySQL-Perl-API nach.
12. Wenn Sie wollen, dass MySQL automatisch startet, wenn Sie Ihre Maschine hoch fahren, kopieren Sie support-files/mysql.server an die Stelle, wo Ihr System seine Startdateien hat. Weitere Informationen finden Sie im support-files/mysql.server-Skript selbst sowie unter section 3.4.3 MySQL automatisch starten und anhalten.

Nachdem alles installiert wurde, sollten Sie Ihre Distribution initialisieren und testen:

Wenn dieser Befehl sofort mit mysqld daemon ended fehlschlägt, finden Sie einige Informationen dazu in der Datei `mysql-Daten-Verzeichnis/'hostname'.err'. Der wahrscheinliche Grund ist der, dass bereits ein anderer mysqld-Server läuft. See section 5.1.4 Viele MySQL-Server auf derselben Maschine laufen lassen.

See section 3.4 Einstellungen und Tests nach der Installation.

3.3.2 Wie man Patches anwendet

Manchmal erscheinen Patches auf der Mailing-Liste oder werden auf Patches-Bereich auf der MySQL-Website eingestellt.

Um einen Patch aus der Mailing-Liste anzuwenden, speichern Sie die Nachricht, in der der Patch enthalten ist, in eine Datei. Wechseln Sie dann ins oberste Verzeichnis Ihres MySQL-Source-Trees und geben Sie folgende Befehle ein:

Patches von der FTP-Site werden als Klartextdateien (Plain Text) oder als mit gzip komprimierte Dateien distribuiert. Ein Klartext-Patch wenden Sie genau so an, wie oben für die Patches von der Mailing-Liste beschrieben. Um ein komprimiertes Patch anzuwenden, wechseln Sie ins oberste Verzeichnis Ihres MySQL-Source-Trees und geben Sie folgende Befehle ein:

Nachdem Sie einen Patch angewendet haben, folgen Sie den Anweisungen für eine normale Installation vom Quellcode, indem Sie mit dem Schritt ./configure anfangen. Nach dem Schritt make install, starten Sie den MySQL-Server neu.

Es kann sein, dass Sie jeden laufenden Server anhalten müssen, bevor Sie make install laufen lassen können. (Das machen Sie mit mysqladmin shutdown.) Einige Systeme lassen es nicht zu, dass eine neue Programmversion installiert wird, wenn diese eine Version ersetzt, die momentan ausgeführt wird.

3.3.3 Typische configure-Optionen

Das configure-Skript gibt Ihnen in großem Umfang Kontrolle über die Konfigurationsmöglichkeiten Ihrer MySQL-Distribution. Typischerweise machen Sie das unter Verwendung der Optionen auf der configure-Kommandozeile. Sie können ausserdem configure beeinflussen, indem Sie bestimmte Umgebungsvariablen benutzen. See section F Umgebungsvariablen. Um eine Liste der Optionen zu erhalten, die configure unterstützt, geben Sie folgendes ein:

Einige der gebräuchlicheren configure-Optionen sind im Folgenden beschrieben:

• Um nur die MySQL-Client Bibliotheken und Client-Programme und nicht den Server zu kompilieren, benutzen Sie die --ohne-server-Option: shell> ./configure --without-server Wenn Sie keinen C++-Kompiler haben, können Sie mysql nicht kompilieren (MySQL ist das einzige Client-Programm, das C++ erfordert). In diesem Fall können Sie den Code in configure entfernen, der auf den C++-Kompiler testet, und dann ./configure mit der --without-server-Option eingeben. Dieser Kompilierschritt wird nach wie vor versuchen, mysql zu bauen, aber Sie können alle Warnungen zu `mysql.cc' ignorieren. (Wenn make anhält, versuchen Sie make -k, um ihm mitzuteilen, dass es mit dem Rest des Builds fortfahren soll, auch wenn Fehler auftreten.)
• Wenn Sie nicht wollen, dass Ihre Log-Dateien und Datenbankverzeichnisse unter `/usr/local/var' liegen, benutzen Sie ein configure-Kommando wie folgendes: shell> ./configure --prefix=/usr/local/mysql shell> ./configure --prefix=/usr/local \ --localstatedir=/usr/local/mysql/data Der erste Befehl ändert das Installationspräfix, so dass alles unter `/usr/local/mysql' statt unter `/usr/local' installiert wird. Der zweite Befehl bewahrt das vorgabemäßige Installationspräfix, aber überschreibt die vorgabemäßige Stelle für Datenbankverzeichnisse (normalerweise `/usr/local/var') und ändert sie zu /usr/local/mysql/data.
• Wenn Sie Unix benutzen und wollen, dass der MySQL-Socket an anderer Stelle liegt als vorgabemäßig (normalerweise im Verzeichnis `/tmp' oder `/var/run'), benutzen Sie ein configure-Kommando wie folgendes: shell> ./configure --with-unix-socket-path=/usr/local/mysql/tmp/mysql.sock Beachten Sie, dass die angegebene Datei mit einem absoluten Pfadnamen angegeben werden muss! Sie können den Speicherort von `mysql.sock' auch später noch ändern, indem Sie die MySQL Optionsdateien benutzen. See section A.4.5 Wie Sie die MySQL-Socket-Datei `/tmp/mysql.sock' schützen oder ändern.
• Wenn Sie statisch gelinkte Programme kompilieren wollen (um zum Beispiel eine Binärdistribution zu machen, mehr Geschwindigkeit zu erhalten oder Probleme mit RedHat-Linux-Distributionen zu umgehen (Workaround)), geben Sie configure wie folgt ein: shell> ./configure --with-client-ldflags=-all-static \ --with-mysqld-ldflags=-all-static
• Wenn Sie gcc benutzen und libg++ oder libstdc++ nicht installiert haben, können Sie configure mitteilen, gcc als Ihren C++-Kompiler zu benutzen: shell> CC=gcc CXX=gcc ./configure Wenn Sie gcc als C++-Kompiler benutzen, versucht dieser nicht, libg++ oder libstdc++ zu linken. Hier sind einige gebräuchliche Umgebungsvariablen, die man in Abhängigkeit vom verwendeten Kompiler setzen kann:

  gcc 2.7.2.1	CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors"
  egcs 1.0.3a	CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti"
  gcc 2.95.2	CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro -felide-constructors -fno-exceptions -fno-rtti"
  pgcc 2.90.29 oder newer	CFLAGS="-O3 -mpentiumpro -mstack-align-double" CXX=gcc CXXFLAGS="-O3 -mpentiumpro -mstack-align-double -felide-constructors -fno-exceptions -fno-rtti"

  In den meisten Fällen erhalten Sie eine ziemlich optimale MySQL-Binärdatei, indem Sie die Optionen von weiter oben nutzen und die folgenden Optionen zur Konfigurationszeile hinzufügen: --prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static Die komplette Konfigurationszeile würde also etwa wie folgt aussehen (für alle aktuellen gcc-Versionen): CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static Die Binärdistributionen, die wir auf der MySQL-Website unter http://www.mysql.com zur Verfügung stellen, sind allesamt mit voller Optimierung kompiliert und sollten daher für die meisten Benutzer perfekt sein. See section 3.2.6 MySQL-Binärdistributionen, die von MySQL AB kompiliert wurden. Einiges können Sie noch fein justieren, um noch schnellere Binärdistributionen zu erhalten, aber das ist nur etwas für fortgeschrittene Benutzer. See section 6.5.3 Wie Kompilieren und Linken die Geschwindigkeit von MySQL beeinflusst. Wenn der Build fehlschlägt und Fehler produziert, die aussagen, dass Ihr Kompiler oder Linker nicht in der Lage ist, die gemeinsam benutzte (shared) Bibliothek `libmysqlclient.so.#' (`#' ist eine Versionsnummer) zu erzeugen, können Sie dieses Problem umgehen, indem Sie die --disable-shared-Option von configure benutzen. In diesem Fall baut configure keine gemeinsam benutzte libmysqlclient.so.#-Bibliothek.
• Sie können MySQL so konfigurieren, dass keine DEFAULT-Spaltenwerte für Nicht-NULL-Spalten benutzt werden (also Spalten, bei denen nicht zulässig ist, dass sie NULL sind). Das führt dazu, dass INSERT-Statements einen Fehler erzeugen, ausser wenn ausdrücklich Werte für Spalten angegeben werden, die einen Nicht-NULL-Werte verlangen. Um die Benutzung von Vorgabewerten zu unterdrücken, geben Sie configure wie folgt ein: shell> CXXFLAGS=-DDONT_USE_DEFAULT_FIELDS ./configure
• Als Vorgabe benutzt MySQL den Zeichensatz ISO-8859-1 (Latin1). Um diesen Vorgabesatz zu ändern, benutzen Sie die --with-charset-Option: shell> ./configure --with-charset=CHARSET CHARSET kann einer der folgenden sein: big5, cp1251, cp1257, czech, danish, dec8, dos, euc_kr, gb2312, gbk, german1, hebrew, hp8, hungarian, koi8_ru, koi8_ukr, latin1, latin2, sjis, swe7, tis620, ujis, usa7 oder win1251ukr. See section 5.6.1 Der für Daten und Sortieren benutzte Zeichensatz. Wenn Sie Zeichen zwischen Server und Client konvertieren wollen, sollten Sie sich den SET OPTION CHARACTER SET-Befehl ansehen. See section 6.5.6 SET-Syntax. Achtung: Wenn Sie Zeichensätze ändern, nachdem Sie irgend welche Tabellen angelegt haben, müssen Sie myisamchk -r -q über jede Tabelle laufen lassen, denn ansonsten könnten Ihre Indexe falsch sortiert werden. (Das kann passieren, wenn Sie MySQL installieren, ein paar Tabellen erzeugen und danach MySQL rekonfigurieren, so dass es einen anderen Zeichensatz benutzt, und dann neu installieren.) Mit der Option --with-extra-charset=LIST können Sie zusätzliche Zeichensätze definieren, die in den Server einkompiliert werden sollen. Hierbei ist LIST entweder eine Liste eines Zeichensatzes, die durch Leerzeichen getrennt ist, oder complex, um alle Zeichen einzuschließen, die nicht dynamisch geladen werden können, oder all, um alle Zeichensätze in die Binärdateien einzuschließen.
• Um MySQL mit Debug-Code zu konfigurieren, benutzen Sie die --with-debug-Option: shell> ./configure --with-debug Das bewirkt, dass eine sichere Speicherzuweisung (Memory Allocator) eingeschlossen wird, die einige Fehler finden kann und die Ausgaben liefert, was passiert ist. See section E.1 Einen MySQL-Server debuggen.
• Wenn Ihre Client-Programme Threads benutzen, müssen Sie zusätzlich eine Thread-sichere Version der MySQL-Client-Bibliothek mit der --enable-Thread-safe-client-configure-Option kompilieren. Hierdurch wird eine libmysqlclient_r-Bibliothek angelegt, mit der Sie Ihre threaded Applikationen linken können. See section 9.4.8 Wie man einen threaded Client herstellt.
• Optionen, die zu bestimmten Systemen gehören, finden sich im systemspezifischen Abschnitt dieses Handbuchs. See section 3.2.2 Betriebssysteme, die von MySQL unterstützt werden.

3.3.4 Installation vom Entwicklungs-Source-Tree

VORSICHT: Sie sollten diesen Abschnitt nur lesen, wenn Sie daran interessiert sind, uns beim Testen von neuem Code zu helfen. Wenn Sie nur wollen, dass MySQL auf Ihrem System läuft, sollten Sie eine Standard-Distribution wählen (entweder eine Quell- oder eine Binärdistribution).

Um unseren aktuellsten Entwicklungs-Source-Tree zu bekommen, folgen Sie diesen Anweisungen:

1. Laden Sie BitKeeper von http://www.bitmover.com/cgi-bin/download.cgi herunter. Sie benötigen Bitkeeper 2.0 oder neuer, um auf unser Repository zuzugreifen.
2. Folgen Sie den Anweisungen, um BitKeeper zu installieren.
3. Nachdem BitKeeper installiert ist, benutzen Sie diesen Befehl, um den MySQL-3.23-Branch zu klonen: shell> bk clone bk://mysql.bkbits.net/mysql-3.23 mysql-3.23 Um den 4.0-Branch zu klonen, benutzen Sie statt dessen diesen Befehl: shell> bk clone bk://mysql.bkbits.net/mysql-4.0 mysql-4.0 Um den 4.1-Branch zu klonen, benutzen Sie statt dessen diesen Befehl: shell> bk clone bk://mysql.bkbits.net/mysql-4.1 mysql-4.1 Um den 5.0-Branch zu klonen, benutzen Sie statt dessen diesen Befehl: shell> bk clone bk://mysql.bkbits.net/mysql-5.0 mysql-5.0 Das erstmalige Herunterladen des Source-Trees kann eine Weile dauern, abhängig von Ihrer Verbindungsgeschwindigkeit. Bitte Geduld.
4. Sie brauchen GNU autoconf, automake, libtool und m4, um die nächsten Befehle auszuführen. Wenn Sie in diesem Stadium seltsame Fehler erhalten, überprüfen Sie bitte, ob Sie wirklich libtool installiert haben! shell> cd mysql shell> bk -r edit shell> aclocal; autoheader; autoconf; automake; shell> ./configure # Geben Sie hier Ihre Lieblingsoptionen an shell> make Eine Sammlung unserer Standard-configure-Skripts befindet sich im `BUILD/' Unterverzeichnis. Wenn Sie faul sind, können Sie `BUILD/compile-pentium-debug' benutzen. Um für unterschiedliche Architekturen zu kompilieren, ändern Sie das Skript ab und entfernen die Flags, die Pentium-spezifisch sind.
5. Wenn der Build fertig ist, lassen Sie make install laufen. Seien Sie damit vorsichtig auf Produktionsmaschinen, denn dieser Befehl kann Ihre Live-Release-Installation überschreiben! Wenn Sie eine weitere Installation von MySQL haben, empfehlen wir, dass Sie ./configure mit anderen Werten für die prefix-, tcp-port- und unix-socket-path-Optionen ausführen als die, die für Ihren Produktionsserver benutzt werden.
6. Spielen Sie reichlich mit Ihrer neuen Installation herum und versuchen Sie, die neuen Features zum Absturz zu bringen. Fangen Sie an, indem Sie make test laufen lassen. See section 10.3.2 MySQL-Test-Suite.
7. Wenn Sie bis zum make-Stadium gekommen sind und die Distribution sich nicht kompilieren läßt, berichten Sie das bitte an bugs@lists.mysql.com. Wenn Sie die letzten Versionen der erforderlichen GNU-Werkzeuge installiert haben und sie abstürzen, wenn Sie versuchen, Ihre Konfigurationsdateien zu verarbeiten, berichten Sie das bitte ebenfalls. Wenn Sie jedoch aclocal und einen Befehl nicht gefunden-Fehler erhalten, berichten Sie diesen nicht. Stellen Sie statt dessen sicher, dass alle notwendigen Werkzeuge installiert sind und dass Ihre PATH-Variable korrekt gesetzt ist, damit Ihre Shell diese finden kann.
8. Nach der erstmaligen bk clone-Operation, um den Source-Tree zu erhalten, sollten Sie in regelmäßigen Abständen bk pull laufen lassen, um Aktualisierungen zu erhalten.
9. Sie erhalten die Änderungen-Geschichte (Change History) des Trees mit allen Diffs, indem Sie bk sccstool benutzen. Wenn Sie seltsame Diffs sehen oder Code, zu dem Sie Fragen haben, zögern Sie nicht, uns eine E-Mail an internals@lists.mysql.com zu schicken. Auch wenn Sie meinen, eine bessere Idee zu haben, wie etwas gemacht werden sollte, schicken Sie uns eine E-Mail an dieselbe Adresse, mit einem Patch. bk diffs erzeugt ein Patch für Sie, nachdem Sie Änderungen am Quellcode durchgeführt haben. Wenn Sie keine Zeit haben, Ihre Idee zu kodieren, schicken Sie einfach eine Beschreibung.
10. BitKeeper hat ein nettes Hilfe-Dienstprogramm, auf das Sie über bk helptool zugreifen können.

3.3.5 Probleme beim Kompilieren?

Alle MySQL-Programme lassen sich sauber ohne Warnungen auf Solaris mit gcc kompilieren. Auf anderen Systemen können Warnungen wegen Unterschieden in System-Include-Dateien auftreten. Siehe section 3.3.6 Anmerkungen zu MIT-pThreads wegen Warnungen, die auftreten können, wenn Sie MIT-pThreads verwenden. Wegen anderer Probleme sehen Sie bitte in der unten stehenden Liste nach.

Die Lösung für viele Probleme beinhaltet Rekonfigurieren. Wenn Sie rekonfigurieren müssen, beachten Sie Folgendes:

• Wenn configure laufen gelassen wird, nachdem es schon einmal lief, benutzt es möglicherweise Informationen, die bei vorherigen Aufrufen gesammelt wurden. Diese Information wird in der Datei `config.cache' gespeichert. Wenn configure startet, sucht es diese Datei und liest ihren Inhalt, wenn sie existiert, unter der Annahme, dass diese Information immer noch stimmt. Diese Annahme ist falsch, wenn Sie rekonfigurieren.
• Immer, wenn Sie configure laufen lassen, müssen Sie auch make laufen lassen, um erneut zu kompilieren. Sie werden jedoch einige alte Objektdateien vorheriger Builds entfernen wollen, denn diese wurden mit anderen Konfigurationsoptionen kompiliert.

Um zu verhindern, dass alte Konfigurationsinformationen oder Objektdateien benutzt werden, geben Sie vor dem erneuten Aufruf von configure folgende Befehle ein:

Alternativ können Sie auch make distclean laufen lassen.

Die unten stehende Liste beschreibt einige der Probleme, die beim Kompilieren von MySQL am häufigsten auftreten:

• Wenn Sie Probleme beim Kompilieren von `sql_yacc.cc' erhalten, die den unten gezeigten ähneln, haben Sie wahrscheinlich keinen Arbeitsspeicher oder Swap-Platz (Auslagerungsdatei) mehr. Internal compiler error: Programm cc1plus got fatal signal 11 oder Out of virtual memory oder Virtual memory exhausted Das Problem liegt darin, dass gcc riesige Mengen von Arbeitsspeicher benötigt, um `sql_yacc.cc' mit Inline-Funktionen zu kompilieren. Versuchen Sie, configure mit der --with-low-memory-Option auszuführen: shell> ./configure --with-low-memory Diese Option veranlasst, dass -fno-inline zur Kompilierzeile hinzugefügt wird, wenn Sie gcc benutzen, bzw. -O0, wenn Sie etwas anderes benutzen. Sie sollten die --with-low-memory-Option selbst dann benutzen, wenn Sie glauben, so viel Arbeitsspeicher und Swap-Platz zu haben, dass Ihnen diese unmöglich ausgehen können. Das Problem wurde selbst auf Systemen mit großzügiger Hardware-Ausstattung beobachtet, und die --with-low-memory-Option behebt es üblicherweise.
• Vorgabemäßig sucht configure c++ als Kompiler-Namen aus und GNU c++ linkt mit -lg++. Wenn Sie gcc benutzen, kann dieses Verhalten Probleme bei Konfigurationen wie dieser verursachen: configure: error: installation oder configuration problem: c++ compiler cannot create executables. Eventuell stoßen Sie beim Kompilieren auch auf Probleme, die mit g++, libg++ oder libstdc++ zu tun haben. Eine Ursache dieser Probleme liegt darin, dass Sie kein g++ haben dürfen, oder Sie dürfen g++ haben, aber nicht libg++ oder libstdc++. Schauen Sie in die `config.log'-Datei! Sie sollten die genaue Ursache enthalten, warum Ihr C++-Kompiler nicht funktioniert! Um dieses Problem zu umgehen, können Sie gcc als Ihren C++-Kompiler benutzen. Versuchen Sie, die Umgebungsvariable CXX auf "gcc -O3" zu setzen. Beispiel: shell> CXX="gcc -O3" ./configure Das funktioniert, weil gcc C++-Quellen genau so gut wie g++ kompiliert, aber vorgabemäßig weder libg++ noch libstdc++ linkt. Eine andere Möglichkeit, das Problem zu beheben, besteht natürlich darin, g++, libg++ und libstdc++ zu installieren.
• Wenn Ihr Kompilieren mit Fehlern wie dem folgenden fehlschlägt, müssen Sie Ihre Version von make auf GNU make aktualisieren: making all in mit-pThreads make: Fatal error in reader: Makefile, line 18: Badly formed macro assignment oder make:Datei `Makefile' line 18: Must be a separator (: oder pThread.h: No such file or directory Von Solaris und FreeBSD ist bekannt, dass sie problembehaftete make-Programme haben. GNU make Version 3.75 funktioniert bekanntermaßen.
• Wenn Sie Flags definieren wollen, die von Ihrem C- oder C++-Kompiler benutzt werden, fügen Sie die Flags den CFLAGS- und CXXFLAGS-Umgebungsvariablen hinzu. Sie können auf diese Weise auch die Kompilernamen festlegen, indem Sie CC und CXX benutzen. Beispiel: shell> CC=gcc shell> CFLAGS=-O3 shell> CXX=gcc shell> CXXFLAGS=-O3 shell> export CC CFLAGS CXX CXXFLAGS Siehe section 3.2.6 MySQL-Binärdistributionen, die von MySQL AB kompiliert wurden: Eine Liste von Flag-Definitionen, die sich auf verschiedenen Systemen als nützlich erwiesen haben.
• Wenn Sie einen Fehler wie den folgenden erhalten, müssen Sie Ihren gcc-Kompiler aktualisieren: client/libmysql.c:273: parse error before `__attribute__' gcc 2.8.1 funktioniert bekanntermaßen, aber wir empfehlen statt dessen gcc 2.95.2 oder egcs 1.0.3a.
• Wenn Sie Fehler wie die unten stehenden erhalten, wenn Sie mysqld kompilieren, hat configure den Typ des letzten Arguments für accept(), getsockname() oder getpeername() nicht korrekt erkannt: cxx: Error: mysqld.cc, line 645: In this statement, the referenced type of the pointer value "&length" is "unsigned long", which is not compatible with "int". new_sock = accept(sock, (struct sockaddr *)&cAddr, &length); Um das zu beheben, editieren Sie die `config.h'-Datei (die von configure angelegt wird). Suchen Sie nach folgenden Zeilen: /* Define as the base type of the last arg to accept */ #define SOCKET_SIZE_TYPE XXX Ändern Sie XXX zu size_t oder int, abhängig von Ihrem Betriebssystem. (Beachten Sie, dass Sie das jedes Mal tun müssen, wenn Sie configure laufen lassen, weil configure die Datei `config.h' neu erzeugt.)
• Die `sql_yacc.cc'-Datei wird von `sql_yacc.yy' erzeugt. Normalerweise muss der Build-Prozess keine `sql_yacc.cc' erzeugen, weil MySQL schon mit einer fertig erzeugten Kopie daher kommt. Wenn Sie sie jedoch neu erzeugen müssen, könnten Sie folgenden Fehler erhalten: "sql_yacc.yy", line xxx fatal: default action causes potential... Das ist ein Indiz dafür, dass Ihre Version von yacc fehlerhaft ist. Sie müssen statt dessen wahrscheinlich bison (die GNU-Version von yacc) installieren und benutzen.
• Wenn Sie mysqld oder einen MySQL-Client debuggen wollen, lassen Sie configure mit der --with-debug-Option laufen. Kompilieren Sie danach neu und linken Sie Ihre Clients mit der neuen Client-Bibliothek. See section E.2 Einen MySQL-Client debuggen.

3.3.6 Anmerkungen zu MIT-pThreads

Dieser Abschnitt beschreibt einige der Themen im Zusammenhang mit MIT-pThreads.

Beachten Sie, dass Sie auf Linux KEINE MIT-pThreads benutzen, sondern statt dessen LinuxThreads installieren sollten! See section 3.6.1 Linux (alle Linux-Versionen).

Wenn Ihr System keine native Thread-Unterstützung bietet, müssen Sie MySQL unter Verwendung des MIT-pThread-Pakets bauen. Das betrifft ältere FreeBSD-Systeme, SunOS 4.x, Solaris 2.4 und früher und einige andere. See section 3.2.2 Betriebssysteme, die von MySQL unterstützt werden.

• Auf den meisten Systemen können Sie die Benutzung von erzwingen, indem Sie configure mit der --with-mit-Threads-Option laufen lassen: shell> ./configure --with-mit-threads Wenn Sie MIT-pThreads benutzen, wird das Bauen (Building) in ein Nicht-Quellcode-Verzeichnis nicht unterstützt, weil wir die Änderungen an diesem Code minimal halten wollen.
• Die Überprüfungen, die festlegen, ob MIT-pThreads benutzt werden sollten oder nicht, finden nur in dem Teil des Konfigurationsprozesses statt, der mit dem Server-Code zu tun hat. Wenn Sie die Distribution mit --without-server konfigurieren, um nicht den Client-Code zu bauen, wissen die Clients nicht, ob sie MIT-pThreads benutzen sollen oder nicht und werden vorgabemäßig Unix-Socket-Verbindungen benutzen. Weil Unix-Sockets unter MIT-pThreads nicht laufen, heißt das, dass Sie -h oder --host benutzen müssen, wenn Sie Client-Programme laufen lassen.
• Wenn MySQL so kompiliert wird, dass es MIT-pThreads benutzt, wird System-Sperren (System Locking) vorgabemäßig aus Performance-Gründen ausgeschaltet. Mit der --use-locking-Option können Sie dem Server mitteilen, System-Sperren zu benutzen.
• Manchmal schlägt der pThread-bind()-Befehl fehl und bindet nicht an ein Socket, ohne jede Fehlermeldung (zumindest auf Solaris). Als Ergebnis schlagen alle Verbindungen zum Server fehl. Beispiel: shell> mysqladmin version mysqladmin: connect to server at '' failed; error: 'Can't connect to mysql server on localhost (146)' Die Lösung besteht darin, den mysqld-Server zu killen und neu zu starten. Uns ist das nur dann passiert, wenn wir den Server gezwungen haben, herunter zu fahren und sofort danach einen Neustart durchgeführt haben.
• Bei MIT-pThreads läßt sich der sleep()-Systemaufruf nicht mit SIGINT (break) unterbrechen. Das merken Sie nur, wenn Sie mysqladmin --sleep ausführen. Sie müssen dann warten, bis der sleep()-Aufruf beendet wurde, bevor die Unterbrechungsanforderung (Interrupt) bedient wird und der Prozess anhält.
• Wenn Sie linken, erhalten Sie möglicherweise Warnmeldungen wie diese (zumindest auf Solaris). Sie können sie ignorieren: ld: warning: symbol `_iob' hat differing sizes: (file /my/local/pThreads/lib/libpThread.a(findfp.o) value=0x4; file /usr/lib/libc.so value=0x140); /my/local/pThreads/lib/libpThread.a(findfp.o) definition taken ld: warning: symbol `__iob' hat differing sizes: (file /my/local/pThreads/lib/libpThread.a(findfp.o) value=0x4; file /usr/lib/libc.so value=0x140); /my/local/pThreads/lib/libpThread.a(findfp.o) definition taken
• Einige weitere Warnungen können ebenfalls ignoriert werden: implicit declaration of function `int strtoll(...)' implicit declaration of function `int strtoul(...)'
• Wir haben es bislang nicht geschafft, readline mit MIT-pThreads zum Laufen zu bringen. (Das wird zwar nicht benötigt, mag aber für einige interessant sein.)

3.3.6.1 Vorbereitung der Windows-Umgebung

3.3.7 Windows-Quelldistribution

Sie benötigen folgendes:

• VC++-6.0-Kompiler (aktualisiert mit Service-Pack 4 oder 5 und dem Präprozessor-Paket). Das Präprozessor-Paket wird für den Makro-Assembler benötigt. Weitere Details finden Sie unter: http://msdn.microsoft.com/vstudio/sp/vs6sp5/faq.asp.
• Die MySQL-Quelldistribution für Windows, die von http://www.mysql.com/downloads/ herunter geladen werden kann.

MySQL bauen

1. Erzeugen Sie ein Arbeitsverzeichnis (z. B. workdir).
2. Entpacken Sie die Quelldistribution in dieses Verzeichnis.
3. Starten Sie den VC++-6.0-Kompiler.
4. Wählen Sie im File-Menü Open Workspace.
5. Öffnen Sie den `mysql.dsw'-Workspace, den Sie im Arbeitsverzeichnis finden.
6. Wählen Sie im Build-Menü das Set Active Configuration- Menü.
7. Wählen Sie mysqld - Win32 Debug und klicken Sie auf OK.
8. Drücken Sie F7, um mit dem Bauen des Debug-Servers, der Bibliotheken und einiger Client-Applikationen zu beginnen.
9. Wenn das Kompilieren beendet ist, kopieren Sie die Bibliotheken und die ausführbaren Dateien in ein separates Verzeichnis.
10. Kompilieren Sie die Release-Versionen, die Sie haben wollen, auf dieselbe Art.
11. Erzeugen Sie das Verzeichnis für die MySQL-Dateien, z. B. `c:\mysql'.
12. Kopieren Sie aus dem Arbeitsverzeichnis folgende Verzeichnisse in das c:\mysql-Verzeichnis:
    • Data
    • Docs
    • Share
13. Erzeugen Sie das Verzeichnis `c:\mysql\bin' und kopieren Sie alle Server und Clients, die Sie vorher kompiliert haben, hinein.
14. Wenn Sie wollen, können Sie auch das `lib'-Verzeichnis erzeugen und die vorher kompilierten Bibliotheken hinein kopieren.
15. Führen Sie mit Visual Studio ein Clean durch.

Konfigurieren und starten Sie den Server auf dieselbe Weise wie bei der Windows-Binärdistribution. See section 3.3.6.1 Vorbereitung der Windows-Umgebung.

3.4 Einstellungen und Tests nach der Installation

Wenn Sie MySQL erst einmal installiert haben (aus einer Binär- oder einer Quelldistribution), müssen Sie die Berechtigungstabellen (Grant Tables) initialisieren, den Server starten und sicherstellen, dass der Server korrekt funktioniert. Eventuell wollen Sie auch einrichten, dass der Server automatisch gestartet und angehalten wird, wenn Ihr System startet oder herunter gefahren wird.

Normalerweise installieren Sie die Berechtigungstabellen und starten den Server wie folgt: Bei der Installation einer Quelldistribution:

Bei einer Binärdistribution (nicht RPM- oder pkg-Pakete) tun Sie folgendes:

Das legt die mysql-Datenbank an, die alle Zugriffsrechte auf Datenbanken enthält, die test-Datenbank, die Sie benutzen können, um MySQL zu testen und zusätzlich Berechtigungseinträge für den Benutzer, der mysql_install_db ausführt sowie einen root-Benutzer (ohne Passworte!). Durch den letzten Befehl wird der mysqld-Server gestartet.

mysql_install_db überschreibt keine alten Berechtigungstabellen, deshalb sollte es unter allen Umständen sicher sein. Wenn Sie die test-Datenbank nicht haben wollen, können Sie sie mit mysqladmin -u root drop test entfernen.

Am einfachsten läßt sich das Durchtesten vom obersten Verzeichnis der MySQL-Distribution durchführen. Bei einer Binärdistribution ist das Ihr Installationsverzeichnis (üblicherweise etwas wie `/usr/local/mysql'). Bei einer Quelldistribution ist es das Hauptverzeichnis Ihres MySQL-Source-Trees.

In den unten dargestellten Befehlen dieses Abschnitts und der folgenden Unterabschnitte ist BINDIR der Pfad zu dem Speicherort, wo Programme wie mysqladmin und safe_mysqld installiert sind. Bei einer Binärdistribution ist das `bin'-Verzeichnis innerhalb der Distribution. Bei einer Quelldistribution ist BINDIR wahrscheinlich `/usr/local/bin', es sei denn, Sie haben ein anderes Installationsverzeichnis als `/usr/local' angegeben, als Sie configure laufen ließen. EXECDIR ist der Speicherort, in dem der mysqld-Server installiert ist. Bei einer Binärdistribution ist das derselbe wie BINDIR. Bei einer Quelldistribution ist EXECDIR wahrscheinlich `/usr/local/libexec'.

Das Durchtesten wird im Folgenden detailliert beschrieben.

1. Falls notwendig, starten Sie den mysqld-Server und richten die anfänglichen MySQL-Berechtigungstabellen ein, die alle Zugriffsrechte enthalten, die festlegen, wie sich Benutzer mit dem Server verbinden dürfen. Das wird normalerweise mit dem mysql_install_db-Skript gemacht: shell> scripts/mysql_install_db Typischerweise müssen Sie mysql_install_db nur laufen lassen, wenn Sie MySQL zum ersten Mal installieren. Wenn Sie eine existierende Installation aktualisieren (Update), können Sie deshalb diesen Schritt überspringen. (mysql_install_db ist jedoch ziemlich sicher und aktualisiert keine bereits existierenden Tabellen, daher können Sie im Zweifel immer mysql_install_db laufen lassen.) mysql_install_db erzeugt sechs Tabellen (user, db, host, tables_priv, columns_priv und func) in der mysql-Datenbank. Eine Beschreibung der anfänglichen Zugriffsrechte wird in section 5.2.5 Wie das Berechtigungssystem funktioniert festgelegt. Kurz gesagt erlauben diese Zugriffsrechte dem MySQL-Benutzer root, alles zu tun, und jedem, Datenbanken anzulegen oder zu benutzen, deren Name 'test' ist oder mit 'test_' beginnt. Wenn Sie die Zugriffsberechtigungstabellen (Grant Tables) nicht einrichten, wird folgender Fehler in der Logdatei erscheinen, wenn Sie den Server starten: mysqld: Can't find file: 'host.frm' Dasselbe kann auch bei einer MySQL-Binärdistribution passieren, wenn Sie MySQL nicht mit exakt ./bin/safe_mysqld starten! See section 5.7.2 safe_mysqld, der Wrapper um mysqld. Eventuell müssen Sie mysql_install_db als root laufen lassen. Wenn Sie wollen, können Sie jedoch den MySQL-Server als unprivilegierter (non-root)-Benutzer laufen lassen, vorausgesetzt, dieser Benutzer darf Dateien im Datenbank-Verzeichnis lesen und schreiben. Anweisungen, wie Sie MySQL als unprivilegierter Benutzer laufen lassen können, finden Sie in section 5.3.3 Wann Berechtigungsänderungen wirksam werden. Wenn Sie Probleme mit mysql_install_db bekommen, sehen Sie bitte unter section 3.4.1 Probleme mit mysql_install_db nach. Es gibt eine Reihe von Alternativen zum Laufenlassen des mysql_install_db-Skripts, was mit der MySQL-Distribution mitgeliefert wird:
   • Sie können mysql_install_db editieren, bevor Sie es laufen lassen, um die anfänglichen Zugriffsrechte zu ändern, die in die Rechtetabellen installiert werden. Das ist nützlich, wenn Sie MySQL auf einer großen Zahl von Maschinen mit denselben Zugriffsrechten installieren wollen. In diesem Fall müssen Sie wahrscheinlich nur ein paar zusätzliche INSERT-Statements für die mysql.user- und mysql.db-Tabellen hinzufügen!
   • Wenn Sie Dinge in den Berechtigungstabellen ändern wollen, nachdem diese installiert wurden, lassen Sie mysql_install_db laufen und geben dann den Befehl mysql -u root mysql ein, um sich als MySQL-root-Benutzer mit den Berechtigungstabellen zu verbinden. Danach können Sie SQL-Statements eingeben, um die Tabellen direkt zu verändern.
   • Es ist möglich, die Berechtigungstabellen komplett neu zu erzeugen, nachdem Sie angelegt wurden. Das werden Sie zum Beispiel tun wollen, wenn Sie die Tabellen bereits angelegt haben, Sie nun aber neu anlegen wollen, weil Sie mysql_install_db editiert haben.
   Zu weiteren Informationen über diese Alternativen siehe section 5.2 Allgemeine Sicherheitsthemen und das MySQL-Zugriffsberechtigungssystem.
2. Starten Sie den MySQL-Server wie folgt: shell> cd mysql_installations_verzeichnis shell> bin/safe_mysqld & Wenn Sie Probleme haben, den Server zu starten, sehen Sie unter section 3.4.2 Probleme mit dem Start des MySQL-Servers nach.
3. Benutzen Sie mysqladmin, um sicherzustellen, dass der Server läuft. Die folgenden Befehle sind ein einfacher Test, um zu überprüfen, ob der Server läuft und auf Verbindungen reagiert: shell> BINDIR/mysqladmin version shell> BINDIR/mysqladmin variables Die Ausgabe von mysqladmin version kann geringfügig variieren, abhängig von Ihrer Plattform und der Version von MySQL, sollte aber etwa wie folgt aussehen: shell> BINDIR/mysqladmin version mysqladmin Ver 8.14 Distrib 3.23.32, for linux on i586 Copyright (C) 2000 MySQL AB & MySQL Finnland AB & TCX DataKonsult AB This software comes mit ABSOLUTELY NO WARRANTY. This ist free software, und you are welcome to modify und redistribute it under the GPL license Server version 3.23.32-debug Protokoll version 10 Connection Localhost via Unix socket TCP port 3306 UNIX socket /tmp/mysql.sock Uptime: 16 sec Threads: 1 Questions: 9 Slow queries: 0 Opens: 7 Flush tables: 2 Open tables: 0 Queries per second avg: 0.000 Memory in use: 132K Max memory used: 16773K Um ein Gefühl dafür zu bekommen, was Sie sonst noch mit BINDIR/mysqladmin tun können, rufen Sie es mit der --help-Option auf.
4. Stellen Sie sicher, dass Sie den Server herunter fahren können: shell> BINDIR/mysqladmin -u root shutdown
5. Stellen Sie sicher, dass Sie den Server erneut starten können. Tun Sie das unter Benutzung von safe_mysqld oder indem Sie mysqld direkt aufrufen. Beispiel: shell> BINDIR/safe_mysqld --log & Wenn safe_mysqld fehlschlägt, versuchen Sie, es vom MySQL-Installationsverzeichnis aus zu starten (falls Sie noch nicht dort sind). Wenn das nicht funktioniert, sehen Sie unter see section 3.4.2 Probleme mit dem Start des MySQL-Servers nach.
6. Lassen Sie ein paar einfache Tests ablaufen um sicherzustellen, dass der Server funktioniert. Die Ausgabe sollte ähnlich der folgenden sein: shell> BINDIR/mysqlshow +-----------+ | Databases | +-----------+ | mysql | +-----------+ shell> BINDIR/mysqlshow mysql Datenbank: mysql +--------------+ | Tables | +--------------+ | columns_priv | | db | | func | | host | | tables_priv | | user | +--------------+ shell> BINDIR/mysql -e "select host,db,user from db" mysql +------+--------+------+ | host | db | user | +------+--------+------+ | % | test | | | % | test_% | | +------+--------+------+ Zusätzlich gibt es eine Benchmark-Suite im `sql-bench'-Verzeichnis (unterhalb des MySQL-Installationsverzeichnisses), die Sie benutzen können, um die Leistungsdaten von MySQL auf verschiedenen Plattformen zu vergleichen. Das `sql-bench/Results'-Verzeichnis enthält die Ergebnisse vieler Testläufe mit verschiedenen Datenbanken und Plattformen. Um alle Tests durchzuführen, geben Sie folgende Befehle ein: shell> cd sql-bench shell> run-all-tests Wenn Sie kein `sql-bench'-Verzeichnis haben, benutzen Sie wahrscheinlich ein RPM für eine Binärdistribution. (Quelldistributions-RPMs beinhalten das Benchmark-Verzeichnis.) In diesem Fall müssen Sie die Benchmark-Suite zuerst installieren, bevor Sie sie benutzen können. Ab MySQL Version 3.22 gibt es Benchmark-RPM-Dateien, die `mysql-bench-VERSION-i386.rpm' benannt sind, die Benchmark-Code und Daten enthalten. Wenn Sie eine Quelldistribution haben, können Sie auch die Tests im `tests'-Unterverzeichnis ausführen. Um beispielsweise `auto_increment.tst' auszuführen, geben Sie folgendes ein: shell> BINDIR/mysql -vvf test < ./tests/auto_increment.tst Die Ergebnisse stehen dann in der `./tests/auto_increment.res'-Datei.

3.4.1 Probleme mit mysql_install_db

Der Zweck des mysql_install_db-Skripts ist, neue MySQL-Berechtigungstabellen zu erzeugen. Es betrifft keine anderen Daten! Es tut nichts, wenn Sie bereits MySQL-Berechtigungstabellen installiert haben!

Wenn Sie Ihre Berechtigungstabellen neu erzeugen wollen, sollten Sie den mysqld-Server herunter fahren, falls er läuft, und dann etwas Ähnliches wie folgendes tun:

Dieser Abschnitt listet Probleme auf, denen Sie vielleicht begegnen, wenn Sie mysql_install_db laufen lassen:

mysql_install_db installiert die Berechtigungstabellen nicht.

Eventuell stellen Sie fest, dass mysql_install_db bei der Installations der Berechtigungstabellen fehlschlägt und mit folgenden Meldungen endet: starting mysqld daemon with databases from XXXXXX mysql daemon ended In diesem Fall sollten Sie einen gründlichen Blick in die Log-Datei werfen! Diese sollte sich im Verzeichnis `XXXXXX' befinden, das in der Fehlermeldung ausgegeben wird, und sollte anzeigen, warum mysqld nicht startete. Wenn Sie nicht verstehen, was passiert ist, schicken Sie einen Bug-Bericht inklusive Log. Benutzen Sie hierfür mysqlbug! See section 2.6.2.3 Wie man Bugs oder Probleme berichtet.

Es läuft bereits ein mysqld-Daemon.

In diesem Fall müssen Sie wahrscheinlich mysql_install_db überhaupt nicht starten. Sie müssen mysql_install_db nur einmal starten, und zwar, wenn Sie MySQL zum ersten Mal installieren.

Die Installation eines zweiten mysqld-Daemons schlägt fehl,

wenn bereits ein Daemon läuft. Das kann vorkommen, wenn Sie bereits eine existierende MySQL-Installation haben, aber eine neue Installation an einem anderen Speicherort unterbringen wollen (zum Beispiel für Testzwecke, oder vielleicht wollen Sie auch einfach zwei Installationen zugleich laufen lassen. Im Allgemeinen ist der Grund für das Problem, wenn Sie versuchen, den zweiten Server laufen zu lassen, dass der zweite Server versucht, denselben Socket und Port wie der alte zu benutzen. In diesem Fall erhalten Sie als Fehlermeldung: Can't start server: Bind on TCP/IP port: Address already in use oder Can't start server : Bind on unix socket.... See section 5.1.4 Viele MySQL-Server auf derselben Maschine laufen lassen.

Sie haben keinen Schreibzugriff auf `/tmp'.

Wenn Sie keinen Schreibzugriff haben, um eine Socket-Datei am vorgabemäßigen Ort anzulegen (in `/tmp') oder keine Berechtigung, um temporäre Dateien in `/tmp' anzulegen, erhalten Sie einen Fehler, wenn Sie mysql_install_db laufen lassen oder starten oder wenn Sie mysqld benutzen. So können Sie einen anderen Socket und ein anderes temporäres Verzeichnis festlegen: shell> TMPDIR=/irgendein_temporaeres_verzeichnis/ shell> MYSQL_UNIX_PORT=/irgendein_temporaeres_verzeichnis/mysqld.sock shell> export TMPDIR MYSQL_UNIX_PORT See section A.4.5 Wie Sie die MySQL-Socket-Datei `/tmp/mysql.sock' schützen oder ändern. `irgendein_temporaeres_verzeichnis' sollte der Pfad zu einem Verzeichnis sein, für das Sie Schreibberechtigung haben. See section F Umgebungsvariablen. Danach sollten Sie in der Lage sein, mysql_install_db laufen zu lassen und den Server zu starten, und zwar mit folgenden Befehlen: shell> scripts/mysql_install_db shell> BINDIR/safe_mysqld &

mysqld stürzt sofort ab

Wenn Sie RedHat Version 5.0 mit einer Version von glibc laufen lassen, die älter als 2.0.7-5 ist, sollten Sie sicherstellen, dass Sie alle glibc-Patches installiert haben! Darüber gibt es jede Menge Informationen in den MySQL-Mail-Archiven. Links zu den Mail-Archiven finden Sie online unter http://www.mysql.com/documentation/. Siehe auch section 3.6.1 Linux (alle Linux-Versionen). Sie können mysqld auch manuell starten, dabei die --skip-grant-tables-Option benutzen und dann die Berechtigungsinformationen selbst mit mysql eintragen: shell> BINDIR/safe_mysqld --skip-grant-tables & shell> BINDIR/mysql -u root mysql Von mysql aus geben Sie die SQL-Befehle ein, die in mysql_install_db stehen. Stellen Sie sicher, dass Sie danach mysqladmin flush-privileges oder mysqladmin reload laufen lassen, um dem Server mitzuteilen, die Berechtigungstabellen neu zu laden.

3.4.2 Probleme mit dem Start des MySQL-Servers

Wenn Sie Tabellen einsetzen werden, die Transaktionen unterstützen (InnoDB, BDB), sollten Sie zuerst eine my.cnf-Datei anlegen und die Startoptionen für die Tabellentypen setzen, die Sie einsetzen wollen. See section 8 MySQL-Tabellentypen.

Im allgemeinen starten Sie den mysqld-Server auf eine der drei folgenden Weisen:

• Indem Sie mysql.server aufrufen. Dieses Skript wird hauptsächlich beim Systemstart und -herunterfahren eingesetzt. Es wird ausführlicher in section 3.4.3 MySQL automatisch starten und anhalten beschrieben.
• Indem Sie safe_mysqld aufrufen. Dieses Skript versucht die korrekten Optionen für mysqld festzustellen und läßt den Server dann mit diesen Optionen laufen. See section 5.7.2 safe_mysqld, der Wrapper um mysqld.
• Auf Windows NT sollten Sie mysqld wie folgt als Systemdienst starten: bin\mysqld-nt --install # MySQL als Systemdienst installieren Jetzt können Sie mysqld wie folgt starten / anhalten: NET START mysql NET STOP mysql Beachten Sie, dass Sie in diesem Fall keine weiteren Optionen für mysqld benutzen können! Sie können den Systemdienst wie folgt entfernen: bin\mysqld-nt --remove # MySQL als Systemdienst entfernen
• Indem Sie mysqld direkt aufrufen.

Wenn der mysqld-Daemon hoch fährt, wechselt er in das Daten-Verzeichnis. Dort erwartet er, Log-Dateien und die (process ID)-Datei schreiben zu können. Ebenfalls erwartet er dort, Datenbanken zu finden.

Der Speicherort des Daten-Verzeichnisses wird zum Zeitpunkt des Kompilierens der Distribution fest verdrahtet. Wenn mysqld jedoch erwartet, das Daten-Verzeichnis irgendwo sonst als an der Stelle zu finden, wo es auf Ihrem System tatsächlich ist, funktioniert er nicht richtig. Wenn Sie Probleme mit fehlerhaften Pfaden haben, können Sie durch den Aufruf von mysqld mit der --help-Option herausfinden, welche Optionen mysqld erlaubt und was die vorgabemäßigen Pfad-Einstellung sind. Sie können die Vorgaben überschreiben, indem Sie die korrekten Pfadnamen als Kommandozeilen-Argumente für mysqld festlegen. (Diese Optionen können auch bei safe_mysqld benutzt werden.)

Normalerweise sollte es lediglich nötig sein, mysqld das Basis-Verzeichnis mitzuteilen, wo MySQL installiert ist. Das können Sie mit der Option --basedir machen. Zusätzlich können Sie --help benutzen, um die Auswirkung der Pfadänderungsoptionen zu überprüfen (beachten Sie, dass --help die letzte Option des mysqld-Befehls wein muss. Beispiel:

Wenn Sie die Pfadeinstellungen erst einmal festgelegt haben, die Sie wollen, starten Sie den Server ohne die --help-Option.

Mit welcher Methode auch immer Sie den Server starten: Wenn er nicht korrekt hoch fährt, untersuchen Sie die Log-Datei, um zu sehen, ob Sie den Grund dafür herausfinden können. Log-Dateien liegen im Daten-Verzeichnis (typischerweise `/usr/local/mysql/data' bei einer Binärdistribution, `/usr/local/var' bei einer Quelldistribution und `\mysql\data\mysql.err' unter Windows). Suchen Sie im Daten-Verzeichnis nach Dateien mit Namen der Form `host_name.err' und `host_name.log', wobei host_name der Name Ihres Server-Hosts ist. Sehen Sie in den letzten paar Zeilen dieser Dateien nach:

Wenn Sie etwas wie das Folgende in der Log-Datei finden: 000729 14:50:10 bdb: Recovery function for LSN 1 27595 failed 000729 14:50:10 bdb: warning: ./test/t1.db: No such file or directory 000729 14:50:10 Can't init databases

Das bedeutet, dass Sie mysqld nicht mit --bdb-no-recover gestartet haben und Berkeley DB findet, dass etwas mit seinen Log-Dateien nicht in Ordnung ist, als es versuchte, Ihre Datenbanken wiederherzustellen. Um weitermachen zu können, sollten Sie alle alten Berkeley-DB-Log-Dateien aus dem Datenbankverzeichnis an eine andere Stelle verschieben, wo Sie sie später untersuchen können. Die Log-Dateien sind wie `log.0000000001' benannt, wobei die Nummer im Zeitablauf hochgezählt wird.

Wenn Sie mysqld mit BDB-Tabellenunterstützung laufen lassen und mysqld beim Start einen Speicherauszug (Core Dump) liefert, könnte das an Problemen mit den BDB-Wiederherstellungs-Logs liegen. In diesem Fall können Sie versuchen, mysqld mit --bdb-no-recover zu starten. Wenn das hilft, sollten Sie danach alle `log.*'-Dateien aus dem Daten-Verzeichnis entfernen und versuchen, mysqld erneut zu starten.

Wenn Sie folgenden Fehler bekommen, bedeutet das, dass ein anderes Programm (oder ein anderer mysqld-Server) bereits den TCP/IP-Port oder -Socket benutzt, den mysqld versucht zu benutzen:

Benutzen Sie ps, um sicherzustellen, dass kein weiterer mysqld-Server läuft. Wenn Sie keinen weiteren Server finden, können Sie den Befehl telnet ihr-host-name tcp-ip-port-nummer eingeben und mehrere Male EINGABE drücken. Wenn Sie keine Fehlermeldung wie telnet: Unable to connect to remote host: Connection refused erhalten, benutzt irgend etwas anderes den TCP/IP-Port, den mysqld versucht zu benutzen. Siehe section 3.4.1 Probleme mit mysql_install_db und section 5.1.4 Viele MySQL-Server auf derselben Maschine laufen lassen.

Wenn mysqld gerade läuft, können Sie herausfinden, welche Pfadeinstellungen er benutzt, indem Sie folgenden Befehl ausführen:

oder

Wenn safe_mysqld hoch den Server hoch fährt, Sie sich aber nicht mit ihm verbinden können, stellen Sie sicher, dass Sie einen Eintrag wie den folgenden in `/etc/hosts' haben:

Dieses Problem tritt nur auf Systemen auf, die keine funktionierende Thread-Bibliothek besitzen, und für die MySQL so konfiguriert werden muss, dass es MIT-pThreads benutzt.

Wenn Sie es nicht schaffen, mysqld zu starten, können Sie versuchen, eine Trace-Datei anzulegen, um das Problem zu finden. See section E.1.2 Trace-Dateien erzeugen.

Wenn Sie InnoDB-Tabellen benutzen, sehen Sie bei den InnoDB-spezifischen Startoptionen nach. See section 8.5.2 Mit InnoDB anfangen - Optionen.

Wenn Sie BDB-(Berkeley DB)-Tabellen benutzen, sollten Sie sich mit den verschiedenen Startoptionen von BDB vertraut machen. See section 8.6.3 BDB-Startoptionen.

3.4.3 MySQL automatisch starten und anhalten

Die mysql.server- und safe_mysqld-Skripte können benutzt werden, um den Server automatisch beim Hochfahren des Systems zu starten. mysql.server kann ebenfalls dazu benutzt werden, den Server anzuhalten.

Das mysql.server-Skript kann benutzt werden, um den Server zu starten oder anzuhalten, indem man es mit den start- oder stop-Argumenten aufruft:

mysql.server liegt im `share/mysql'-Verzeichnis unterhalb des MySQL-Installationsverzeichnisses oder im `support-files'-Verzeichnis des MySQL-Source-Trees.

Bevor mysql.server den Server startet, wechselt es in das MySQL-Installationsverzeichnis. Dann ruft es safe_mysqld auf. Eventuell müssen Sie mysql.server editieren, wenn Sie eine Binärdistribution haben, die Sie an eine nicht stardardmäßige Stelle installiert haben. Ändern Sie es so ab, dass es in das richtige Verzeichnis wechselt (cd), bevor es safe_mysqld startet. Wenn Sie wollen, dass der Server unter einem bestimmten Benutzer läuft, fügen Sie eine entsprechende user-Zeile zur `/etc/my.cnf'-Datei hinzu, so wie weiter unten in diesem Abschnitt dargestellt.

mysql.server stop hält den Server an, indem es ihm ein Signal sendet. Sie können den Server auch automatisch herunter fahren, indem Sie mysqladmin shutdown ausführen.

Wenn Sie möchten, können Sie diese Start- und Stop-Befehle an den entsprechenden Stellen Ihrer `/etc/rc*'-Dateien einfügen, wenn Sie MySQL für Produktions-Applikationen benutzen. Beachten Sie, wenn Sie mysql.server editieren und dann gelegentlich MySQL aktualisieren (Update), dass dann Ihre geänderte Version überschrieben wird. Daher sollten Sie eine Kopie Ihrer editierten Version machen, die Sie erneut installieren können.

Wenn Ihr System `/etc/rc.local' benutzt, um externe Skripte zu starten, sollten Sie folgendes anhängen: /bin/sh -c 'cd /usr/local/mysql ; ./bin/safe_mysqld --user=mysql &'

Sie können Optionen für mysql.server in einer globalen `/etc/my.cnf'-Datei hinzufügen. Eine typische `/etc/my.cnf'-Datei sieht wie folgt aus:

Das mysql.server-Skript kennt folgende Optionen: datadir, basedir und pid-file.

Folgende Tabelle zeigt, welche Optionsgruppen jedes der Startskripts aus den Optionsdateien liest:

See section 5.1.2 my.cnf-Optionsdateien.

3.5 MySQL aktualisieren (Upgrade / Downgrade)

Sie können die MySQL-form- und data-Dateien jederzeit für verschiedene Versionen auf derselben Architektur benutzen, solange Sie dieselbe Grundversion von MySQL haben. Die aktuelle Grundversion ist 3. Wenn Sie den Zeichensatz ändern, während MySQL läuft (was auch die Sortierreihenfolge betreffen kann), müssen Sie myisamchk -r -q auf alle Tabellen ausführen. Ansonsten könnte es sein, dass Ihre Indexe nicht korrekt sortiert werden.

Wenn Sie vor neuen Versionen zurück schrecken, können Sie Ihren alten mysqld zu etwas wie mysqld-'alte-versions-nummer' umbenennen. Wenn Ihr neuer mysqld dann etwas Unerwartetes tut, können Sie ihn einfach anhalten und mit Ihrem alten mysqld neu starten!

Wenn Sie ein Upgrade vornehmen, sollte Sie natürlich Ihre alten Datenbanken sichern.

Wenn Sie nach einem Upgrade auf Probleme mit neu kompilierten Client-Programmen stoßen, zum Beispiel Commands out of sync oder unerwartete Speicherauszüge (Core Dumps), haben sie wahrscheinlich einen alten Header oder eine alte Bibliotheksdatei benutzt, als Sie die Programme kompilierten. In diesem Fall sollten Sie das Datum Ihrer `mysql.h'-Datei und `libmysqlclient.a'-Bibliothek überprüfen, um sicherzustellen, dass sie aus der neuen MySQL-Distribution stammten. Wenn nicht, kompilieren sie Ihre Programme bitte neu!

Wenn Sie Probleme der Art erhalten, dass Ihr neuer mysqld-Server nicht startet oder dass Sie sich nicht ohne Passwort verbinden können, überprüfen Sie, ob Sie nicht etwa noch die alte `my.cnf'-Datei Ihrer alten Installation haben! Sie können das mit program-name --print-defaults tun. Wenn es irgend etwas anderes als den Programmnamen ausgibt, haben Sie eine aktive my.cnf-Datei, die sich auf die Dinge auswirkt!

Es ist eine gute Idee, die Msql-Mysql-modules-Distribution neu zu bauen und neu zu installieren, wann immer Sie ein neues Release von MySQL installieren, speziell dann, wenn Sie Symptome wie die bemerken, dass alle Ihre DBI-Skripte mit Core-Dumps abbrechen, nachdem Sie MySQL aktualisiert haben.

3.5.1 Upgrade von 3.23 auf Version 4.0

Sie können Ihre alten data-Dateien ohne jede Änderung mit Version 4.0 benutzen. Wenn Sie Ihre Daten eines MySQL-4.0-Servers für einen älteren Server verwenden wollen, müssen Sie mysqldump benutzen.

Alte Clients sollen mit einem Server Version 4.0 ohne jedes Problem funktionieren.

Die folgende Liste stellt dar, auf was Sie aufpassen müssen, wenn Sie auf Version 4.0 aktualisieren (Upgrade):

• `safe_mysqld' wurde zu `mysqld_safe' umbenannt.
• Die alten C-API-Funktionen mysql_drop_db, mysql_create_db und mysql_connect werden nicht mehr unterstützt, es sei denn, MySQL wird mit USE_OLD_FUNCTIONS kompiliert.
• Sie sollten TRUNCATE TABLE benutzen, wenn Sie alle Zeilen aus einer Tabelle löschen wollen und Ihnen egal ist, wie viele Zeilen gelöscht wurden. (TRUNCATE TABLE ist schneller als DELETE FROM tabelle).
• Sie bekommen einen Fehler, wenn Sie ein aktives LOCK TABLES oder eine aktive Transaktion am Laufen haben, wenn Sie versuchen, TRUNCATE TABLE oder DROP DATABASE auszuführen.
• Sie sollten Ganzzahl-(Integer)-Werte in BIGINT-Spalten benutzen (anstelle von Zeichenketten wie in MySQL 3.23). Man kann immer noch Zeichenketten benutzen, aber die Benutzung von Ganzzahlen ist viel effizienter.
• Das Format von SHOW OPEN TABLE hat sich geändert.
• Multithreaded Clients sollten mysql_thread_init() und mysql_thread_end() benutzen. See section 9.4.8 Wie man einen threaded Client herstellt.

3.5.2 Upgrade von einer Version 3.22 auf 3.23

MySQL-Version 3.23 unterstützt Tabellen des neuen MyISAM-Typs und des alten ISAM-Typs. Sie müssen Ihre alten Tabellen nicht konvertieren, um sie mit Version 3.23 einsetzen zu können. Vorgabemäßig werden alle neuen Tabellen mit dem Typ MyISAM angelegt (es sei denn, Sie starten mysqld mit der --default-table-type=isam-Option). Sie können eine ISAM-Tabelle zu einer MyISAM-Tabelle mit ALTER TABLE tabelle TYPE=MyISAM konvertieren oder mit dem Perl-Skript mysql_convert_table_format.

Clients der Versionen 3.22 und 3.21 funktionieren ohne jedes Problem mit einem Server der Version 3.23.

Die folgende Liste stellt dar, auf was Sie aufpassen müssen, wenn Sie auf Version 3.23 aktualisieren (Upgrade):

• Alle Tabellen, die den tis620-Zeichensatz benutzen, müssen mit myisamchk -r oder REPAIR TABLE in Ordnung gebracht werden.
• Wenn Sie ein DROP DATABASE auf eine mit symbolischem Link verknüpfte Datenbank ausführen, werden sowohl der symbolische Links als auch die Datenbank gelöscht. (Das war in Version 3.22 nicht der Fall, weil configure den readlink-Systemaufruf nicht erkannte).
• OPTIMIZE TABLE funktioniert jetzt nur bei MyISAM-Tabellen. Bei anderen Tabellentypen können Sie ALTER TABLE benutzen, um die Tabelle zu optimieren. Während der Ausführung von OPTIMIZE TABLE wird die Tabelle jetzt vor dem Zugriff anderer Threads gesperrt.
• Der MySQL-Client mysql wir jetzt vorgabemäßig mit der Option --no-named-commands (-g) gestartet. Diese Option kann mit --enable-named-commands (-G) abgeschaltet werden. Dies kann ein paar Inkompatibilitätsprobleme verursachen, zum Beispiel in SQL-Skripten, die benannte (named) Befehle ohne ein Semikolon! Befehle im Langformat dagegen funktionieren noch auf der ersten Zeile. some cases, für Beispiel in SQL Skripts that use named Befehle ohne a semicolon! Long format Befehle still work from the first line.
• If you are using the german character sort order, you must repair all your Tabellen mit isamchk -r, as we have made some changes in the sort order!
• The default return type of IF will now depend on both arguments und not only the first argument.
• AUTO_INCREMENT funktioniert nicht mit negativen Zahlen. Der Grund liegt darin, dass negative Zahlen beim Übergang von -1 auf 0 Probleme verursachen. AUTO_INCREMENT wird jetzt bei MyISAM-Tabellen auf einem niedrigeren Level gehandhabt und ist viel schneller als vorher. Bei MyISAM-Tabellen werden alte Zahlen auch nicht mehr wieder benutzt, selbst wenn Sie einige Zeilen aus der Tabelle löschen.
• CASE, DELAYED, ELSE, END, FULLTEXT, INNER, RIGHT, THEN und WHEN sind jetzt reservierte Wörter.
• FLOAT(X) ist jetzt ein echter Fließkomma-Typ und kein Wert mit einer festen Anzahl von Dezimalstellen.
• Wenn Sie DECIMAL(length,dec) deklarieren, beinhaltet das Längen-Argument nicht mehr den Platz für das Vorzeichen oder den Dezimalpunkt.
• Eine TIME-Zeichenkette muss jetzt von einem der folgenden Formate sein: [[[DAYS] [H]H:]MM:]SS[.bruchteil] oder [[[[[H]H]H]H]MM]SS[.bruchteil]
• LIKE vergleicht jetzt Zeichenketten unter Verwendung derselben Vergleichsregeln wie '='. Wenn Sie das alte Verhalten benötigen, können Sie MySQL mit dem CXXFLAGS=-DLIKE_CMP_TOUPPER-Flag kompilieren.
• REGEXP arbeitet jetzt bei normalen (nicht binären) Zeichenketten unabhängig von der Groß-/Kleinschreibung.
• Wenn Sie Tabellen prüfen / reparieren, sollten Sie CHECK TABLE oder myisamchk für MyISAM-Tabellen (.MYI) benutzen und isamchk für ISAM-Tabellen (.ISM).
• Wenn Sie wollen, dass mysqldump-Dateien zwischen MySQL-Version 3.22 und Version 3.23 kompatibel sind, sollten Sie nicht die --opt- oder --full-Option für mysqldump benutzen.
• Überprüfen Sie Ihre Aufrufe von DATE_FORMAT() und stellen Sie sicher, dass vor jedem Formatierungszeichen ein `%' steht. (Spätere MySQL-Versionen 3.22 ließen diese Syntax zu.)
• mysql_fetch_fields_direct ist jetzt eine Funktion (es war ein Makro) und gibt einen Zeiger auf MYSQL_FIELD anstelle eines MYSQL_FIELD zurück.
• mysql_num_fields() kann nicht mehr für ein MYSQL*-Objekt benutzt werden (es ist jetzt eine Funktion, die MYSQL_RES* als Argument nimmt. Sie sollten jetzt statt dessen mysql_field_count() benutzen.
• In MySQL-Version 3.22 war die Ausgabe von SELECT DISTINCT ... fast immer sortiert. In Version 3.23 müssen Sie GROUP BY oder ORDER BY benutzen, um eine sortierte Ausgabe zu erhalten.
• SUM() gibt jetzt NULL zurück statt 0, wenn es keine überein stimmenden Zeilen gibt. Das ist in Übereinstimmung mit ANSI-SQL.
• Ein AND oder OR mit NULL-Werten gibt jetzt NULL anstelle von 0 zurück. Das betrifft hauptsächlich Anfragen, die NOT bei einem AND/OR-Ausdruck wie NOT NULL = NULL benutzen. LPAD() und RPAD() kürzen die Ergebnis-Zeichenkette, wenn sie länger als das Längen-Argument ist.

3.5.3 Upgrade von Version 3.21 auf Version 3.22

Nichts, was die Kompatibilität betrifft, hat sich zwischen Version 3.21 und 3.22 geändert. Die einzige Falle ist die, dass neue Tabellen, die unter Verwendung des DATE-Typs erzeugt werden, die neue Art der Datenspeicherung benutzen. Diese neuen Felder kann man daher nicht von einer alten Version von mysqld ansprechen.

Nachdem Sie MySQL-Version 3.22 installiert haben, starten Sie den neuen Server und lassen dann das mysql_fix_privilege_tables-Skript laufen. Dieses fügt die neuen Zugriffsberechtigungen ein, die Sie benötigen, um den GRANT-Befehl zu benutzen. Wenn Sie das vergessen, erhalten Sie ein Access denied, wenn Sie versuchen, ALTER TABLE, CREATE INDEX oder DROP INDEX zu benutzen. Wenn Ihr MySQL-Root ein Passwort benötigt, müssen Sie dieses als Argument zu mysql_fix_privilege_tables angeben.

Die C-API-Schnittstelle für mysql_real_connect() hat sich geändert. Wenn Sie ein altes Client-Programm haben, das diese Funktion aufruft, müssen Sie eine 0 als neues db-Argument einfügen (oder den Client neu kodieren, so dass er das db-Element für schnellere Verbindungen benutzt). Zusätzlich müssen Sie mysql_init() aufrufen, bevor Sie mysql_real_connect() aufrufen! Diese Änderung wurde durchgeführt, damit die neue mysql_options()-Funktion in der MYSQL-Handler-Struktur Optionen speichern kann.

The mysqld-Variable key_buffer wurde umbenannt in key_buffer_size, Sie können aber in Ihren Startdateien immer noch den alten Namen verwenden.

3.5.4 Upgrade von Version 3.20 auf Version 3.21

Wenn Sie eine Version benutzen, die älter als Version 3.20.28 ist, und auf Version 3.21 umstellen wollen, müssen Sie folgendes tun:

Sie können den mysqld-Server Version 3.21 mit safe_mysqld --old-protocol starten, um ihn mit Clients aus einer Distribution Version 3.20 zu benutzen. In diesem Fall gibt die neue Client-Funktion mysql_errno() überhaupt keine Server-Fehler zurück, nur CR_UNKNOWN_ERROR (funktioniert aber bei Client-Fehlern), und der Server benutzt die alte password()-Überprüfung statt der neuen.

Wenn Sie die --old-protocol-Option NICHT für mysqld benutzen, müssen Sie folgende Änderungen durchführen:

• Jeder Client-Code muss neu kompiliert werden. Wenn Sie ODBC benutzen, müssen Sie die neuen MyODBC-2.x-Treiber verwenden.
• Sie müssen das Skript Skripts/add_long_password laufen lassen, um das Password-Feld in der mysql.user-Tabelle zu CHAR(16) zu ändern.
• Alle Passwörter müssen in der mysql.user-Tabelle neu zugewiesen werden (um 62-Bit- statt 31-Bit-Passwörter zu erhalten).
• Das Tabellenformat hat sich nicht geändert, daher müssen Sie keinerlei Tabellen konvertieren.

MySQL-Version 3.20.28 und höher kann das neue user-Tabellenformat handhaben, ohne sich auf Clients auszuwirken. Wenn Sie eine MySQL-Version vor Version 3.20.28 haben, funktionieren Passwörter damit nicht mehr, wenn Sie die user-Tabelle konvertieren. Um auf Nummer Sicher zu gehen, sollten Sie mindestens auf Version 3.20.28 aktualisieren und erst dann auf Version 3.21.

Der neue Client-Code funktioniert bei einem 3.20.x mysqld-Server. Wenn Sie daher Probleme mit 3.21.x bekommen, können Sie den alten 3.20.x-Server benutzen, ohne die Clients neu kompilieren zu müssen.

Wenn Sie nicht die --old-protocol-Option für mysqld benutzen, werden alte Clients folgende Fehlermeldung ausgeben:

Die neue Perl-DBI/DBD-Schnittstelle unterstützt auch die alte mysqlperl-Schnittstelle. Die einzige Änderung, die Sie machen müssen, wenn Sie mysqlperl benutzen, ist, die Argumente für die connect()-Funktion zu ändern. Die neuen Argumente sind: host, database, user und password (die user- und password-Argumente haben die Plätze getauscht. See section 9.2.2 Die DBI-Schnittstelle.

Folgende Änderungen können Anfragen in alten Applikationen betreffen:

• HAVING muss jetzt vor einer möglichen ORDER BY-Klausel spezifiziert werden.
• Die Parameter für LOCATE() wurden getauscht.
• Es gibt einige neue reservierte Wörter. Die wichtigsten sind DATE, TIME und TIMESTAMP.

3.5.5 Upgrade auf eine andere Architektur

Wenn Sie MySQL-Version 3.23 benutzen, können Sie die .frm-, .MYI- und .MYD-Dateien zwischen verschiedenen Architekturen kopieren, die dasselbe Fließkomma-Format unterstützen. (MySQL kümmert sich um eventuelle Byte-Tausch-Belange.)

Die MySQL-ISAM-Daten und Index-Dateien (`.ISD' und `*.ISM', je nachdem) sind Architektur-abhängig und in manchen Fällen Betriebssystem-abhängig. Wenn Sie Ihre Applikationen auf eine andere Maschine mit einer unterschiedlichen Architektur oder einem anderen Betriebssystem verlagern wollen, wollten Sie nicht einfach eine Datenbank verschieben, indem Sie deren Dateien auf die andere Maschine kopieren. Benutzen Sie statt dessen mysqldump.

Vorgabemäßig erzeugt mysqldump eine Datei mit SQL-Statements. Sie können diese Datei auf die andere Maschine übertragen und Sie als Eingabe für den mysql-Client benutzen.

mysqldump --help zeigt Ihnen, welche Optionen verfügbar sind. Wenn Sie die Daten mit einer neueren Version von MySQL benutzen werden, sollten Sie mysqldump --opt mit der neueren Version benutzen, um einen schnellen, kompakten Dump zu erhalten.

Die einfachste (wenngleich nicht schnellste) Art, eine Datenbank von einer Maschine auf eine andere zu bringen, ist, die folgenden Befehle auf der Maschine auszuführen, auf der die Datenbank liegt:

Wenn Sie eine Datenbank von einer entfernten Maschine über ein langsames Netzwerk kopieren wollen, können Sie folgendes benutzen:

Sie können das Ergebnis auch in einer Datei speichern, diese Datei auf die Zielmaschine übertragen und dort in die Datenbank laden. Sie können zum Beispiel wie folgt die Datenbank in eine Datei auf der Quellmaschine ausgeben (dumpen):

(Die in diesem Beispiel erzeugte Datei ist komprimiert.) Übertragen Sie die Datei, die die Datenbankinhalte enthält, auf die Zielmaschine und geben Sie dort diese Befehle ein:

Sie können auch mysqldump und mysqlimport benutzen, um den Datenbank-Transfer zu bewerkstelligen. Das ist bei großen Tabellen wesentlich schneller als die Benutzung von mysqldump. In den unten dargestellten Befehlen repräsentiert DUMPDIR den vollen Pfadnamen des Verzeichnisses, das Sie benutzen, um die Ausgabe von mysqldump zu speichern.

Legen Sie zunächst das Verzeichnis für die Ausgabe-Dateien an und geben Sie die Datenbank aus (Dump):

Übertragen Sie dann die Dateien des DUMPDIR-Verzeichnisses in ein entsprechendes Verzeichnis auf der Zielmaschine und laden Sie dort die Dateien in MySQL:

Vergessen Sie auch nicht, die mysql-Datenbank zu kopieren, den dort befinden Sie die Berechtigungstabellen (user, db, host). Eventuell müssen Sie die Befehle als MySQL-root-Benutzer auf der neuen Maschine eingeben, um die mysql-Datenbank angelegt zu bekommen.

Nachdem Sie die mysql-Datenbank auf die neue Maschine kopiert haben, führen Sie mysqladmin flush-privileges aus, damit der Server die Berechtigungsinformationen neu einliest.

3.6 Betriebssystem-spezifische Anmerkungen

3.6.1 Linux (alle Linux-Versionen)

Die Anmerkungen weiter unten, die glibc betreffen, gelten nur dann, wenn Sie MySQL selbst bauen. Wenn Sie Linux auf einer x86-Maschine fahren, ist es in den meisten Fällen wesentlich besser, einfach unsere Binärdateien zu benutzen. Wir linken unsere Binärdateien an die am besten gepatchte Version von glibc, die wir bieten können, und mit den besten Kompiler-Optionen, wobei wir versuchen, MySQL für Hochlast-Server geeignet zu machen. Wenn Sie also den Text unten lesen und sich nicht sicher sind, was Sie tun sollen, sollten Sie zunächst unsere Binärdateien ausprobieren, um zu sehen, ob diese Ihren Anforderungen entsprechen. Kümmern Sie sich nur dann um einen eigenen Build, wenn Sie feststellen, dass unsere Binärdateien nicht gut genug sind. In diesem Fall wären wir für einen Hinweis dazu dankbar, damit wir beim nächsten Mal eine bessere Binärdatei bauen können. Für eine typische Benutzung, selbst bei einer großen Zahl gleichzeitiger Verbindungen und / oder Tabellen, die größer als 2 GB sind, sind unsere Binärdateien in den meisten Fällen die beste Wahl.

MySQL benutzt auf Linux LinuxThreads. Wenn Sie eine alte Linux-Version benutzen, die keine glibc2 hat, müssen Sie LinuxThreads installieren, bevor Sie MySQL kompilieren. Sie erhalten LinuxThreads unter http://www.mysql.com/downloads/os-linux.html.

ACHTUNG: Wir haben einige seltsame Probleme bei Linux 2.2.14 und MySQL auf SMP-Systemen festgestellt. Wenn Sie ein SMP-System haben, empfehlen wir, so schnell wie möglich auf Linux 2.4 zu aktualisieren (Upgrade)! Dadurch wird Ihr System ausserdem schneller und stabiler!

Beachten Sie, dass glibc-Versionen vor und einschließlich Version 2.1.1 einen schweren Fehler im pThread_mutex_timedwait-Handling haben, was benutzt wird, wenn Sie INSERT DELAYED verwenden. Wir empfehlen, vor einem Upgrade der glibc INSERT DELAYED nicht zu verwenden.

Wenn Sie planen, mehr als 1000 gleichzeitige Verbindungen zu haben, müssen Sie einige Änderungen an LinuxThreads vornehmen, es neu kompilieren und mit der neuen `libpThread.a' linken. Setzen Sie PTHREAD_THREADS_MAX in `sysdeps/unix/sysv/linux/bits/local_lim.h' auf 4096 herauf und setzen Sie STACK_SIZE in `linuxThreads/internals.h' auf 256 KB herunter. Die Pfade sind relativ zum Wurzelverzeichnis von glibc. Beachten Sie, dass MySQL bei etwa 600 bis 1000 Verbindungen nicht stabil läuft, wenn STACK_SIZE auf den Vorgabewert von 2 MB gesetzt wird.

Wenn Sie Probleme damit bekommen, dass MySQL nicht genug Dateien oder Verbindungen öffnen kann, haben Sie möglicherweise Linux nicht so konfiguriert, dass es genug Dateien handhaben kann.

In Linux 2.2 und Folgenden können Sie die Anzahl der allozierten Datei-Handler herausbekommen, wenn Sie folgendes eingeben:

Wenn Sie mehr als 16M Speicher haben, sollten Sie etwas Ähnliches wie folgendes in Ihr Boot-Skript (`/etc/rc/boot.local' auf SuSE) eintragen:

Das können Sie auch von der Kommandozeile aus als Root eingeben, aber in diesem Fall werden die alten Beschränkungen wieder benutzt, wenn Sie Ihren Computer neu starten.

Zusätzlich sollten Sie in /etc/my.cnf einfügen:

Das sollte MySQL erlauben, bis zu 8192 Verbindungen und Dateien zu erzeugen.

Die STACK_SIZE-Konstante in LinuxThreads steuert das Spacing von Thread-Stacks im Adressraum. Sie muss Groß genug sein, damit reichlich Platz für den Stack jedes individuellen Threads bleibt, aber klein genug, um den Stack irgend eines Threads davon abzuhalten, mit den globalen mysqld-Daten zu kollidieren. Wie wir durch Experimentieren heraus fanden, unmappt die Linux-Implementation von mmap() erfolgreich eine bereits gemappte Region, wenn Sie sie anweisen, eine Adresse auszumappen, die bereits in Benutzung ist, wobei sie alle Daten der gesamten Seite auf Null setzt, statt einen Fehler zurück zu geben. Daher beruht die Sicherheit von mysqld oder jeder anderen Thread-Applikation auf dem "Gentleman"-Verhalten des Codes, der Threads erzeugt. Der Benutzer muss Vorkehrungen treffen, die sicherstellen, dass die Anzahl laufender Threads jederzeit ausreichend gering ist, damit die Thread-Stacks sich vom globalen Heap fernhalten. Bei mysqld sollten Sie dieses "Gentleman"-Verhalten forcieren, indem Sie einen vernünftigen Wert für die the max_connections-Variable setzen.

Wenn Sie MySQL selbst bauen und sich nicht mit dem Patchen von LinuxThreads herum plagen wollen, sollten Sie max_connections auf einen Wert nicht größer als 500 setzen. Dieser Wert sollte sogar noch kleiner sein, wenn Sie einen großen Schlüsselpuffer (Key Buffer), große Heap-Tabellen oder andere Dinge haben, die mysqld dazu bringen könnten, eine Menge Speicher zu allozieren, oder wenn Sie einen 2.2-Kernel mit einem 2GB-Patch fahren. Wenn Sie unsere Binärdateien oder RPM-Versionen 3.23.23 oder später benutzen, können Sie max_connections sicher auf 1500 setzen, unter der Annahme, dass es keine großen Schlüsselpuffer oder Heap-Tabellen mit vielen Daten gibt. Je mehr Sie STACK_SIZE in LinuxThreads reduzieren können, desto mehr können Sie sicher Threads erzeugen. Wir empfehlen einen Wert zwischen 128K und 256K.

Wenn Sie viele gleichzeitige Verbindungen benutzen, bekommen Sie vielleicht Probleme durch ein "Feature" im 2.2-Kernel, der einen Prozess dafür bestraft, dass er sich aufspaltet (fork) oder einen Kindprozess klont, um einen Fork-Bombenangriff (Fork Bomb Attack) zu verhindern. Das bringt MySQL dazu, nicht so gut zu skalieren, wenn Sie die Anzahl gleichzeitiger Clients erhöhen. Wir konnten beobachten, dass sich das auf Einprozessor-Systemen mit sehr langsamer Thread-Erzeugung bemerkbar macht, was sich darin zeigt, dass es sehr lange dauern kann, sich mit MySQL zu verbinden (bis zu einer Minute), und genau so lange, um es herunter zu fahren. Auf Multiprozessor-Systemen haben wir einen allmählichen Abfall der Anfrage-Geschwindigkeit beobachtet, wenn die Anzahl der Clients zunimmt. Im Verlauf der Suche nach einer Lösung haben wir von einem unserer Benutzer einen Kernel-Patch erhalten, von dem dieser sagt, dass er auf seiner Site eine beträchtliche Rolle spielt. Der Patch ist hier verfügbar (http://www.mysql.com/Downloads/Patches/linux-fork.patch). Inzwischen haben wir recht ausführliche Tests dieses Patchs sowohl auf Entwicklungs- als auch auf Produktionssystemen gemacht. Er hat die Performance von MySQL erheblich verbessert, ohne irgend welche Probleme zu verursachen, und wir empfehlen ihn jetzt denjenigen unserer Benutzer, die immer noch Hochlast-Server auf 2.2-Kerneln fahren. Dieses Problem wurde im 2.4-Kernel behoben. Wenn Sie daher nicht zufrieden mit der momentanen Performance Ihres Systems sind, ist es wahrscheinlich einfacher, auf 2.4 zu aktualisieren, statt den 2.2-Kernel zu patchen, was zusätzlich zur Behebung dieses Fairness-Bugs auch noch Multiprozessor-Systemen einen netten Schub gibt.

Wir haben MySQL auf dem 2.4-Kernel auf einer Zweiprozessor-Maschine getestet und haben festgestellt, dass MySQL VIEL bessere Leistungsdaten bringt - es gab praktisch keine Verlangsamung bei Anfragen bis ganz herauf zu 1000 Clients, und der Skalierungsfaktor von MySQL (berechnet als Verhältnis von maximalem Durchsatz zum Durchsatz mit 1 Client) war 100%. Ähnliches haben wir auf einer Vierprozessor-Maschine beobachtet - praktisch keine Verlangsamung, während die Anzahl der Clients bis auf 1000 stieg sowie ein Skalierungsfaktor von 300%. Für einen unter Hochlast fahrenden Multiprozessor-Server empfehlen wir daher ausdrücklich den 2.4-Kernel. Weiter haben wir festgestellt, dass es essentiell wichtig ist, den mysqld-Prozess auf dem 2.4-Kernel mit der höchstmöglichen Priorität laufen zu lassen, um maximale Performance zu erreichen. Das kann dadurch erreicht werden, dass man den renice -20 $$-Befehl zu safe_mysqld hinzufügt. Bei unseren Tests auf der Vierprozessor-Maschine ergab die Erhöhung der Priorität eine 60%-ige Steigerung des Durchsatzes bei 400 Clients.

Wir sind derzeit dabei, mehr Informationen über die Performance von MySQL auf dem 2.4-Kernel auf 4-Weg- und 8-Weg-Systemen zu bekommen. Wenn Sie Zugang zu einem solchen System haben und einige Benchmarks gemacht haben, schicken Sie bitte eine Mail mit den Ergebnissen an docs@mysql.com - wir werden Sie dem Handbuch hinzufügen.

Es gibt eine weitere Sache, die die Performance von MySQL stark beeinträchtigt, besonders auf SMP-Systemen. Die Implementation von mutex in LinuxThreads in glibc-2.1 ist sehr schlecht für Programme mit vielen Threads, die den mutex nur für kurze Zeit behalten. Wenn Sie MySQL mit unveränderten LinuxThreads linken, führt ironischerweise auf einem SMP-System in manchen Fällen das Entfernen von Prozessoren zu einer Leistungssteigerung von MySQL. Für glibc 2.1.3 haben wir ein Patch bereit gestellt, um dieses Verhalten zu korrigieren: linuxthreads-2.1-patch

Bei Verwendung von glibc-2.2.2 benutzt MySQL-Version 3.23.36 den adaptiven mutex, der sogar viel besser als der gepatchte von glibc-2.1.3 ist. Seien Sie jedoch davor gewarnt, dass unter bestimmten Umständen der aktuelle mutex-Code in glibc-2.2.2 überdrehen kann, was die Performance von MySQL beeinträchtigt. Die Gefahr, dass solche Umstände eintreten, kann dadurch verringert werden, dass der mysqld-Prozess auf die höchste Priorität gesetzt wird. Zusätzlich konnten wir das Überdrehverhalten mit einem Patch korrigieren, der hier erhältlich ist. Der Patch kombiniert die Korrektur des Überdrehens, die maximale Anzahl von Threads und das Stack-Spacing in einem. Sie wenden es auf das linuxThreads-Verzeichnis mit patch -p0 </tmp/linuxThreads-2.2.2.patch an. Wir hoffen, dass der Patch in irgend einer Form in zukünftigen Releases von glibc-2.2 enthalten sein wird. Wie es auch sei, wenn Sie mit glibc-2.2.2 linken, müssen Sie immer noch STACK_SIZE und PTHREAD_THREADS_MAX korrigieren. Wir hoffen, dass diese Vorgabewerte zukünftig auf akzeptablere Werte für eine MySQL-Hochlast-Einrichtung gesetzt werden, so dass Ihr eigener Build auf ./configure; make; make install reduziert werden kann.

Wir empfehlen, dass Die die oben genannten Patches benutzen, um eine spezielle statische Version von libpThread.a zu bauen, die Sie nur für statisches Linken mit MySQL benutzen. Wir wissen, dass die Patches für MySQL sicher sind und seine Performance erheblich verbessern, aber wir können diesbezüglich nichts über andere Applikationen sagen. Wenn Sie andere Applikationen mit der gepatchten Version der Bibliothek linken oder eine gepatchte gemeinsam benutzte (shared) Version bauen und auf Ihrem System installieren, tun Sie das auf eigenes Risiko, was andere Applikationen betrifft, die von LinuxThreads abhängen.

Wenn Sie während der Installation von MySQL irgend welche seltsamen Probleme bekommen oder gebräuchliche Utilities hängen bleiben, ist es sehr wahrscheinlich, dass diese entweder Bibliotheks- oder Compiler-bezogen sind. In diesem Fall wird die Benutzung unserer Binärdatei sie beheben.

Ein bekanntes Problem der Binärdistribution ist, dass Sie auf älteren Linux-Systemen, die libc benutzen (wie RedHat 4.x oder Slackware) nicht-schwere (non-fatal) Probleme mit der Auflösung von Hostnamen bekommen. See section 3.1.1 MySQL auf Linux installieren.

Wenn Sie LinuxThreads benutzen, werden Sie feststellen, dass mindestens drei Prozesse laufen. Das sind in Wirklichkeit Threads. Es gibt einen Thread für den LinuxThreads-Manager, einen Thread, um Verbindungen zu handhaben und einen Thread, um Alarme und Signale zu handhaben.

Beachten Sie, dass der Linux-Kernel und die LinuxThread-Bibliothek vorgabemäßig nur 1024 Threads haben können. Das bedeutet, dass Sie auf einem ungepatchten System nur höchstens 1021 Verbindungen zu MySQL haben können. Die Seite http://www.volano.com/linuxnotes.html enthält Informationen, wie man diese Beschränkung umgeht.

Wenn Sie einen toten mysqld-Daemon-Prozess mit ps sehen, bedeutet das üblicherweise, dass Sie einen Bug in MySQL oder eine zerstörte Tabelle gefunden haben. See section A.4.1 Was zu tun ist, wenn MySQL andauernd abstürzt.

Um auf Linux einen Speicherauszug (Core Dump) zu erhalten, wenn mysqld mit einem SIGSEGV-Signal stirbt, können Sie mysqld mit der --core-file-Option starten. Beachten Sie, dass Sie wahrscheinlich core file size hoch setzen müssen, indem Sie ulimit -c 1000000 zu safe_mysqld hinzufügen oder safe_mysqld mit --core-file-sizes=1000000 starten. See section 5.7.2 safe_mysqld, der Wrapper um mysqld.

Wenn Sie Ihren eigenen MySQL-Client linken und bei der Ausführung diesen Fehler erhalten,

kann das Problem durch eine der folgenden Methoden behoben werden:

• Linken Sie den Client mit dem folgenden Flag (anstelle von -Lpath): -Wl,r/path-libmysqlclient.so.
• Kopieren Sie libmysqclient.so nach `/usr/lib'.
• Fügen Sie der LD_RUN_PATH-Umgebungsvariablen den Pfadnamen des Verzeichnisses hinzu, wo libmysqlclient.so liegt, bevor Sie Ihren Client laufen lassen.

Wenn Sie den Fujitsu-Compiler (fcc / FCC) benutzen, werden Sie beim Kompilieren von MySQL einige Probleme bekommen, weil die Linux-Header-Dateien sehr gcc-orientiert sind.

Folgende configure-Zeile sollte mit fcc/FCC funktionieren:

3.6.1.1 Anmerkungen zur Binärdistribution (Linux)

MySQL benötigt zumindest Linux-Version 2.0.

ACHTUNG: Wir haben Berichte von MySQL-Benutzern erhalten, die schwer wiegende Stabilitätsprobleme mit Linux-Kernel 2.2.14 mitgeteilt haben. Wenn Sie diesen Kernel benutzen, sollten Sie auf 2.2.19 (oder neuer) oder auf einen 2.4-Kernel aktualisieren. Wenn Sie eine Mehrprozessormaschine haben, sollten Sie auf jeden Fall in Betracht ziehen, 2.4 zu benutzen, weil Ihnen das erhebliche Geschwindigkeitssteigerung geben wird.

Die Binärdistribution wird mit -static gelinkt, was normalerweise heißt, dass Sie sich nicht um die Version der Systembibliotheken kümmern müssen, die Sie haben. Ausserdem brauchen Sie nicht LinuxThread installieren. Ein Programm, das mit -static gelinkt ist, ist etwas größer als ein dynamisch gelinktes Programm, und gleichzeitig etwas schneller (3-5%). Ein Problem liegt jedoch darin, dass Sie bei einem statisch gelinkten Programm keine benutzerdefinierten Funktionen (UDF) benutzen können. Wenn Sie UDF-Funktionen schreiben oder benutzen wollen (das ist nur etwas für C- oder C++-Programmierer), müssen Sie MySQL selbst kompilieren und das dynamische Linken benutzen.

Wenn Sie ein libc-basierendes System benutzen (statt eines glibc2-Systems), bekommen Sie bei der Binärdistribution wahrscheinlich Probleme mit der Auflösung von Hostnamen und mit getpwnam(). (Das liegt daran, dass glibc leider von einigen externen Bibliotheken abhängt, um Hostnamen aufzulösen und und getpwent(), selbst wenn es mit -static kompiliert wird.) In diesem Fall erhalten Sie wahrscheinlich folgende Fehlermeldung, wenn Sie mysql_install_db ausführen:

oder den folgenden Fehler, wenn Sie versuchen, mysqld mit der --user-Option laufen zu lassen:

Sie können dieses Problem auf eine der folgenden Weisen lösen:

• Holen Sie sich eine MySQL-Quelldistribution (eine RPM oder die tar.gz-Distribution) und installieren Sie statt dessen diese.
• Führen Sie mysql_install_db --force aus. Das führt nicht den resolveip-Test in mysql_install_db aus. Der Nachteil ist, dass Sie keine Hostnamen in the Berechtigungstabellen benutzen können, sondern nur IP-Nummern (ausser für localhost). Wenn Sie ein altes MySQL-Release benutzen, das --force nicht unterstützt, müssen Sie den resolveip-Test in mysql_install mit einem Editor deaktivieren.
• Starten Sie mysqld mit su anstelle von --user.

Die Linux-Intel-Binärdatei und die RPM-Releases von MySQL sind für höchst mögliche Geschwindigkeit konfiguriert. Wir versuchen immer, den schnellsten stabilen Kompiler zu benutzen, der verfügbar ist.

MySQL-Perl-Unterstützung erfordert Perl-Version 5.004_03 oder neuer.

Auf einigen Linux-2.2-Versionen erhalten Sie womöglich den Fehler Resource temporarily unavailable, wenn Sie eine Menge neuer Verbindungen zu einem mysqld-Server über TCP/IP aufmachen.

Das Problem liegt darin, dass Linux eine Verzögerung zwischen dem Schließen eines TCP/IP-Sockets und dem tatsächlichen Freigeben durch das System hat. Da es nur Platz für eine bestimmte Anzahl von TCP/IP-Slots gibt, bekommen Sie den genannten Fehler, wenn Sie viele neue TCP/IP-Verbindungen innerhalb kurzer Zeit aufbauen, zum Beispiel, wenn Sie den MySQL-`test-connect'-Benchmark über TCP/IP laufen lassen.

Wir haben dieses Problem mehrfach an verschiedene Linux-Mailing-Listen geschrieben, konnten aber bislang keine saubere Lösung erhalten.

Die einzige bekannte 'Behebung' des Problems liegt darin, persistente Verbindungen bei Ihren Clients zu verwenden oder Sockets zu benutzen, wenn Sie den Datenbankserver und die Clients auf derselben Maschine laufen lassen. Wir hoffen, dass zukünftig der Linux 2.4-Kernel dieses Problem lösen wird.

3.6.1.2 Anmerkungen zu Linux x86

MySQL erfordert libc-Version 5.4.12 oder neuer. Bekannt ist, dass libc 5.4.46 funktioniert. glibc-Version 2.0.6 und später sollten ebenfalls funktionieren. Es hat einige Probleme mit den glibc-RPMs von RedHat gegeben. Wenn Sie Probleme haben, prüfen Sie daher, ob es Updates gibt! Die glibc-2.0.7-19- und -2.0.7-29-RPMs funktionieren bekanntermaßen ebenfalls.

Bei einigen älteren Linux-Distributionen kann configure einen Fehler wie folgt produzieren:

Machen Sie, was die (englischsprachige) Fehlermeldung sagt. Fügen Sie also einen zusätzlichen Unterstrich zum _P-Makro hinzu, das nur einen Unterstrich hat, und versuchen Sie es noch einmal.

Möglicherweise erhalten Sie beim Kompilieren Warnungen. Die folgenden davon können ignoriert werden:

In Debian-GNU/Linux müssen Sie folgendes tun, damit MySQL beim Hochfahren des Systems automatisch startet:

mysql.server befindet sich im `share/mysql'-Verzeichnis unterhalb des MySQL-Installationsverzeichnisses oder im `support-files'-Verzeichnis des MySQL-Source-Trees.

Wenn mysqld beim Start immer einen Speicherauszug (Core Dump) erzeugt, kann das Problem darin liegen, dass Sie eine alte `/lib/libc.a' haben. Versuchen Sie sie umzubenennen, entfernen Sie dann `sql/mysqld', führen Sie ein neues make install durch und versuchen Sie es noch einmal. Dieses Problem wurde von einigen Slackware-Installationen berichtet.

Wenn Sie beim Linken von mysqld folgenden Fehler erhalten, bedeutet das, dass Ihre `libg++.a' nicht korrekt installiert ist:

Sie können vermeiden, dass `libg++.a' benutzt wird, indem Sie configure wie folgt ablaufen lassen:

3.6.1.3 Anmerkungen zu Linux SPARC

Bei einigen Implementationen ist readdir_r() fehlerhaft. Das äußert sich darin, dass SHOW DATABASES immer einen leeren Satz (Empty Set) zurück gibt. Das kann behoben werden, indem HAVE_READDIR_R aus

3.6.1.4 Anmerkungen zu Linux Alpha

MySQL-Version 3.23.12 ist die erste MySQL-Version, die auf Linux-Alpha getestet wurde. Wenn Sie planen, MySQL auf Linux-Alpha einzusetzen, stellen Sie sicher, dass Sie diese oder eine neuere Version haben.

Wir haben MySQL auf Alpha mit unseren Benchmarks und unserer Test-Suite getestet, und es scheint gut zu funktionieren. Hauptsächlich noch nicht getestet haben wird, wie die Dinge mit vielen gleichzeitigen Verbindungen funktionieren.

Wir kompilieren die Standard-MySQL-Binärdatei mit SuSE 6.4, Kernel 2.2.13-SMP, Compaq-C-Kompiler Version 6.2-504 und Compaq-C++-Kompiler Version 6.3-005 auf einer Compaq-DS20-Maschine mit einem Alpha-EV6-Prozessor.

Sie finden die genannten Kompiler auf http://www.support.compaq.com/alpha-tools). Durch die Verwendung dieser Kompiler anstelle von gcc erhalten wir eine 9% bis 14% bessere Performance für MySQL.

Beachten Sie, dass die Konfigurationszeile die Binärversion auf die aktuelle CPU optimiert. Das heißt, dass Sie unsere Binärdatei nur benutzen können, wenn Sie einen Alpha-EV6-Prozessor haben. Ausserdem haben wir statisch kompiliert, um Bibliothek-Probleme zu vermeiden.

Bei Benutzung von egcs funktionierte bei uns die folgende Konfigurationszeile:

Einige bekannte Probleme, wenn MySQL auf Linux-Alpha läuft:

• Das Debuggen von threaded Applikationen wie MySQL funktioniert nicht mit gdb 4.18. Statt dessen sollten Sie gdb 5.0 herunter laden und benutzen!
• Wenn Sie versuchen, mysqld unter Benutzung von gcc statisch zu linken, wird das resultierende Image beim Starten einen Speicherauszug (Core Dump) erzeugen. Mit anderen Worten: Benutzen Sie NICHT --with-mysqld-ldflags=-all-static mit gcc.

3.6.1.5 Anmerkungen zu Linux PowerPC

MySQL sollte auf MkLinux mit dem neuesten glibc-Paket funktionieren (getestet mit glibc 2.0.7).

3.6.1.6 Anmerkungen zu Linux MIPS

Um MySQL auf Qube2 zum Laufen zu bringen (Linux Mips), benötigen Sie die neuesten glibc-Bibliotheken (glibc-2.0.7-29C2 funktioniert bekanntermaßen). Ausserdem müssen Sie den egcs-C++-Kompiler (egcs-1.0.2-9, gcc 2.95.2 oder neuer) benutzen.

3.6.1.7 Anmerkungen zu Linux IA64

Um MySQL auf Linux Ia64 zu kompilieren, mussten wir folgendes tun (wir vermuten, dass das leichter wird, wenn die neue gcc-Version für ia64 herausgebracht wird).

Unter Verwendung von gcc-2.9-final:

Nach make werden Sie einen Fehler erhalten, dass sql/opt_range.cc nicht kompiliert (interner Kompiler-Fehler). Um das zu beheben, gehen Sie ins sql-Verzeichnis und tippen Sie erneut make ein. Kopieren Sie die Kompilierzeile, ändern Sie aber -O2 zu -O0. Die Datei sollte nunmehr kompilieren.

Jetzt können Sie folgendes tun:

und mysqld sollte lauffähig sein.

Auf Ia64 benutzen die MySQL-Client-Binärdateien gemeinsam genutzte (shared) Bibliotheken. Wenn Sie daher unsere Binärdistribution an anderer Stelle als `/usr/local/mysql' benutzen, müssen Sie entweder `/etc/ld.so.conf' ändern oder den Pfad zum Verzeichnis hinzufügen, wo Sie `libmysqlclient.so' haben, und zwar in der LD_LIBRARY_PATH-Umgebungsvariablen.

See section A.3.1 Probleme beim Linken mit der MySQL-Client-Bibliothek.

3.6.2 Anmerkungen zu Windows

Dieser Abschnitt beschreibt Installation und Benutzung von MySQL auf Windows. Diese Information steht zusätzlich in der `README'-Datei, die mit der MySQL-Windows-Distribution mitgeliefert wird.

3.6.2.1 Wie man MySQL auf Win95 / Win98 startet

MySQL benutzt TCP/IP, um einen Client mit einem Server zu verbinden. (Das erlaubt jeder beliebigen Maschine in Ihrem Netzwerk, sich mit Ihrem MySQL-Server zu verbinden.) Aus diesem Grund müssen Sie MySQL auf Ihrer Maschine installieren, bevor Sie MySQL starten. Sie finden TCP/IP auf Ihrer Windows-CD-ROM.

Beachten Sie, dass Sie bei Verwendung eines alten Win95-Releases (zum Beispiel OSR2) wahrscheinlich ist, dass Sie ein altes Winsock-Paket haben! MySQL erfordert Winsock 2! Sie erhalten das neueste Winsock von http://www.microsoft.com/. Win98 enthält die neue Winsock-2-Bibliothek, deshalb trifft das Gesagte nicht auf Win98 zu.

Um den mysqld-Server zu starten, öffnen Sie ein MS-DOS-Fenster (MS-DOS-Eingabeaufforderung) und geben Sie ein:

Das startet mysqld im Hintergrund ohne Fenster.

Sie können den MySQL-Server killen, indem Sie eingeben:

Beachten Sie, dass Win95 und Win98 die Erzeugung von Named Pipes nicht unterstützen. Auf Win95 und Win98 können Sie Named Pipes nur benutzen, um sich zu einem entfernten MySQL-Server zu verbinden, der auf einem NT-Server-Host läuft. (Natürlich muss auch der MySQL-Server Named Pipes unterstützen. Beispielsweise läßt die Verwendung von mysqld-opt unter NT keine Named-Pipe-Verbindungen zu. Sie sollten daher entweder mysqld-nt oder mysqld-max-nt verwenden.)

Wenn mysqld nicht startet, überprüfen Sie bitte die `\mysql\data\mysql.err'-Datei um zu sehen, ob der Server eine Meldung ausgegeben hat, die auf die Ursache des Problems hinweist. Sie können auch versuchen, den Server mit mysqld --standalone zu starten. In diesem Fall erscheinen vielleicht nützliche Informationen auf dem Bildschirm, die Ihnen bei der Lösung des Problems helfen.

Die letzte Option besteht darin, mysqld mit --standalone --debug zu starten. In diesem Fall schreibt mysqld eine Log-Datei `C:\mysqld.trace', die die Ursache enthalten könnte, warum mysqld nicht startet. See section E.1.2 Trace-Dateien erzeugen.

3.6.2.2 MySQL auf Windows NT oder Windows 2000 starten

Der Win95-/Win98-Abschnitt trifft auch auf NT/Win2000 zu, mit folgenden Unterschieden:

Damit MySQL mit TCP/IP auf NT läuft, müssen Sie Service-Pack 3 (oder neuer) installieren!

Beachten Sie, dass alles Folgende, das für NT zutrifft, ebenfalls für Win2000 zutrifft!

Für NT/Win2000 ist der Servername mysqld-nt. Normalerweise sollten Sie MySQL auf NT/Win2000 als Systemdienst installieren:

oder

(Unter Windows NT können Sie in der Tat jede der Server-Binärdateien als Systemdienst installieren, aber nur diejenigen, die Namen haben, die auf -nt.exe enden, bieten Unterstützung für Named Pipes.)

Sie können MySQL mit diesen Befehlen starten und anhalten:

Beachten Sie, dass Sie in diesem Fall keine weiteren Optionen für mysqld-nt angeben können!

Sie können mysqld-nt auf NT auch als allein ablaufendes Programm (Stand-alone) laufen lassen, wenn Sie mysqld-nt mit irgend welchen Optionen starten wollen! Wenn Sie mysqld-nt auf NT ohne Optionen laufen lassen, versucht mysqld-nt, sich mit den Vorgabeoptionen als Systemdienst zu starten. Wenn Sie mysqld-nt angehalten haben, müssen Sie es mit NET START mysql neu starten.

Der Systemdienst wird installiert mit dem Namen MySQL. Einmal installiert, muss er mit dem Systemdienst-Steuerungs-Manager (SCM) in der Systemsteuerung gestartet werden, oder indem Sie den NET START MySQL-Befehl benutzen. Wenn irgend welche Optionen angegeben werden sollen, müssen diese als ``Startparameter'' im SCM-Dienstprogramm angegeben werden, bevor Sie den MySQL-Dienst starten. Wenn mysqld-nt läuft, kann er mit mysqladmin oder dem SCM-Dienstprogramm angehalten werden, oder indem Sie den Befehl NET STOP MySQL benutzen. Wenn Sie SCM benutzen mysqld-nt, um den Server anzuhalten, gibt es eine seltsame Meldung von SCM über mysqld shutdown normally. Wenn er als Systemdienst läuft, hat mysqld-nt keinen Zugriff auf die Konsole. Daher werden auch keine Meldungen angezeigt.

Auf NT erhalten Sie möglicherweise folgende Systemdienst-Fehlermeldungen:

Zugriff verboten	Bedeutung: mysqld-nt.exe kann nicht gefunden werden.
Kann nicht registrieren	Bedeutung: Der Pfad ist falsch.
Installation des Systemdienstes fehlgeschlagen.	Bedeutung: Der Systemdienst ist bereits installiert oder der Systemdienst-Steuerungs-Manager ist in einem schlechten Zustand.

Wenn Sie Problem haben, mysqld-nt als Systemdienst zu installieren, versuchen Sie, ihn mit dem vollen Pfad zu installieren:

Wenn das nicht funktioniert, können Sie erreichen, dass mysqld-nt korrekt startet, indem Sie den Pfad in der Registrierung korrigieren!

Wenn Sie nicht wollen, dass mysqld-nt als Systemdienst startet, können Sie ihn wie folgt starten:

oder

Letztgenanntes gibt Ihnen eine Debug-Spur in `C:\mysqld.trace'. See section E.1.2 Trace-Dateien erzeugen.

3.6.2.3 MySQL auf Windows laufen lassen

MySQL unterstützt TCP/IP auf allen Windows-Plattformen und Named Pipes auf NT. Vorgabemäßig werden Named Pipes für lokale Verbindungen auf NT und TCP/IP für alle anderen Fälle benutzt, wenn der Client TCP/IP installiert hat. Der Hostname legt fest, welches Protokoll benutzt wird:

Sie können erzwingen, dass ein MySQL-Client Named Pipes benutzt, indem Sie die --pipe-Option oder . als Hostnamen angeben. Benutzen Sie die --socket-Option, um den Namen der Pipe festzulegen.

Sie können feststellen, ob MySQL funktioniert, indem Sie die folgenden Befehle eingeben:

Wenn mysqld nur langsam auf Verbindungen auf Win95/Win98 antwortet, gibt es wahrscheinlich ein Problem mit Ihrem DNS. Starten Sie in diesem Fall mysqld mit --skip-name-resolve und benutzen Sie nur localhost und IP-Nummern in den MySQL Berechtigungstabellen. Sie können DNS bei einer Verbindung zu einem mysqld-nt-MySQL-Server, der auf NT läuft, ebenfalls dadurch vermeiden, dass Sie das --pipe-Argument verwenden, um die Benutzung von Named Pipes festzulegen. Das funktioniert bei den meisten MySQL-Clients.

Es gibt zwei Versionen des MySQL-Kommadozeilen-Werkzeugs:

mysql	Kompiliert auf nativem Windows, was sehr eingeschränkte Texteditiermöglichkeiten bietet.
mysqlc	Kompiliert mit dem Cygnus-GNU-Kompiler und -Bibliotheken, was readline-Editiermöglichkeit bietet.

Wenn Sie mysqlc.exe benutzen wollen, müssen Sie `C:\mysql\lib\cygwinb19.dll' in Ihr Windows-Systemverzeichnis kopieren (`\windows\system' oder ein ähnlicher Ort).

Vorgabemäßig geben die Berechtigungen auf Windows allen lokalen Benutzern volle Zugriffsrechte auf alle Datenbanken, ohne ein Passwort anzugeben. Um MySQL sicherer zu machen, sollten Sie für alle Benutzer ein Passwort setzen und die Zeile in der Tabelle mysql.user, die Host='localhost' und User='' enthält, löschen.

Sie sollten auch für den root-Benutzer ein Passwort vergeben. Das folgende Beispiel entfernt den anonymen Benutzer, der von jedem genutzt werden kann, um auf die test-Datenbank zuzugreifen und setzt dann für den root-Benutzer ein Passwort:

Nachdem Sie das Passwort gesetzt haben, sollten Sie den mysqld-Server herunter fahren, was Sie mit folgendem Befehl bewerkstelligen können:

Wenn Sie die alte Shareware-Version von MySQL-Version 3.21 unter Windows benutzen, schlägt der genannte Befehl mit einem Fehler fehl: parse error near 'SET OPTION password'. Die Lösung besteht darin, auf die aktuelle MySQL-Version zu aktualisieren, die frei verfügbar ist.

Mit den neuen MySQL-Versionen können Sie auf einfache Art neue Benutzer hinzufügen und Zugriffsrechte mit den GRANT- und REVOKE-Befehlen ändern. See section 5.3.1 GRANT- und REVOKE-Syntax.

3.6.2.4 Verbinden mit einem entfernten MySQL-Server von Windows mit SSH aus

Hier ist eine Anmerkung dazu, wie man sich über eine sichere Verbindung zu einem entfernten MySQL-Server mit SSH verbindet (von David Carlson dcarlson@mplcomm.com):

• Installieren Sie einen SSH-Client auf Ihrer Windows-Maschine. Das beste nicht kostenlose Werkzeug, das ich gefunden habe, ist SecureCRT von http://www.vundyke.com/. Eine andere Option ist f-secure von http://www.f-secure.com/. Sie finden kostenlose Werkzeuge über Google auf http://directory.google.com/Top/Computers/Security/Products_and_Tools/Cryptography/SSH/Clients/Windows/.
• Starten Sie Ihren Windows-SSH-Client. Konfigurieren Sie: Host_Name = ihr_mysql_server_URL_oder_IP. Konfigurieren Sie: userid=ihre_userid, um sich an Ihrem Server anzumelden (wahrscheinlich nicht dasselbe wie Ihr MySQL-Benutzername / -Passwort).
• Konfigurieren Sie Port-Forwarding. Machen Sie entweder ein Remote Forward (einstellen: local_port: 3306, remote_host: ihr_mysql_servername_oder_ip, remote_port: 3306 ) oder ein lokales Forward (einstellen: port: 3306, host: localhost, remote port: 3306).
• Speichern Sie alles, damit Sie es beim nächsten Mal nicht noch einmal eingeben müssen.
• Melden Sie sich an Ihrem Server mit der SSH-Sitzung, die Sie gerade erzeugt haben.
• Starten Sie auf Ihrer Windows-Maschine irgend eine Applikation wie Access.
• Erzeugen Sie unter Windows eine neue Datei und stellen Sie eine Verknüpfung zu MySQL her, indem Sie den ODBC-Treiber so benutzen, wie Sie es normalerweise tun, AUSSER dass Sie localhost als MySQL-Host-Server eingeben - NICHT yourmysqlservername.

Jetzt sollten Sie eine ODBC-Verbindung zu MySQL haben, die mit SSH verschlüsselt ist.

3.6.2.5 Daten auf verschiedenen Platten unter Win32 aufteilen

Ab MySQL-Version 3.23.16 werden die mysqld-max- und mysql-max-nt-Server in der MySQL-Distribution mit der -DUSE_SYMDIR-Option kompiliert. Das gibt Ihnen die Möglichkeit, Datenbanken auf verschiedene Festplatten zu verteilen, indem Sie symbolische Links darauf machen (in ähnlicher Weise, wie symbolische Links unter Unix funktionieren).

Unter Windows legen Sie einen symbolischen Link auf eine Datenbank an, indem Sie eine Datei erzeugen, die den Pfad zum Zielverzeichnis enthält, und diese Datei im `mysql_data'-Verzeichnis unter dem Dateiname `Datenbank.sym' speichern. Beachten Sie, dass der symbolische Link nur dann benutzt wird, wenn das Verzeichnis `mysql_data_dir\datenbank' nicht existiert.

Wenn Ihr MySQL-Daten-Verzeichnis beispielsweise `C:\mysql\data' ist und Sie die Datenbank foo dort haben wollen, die aber in `D:\data\foo' liegt, erzeugen Sie die Datei `C:\mysql\data\foo.sym', die als Text D:\data\foo\ enthält. Dann werden alle Tabellen, die in der Datenbank foo sind, in `D:\data\foo' erzeugt.

Beachten Sie, dass wir dieses Feature nicht vorgabemäßig aktiviert haben, weil es mit Geschwindigkeitsnachteilen verbunden ist. Es ist selbst dann nicht aktiviert, wenn Sie MySQL mit Unterstützung dafür kompiliert haben. Um symbolische Links zu aktivieren, müssen Sie in Ihre my.cnf- oder my.ini-Datei folgenden Eintrag machen:

In MySQL 4.0 werden symbolische Links vorgabemäßig aktiviert sein. Wenn Sie dies deaktivieren wollen, benutzen Sie die skip-symlink-Option.

3.6.2.6 MySQL-Clients auf Windows kompilieren

In Ihren Quell-Dateien sollten Sie `windows.h' einschließen, bevor Sie `mysql.h' einschließen:

Sie können Ihren Code entweder mit der dynamischen `libmysql.lib'-Bibliothek linken, die nur ein Wrapper zum Laden der `libmysql.dll' bei Bedarf ist, oder mit der statischen `mysqlclient.lib'-Bibliothek.

Beachten Sie, dass MySQL-Client-Bibliotheken als threaded Bibliotheken kompiliert werden, daher sollten Sie auch Ihren Code so kompilieren, dass er multi-threaded ist!

3.6.2.7 MySQL-Windows im Vergleich zu Unix-MySQL

MySQL-Windows hat sich mittlerweile als sehr stabil erwiesen. Diese Version von MySQL hat dieselben Features wie die entsprechende Unix-Version, allerdings mit folgenden Ausnahmen:

Windows 95 und Threads

Windows 95 hat ein etwa 200 Bytes großes Hauptspeicher-Leck (Memory Leak) für jede Thread-Erzeugung. Jede Verbindung zu MySQL erzeugt eine neues Thread, daher sollten Sie mysqld nicht für längere Zeiträume auf Windows 95 laufen lassen, wenn Ihr Server viele Verbindungen handhabt! Windows NT und Windows 98 haben diesen Bug nicht.

Gleichzeitige Lesezugriffe

MySQL vertraut auf pread()- und pwrite()-Aufrufe, um in der Lage zu sein, INSERT und SELECT zu mischen. Momentan benutzen wir mutexes, um pread() / pwrite() zu emulieren. Langfristig werden wir die Dateiebenen-Schnittstelle durch eine virtuelle Schnittstelle ersetzen, um die readfile()- / writefile()-Schnittstelle auf NT mit höherer Geschwindigkeit benutzen zu können. Die aktuelle Implementation begrenzt die Anzahl offener Dateien, die MySQL benutzen kann, auf 1024, was bedeutet, dass Sie nicht so viele gleichzeitige Threads auf NT benutzen können wie auf Unix.

Blockierendes Lesen

MySQL benutzt blockierendes Lesen (Blocking Read) für jede Verbindung. Das bedeutet in der Anwendung:

• Eine Verbindung wird nicht automatisch nach 8 Stunden abgebaut, wie es unter der Unix-Version von MySQL der Fall ist.
• Wenn eine Verbindung hängen bleibt, ist es unmöglich, sie abzubrechen, ohne MySQL zu killen.
• mysqladmin kill funktioniert nicht für schlafende Verbindungen.
• mysqladmin shutdown kann nicht abgebrochen werden, solange es noch schlafende Verbindungen gibt.

Geplant ist, dieses Problem zu beheben, sobald unsere Windows-Entwickler ein nettes Workaround heraus gefunden haben.

UDF-Funktionen

Momentan unterstützt MySQL-Windows keine benutzerdefinierten Funktionen (UDF, user defined functions).

DROP DATABASE

Sie können keine Datenbank löschen, die durch irgend einen Thread in Benutzung ist.

MySQL vom Task-Manager aus killen

Sie können MySQL nicht vom Task-Manager oder mit dem Shutdown-Dienstprogramm unter Windows 95 killen. Sie müssen es mit mysqladmin shutdown herunter fahren.

Von Groß-/Kleinschreibung unabhängige Namen

Unter Windows sind Dateinamen unabhängig von der Groß-/Kleinschreibung. Daher sind Datenbank- und Tabellennamen in MySQL für Windows ebenfalls unabhängig von der Groß-/Kleinschreibung. Die einzige Einschränkung ist die, dass Datenbank- und Tabellennamen innerhalb eines bestimmten Statements dieselbe Groß-/Kleinschreibung haben müssen. See section A.5.1 Groß-/Kleinschreibung beim Suchen.

Das `\'-Verzeichnis-Zeichen

Bestandteile von Pfadnamen werden unter Windows mit dem `\'-Zeichen getrennt, das in MySQL als Fluchtzeichen (Escape Character) dient. Wenn Sie LOAD DATA INFILE oder SELECT ... INTO OUTFILE benutzen, müssen Sie `\' an solchen Stellen doppelt eingeben: mysql> LOAD DATA INFILE "C:\tmp\skr.txt" INTO TABLE skr; mysql> SELECT * INTO OUTFILE 'C:\tmp\skr.txt' FROM skr; Alternativ können Sie auch Dateinamen im Unix-Stil mit `/'-Zeichen benutzen: mysql> LOAD DATA INFILE "C:/tmp/skr.txt" INTO TABLE skr; mysql> SELECT * INTO OUTFILE 'C:/tmp/skr.txt' FROM skr;

Can't open named pipe-Fehler

Wenn Sie MySQL-Version 3.22 auf NT mit den neuesten MySQL-Clients benutzen, erhalten Sie folgende Fehlermeldung: error 2017: can't open named pipe to host: . pipe... Das liegt daran, dass die MySQL-Version für NT auf NT vorgabemäßig Named Pipes benutzt. Sie können diesen Fehler vermeiden, indem Sie bei den neuen MySQL-Clients die --host=localhost-Option benutzen oder eine Optionsdatei `C:\my.cnf' anlegen, die folgendes enthält: [client] host = localhost

Access denied for user-Fehler

Wenn Sie den Fehler Access denied for user: 'ein-benutzer@unknown' to database 'mysql' erhalten, wenn Sie auf einen MySQL-Server auf derselben Maschine zugreifen, heißt das, dass MySQL Ihren Hostnamen nicht richtig auflösen kann. Um das zu beheben, legen Sie eine Datei `\windows\hosts' mit folgender Zeile an: 127.0.0.1 localhost

ALTER TABLE

Wenn Sie ein ALTER TABLE-Statement ausführen, ist die Tabelle gegen Benutzung durch andere Threads gesperrt. Das hat damit zu tun, dass Sie unter Windows keine Datei löschen können, die durch andere Threads in Benutzung ist. (Zukünftig finden wir möglicherweise einen Weg, dieses Problem zu umgehen.)

DROP TABLE auf eine Tabelle, die durch eine

MERGE-Tabelle in Benutzung ist, funktioniert nicht. Der MERGE-Handler führt sein Tabellen-Mapping versteckt vor MySQL durch. Weil Windows das Löschen von Dateien verbietet, die offen sind, müssen Sie zuerst alle MERGE-Tabellen flushen (mit FLUSH TABLES) oder die MERGE-Tabelle löschen, bevor Sie die Tabelle löschen. Wir werden das zusammen mit der Einführung von Sichten (VIEWs) beheben.

Hier sind einige Themen für diejenigen, die uns beim Windows-Release helfen wollen:

• Einen Ein-Benutzer-Server MYSQL.DLL herstellen. Das könnte alles beinhalten, was einen Standard-Server ausmacht, ausser Thread-Erzeugung. Das würde es erheblich erleichtern, MySQL in Applikationen zu benutzen, die keinen echten Client/Server und keinen Zugriff auf den Server von anderen Hosts benötigen.
• Ein paar nette Start- und Stop-Icons zur MySQL-Installation hinzufügen.
• Ein Werkzeug bauen, das Registrierungseinträge für die MySQL-Startoptionen handhabt. Das Lesen der Registrierungseinträge ist bereits in `mysqld.cc' kodiert, sollte aber umgeschrieben werden, damit es mehr Parameter-orientiert ist. Das Werkzeug sollte auch in der Lage sein, die `C:\my.cnf'-Optionsdatei zu aktualisieren, wenn der Benutzer diese lieber als die Registrierungsdatei benutzen will.
• Wenn man mysqld als Systemdienst mit --install (auf NT) installiert, wäre es nett, wenn man vorgabemäßige Optionen auf der Kommandozeile hinzufügen könnte. Im Moment muss man diese fehlende Möglichkeit durch eine Liste der Parameter in der `C:\my.cnf'-Datei ersetzen.
• Es wäre eine feine Sache, wenn man mysqld vom Task-Manager aus killen könnte. Momentan muss man mysqladmin shutdown benutzen.
• readline auf Windows portieren, damit es im mysql-Kommandozeilen-Werkzeug benutzt werden kann.
• GUI-Versionen der Standard-MySQL-Clients (mysql, mysqlshow, mysqladmin und mysqldump) wären nett.
• Nett wäre auch, wenn die Socket-Lese- und Schreib-Funktionen in `net.c' unterbrechbar wären. Das würde es ermöglichen, offen Threads mit mysqladmin kill auf Windows zu killen.
• following two lines? mysqld always starts in the "C" locale und not in the default locale. We would like to have mysqld use the current locale für the sort order.
• Benutzerdefinierte Funktionen (UDF) mit .DLLs implementieren.
• Makros hinzufügen, um die schnelleren, Thread-sicheren Inkrementierungs-/Dekrementierungsmethoden nutzen zu können, die Windows bietet.

Weitere Windows-spezifische Themen sind in der `README'-Datei beschrieben, die mit der MySQL-Windows-Distribution ausgeliefert wird.

3.6.3 Anmerkungen zu Solaris

Auf Solaris bekommen Sie vielleicht schon Probleme, bevor Sie überhaupt Ihre MySQL-Distribution entpackt haben! Solaris-tar kann nicht mit langen Dateinamen umgehen. Daher sehen Sie vielleicht einen Fehler wie den folgenden, wenn Sie MySQL entpacken:

In diesem Fall müssen Sie GNU-tar (gtar) benutzen, um die Distribution zu entpacken. Sie finden eine vorkompilierte Version für Solaris auf http://www.mysql.com/downloads/.

Native Sun-Threads funktinieren nur auf Solaris 2.5 und höher. Auf 2.4 und früher benutzt MySQL automatisch MIT-pThreads. See section 3.3.6 Anmerkungen zu MIT-pThreads.

Vielleicht erhalten Sie von configure folgenden Fehler:

Das bedeutet, dass mit Ihrer Kompiler-Installation etwas nicht stimmt! In diesem Fall sollten Sie Ihren Kompiler auf eine neuere Version aktualisieren. Eventuell sind Sie in der Lage, das Problem zu lösen, indem Sie folgende Zeile in die `config.cache'-Datei einfügen:

Wenn Sie Solaris auf einer SPARC benutzen, ist der empfohlene Kompiler gcc 2.95.2. Sie finden ihn auf http://gcc.gnu.org/. Beachten Sie, dass egcs 1.1.1 und gcc 2.8.1 auf SPARC nicht zuverlässig laufen!

Die empfohlene configure-Zeile ist bei der Benutzung von gcc 2.95.2:

Wenn Sie eine Ultra-Sparc haben, erhalten Sie 4 % mehr Performance, wenn Sie "-mcpu=v8 -Wa,-xarch=v8plusa" zu CFLAGS und CXXFLAGS hinzufügen.

Wenn Sie einen Sun Workshop (Fortre) 5.3 (oder neueren) Kompiler haben, können Sie configure wie folgt laufen lassen:

In den MySQL-Benchmarks haben wir auf einer Ultra-Sparc 6% Geschwindigkeitssteigerung erreicht, wenn wir Sun Workshop 5.3 benutzen, im Vergleich mit der Benutzung von gcc mit -mcpu-Flags.

Wenn Sie Probleme mit fdatasync oder sched_yield bekommen, können Sie diese beheben, indem Sie LIBS=-lrt zur Konfigurationszeile hinzufügen.

Der folgende Absatz ist nur für ältere Kompiler als WorkShop 5.3 relevant:

Eventuell müssen Sie auch das configure-Skript editieren und folgende Zeile ändern:

Ändern zu:

Wenn Sie __STDC__ mit der -Xc-Option anschalten, kann der Sun-Kompiler nicht mit der Solaris-`pThread.h'-Header-Datei kompilieren. Das ist ein Bug von Sun (Kompiler-Problem oder beschädigte Include-Datei).

Wenn mysqld beim Laufenlassen eine Fehlermeldung wie die unten stehende ausgibt, haben Sie versucht, MySQL mit dem Sun-Kompiler zu kompilieren, ohne die Multi-Thread-Option (-mt) anzuschalten:

Fügen Sie -mt zu CFLAGS und CXXFLAGS hinzu und versuchen Sie es noch einmal.

Wenn Sie folgenden Fehler beim Kompilieren von MySQL mit gcc erhalten, ist Ihr gcc nicht für Ihre Version von Solaris konfiguriert:

Die einzige richtige Möglichkeit in diesem Fall ist, sich die neueste Version von gcc zu besorgen und Sie mit Ihrem aktuellen gcc-Kompiler zu kompilieren. Zumindest auf Solaris 2.5 haben fast alle Binärversionen von gcc alte, unbrauchbare Include-Dateien, die alle Programme beschädigen, die Threads benutzen (und möglicherweise auch andere Programme)!

Solaris stellt keine statischen Versionen aller Systembibliotheken zur Verfügung (libpThreads und libdl). Daher können Sie MySQL nicht mit --static kompilieren. Wenn Sie es dennoch versuchen, erhalten Sie folgenden Fehler:

Wenn zu viele Prozesse zu schnell hintereinander versuchen, sich mit mysqld zu verbinden, werden Sie folgenden Fehler im MySQL-Log sehen:

Als Workaround können Sie versuchen, den Server mit der --set-variable back_log=50-Option zu starten. See section 5.1.1 mysqld-Kommandozeilenoptionen.

Wenn Sie Ihren eigenen MySQL-Client linken, erhalten Sie möglicherweise folgenden Fehler, wenn Sie versuchen, ihn auszuführen:

Dieses Problem kann mit einer der folgenden Methoden vermieden werden:

• Linken Sie den Client mit folgendem Flag (anstelle von -Lpath): -Wl,r/full-path-to-libmysqlclient.so.
• Kopieren Sie `libmysqclient.so' nach `/usr/lib'.
• Fügen Sie den Pfadnamen des Verzeichnisses, wo `libmysqlclient.so' liegt, der LD_RUN_PATH-Umgebungsvariablen hinzu, bevor Sie Ihren Client laufen lassen.

Wenn Sie die --with-libwrap-configure-Option benutzen, müssen Sie auch die Bibliotheken einschließen, die `libwrap.a' benötigt:

Wenn Sie Probleme mit configure haben, wenn Sie versuchen, mit -lz zu linken und keine zlib installiert haben, haben Sie zwei Möglichkeiten:

• Wenn Sie in der Lage sein wollen, dass komprimierte Kommunikationsprotokoll zu benutzen, müssen Sie zlib von ftp.gnu.org laden und installieren.
• Konfigurieren Sie mit --with-named-z-libs=no.

Wenn Sie gcc benutzen und Probleme mit dem Laden von UDF-Funktionen in MySQL haben, versuchen Sie, -lgcc zur Link-Zeile für die UDF-Funktion hinzuzufügen.

Wenn Sie wollen, dass MySQL automatisch startet, kopieren Sie `Support-files/mysql.server' nach `/etc/init.d' und erzeugen Sie einen symbolischen Link darauf, den Sie `/etc/rc3.d/S99mysql.server' nennen.

3.6.3.1 Anmerkungen zu Solaris 2.7/2.8

Normalerweise können Sie eine Solaris-2.6-Binärdatei für Solaris 2.7 und 2.8 benutzen. Die meisten Dinge, die Solaris 2.6 betreffen, treffen auch für Solaris 2.7 und 2.8 zu.

Beachten Sie, dass MySQL-Version 3.23.4 und höher in der Lage sein sollte, automatisch neue Versionen von Solaris zu erkennen und Workarounds für die folgenden Probleme zu aktivieren!

Solaris 2.7 / 2.8 hat einige Bugs in den Include-Dateien. Eventuell sehen Sie folgenden Fehler, wenn Sie gcc benutzen:

Wenn das auftritt, können Sie folgendes tun, um das Problem zu lösen:

Kopieren Sie /usr/include/widec.h nach .../lib/gcc-lib/os/gcc-version/include und ändern Sie Zeile 41 von:

Alternativ können Sie `/usr/include/widec.h' direkt editieren. Egal, wie Sie vorgehen: Nachdem Sie die Fehlerbehebung durchgeführt haben, sollten Sie `config.cache' entfernen und configure noch einmal laufen lassen!

Wenn Sie beim Laufenlassen von make folgende Fehler bekommen, liegt das daran, dass configure die `curses.h'-Datei nicht erkannte (vermutlich aufgrund des Fehlers in `/usr/include/widec.h'):

Das Problem lösen Sie auf eine der folgenden Weisen:

• Konfigurieren Sie mit CFLAGS=-DHAVE_CURSES_H CXXFLAGS=-DHAVE_CURSES_H ./configure.
• Editieren Sie `/usr/include/widec.h', wie weiter oben gezeigt, und lassen Sie configure noch einmal laufen.
• Entfernen Sie die #define HAVE_TERM-Zeile aus der `config.h'-Datei und lassen Sie make noch einmal laufen.

Wenn Sie das Problem bekommen, dass Ihr Linker -lz nicht finden kann, wenn Sie Ihr Client-Programm linken, liegt das wahrscheinlich daran, dass Ihre `libz.so'-Datei in `/usr/local/lib' installiert ist. Sie können das mit einer der folgenden Methoden beheben:

• Fügen Sie `/usr/local/lib' zu LD_LIBRARY_PATH hinzu.
• Fügen Sie einen Link auf `libz.so' von `/lib' hinzu.
• Wenn Sie Solaris 8 benutzen, können Sie die optionale zlib aus Ihrer Solaris-8-CD-Distribution installieren.
• Konfigurieren Sie MySQL mit der --with-named-z-libs=no-Option.

3.6.3.2 Anmerkungen zu Solaris x86

Auf Solaris 2.8 auf x86 erzeugt mysqld einen Speicherauszug (Core Dump), wenn Sie darin 'strip' laufen lassen.

Wenn Sie gcc oder egcs auf Solaris x86 benutzen und Probleme mit Speicherauszügen (Core Dumps) unter Last erleben, sollten Sie folgenden configure-Befehl benutzen:

Das vermeidet Probleme mit der libstdc++-Bibliothek und mit C++-Ausnahmefehlern.

Wenn das nicht hilft, sollten Sie eine Debug-Version kompilieren und sie mit einer Trace-Datei oder unter gdb laufen lassen. See section E.1.3 mysqld unter gdb debuggen.

3.6.4 Anmerkungen zu BSD

3.6.4.1 Anmerkungen zu FreeBSD

FreeBSD 3.x wird für MySQL empfohlen, weil das Thread-Paket sehr viel integrierter ist.

Die einfachste und daher empfohlene Art der Installation ist die Benutzung der mysql-server- und mysql-client-Ports, die auf http://www.freebsd.org verfügbar sind.

Durch deren Benutzung erhalten Sie:

• Ein funktionierendes MySQL mit allen Optimierungen bereits aktiviert, von denen bekannt ist, dass Sie auf Ihrer Version von FreeBSD funktionieren.
• Automatische Konfiguration, automatisches Build.
• Start-Skripte, die in /usr/local/etc/rc.d installiert werden.
• Die Möglichkeit festzustellen, welche Dateien installiert sind, mit pkg_info -L. Und die Möglichkeit, sie mit pkg_delete zu entfernen, wenn Sie MySQL nicht mehr auf dieser Maschine haben wollen.

Empfohlen wird die Benutzung von MIT-pThreads auf FreeBSD 2.x und von nativen Threads auf Version 3 und höher. Es ist möglich, auf einigen späten 2.2.x-Versionen mit nativen Threads zu arbeiten, aber Sie können beim Herunterfahren von mysqld Probleme bekommen.

Die MySQL-`Makefile'-Dateien erfordern GNU-make (gmake). Wenn Sie MySQL kompilieren wollen, müssen Sie zuerst GNU-make installieren.

Stellen Sie sicher, dass Ihr Namensauflöser (Name Resolver) korrekt eingerichtet ist. Ansonsten erleben Sie vielleicht Resolver-Verzögerungen oder -Fehler, wenn Sie sich mit mysqld verbinden.

Stellen Sie sicher, dass der localhost-Eintrag in der `/etc/hosts'-Datei stimmt. Ansonsten werden Sie Probleme haben, sich mit der Datenbank zu verbinden. Die `/etc/hosts'-Datei sollte mit folgender Zeile beginnen:

Wenn Sie bemerken, dass configure MIT-pThreads benutzen wird, lesen Sie die Anmerkungen zu MIT-pThreads. See section 3.3.6 Anmerkungen zu MIT-pThreads.

Wenn make install meldet, dass es `/usr/include/pThreads' nicht finden kann, hat configure nicht entdeckt, dass Sie MIT-pThreads benötigen. Das kann durch die Ausführung folgender Befehle behoben werden:

FreeBSD ist dafür bekannt, dass es vorgabemäßig einen sehr niedrigen Wert für Datei-Handles eingestellt hat. See section A.2.16 File Not Found. Kommentieren Sie den Abschnitt ulimit -n section in safe_mysqld aus oder erhöhen Sie die Werte für den mysqld-Benutzer in /etc/login.conf (und bauen Sie es neu mit cap_mkdb /etc/login.conf). Stellen Sie ausserdem sicher, dass Sie die korrekte Klasse für diesen Benutzer in der Passwort-Datei einstellen, wenn Sie nicht den Vorgabewert benutzen (benutzen Sie chpass mysqld-user-name). See section 5.7.2 safe_mysqld, der Wrapper um mysqld.

Wenn Sie Probleme mit dem aktuellen Datum in MySQL erhalten, wird das Setzen der TZ-Variablen das wahrscheinlich beheben. See section F Umgebungsvariablen.

Um ein sicheres, stabiles System zu erhalten, sollten Sie ausschließlich FreeBSD-Kernels benutzen, die als -STABLE markiert sind.

3.6.4.2 Anmerkungen zu NetBSD

Um auf NetBSD zu kompilieren, benötigen Sie GNU make. Ansonsten wird das Kompilieren abstürzen, wenn make versucht, lint auf C++Dateien laufen zu lassen.

3.6.4.3 Anmerkungen zu OpenBSD

3.6.4.4 Anmerkungen zu OpenBSD 2.5

Auf OpenBSD-Version 2.5 können Sie MySQL mit nativen Threads mit folgenden Optionen kompilieren:

3.6.4.5 Anmerkungen zu OpenBSD 2.8

Unsere Benutzer haben berichtet, dass OpenBSD 2.8 einen Thread-Bug hat, der Probleme mit MySQL verursacht. Die OpenBSD-Entwickler haben das Problem behoben, aber seit dem 25. Januar 2001 ist es nur im ``-current''-Zweig verfügbar. Die Symptome dieses Thread-Bugs sind langsames Antworten, hohe Lase, hohe Prozessorauslastung und Abstürze.

3.6.4.6 Anmerkungen zu BSD/OS

3.6.4.7 Anmerkungen zu BSD/OS Version 2.x

Wenn Sie folgenden Fehler beim Kompilieren von MySQL erhalten, ist Ihr ulimit-Wert für virtuellen Speicher zu niedrig:

Versuchen Sie, ulimit -v 80000 zu benutzen, und lassen Sie make erneut laufen. Wenn das nicht funktioniert und Sie bash benutzen, versuchen Sie, statt dessen csh oder sh zu benutzen. Einige BSDI-Benutzer haben Probleme mit bash und ulimit berichtet.

Wenn Sie gcc benutzen, müssen Sie eventuell auch den --with-low-memory-Flag für configure benutzen, um in der Lage zu sein, `sql_yacc.cc' zu kompilieren.

Wenn Sie Probleme mit dem aktuellen Datum in MySQL erhalten, wird das Setzen der TZ-Variablen das wahrscheinlich beheben. See section F Umgebungsvariablen.

3.6.4.8 Anmerkungen zu BSD/OS Version 3.x

Aktualisieren Sie auf BSD/OS Version 3.1. Wenn das nicht möglich ist, installieren Sie BSDI-Patch M300-038.

Benutzen Sie zur Konfiguration von MySQL folgenden Befehl:

Folgendes funktioniert bekanntermaßen ebenfalls:

Wenn Sie wollen, können Sie die Verzeichnisorte ändern oder aber die Vorgabewerte benutzen, indem Sie einfach keine Speicherorte angeben.

Wenn Sie Performance-Probleme unter Hochlast bekommen, versuchen Sie die --skip-thread-priority-Option für mysqld! Dies führt alle Threads mit derselben Priorität aus. Auf BSDI-Version 3.1 gibt Ihnen das bessere Performance (zumindest solange, bis BSDI ihren Thread-Scheduler in Ordnung bringt).

Wenn Sie beim Kompilieren den Fehler virtual memory exhausted erhalten, probieren Sie es mit ulimit -v 80000 und lassen Sie make noch einmal laufen. Wenn das nicht funktioniert und Sie bash benutzen, versuchen Sie, statt dessen csh oder sh zu benutzen. Einige BSDI-Benutzer haben Probleme mit bash und ulimit berichtet.

3.6.4.9 Anmerkungen zu BSD/OS Version 4.x

BSDI-Version 4.x hat einige auf Threads bezogene Bugs. Wenn Sie auf dieser Plattform MySQL benutzen wollen, sollten Sie alle Patches installieren, die sich auf Threads beziehen. Zumindest M400-023 sollte installiert sein.

Auf einigen Systemen mit BSDI-Version 4.x bekommen Sie vielleicht Probleme mit gemeinsam verwendeten (shared) Bibliotheken. Das äußert sich darin, dass Sie keinerlei Client-Programme wie mysqladmin ausführen können. In diesem Fall müssen Sie MySQL so rekonfigurieren, dass keine gemeinsam genutzten Bibliotheken benutzt werden, indem Sie die --disable-shared-Option für configure benutzen.

Einige Kunden hatten auf BSDI 4.0.1 Probleme damit, dass die mysqld-Binärdatei nach einiger Zeit keine Tabellen mehr öffnen konnte. Das liegt an einigen Bugs, die sich auf Bibliothek / System beziehen, und die mysqld veranlassen, das aktuelle Verzeichnis zu wechseln, ohne danach gefragt zu haben!

Die Lösung besteht darin, entweder auf 3.23.34 zu aktualisieren oder nach dem Laufenlassen von configure die Zeile #define HAVE_REALPATH aus config.h zu entfernen, bevor Sie make laufen lassen.

Beachten Sie, dass sich aus dem Gesagten ergibt, dass Sie auf BSDI keine symbolischen Links von Datenbankverzeichnissen zu einem anderen Datenbankverzeichnis oder symbolische Links von einer Tabelle zu einer anderen Datenbank herstellen können! (Ein symbolischer Link auf eine andere Platte ist okay.)

3.6.5 Anmerkungen zu Mac OS X

3.6.5.1 Mac OS X Public Beta

MySQL sollte ohne jedes Problem auf Mac OS X Public Beta (Darwin) laufen. Die pThread-Patches für dieses Betriebssystem benötigen Sie nicht!

3.6.5.2 Mac OS X Server

Bevor Sie versuchen, MySQL auf Mac OS X Server zu konfigurieren, müssen Sie das pThread-Paket von http://www.prnet.de/RegEx/mysql.html installieren.

Unsere Binärdatei für Mac OS X wird kompiliert auf Rhapsody 5.5, mit folgender Konfigurationszeile:

Wenn Sie der Ressourcen-Datei Ihrer Shell Aliase hinzufügen wollen, um auf mysql und mysqladmin von der Kommandozeile aus zuzugreifen, geben Sie ein:

3.6.6 Anmerkungen zu anderen Unixen

3.6.6.1 Anmerkungen zu HP-UX Notes für Binärdistributionen

Einige Binärdistributionen von MySQL für HP-UX werden als HP-Depot-Datei und als Tar-Datei ausgeliefert. Um die Depot-Datei benutzen zu können, müssen Sie mindestens HP-UX 10.x haben, um auf HP's Software-Depot-Werkzeuge zugreifen zu können.

Die HP-Version von MySQL wurde auf einem HP 9000/8xx-Server unter HP-UX 10.20 kompiliert und benutzt MIT-pThreads. Unter dieser Konfiguration arbeitet sie bekanntermaßen gut. MySQL-Version 3.22.26 und neuer kann auch mit HP's nativem Thread-Paket gebaut werden.

Weitere Konfigurationen, die ebenfalls funktionieren können:

• HP 9000/7xx mit HP-UX 10.20+
• HP 9000/8xx mit HP-UX 10.30

Folgende Konfigurationen werden fast mit Sicherheit nicht laufen:

• HP 9000/7xx oder 8xx mit HP-UX 10.x, wobei x < 2
• HP 9000/7xx oder 8xx mit HP-UX 9.x

Um die Distribution zu installieren, benutzen Sie die unten stehenden Befehle, wobei /pfad/zum/depot der volle Pfadname der Depot-Datei ist:

• Um alles inklusive Server, Client- und Entwicklungs-Werkzeuge zu installieren: shell> /usr/sbin/swinstall -s /pfad/zum/depot mysql.full
• Um nur den Server zu installieren: shell> /usr/sbin/swinstall -s /pfad/zum/depot mysql.server
• Um nur das Client-Paket zu installieren: shell> /usr/sbin/swinstall -s /pfad/zum/depot mysql.client
• Um nur die Entwicklungs-Werkzeuge zu installieren: shell> /usr/sbin/swinstall -s /pfad/zum/depot mysql.developer

Das Depot speichert Binärdateien und Bibliotheken in `/opt/mysql' und Daten in `/var/opt/mysql'. Es legt auch die entsprechenden Einträge in `/etc/init.d' und `/etc/rc2.d' an, um den Server automatisch beim Hochfahren zu starten. Das setzt root-Rechte zum Installieren voraus.

Um die HP-UX-tar.gz-Distribution zu installieren, müssen Sie GNU tar haben.

3.6.6.2 Anmerkungen zu HP-UX Version 10.20

Es gibt einige kleine Probleme, wenn Sie MySQL auf HP-UX kompilieren. Wir empfehlen, anstelle des nativen HP-UX-Kompilers gcc zu benutzen, weil gcc besseren Code produziert!

Wir empfehlen die Benutzung von gcc 2.95 auf HP-UX. Benutzen Sie keine hohen Optimierungs-Flags (wie -O6), weil das eventuell für HP-UX nicht sicher ist.

Beachten Sie, dass MIT-pThreads nicht mit dem HP-UX-Kompiler kompiliert werden können, weil dieser keine .S-(Assembler)-Dateien kompilieren kann.

Folgende Konfigurationszeile sollte funktionieren:

Wenn Sie gcc 2.95 selbst kompilieren, sollten Sie ihn NICHT mit den DCE-Bibliotheken (libdce.a oder libcma.a) linken, wenn Sie MySQL mit MIT-pThreads kompilieren wollen. Wenn Sie DCE- und MIT-pThreads-Pakete mischen, erhalten Sie einen mysqld, mit dem Sie sich nicht verbinden können. Entfernen Sie die DCE-Bibliotheken, während Sie gcc 2.95 kompilieren!

3.6.6.3 Anmerkungen zu HP-UX Version 11.x

Für HP-UX Version 11.x empfehlen wir MySQL-Version 3.23.15 oder später.

Wegen einiger kritischer Bugs in den Standard-HP-UX-Bibliotheken sollten Sie folgende Patches installieren, bevor Sie MySQL auf HP-UX 11.0 laufen lassen:

Das löst das Problem, dass man EWOULDBLOCK von recv() und EBADF von accept() in threaded Applikationen erhält.

Wenn Sie gcc 2.95.1 auf einem nicht-gepatchten HP-UX-11.x-System benutzen, erhalten Sie den Fehler:

Das Problem liegt darin, dass HP-UX pThreads_atfork() nicht konsistent definiert. Es hat konfliktbehaftete Prototypes in `/usr/include/sys/unistd.h':184 und `/usr/include/sys/pThread.h':440 (Details weiter unten).

Eine Lösung besteht darin, `/usr/include/sys/unistd.h' nach `mysql/include' zu kopieren und `unistd.h' zu editieren, wobei es so abgeändert wird, dass es der Definition in `pThread.h' entspricht. Hier ist der Diff:

Danach sollte folgende Konfigurationszeile funktionieren:

Hier sind ein paar Informationen über das Kompilieren von MySQL mit dem HP-UX:x-Kompiler, die uns ein Benutzer der HP-UX-Version 11.x geschickt hat:

• Ich muss den Compile-Time-Flag -D_REENTRANT benutzen, um den Kompiler dazu zu bringen, den Prototype für localtime_r zu erkennen. Alternativ hätte ich auch den Prototype für localtime_r bereit stellen können. Aber ich wollte weitere Bugs abfangen, in die ich sonst gerannt wäre. Ich war nicht sicher, wo ich es benötigen würde, daher fügte ich es zu allen Flags hinzu.
• Die Optimierungs-Flags, die MySQL benutzt (-O3), werden von den HP-Kompilern nicht erkannt. Ich habe die Flags nicht geändert.

Wenn Sie folgenden Fehler von configure erhalten:

Überprüfen Sie, dass Sie den Pfad zum K&R-Kompiler nicht vor dem Pfad zum HP-UX-C- und C++-Kompiler haben.

3.6.6.4 Anmerkungen zu IBM-AIX

Automatische Erkennung von xlC fehlt bei Autoconf, daher wird ein configure-Befehl wie folgender benötigt, wenn Sie MySQL kompilieren (dieses Beispiel benutzt den IBM-Kompiler):

Das sind die Optionen, die benutzt werden, um die MySQL-Distribution zu kompilieren, die sich auf http://www-frec.bull.com/ befindet.

Wenn Sie in obiger Konfigurationszeile -O3 zu -O2 ändern, müssen Sie auch die -qstrict-Option entfernen (das ist eine Beschränkung im IBM-C-Kompiler).

Wenn Sie gcc oder egcs benutzen, um MySQL zu kompilieren, MÜSSEN Sie den -fno-exceptions-Flag benutzen, weil das Exception-Handling in gcc / egcs nicht Thread-sicher ist! (Das wurde mit egcs 1.1. getestet.) Es gibt auch ein paar bekannte Probleme mit dem IBM-Assembler, die dazu führen können, dass schlechter Code erzeugt wird, wenn er zusammen mit gcc benutzt wird.

Wir empfehlen folgende configure-Zeile für egcs und gcc 2.95 auf AIX:

-Wa,-many ist notwendig, damit das Kompilieren gelingt. Das Problem ist IBM bekannt, hat es aber nicht eilig, es zu beheben, weil ein Workaround verfügbar ist. Wir wissen nicht, ob -fno-exceptions für gcc 2.95 erforderlich ist, aber weil MySQL keine Exceptions benutzt und die obige Option schnelleren Code erzeugt, empfehlen wir, dass Sie diese Option für egcs / gcc immer benutzen.

Wenn Sie ein Problem mit Assembler-Code bekommen, versuchen Sie, -mcpu=xxx so anzupassen, dass es zu Ihrem Prozessor passt. Typischerweise wird man power2, power oder powerpc benutzen, alternativ kann man eventuell 604 oder 604e benutzen. Ich bin nicht ganz sicher, aber ich würde sagen, dass "power" meist sicher sein sollte, selbst auf einer power2-Maschine.

Wenn Sie nicht wissen, welchen Prozessor Sie haben, geben Sie "uname -m" ein. Das gibt eine Zeichenkette zurück, die etwa wie "000514676700" aussieht, mit dem Format xxyyyyyymmss, wobei xx und ss immer die Nullen sind (0). yyyyyy ist eine eindeutige System-ID und mm ist die ID des CPU-Planars. Eine Tabelle dieser Werte liegt auf http://www.rs6000.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds5/uname.htm. Darin finden Sie Maschinentyp und Maschinenmodell, was Sie benutzen können, um herauszufinden, welchen Prozessortyp Sie haben.

Wenn Sie Probleme mit Signalen haben (MySQL stirbt unerwartet unter hoher Last), haben Sie vielleicht einen Betriebssystem-Bug bei Threads und Signalen gefunden. In diesem Fall können Sie MySQL anweisen, keine Signale zu benutzen, indem Sie es wie folgt konfigurieren:

Das berührt nicht die Performance von MySQL, hat aber den Nebeneffekt, dass Sie keine Clients auf einer Verbindung mit mysqladmin kill oder mysqladmin shutdown killen können, die ``schlafen''. Statt dessen wird der Client sterben, wenn er den nächsten Befehl sendet.

Bei einigen Versionen von AIX für das Linken mit libbind.a bei getservbyname zu einem Speicherauszug (Core Dump). Das ist ein AIX-Bug, der IBM berichtet werden sollte.

Bei AIX 4.2.1 und gcc müssen Sie folgende Änderungen durchführen:

Nach dem Konfigurieren müssen Sie `config.h' und `include/my_config.h' editieren und die Zeile ändern, in der steht:

zu

Schließlich müssen Sie in `mysqld.cc' einen Prototype für initgoups hinzufügen:

3.6.6.5 Anmerkungen zu SunOS 4

Auf SunOS 4 werden MIT-pThreads benötigt, um MySQL zu kompilieren, was letztlich bedeutet, dass Sie GNU-make benötigen.

Einige SunOS-4-Systeme haben Probleme mit dynamischen Bibliotheken und libtool. Sie können folgende configure-Zeile benutzen, um das Problem zu vermeiden:

Wenn Sie readline kompilieren, erhalten Sie vielleicht Warnungen über duplizierte Defines. Diese können ignoriert werden.

Wenn Sie mysqld kompilieren, gibt es ein paar implicit declaration of function-Warnungen. Diese können ignoriert werden.

3.6.6.6 Anmerkungen zu Alpha-DEC-UNIX (Tru64)

Wenn Sie egcs 1.1.2 auf Digital Unix benutzen, sollten Sie auf gcc 2.95.2 aktualisieren, weil egcs auf DEC einige schwer wiegende Bugs hat!

Wenn Sie threaded Programme unter Digital Unix kompilieren, empfiehlt die Dokumentation, die -pThread-Option für cc und cxx und die Bibliotheken -lmach -lexc zu benutzen (zusätzlich zu -lpThread). Sie sollten configure wie folgt laufen lassen:

Wenn Sie mysqld kompilieren, sehen Sie eventuell eine Reihe von Warnungen wie die folgende:

Sie können diese Warnungen ignorieren. Sie treten auf, weil configure nur Fehler entdecken kann, keine Warnungen.

Wenn Sie den Server direkt von the Kommandozeile starten, haben Sie vielleicht Probleme, dass er stirbt, wenn Sie sich ausloggen. (Wenn Sie sich ausloggen, erhalten Ihre offenen Prozesse ein SIGHUP-Signal.) Wenn das der Fall ist, starten Sie den Server wie folgt:

nohup bewirkt, dass der folgende Befehl jegliche SIGHUP-Signale, die vom Terminal gesendet werden, ignoriert. Alternativ starten Sie den Server mit safe_mysqld, was mysqld mit nohup für Sie aufruft. See section 5.7.2 safe_mysqld, der Wrapper um mysqld.

Wenn Sie ein Problem beim Kompilieren von mysys/get_opt.c bekommen, entfernen Sie einfach die Zeile #define _NO_PROTO am Anfang dieser Datei!

Wenn Sie den CC-Kompiler von Compaq benutzen, sollte die folgende Konfigurationszeile funktionieren:

Wenn Sie ein Problem mit libtool beim Kompilieren mit gemeinsam genutzten (shared) Bibliotheken bekommen wie oben, wenn Sie mysql linken, sollten Sie dies folgendermaßen umgehen können:

3.6.6.7 Anmerkungen zu Alpha-DEC-OSF1

Wenn Sie Probleme beim Kompilieren haben und DEC CC und gcc installiert sind, versuchen Sie, configure wie folgt laufen zu lassen:

Wenn Sie Probleme mit der `c_asm.h'-Datei bekommen, können Sie wie folgt eine 'dummy'-`c_asm.h'-Datei erzeugen und benutzen:

Beachten Sie, dass die im Folgenden beschriebenen Probleme mit dem ld-Programm behoben werden können, indem Sie das neueste DEC-(Compaq)-Patch-Kit herunterladen, und zwar von folgender Seite: http://ftp.Support.compaq.com/public/unix/.

Auf OSF1 V4.0D und Kompiler "DEC C V5.6-071 auf Digital Unix V4.0 (Rev. 878)" zeigt der Kompiler einige seltsame Verhaltensweisen (undefinierte asm-Symbole). Ausserdem scheint /bin/ld beschädigt zu sein (Probleme mit _exit undefined-Fehlern, die auftreten, wenn Sie mysqld linken). Auf diesem System konnten wir MySQL mit folgender configure-Zeile kompilieren, nachdem wir /bin/ld mit der Version von OSF 4.0C ersetzt haben:

Beim Digital-Kompiler "C++ V6.1-029" sollte folgendes funktionieren:

In einigen Versionen von OSF1 ist die alloca()-Funktion beschädigt. Beheben Sie dies, indem Sie die Zeile in `config.h' entfernen, die 'HAVE_ALLOCA' definiert.

Die alloca()-Funktion kann ebenfalls einen falschen Prototyp in /usr/include/alloca.h haben. Die Warnung, die hieraus resultiert, kann ignoriert werden.

configure benutzt automatisch folgenden Thread-Bibliotheken: --with-named-thread-libs="-lpThread -lmach -lexc -lc".

Wenn Sie gcc benutzen, können Sie auch versuchen, configure wie folgt laufen zu lassen:

Wenn Sie Probleme mit Signalen haben (MySQL stirbt unerwartet unter Hochlast), haben Sie vielleicht einen Betriebssystem-Bug bei Threads und Signalen gefunden. In diesem Fall können Sie MySQL anweisen, keine Signale zu benutzen, indem Sie es wie folgt konfigurieren:

Das berührt nicht die Performance von MySQL, hat aber den Nebeneffekt, dass Sie keine Clients auf einer Verbindung mit mysqladmin kill oder mysqladmin shutdown killen können, die ``schlafen''. Statt dessen wird der Client sterben, wenn er den nächsten Befehl sendet.

Bei gcc 2.95.2 erhalten Sie wahrscheinlich folgenden Kompilierfehler:

Um das zu beheben, wechseln Sie ins sql-Verzeichnis und machen ein ``Kopieren und Einfügen'' der letzten gcc-Zeile, ändern aber -O3 zu -O0 (oder fügen -O0 unmittelbar nach gcc hinzu, falls Sie keine -O-Option auf Ihrer Kompilierzeile haben.) Danach wechseln Sie einfach direkt zurück in oberste Verzeichnis und lassen make noch einmal laufen.

3.6.6.8 Anmerkungen zu SGI Irix

Wenn Sie Irix-Version 6.5.3 oder neuer benutzen, kann mysqld nur dann Threads erzeugen, wenn Sie ihn als Benutzer mit CAP_SCHED_MGT-Zugriffsrechten (wie root) laufen lassen oder dem mysqld-Server dieses Recht mit dem folgenden Befehl geben:

Sie müssen eventuell in `config.h' einige Dinge umdefinieren, nachdem Sie configure laufen gelassen haben und vor dem Kompilieren.

In einigen Irix-Implementationen ist die alloca()-Funktion beschädigt. Wenn der mysqld-Server bei manchen SELECT-Statements stirbt, entfernen Sie die Zeilen aus `config.h', die HAVE_ALLOC und HAVE_ALLOCA_H definieren. Wenn mysqladmin create nicht funktioniert, entfernen Sie die Zeile aus `config.h', die HAVE_READDIR_R definiert. Eventuell müssen Sie auch die HAVE_TERM_H-Zeile entfernen.

SGI empfiehlt, dass Sie alle Patches auf dieser Seite auf einmal installieren: http://Support.sgi.com/surfzone/patches/patchset/6.2_indigo.rps.html

Als absolutes Minimum sollten Sie das letzte Kernel-Rollup installieren, das letzte rld-Rollup und das letzte libc-Rollup.

In jedem Fall brauchen Sie für die pThread-Unterstützung alle POSIX-Patches auf dieser Seite:

http://Support.sgi.com/surfzone/patches/patchset/6.2_posix.rps.html

Wenn Sie beim Kompilieren von `mysql.cc' etwa folgenden Fehler erhalten:

Geben Sie folgendes im obersten Verzeichnis Ihres MySQL-Source-Trees ein:

Es wurden ausserdem Scheduling-Probleme berichtet. Wenn nur ein Thread läuft, läuft alles recht langsam. Das können Sie vermeiden, indem Sie einen weiteren Client-Starten. Daraus kann sich eine zwei- bis zehnfache Geschwindigkeitssteigerung für den anderen Thread ergeben. Das liegt an einem Problem mit Irix-Threads, das kaum zu verstehen ist. Eventuell müssen Sie improvisieren, um eine Lösung zu finden, bis dies behoben ist.

Wenn Sie mit gcc kompilieren, können Sie folgenden configure-Befehl benutzen:

Auf Irix 6.5.11 mit nativen Irix-C- und C++-Kompilern der Version 7.3.1.2 soll auch folgendes funktionieren:

3.6.6.9 Anmerkungen zu Caldera

Die aktuelle Portierung wird auf ``sco3.2v5.0.4''- und-``sco3.2v5.0.5''-Systemen getestet. Die Portierung auf ``sco 3.2v4.2'' ist ebenfalls weit fortgeschritten.

Momentan ist der empfohlene Kompiler auf OpenServer gcc 2.95.2. Damit sollten Sie in der Lage sein, MySQL einfach durch folgendes zu kompilieren:

1. Bei OpenServer 5.0.X müssen Sie GDS in Skunkware 95 (95q4c) benutzen. Das ist deshalb notwendig, weil GNU-gcc 2.7.2 in Skunkware 97 kein GNU-as hat. Sie können auch egcs 1.1.2 oder neuer benutzen http://www.egcs.com/. Wenn Sie egcs 1.1.2 benutzen, müssen Sie folgenden Befehl eingeben: shell> cp -p /usr/include/pThread/stdtypes.h /usr/local/lib/gcc-lib/i386-pc-sco3.2v5.0.5/egcs-2.91.66/include/pThread/
2. Sie brauchen die Portierung von GCC 2.5.x für dieses Produkt und das Entwicklungssystem. Sie werden auf dieser Version von Caldera (SCO) Unix benötigt. Sie können nicht lediglich das GCC-Dev-System benutzen.
3. Sie sollten zuerst das FSU-PThreads-Paket holen und installieren. Dieses finden Sie auf http://www.cs.wustl.edu/~schmidt/ACE_wrappers/FSU-threads.tar.gz. Sie finden ein vorkompiliertes Paket auf http://www.mysql.com/Downloads/SCO/FSU-threads-3.5c.tar.gz.
4. FSU-PThreads kann mit SCO Unix 4.2 mit TCP/IP kompiliert werden. Oder mit OpenServer 3.0 oder Open Desktop 3.0 (OS 3.0 ODT 3.0), mit installiertem Caldera (SCO) Entwicklungssystem unter Benutzung einer guten Portierung von GCC 2.5.x ODT oder OS 3.0. Hierbei brauchen Sie eine gute Portierung von GCC 2.5.x. Ohne gute Portierung gibt es eine Menge Probleme. Die Portierung für dieses Produkt erfordert das Caldera (SCO) Unix-Entwicklungssystem. Ohne dieses fehlen die Bibliotheken und der Linker, die benötigt werden.
5. Um FSU-PThreads auf Ihrem System zu bauen, tun Sie folgendes:
   1. Lassen Sie ./configure im `Threads/src'-Verzeichnis laufen und wählen Sie die SCO-OpenServer-Option. Dieser Befehl kopiert `Makefile.SCO5' nach `Makefile'.
   2. Lassen Sie make laufen.
   3. Um in das vorgabemäßige `/usr/include'-Verzeichnis zu installieren, loggen Sie sich als Root ein und wechseln (cd) Sie in das `thread/src'-Verzeichnis. Führen Sie dann make install aus.
6. Denken Sie daran, GNU make zu benutzen, wenn Sie MySQL machen.
7. Wenn Sie safe_mysqld nicht als Root starten, erhalten Sie wahrscheinlich nur die 110 offenen Dateien pro Prozess. mysqld macht darüber in der Log-Datei einen Eintrag.
8. Bei SCO 3.2V5.0.5 sollten Sie FSU-PThreads-Version 3.5c oder neuer benutzen. Ausserdem sollten Sie gcc 2.95.2 oder neuer benutzen! Folgender configure-Befehl sollte funktionieren: shell> ./configure --prefix=/usr/local/mysql --disable-shared
9. Bei SCO 3.2V4.2 sollten Sie FSU-PThreads-Version 3.5c oder neuer benutzen. Folgender configure-Befehl sollte funktionieren: shell> CFLAGS="-D_XOPEN_XPG4" CXX=gcc CXXFLAGS="-D_XOPEN_XPG4" \ ./configure \ --prefix=/usr/local/mysql \ --with-named-thread-libs="-lgThreads -lsocket -lgen -lgThreads" \ --with-named-curses-libs="-lcurses" Möglicherweise bekommen Sie Probleme mit einigen Include-Dateien. In diesem Fall finden Sie neue, SCO-spezifische Include-Dateien auf http://www.mysql.com/Downloads/SCO/SCO-3.2v4.2-includes.tar.gz. Entpacken Sie diese Datei ins `include'-Verzeichnis Ihres MySQL-Source-Trees.

Anmerkungen zur Caldera (SCO) Entwicklung:

• MySQL kann FSU-PThreads automatisch erkennen und mysqld mit -lgThreads -lsocket -lgThreads linken.
• Die Caldera (SCO) Entwicklungsbibliotheken sind re-entrant in FSU-PThreads. Caldera behauptet, dass seine Bibliotheken-Funktionen re-entrant sind, daher müssen sie mit FSU-PThreads re-entrant sein. FSU-PThreads auf OpenServer versucht, das SCO-Scheme zu benutzen, um Bibliotheken re-entrant zu machen.
• FSU-PThreads (zumindest die Version auf http://www.mysql.com/) wird mit gelinktem GNU-malloc ausgeliefert. Wenn Sie Problemen mit der Speicherbenutzung begegnen, stellen Sie sicher, dass `gmalloc.o' in `libgThreads.a' und `libgThreads.so' beinhaltet ist.
• In FSU-PThreads achten folgende Systemaufrufe auf pThreads: read(), write(), getmsg(), connect(), accept(), select() und wait().

Wenn Sie DBI auf Caldera (SCO) installieren wollen, müssen Sie `Makefile' in DBI-xxx und jedem Unterverzeichnis editieren.

Beachten Sie, dass folgendes gcc 2.95.2 oder neuer voraussetzt:

Das liegt daran, dass der Perl-dynaloader keine DBI-Module lädt, die mit icc oder cc kompiliert wurden.

Perl funktioniert am besten, wenn es mit cc kompiliert wird.

3.6.6.10 Anmerkungen zu Caldera Unixware Version 7.0

Sie benötigen mindestens MySQL-Version 3.22.13, weil diese Version einige Portabilitätsprobleme unter Unixware behebt.

Wir waren in der Lage, MySQL mit folgendem configure-Befehl auf Unixware Version 7.0.1 zu kompilieren:

Wenn Sie gcc benutzen wollen, müssen Sie gcc 2.95.2 oder neuer benutzen.

3.6.7 Anmerkungen zu OS/2

MySQL benutzt eine ganze Menge offener Dateien. Deswegen sollten Sie Ihrer `CONFIG.SYS'-Datei folgendes hinzufügen:

Wenn Sie das nicht tun, erhalten Sie wahrscheinlich folgenden Fehler:

Wenn Sie MySQL auf OS/2 Warp 3 einsetzen, wird FixPack 29 oder höher benötigt. Bei OS/2 Warp 4 wird FixPack 4 oder höher benötigt. Das erfordert die PThreads-Bibliothek. MySQL muss auf einer Partition installiert werden, die lange Dateinamen unterstützt, also zum Beispiel HPFS, FAT32 usw.

Das `INSTALL.CMD'-Skript muss von OS/2's eigener `CMD.EXE' aus laufen gelassen werden und funktioniert eventuell nicht mit Ersatz-Shells wie `4OS2.EXE'.

Das `scripts/mysql-install-db'-Skript wurde umbenannt. Es heißt jetzt `install.cmd' und ist ein REXX-Skript, welches die vorgabemäßigen MySQL-Sicherheitseinstellungen einstellt und die WorkPlace-Shell-Icons für MySQL erstellt.

Unterstützung für dynamische Module wird einkompiliert, ist aber noch nicht komplett durchgetestet. Dynamische Module sollten unter Benutzung der PThreads-Runtime-Bibliothek kompiliert werden.

Beachten Sie: Aufgrund von Beschränkungen in OS/2 dürfen UDF-module-name-stems nicht länger als 8 Zeichen sein. Module werden im `/mysql2/udf'-Verzeichnis gespeichert; das safe-mysqld.cmd-Skript trägt dieses Verzeichnis in die BEGINLIBPATH-Umgebungsvariable ein. Wenn Sie UDF-Module benutzen, werden festgelegte Erweiterungen ignoriert - es wird nicht angenommen, dass sie `.udf' sind. Unter Unix zum Beispiel könnte das gemeinsam genutzte (shared) Module `example.so' benannt sein. Sie würden daraus eine Funktion wie folgt laden:

Unter OS/2 würde das Modul `example.udf' heißen, aber Sie würden nicht die Modul-Erweiterung angeben:

3.6.8 Anmerkungen zu BeOS

Wir sind sehr daran interessiert, MySQL auf BeOS ans Laufen zu bringen, aber leider kennen wir niemanden, der sich mit BeOS auskennt oder Zeit hat, eine Portierung durchzuführen.

Wir sind daran interessiert, jemanden für eine Portierung zu finden, und wir werden ihn / sie bei allen technischen Fragen helfen, die bei einer Portierung auftreten können.

Wir haben vor einiger Zeit mit einigen BeOS-Entwicklern gesprochen, die uns sagten, dass MySQL zu 80% auf BeOS portiert ist, aber wir haben schon eine Weile nichts von ihnen gehört.

3.6.9 Anmerkungen zu Novell NetWare

Wir sind sehr daran interessiert, MySQL auf NetWare ans Laufen zu bringen, aber leider kennen wir niemanden, der sich mit NetWare auskennt oder Zeit hat, eine Portierung durchzuführen.

Wir sind daran interessiert, jemanden für eine Portierung zu finden, und wir werden ihn / sie bei allen technischen Fragen helfen, die bei einer Portierung auftreten können.

3.7 Anmerkungen zur Perl-Installation

DBI/DBD-Schnittstelle

3.7.1 Installation von Perl unter Unix

Perl-Unterstützung für MySQL wird durch die DBI/DBD- Client-Schnittstelle zur Verfügung gestellt. See section 9.2 MySQL-Perl-API. Der Perl- DBD/DBI-Client-Code erfordert Perl Version 5.004 oder später. Die Schnittstelle funktioniert nicht, wenn Sie eine ältere Version von Perl haben.

MySQL-Perl-Unterstützung erfordert ausserdem, dass Sie MySQL-Client- Programmierunterstützung installiert haben. Wenn Sie MySQL von RPM- Dateien installiert haben, sind Client-Programme im Client-RPM enthalten, aber Client-Programmierunterstützung ist im Entwickler-RPM. Stellen Sie sicher, dass Sie auch das letztgenannte RPM installiert haben.

Ab Version 3.22.8 wird Perl-Unterstützung getrennt von der Haupt-MySQL- Unterstützung ausgeliefert. Wenn Sie Perl-Unterstützung installieren wollen, können Sie die benötigten Dateien von http://www.mysql.com/downloads/api-dbi.html herunter laden.

Die Perl-Distributionen werden als komprimierte tar-Archive zur Verfügung gestellt und haben Namen wie `MODULE-VERSION.tar.gz', wobei MODULE der Modulname und VERSION die Versionsnummer ist. Sie sollten die Data-Dumper-, DBI- und Msql- Mysql-modules-Distributionen laden und sie in dieser Reihenfolge installieren. Die Installationsprozedur ist unten dargestellt. Das Beispiel gilt für das Data-Dumper-Modul, ist aber für alle drei Distributionen dieselbe:

1. Entpacken Sie die Distribution ins aktuelle Verzeichnis. shell> gunzip < Data-Dumper-VERSION.tar.gz | tar xvf - Dieser Befehl erzeugt ein Verzeichnis namens `Data-Dumper- VERSION'.
2. Wechseln Sie ins oberste Verzeichnis der entpackten Distribution: shell> cd Data-Dumper-VERSION
3. Bauen Sie die Distribution und kompilieren Sie alles: shell> perl Makefile.PL shell> make shell> make test shell> make install

Der make test-Befehl ist wichtig, weil er sicherstellt, dass die Module funktionieren. Beachten Sie, dass der MySQL-Server während der Befehlsausführung bei der Msql-Mysql-modules-Installation laufen muss, um den Schnittstellen-Code auszuführen, den ansonsten schlägt der Test fehl.

Es ist eine gute Idee, die Msql-Mysql-modules-Distribution neu zu kompilieren und zu installieren, wenn Sie ein neues Release von MySQL installieren, insbesondere, wenn Sie Symptome feststellen wie dass alle Ihre DBI-Skripte einen Coredump liefern, nachdem Sie auf eine höhere Version von MySQL aktualisiert haben.

Wenn Sie keine Rechte haben, die Perl-Module im Systemverzeichnis zu installieren, oder wenn Sie lokale Perl-Module installieren wollen, könnte Ihnen der folgende Link helfen:

Suchen Sie nach der Überschrift Installing New Modules that Require Locally Installed Modules.

3.7.2 Installation von ActiveState-Perl unter Windows

Um das MySQL-DBD-Modul mit ActiveState-Perl unter Windows zu installieren, gehen Sie wie folgt vor:

• Laden Sie ActiveState-Perl von http://www.activestate.com/Products/ActivePerl/ und installieren Sie es.
• Öffnen Sie eine MS-DOS-Eingabeaufforderung.
• Setzen Sie - falls erforderlich - die HTTP_proxy-Variable, zum Beispiel wie folgt: set HTTP_proxy=my.proxy.com:3128
• Starten Sie das PPM-Programm: C:\> c:\perl\bin\ppm.pl
• Falls noch nicht geschehen, installieren Sie DBI: ppm> install DBI
• Wenn das erfolgreich verlief, führen Sie folgenden Befehl aus: install ftp://ftp.de.uu.net/pub/CPAN/authors/id/JWIED/DBD-mysql-1.2212.x86.ppd

Das sollte zumindest bei ActiveState-Perl Version 5.6 funktionieren.

Wenn Sie es nicht schaffen, dass oben Genanntes funktioniert, sollten Sie statt dessen den MyODBC-Treiber installieren und sich mit dem MySQL-Server über ODBC verbinden:

3.7.3 Installation der MySQL-Perl-Distribution unter Windows

Die MySQL-Perl-Distribution enthält DBI, DBD:MySQL und DBD:ODBC.

• Laden Sie die Perl-Distribution für Windows von http://www.mysql.com/download.html.
• Entpacken Sie die Distribution in C:, so dass Sie ein `C:\PERL'-Verzeichnis erhalten.
• Fügen Sie Ihrem Pfad `C:\PERL\BIN' hinzu.
• Fügen Sie Ihrem Pfad das Verzeichnis `C:\PERL\BIN\MSWIN32-x86- thread' oder `C:\PERL\BIN\MSWIN32-x86' hinzu.
• Testen Sie, ob perl funktioniert, indem Sie perl -v in einer MS-DOS-Eingabeaufforderung ausführen.

3.7.4 Probleme bei der Benutzung von Perl DBI/DBD-Schnittstelle

Wenn Perl ausgibt, dass es das `../mysql/mysql.so'-Modul nicht finden kann, liegt das Problem wahrscheinlich darin, dass Perl die gemeinsam genutzte `libmysqlclient.so' nicht findet.

Das können Sie mit einer der folgenden Methoden beheben:

• Kompilieren Sie die Msql-Mysql-modules-Distribution mit perl Makefile.PL -static -config statt mit perl Makefile.PL.
• Kopieren Sie libmysqlclient.so in das Verzeichnis, in dem Ihre anderen gemeinsam genutzten Bibliotheken liegen (wahrscheinlich `/usr/lib' oder `/lib').
• Unter Linux können Sie der `/etc/ld.so.conf'-Datei den Pfadnamen des Verzeichnisses hinzufügen, in dem `libmysqlclient.so' liegt.
• Fügen Sie der LD_RUN_PATH-Umgebungsvariablen den Pfadnamen des Verzeichnisses hinzu, in dem `libmysqlclient.so' liegt.

Wenn Sie folgende Fehler von DBD-mysql erhalten, benutzen Sie wahrscheinlich gcc (oder eine alte Binärdatei, die mit gcc kompiliert wurde):

Fügen Sie -L/usr/lib/gcc-lib/... -lgcc zum Link-Befehl hinzu, wenn die `mysql.so'-Bibliothek gebaut wird (überprüfen Sie die Ausgabe von make nach `mysql.so', wenn Sie den Perl-Client kompilieren). Die -L-Option sollte den Pfadnamen des Verzeichnisses angeben, in dem `libgcc.a' auf Ihrem System liegt.

Ein weiterer Grund für dieses Problem kann sein, dass Perl und MySQL nicht beide mit gcc kompiliert wurden. In diesem Fall können Sie die fehlende Übereinstimmung (Mismatch) durch Kompilieren von beiden mit gcc aufheben.

Wenn Sie folgende Fehler von Msql-Mysql-modules erhalten, wenn Sie die Tests laufen lassen:

Bedeutet das, dass Sie die Kompressionsbibliothek (-lz) in die Link- Zeile einschließen müssen. Das kann man durch folgende Änderung in der Datei `lib/DBD/mysql/Install.pm' tun:

Danach müssen Sie 'make realclean' laufen lassen und danach mit der Installation von Anfang an beginnen.

Wenn Sie das Perl-Modul auf einem System laufen lassen wollen, das dynamisches Linken nicht unterstützt (wie Caldera/SCO), können Sie eine statische Version von Perl erzeugen, die DBI und DBD-mysql enthält. Das bringt man zum Laufen, indem man eine Version von Perl erzeugt, in der der DBI-Code eingelinkt ist, und diese über das aktuelle Perls installiert. Dann benutzen Sie diese, um eine Version von Perl zu bauen, die zusätzlich den DBD-Code eingelinkt hat, und installieren diese.

Unter Caldera (SCO) müssen folgende Umgebungsvariablen gesetzt sein:

Erzeugen Sie zuerst ein Perl, das ein statisch gelinktes DBI enthält, indem Sie diese Befehle im Verzeichnis ausführen, in dem Ihre DBI-Distribution liegt:

Dann müssen Sie das neue Perl installieren. Die Ausgabe von make perl zeigt den genauen make-Befehl an, den Sie für die Installation ausführen müssen. Unter Caldera (SCO) ist das make -f Makefile.aperl inst_perl MAP_TARGET=perl.

Benutzen Sie als nächstes dieses soeben erzeugte Perl, um ein weiteres Perl zu erzeugen, dass auch ein statisch gelinktes DBD::mysql enthält, indem Sie diese Befehle im Verzeichnis ausführen, in dem Ihre Msql-Mysql-modules-Distribution liegt:

Zum Schluss müssen Sie dieses neue Perl installieren. Hierbei zeigt die Ausgabe von make perl wiederum, welcher Befehl benutzt werden muss.

Go to the first, previous, next, last section, table of contents.