Die erste zu treffende Entscheidung ist die, ob Sie einen (stabilen) Produktions-Release oder aber einen Entwicklungs-Release verwenden wollen. Im MySQL-Entwicklungsprozess koexistieren mehrere Release-Serien miteinander, die sich alle durch ihren Grad der Ausgereiftheit voneinander unterscheiden:

Wir halten ein endgültiges Einfrieren von Codes nicht für machbar, da dies Bugfixes und andere Fehlerbereinigungen, die erforderlich sind, unmöglich machen würde. Das von uns bevorzugte „Teileinfrieren“ erlaubt uns das Ergänzen von Kleinigkeiten, die sich nicht auf die Einsatzfähigkeit eines Produktions-Releases auswirken sollten. Natürlich pflanzen sich wesentliche Bugfixes in früheren Serien auch auf ihre jeweiligen Nachfolger fort.

Wenn Sie MySQL zum ersten Mal verwenden oder es auf ein System portieren wollen, für das keine binäre Distribution verfügbar ist, empfehlen wir Ihnen normalerweise, die Produktions-Release-Serie zu verwenden. Derzeit ist dies MySQL 5.0. Alle MySQL-Releases – auch die der Entwicklungsserie – werden vor der Veröffentlichung mit den MySQL-Benchmarks und der umfangreichen Testsuite überprüft.

Wenn Sie ein älteres System verwenden und ein Upgrade durchzuführen beabsichtigen, gleichzeitig aber verhindern wollen, dass es während der Aktualisierung zu Problemen kommt, dann sollten Sie auf die aktuelle Version derselben Release-Serie aktualisieren, die Sie bereits verwenden (hierbei ist nur der letzte Teil der Versionsnummer höher als bei der von Ihnen verwendeten Version). Wir haben lediglich versucht, kritische Bugs zu beheben und kleine, relativ „sichere“ Änderungen an dieser Version vorzunehmen.

Wenn Sie neue Funktionen verwenden wollen, die nicht in der Produktions-Release-Serie vorhanden sind, können Sie sich auch für eine Version aus der Entwicklungsserie entscheiden. Beachten Sie, dass die Entwicklungs-Releases nicht so stabil sind wie die Produktions-Releases.

Wollen Sie die allerneuesten Quellcodes mit allen aktuellen Patches und Bugfixes einsetzen, dann können Sie eines unserer BitKeeper-Repositorys verwenden. Dies sind nicht „Releases“ im eigentlichen Sinne, sondern Vorabversionen des Codes, auf dem zukünftige Releases basieren werden.

Das MySQL-Benennungsschema verwendet Release-Namen, die aus drei Zahlen und einem Suffix bestehen. Dies kann etwa so aussehen: mysql-5.0.12-beta. Die Zahlen im Release-Namen sind wie folgt zu interpretieren:

Bei kleineren Updates wird jeweils die letzte Zahl im Versions-String hochgezählt. Liegen wesentliche Neuerungen bei den Merkmalen oder kleinere Inkompatibilitäten mit vorherigen Versionen vor, dann wird die zweite Zahl im Versions-String hochgezählt. Ändert sich schließlich das Dateiformat, dann wird die erste Zahl erhöht.

Release-Namen enthalten auch ein Suffix, welches die Stabilitätsstufe für den Release angibt. Releases innerhalb einer Serie durchschritten eine bestimmte Abfolge von Suffixen, die jeweils anzeigen, wie sich die Stabilität erhöht. Mögliche Suffixe sind die folgenden:

MySQL verwendet ein Benennungsschema, welches sich geringfügig von dem anderer Produkte unterscheidet. In der Regel können Sie problemlos jede Version einsetzen, die bereits seit ein paar Wochen verfügbar ist, ohne durch eine neue Version innerhalb derselben Release-Serie ersetzt worden zu sein.

Alle MySQL-Releases werden mit unseren Standardtests und Benchmarks überprüft, damit gewährleistet ist, dass ihr Einsatz relativ sicher ist. Da die Standardtests im Laufe der Zeit so erweitert werden, dass alle zuvor gefundenen Bugs berücksichtigt werden, wird unsere Testsuite immer besser.

Alle Releases wurden zumindest mit den folgenden Tools getestet:

Wir testen außerdem die neueste MySQL-Version immer auf zumindest einem System in unserer internen Produktionsumgebung. Dabei stehen uns mehr als 100 Gbyte Daten zum Arbeiten zur Verfügung.

Nachdem Sie die zu installierende MySQL-Version gewählt haben, müssen Sie noch festlegen, ob eine binäre oder eine Quelldistribution für die Installation verwendet werden soll. In den meisten Fällen werden Sie sich wahrscheinlich für die Binärdistribution entscheiden, sofern es für Ihre Plattform eine solche gibt. Binärdistributionen sind für viele Plattformen im nativen Format verfügbar, z. B. RPM-Dateien für Linux oder DMG-Pakete für Mac OS X. Distributionen sind außerdem als ZIP-Archive oder komprimierte tar-Dateien erhältlich.

Die folgenden Gründe sprechen für die Verwendung einer Binärdistribution:

Unter bestimmten Umständen kann es auch von Vorteil sein, MySQL aus einer Quelldistribution heraus zu installieren:

MySQL entwickelt sich ziemlich schnell, und neue Entwicklungen wollen wir anderen MySQL-Benutzern möglichst umgehend bereitstellen. Deswegen erstellen wir immer dann einen neuen Release, wenn wir neue und nützliche Funktionen integriert haben, die auch für andere Benutzer nützlich oder notwendig sein könnten.

Außerdem versuchen wir Benutzern zu helfen, die nach Funktionen fragen, welche leicht zu implementieren sind. Wir achten darauf, was unsere lizenzierten Benutzer – und insbesondere die Kunden unseres Supports – wollen, und versuchen ihnen in dieser Hinsicht zu helfen.

Niemand ist gezwungen, einen neuen Release herunterzuladen. Der Abschnitt „News“ soll Ihnen dabei helfen zu ermitteln, ob im neuen Release etwas dabei ist, was Sie wirklich brauchen. Siehe auch Anhang D, MySQL-Änderungsverlauf (Change History).

Bei der Aktualisierung von MySQL halten wir uns an die folgenden Richtlinien:

Wir verwenden viel Zeit und Mühe darauf, unsere Releases fehlerfrei zu machen. Bislang haben wir nicht eine einzige MySQL-Version veröffentlicht, die einen bekannten nachvollziehbaren schweren Bug aufwies (ein „schwerer“ Bug ist ein Umstand, der dazu führt, dass MySQL bei normaler Verwendung abstürzt, falsche Antworten für normale Abfragen erzeugt oder ein Sicherheitsproblem aufweist).

Wir haben alle offenen Probleme, Bugs und Streitfragen dokumentiert, die von strukturellen Entscheidungen abhängen. Siehe auch Abschnitt A.8, „Bekannte Fehler und konzeptionelle Unzulänglichkeiten in MySQL“.

Unser Ziel ist es, alle Bugs zu beheben, die behebbar sind, ohne eine stabile MySQL-Version weniger stabil machen zu müssen. In bestimmten Fällen bedeutet dies, dass wir ein Problem in den Entwicklungsversionen, nicht aber in der stabilen Produktionsversion beheben können. Natürlich dokumentieren wir solche Probleme, damit sie den Benutzern bekannt sind.

Es folgt eine Beschreibung unserer Vorgehensweise:

Eine der Dienstleistungen von MySQL AB besteht in der Bereitstellung von MySQL-Binärdistributionen, die entweder auf unseren eigenen Systemen oder aber auf Systemen kompiliert wurden, bei denen uns Unterstützer von MySQL freundlicherweise Zugang zu ihren Computern gewährt haben.

Neben den Binärdateien in den plattformspezifischen Paketformaten bieten wir für eine Anzahl von Plattformen auch Binärdistributionen in Form komprimierter tar-Dateien (.tar.gz-Dateien) an. Siehe auch Abschnitt 2.2, „Schnelle Standardinstallation von MySQL“.

Die RPM-Distributionen für MySQL 5.1-Releases, die wir über die Website bereitstellen, werden von MySQL AB angefertigt.

Informationen zu Windows-Distributionen finden Sie in Abschnitt 2.3, „Installation von MySQL unter Windows“.

Diese Distributionen werden mithilfe des Skripts Build-tools/Do-compile erzeugt, das den Quellcode kompiliert und das Binärarchiv tar.gz mithilfe von scripts/make_binary_distribution erstellt.

Diese Binärdateien werden mit den folgenden Compilern und Optionen konfiguriert und erstellt. Diese Informationen können Sie auch abrufen, indem Sie die Variablen COMP_ENV_INFO und CONFIGURE_LINE im Skript bin/mysqlbug jeder tar-Binärdistributionsdatei abfragen.

Sollten Sie optimalere Optionen für einen der folgenden configure-Befehle haben, dann schicken Sie diese an die MySQL-Mailingliste internals. Siehe auch Abschnitt 1.7.1, „Die MySQL-Mailinglisten“.

Wollen Sie eine Debugversion von MySQL kompilieren, dann sollten Sie die Option--with-debug oder --with-debug=full zu den folgenden configure-Befehlen hinzufügen und ggf. vorhandene -fomit-frame-pointer-Optionen entfernen.

Die folgenden Binärdateien werden auf den Entwicklungssystemen von MySQL AB erstellt:

Die folgenden Binärdistributionen wurden auf Systemen von Dritten erstellt, die MySQL AB freundlicherweise von anderen Benutzern zur Verfügung gestellt wurden. Diese werden aus Gefälligkeit bereitgestellt; MySQL AB hat keine vollständige Kontrolle über diese Systeme, weswegen wir für Binärdistributionen, die auf ihnen erstellt wurden, nur eingeschränkten Support bieten können.

Die folgenden Kompilierungsoptionen wurden für Binärpakete verwendet, die MySQL AB in der Vergangenheit bereitgestellt hat. Diese Binärdistributionen werden nicht mehr aktualisiert. Die Kompilierungsoptionen werden zu Referenzzwecken an diese Stelle aufgelistet.

Wenn Sie ein MySQL-Paket heruntergeladen haben, sollten Sie sicherstellen, dass die zugehörige MD5-Prüfsumme mit der auf den MySQL-Downloadseiten angegebenen Prüfsumme übereinstimmt. Jedes Paket weist eine individuelle Prüfsumme auf, die Sie mithilfe des folgenden Befehls abfragen können (hierbei ist package_name der Name des heruntergeladenen Pakets):

shell> md5sum package_name

Beispiel:

shell> md5sum mysql-standard-5.1.5-alpha-linux-i686.tar.gz
aaab65abbec64d5e907dcd41b8699945  mysql-standard-5.1.5-alpha-linux-i686.tar.gz

Vergewissern Sie sich, dass die resultierende Prüfsumme (der angezeigte Hexadezimal-String) mit der Angabe übereinstimmt, die auf der Downloadseite unmittelbar unter dem betreffenden Paket angegeben ist.

Hinweis: Sie müssen die Prüfsumme der Archivdatei (d. h. der .zip- oder .tar.gz-Datei) verifizieren, nicht die Prüfsumme der Dateien, die im Archiv gespeichert sind.

Beachten Sie, dass nicht alle Betriebssysteme den Befehl md5sum unterstützen. Bei manchen heißt er einfach md5, bei anderen ist er überhaupt nicht enthalten. Bei Linux ist er Teil des Pakets GNU Text Utilities, das für eine Vielzahl von Plattformen verfügbar ist. Sie können den Quellcode auch unter http://www.gnu.org/software/textutils/ herunterladen. Wenn Sie OpenSSL installiert haben, können Sie stattdessen den Befehl openssl md5 package_name verwenden. Eine Windows-Implementierung des Befehls md5 ist unter http://www.fourmilab.ch/md5/ verfügbar. winMd5Sum ist ein grafisches MD5-Prüfwerkzeug, das Sie sich unter http://www.nullriver.com/index/products/winmd5sum beschaffen können.

Eine andere Methode zur Überprüfung der Integrität und Authentizität eines Pakets besteht in der Verwendung kryptografischer Signaturen. Diese sind zuverlässiger, aber arbeitsaufwändiger als MD5-Prüfsummen.

Wir von MySQL AB signieren MySQL-Pakete für den Download mit GnuPG (GNU Privacy Guard). GnuPG ist eine Open-Source-Alternative zum bekannten Pretty Good Privacy (PGP) von Phil Zimmermann. Weitere Informationen zu GnuPG sowie zu dessen Download und Installation auf Ihrem System finden Sie unter http://www.gnupg.org/. Die meisten Linux-Distributionen werden mit standardmäßig installiertem GnuPG ausgeliefert. Weitere Informationen zu GnuPG finden Sie unter http://www.openpgp.org/.

Um die Signatur für ein bestimmtes Paket zu überprüfen, müssen Sie sich zunächst eine Kopie des GPG-Build-Schlüssels von MySQL AB beschaffen. Diese können Sie unter http://www.keyserver.net/ herunterladen. Der erforderliche Schlüssel heißt build@mysql.com. Alternativ können Sie den Schlüssel aus dem folgenden Text kopieren und direkt einfügen:

Key ID:
pub  1024D/5072E1F5 2003-02-03
     MySQL Package signing key (www.mysql.com) <build@mysql.com>
Fingerprint: A4A9 4068 76FC BD3C 4567  70C8 8C71 8D3B 5072 E1F5

Public Key (ASCII-armored):

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

mQGiBD4+owwRBAC14GIfUfCyEDSIePvEW3SAFUdJBtoQHH/nJKZyQT7h9bPlUWC3
RODjQReyCITRrdwyrKUGku2FmeVGwn2u2WmDMNABLnpprWPkBdCk96+OmSLN9brZ
fw2vOUgCmYv2hW0hyDHuvYlQA/BThQoADgj8AW6/0Lo7V1W9/8VuHP0gQwCgvzV3
BqOxRznNCRCRxAuAuVztHRcEAJooQK1+iSiunZMYD1WufeXfshc57S/+yeJkegNW
hxwR9pRWVArNYJdDRT+rf2RUe3vpquKNQU/hnEIUHJRQqYHo8gTxvxXNQc7fJYLV
K2HtkrPbP72vwsEKMYhhr0eKCbtLGfls9krjJ6sBgACyP/Vb7hiPwxh6rDZ7ITnE
kYpXBACmWpP8NJTkamEnPCia2ZoOHODANwpUkP43I7jsDmgtobZX9qnrAXw+uNDI
QJEXM6FSbi0LLtZciNlYsafwAPEOMDKpMqAK6IyisNtPvaLd8lH0bPAnWqcyefep
rv0sxxqUEMcM3o7wwgfN83POkDasDbs3pjwPhxvhz6//62zQJ7Q7TXlTUUwgUGFj
a2FnZSBzaWduaW5nIGtleSAod3d3Lm15c3FsLmNvbSkgPGJ1aWxkQG15c3FsLmNv
bT6IXQQTEQIAHQUCPj6jDAUJCWYBgAULBwoDBAMVAwIDFgIBAheAAAoJEIxxjTtQ
cuH1cY4AnilUwTXn8MatQOiG0a/bPxrvK/gCAJ4oinSNZRYTnblChwFaazt7PF3q
zIhMBBMRAgAMBQI+PqPRBYMJZgC7AAoJEElQ4SqycpHyJOEAn1mxHijft00bKXvu
cSo/pECUmppiAJ41M9MRVj5VcdH/KN/KjRtW6tHFPYhMBBMRAgAMBQI+QoIDBYMJ
YiKJAAoJELb1zU3GuiQ/lpEAoIhpp6BozKI8p6eaabzF5MlJH58pAKCu/ROofK8J
Eg2aLos+5zEYrB/LsrkCDQQ+PqMdEAgA7+GJfxbMdY4wslPnjH9rF4N2qfWsEN/l
xaZoJYc3a6M02WCnHl6ahT2/tBK2w1QI4YFteR47gCvtgb6O1JHffOo2HfLmRDRi
Rjd1DTCHqeyX7CHhcghj/dNRlW2Z0l5QFEcmV9U0Vhp3aFfWC4Ujfs3LU+hkAWzE
7zaD5cH9J7yv/6xuZVw411x0h4UqsTcWMu0iM1BzELqX1DY7LwoPEb/O9Rkbf4fm
Le11EzIaCa4PqARXQZc4dhSinMt6K3X4BrRsKTfozBu74F47D8Ilbf5vSYHbuE5p
/1oIDznkg/p8kW+3FxuWrycciqFTcNz215yyX39LXFnlLzKUb/F5GwADBQf+Lwqq
a8CGrRfsOAJxim63CHfty5mUc5rUSnTslGYEIOCR1BeQauyPZbPDsDD9MZ1ZaSaf
anFvwFG6Llx9xkU7tzq+vKLoWkm4u5xf3vn55VjnSd1aQ9eQnUcXiL4cnBGoTbOW
I39EcyzgslzBdC++MPjcQTcA7p6JUVsP6oAB3FQWg54tuUo0Ec8bsM8b3Ev42Lmu
QT5NdKHGwHsXTPtl0klk4bQk4OajHsiy1BMahpT27jWjJlMiJc+IWJ0mghkKHt92
6s/ymfdf5HkdQ1cyvsz5tryVI3Fx78XeSYfQvuuwqp2H139pXGEkg0n6KdUOetdZ
Whe70YGNPw1yjWJT1IhMBBgRAgAMBQI+PqMdBQkJZgGAAAoJEIxxjTtQcuH17p4A
n3r1QpVC9yhnW2cSAjq+kr72GX0eAJ4295kl6NxYEuFApmr1+0uUq/SlsQ==
=YJkx
-----END PGP PUBLIC KEY BLOCK-----

Um den Schlüssel in Ihren eigenen öffentlichen GPG-Schlüsselbund zu importieren, verwenden Sie gpg --import. Haben Sie den Schlüssel beispielsweise unter dem Dateinamen mysql_pubkey.asc gespeichert, dann sieht der Importbefehl wie folgt aus:

shell> gpg --import mysql_pubkey.asc

Nachdem Sie den öffentlichen Schlüssel heruntergeladen und importiert haben, laden Sie das gewünschte MySQL-Paket und die entsprechende Signatur herunter (diese steht ebenfalls auf der Downloadseite zur Verfügung). Die Signaturdatei hat den gleichen Namen wie die Distributionsdatei und trägt die Erweiterung .asc. Ein Beispiel:

Stellen Sie sicher, dass beide Dateien im gleichen Verzeichnis gespeichert sind, und führen Sie dann den folgenden Befehl aus, um die Signatur der Distributionsdatei zu verifizieren:

shell> gpg --verify package_name.asc

Beispiel:

shell> gpg --verify mysql-standard-5.1.5-alpha-linux-i686.tar.gz.asc
gpg: Signature made Tue 12 Jul 2005 23:35:41 EST using DSA key ID 5072E1F5
gpg: Good signature from "MySQL Package signing key (www.mysql.com) <build@mysql.com>"

Die Meldung Good signature (Signatur korrekt) zeigt an, dass alles in Ordnung ist. Sie können alle Warnungen vom Typ insecure memory ignorieren, die unter Umständen angezeigt werden.

Weitere Informationen zum Umgang mit öffentlichen Schlüsseln finden Sie in der GPG-Dokumentation.

Bei RPM-Paketen ist keine separate Signatur vorhanden. RPM-Pakete enthalten vielmehr eine integrierte GPG-Signatur und eine MD5-Prüfsumme. Sie können ein Paket durch Ausführen des folgenden Befehls verifizieren:

shell> rpm --checksig package_name.rpm

Beispiel:

shell> rpm --checksig MySQL-server-5.1.5-alpha-0.i386.rpm
MySQL-server-5.1.5-alpha-0.i386.rpm: md5 gpg OK

Hinweis: Wenn Sie RPM 4.1 verwenden und die Meldung (GPG) NOT OK (MISSING KEYS: GPG#5072e1f5) erhalten, obwohl Sie den öffentlichen MySQL-Schlüssel zuerst in Ihren eigenen GPG-Schlüsselbund importiert haben, dann müssen Sie den Schlüssel zuerst in Ihren RPM-Schlüsselbund importieren. RPM 4.1 verwendet nicht länger den GPG-Schlüsselbund (oder GPG selbst). Stattdessen arbeitet es mit einem eigenen Schlüsselbund, da es eine systemweite Anwendung ist, während der öffentliche GPG-Schlüsselbund eine benutzerspezifische Datei ist. Um den öffentlichen MySQL-Schlüssel in den RPM-Schlüsselbund zu importieren, besorgen Sie sich den Schlüssel zunächst wie in Abschnitt 2.1.4.2, „Signaturüberprüfung mit GnuPG“, beschrieben. Nachfolgend verwenden Sie den Befehl rpm --import für den Schlüsselimport. Haben Sie den öffentlichen Schlüssel beispielsweise unter dem Dateinamen mysql_pubkey.asc gespeichert, dann sieht der Importbefehl wie folgt aus:

shell> rpm --import mysql_pubkey.asc

Wie Sie sich den öffentlichen MySQL-Schlüssel beschaffen, lesen Sie in Abschnitt 2.1.4.2, „Signaturüberprüfung mit GnuPG“.

Der MySQL-Installations-Assistent ist ein Installationsprogramm für den MySQL Server, das die aktuellen Installer-Technologien von Microsoft Windows nutzt. In Verbindung mit dem MySQL-Konfigurations-Assistenten ermöglicht der MySQL-Installations-Assistent einem Benutzer die Installation und Konfiguration eines MySQL Servers, der direkt nach der Installation einsatzbereit ist.

Der MySQL-Installations-Assistent ist das Standardinstallationsprogramm für alle MySQL Server-Distributionen ab Version 4.1.5. Benutzer vorheriger MySQL-Versionen müssen ihre vorhandenen MySQL-Installationen manuell herunterfahren und entfernen, bevor sie MySQL mit dem MySQL-Installations-Assistenten installieren. In Abschnitt 2.3.4.7, „Upgrade von MySQL mit dem Installations-Assistenten“, finden Sie weitere Informationen zur Aktualisierung einer früheren Version.

In den aktuellen Windows-Versionen hat Microsoft eine verbesserte Version von MSI (Microsoft Windows Installer) implementiert. In Windows 2000, Windows XP und Windows Server 2003 ist MSI der De-facto-Standard für die Anwendungsinstallation. Der MySQL-Installations-Assistent nutzt diese Technologie, um den Installationsprozess reibungsloser und flexibler zu gestalten.

Die MSI-Engine wurde mit der Veröffentlichung von Windows XP aktualisiert. Wenn Sie eine vorherige Windows-Version einsetzen, finden Sie in dem Microsoft Knowledge Base-Artikel unter der Adresse http://support.microsoft.com/default.aspx?scid=kb;EN-US;292539 Informationen zum Upgrade auf die aktuelle Version der MSI-Engine.

Ferner hat Microsoft kürzlich das WiX-Toolkit (Windows Installer XML) vorgestellt. Hierbei handelt es sich um das erste offizielle Open-Source-Projekt von Microsoft. Wir verwenden WiX nun auch, denn erstens ist es ein Open-Source-Projekt, und zweitens gestattet es die Handhabung des gesamten Windows-Installationsvorgangs auf flexible Weise unter Verwendung von Skripten.

Die Optimierung des MySQL-Installations-Assistenten steht und fällt mit der Unterstützung und dem Feedback solcher Benutzer wie Ihnen. Wenn Sie feststellen, dass im MySQL-Installations-Assistenten etwas fehlt, das für Sie sehr wichtig wäre, oder einen Bug entdecken, melden Sie dies bitte in unserer Bugdatenbank. Hinweise hierzu finden Sie in Abschnitt 1.8, „Wie man Bugs oder Probleme meldet“.

Die MySQL-Installationspakete können unter http://dev.mysql.com/downloads/ heruntergeladen werden. Wenn das von Ihnen heruntergeladene Paket in einem ZIP-Archiv gespeichert ist, müssen Sie dieses zunächst entpacken.

Der Vorgang zum Starten des Assistenten hängt vom Inhalt des heruntergeladenen Installationspakets ab. Enthält dieses eine Datei namens setup.exe, dann doppelklicken Sie darauf, um den Installationsvorgang zu starten. Enthält das Paket hingegen eine .msi-Datei, dann doppelklicken Sie darauf, um den Installationsvorgang zu starten.

Es sind drei Installationstypen vorhanden: Typical (Standard), Complete (Vollständig) und Custom (Benutzerdefiniert).

Bei der Installationsmethode Typical werden der MySQL Server, der Befehlszeilenclient mysql und die befehlszeilenbasierten Hilfsprogramme installiert. Zu den Befehlszeilenclients und Hilfsprogrammen gehören mysqldump, myisamchk und verschiedene weitere Programme zur Verwaltung des MySQL Servers.

Die Installationsmethode Complete installiert alle Komponenten, die im Installationspaket enthalten sind. Das vollständige Installationspaket umfasst Komponenten wie die eingebettete Serverbibliothek, die Benchmark-Reihe, Support-Skripten und die Dokumentation.

Bei der Installationsmethode Custom haben Sie vollständige Kontrolle darüber, welche Pakete installiert werden und wie der Installationspfad aussieht. Weitere Informationen zur benutzerdefinierten Installation finden Sie unter Abschnitt 2.3.4.4, „Der Dialog zur benutzerspezifischen Installation“.

Wenn Sie sich für die Installationsmethode Typical oder Complete entschieden haben und auf die Schaltfläche Next klicken, wird ein Fenster angezeigt, in dem Sie die gewählten Optionen überprüfen und die Installation dann starten können. Wenn Sie hingegen die Methode Custom auswählen und dann auf die Schaltfläche Next klicken, wird nachfolgend das Dialogfeld für die benutzerdefinierte Installation aufgerufen, welches in Abschnitt 2.3.4.4, „Der Dialog zur benutzerspezifischen Installation“, beschrieben wird.

Wenn Sie den Installationspfad oder bestimmte Komponenten ändern wollen, die vom MySQL-Installations-Assistenten installiert werden, wählen Sie die Installationsmethode Custom.

Alle verfügbaren Komponenten werden dann in einer Baumstruktur links im Installationsdialog angezeigt. Komponenten, die nicht installiert werden, sind durch ein rotes X gekennzeichnet, während für die Installation gewählten Komponenten ein graues Symbol aufweisen. Um den Installationsstatus einer Komponente umzuschalten, klicken Sie auf das Symbol der betreffenden Komponente und wählen die gewünschte Option aus der erscheinenden Dropdown-Liste.

Sie können den vorgegebenen Installationspfad ändern, indem Sie auf die Schaltfläche Change... rechts neben dem angezeigten Installationspfad klicken.

Wenn Sie die zu installierenden Komponenten und den Pfad gewählt haben, klicken Sie auf die Schaltfläche Next, um den Bestätigungsdialog anzuzeigen.

Wenn Sie eine Installationsmethode und ggf. die zu installierenden Komponenten gewählt haben, schreiten Sie fort zum Bestätigungsdialog. Installationsmethode und Pfad werden nun zur Bestätigung angezeigt.

Wenn die angezeigten Einstellungen korrekt sind, klicken Sie auf die Schaltfläche Install, um MySQL zu installieren. Wenn Sie Ihre Einstellungen noch einmal ändern wollen, klicken Sie auf die Schaltfläche Back. Um den MySQL-Installations-Assistenten zu verlassen, ohne MySQL zu installieren, klicken Sie auf die Schaltfläche Cancel.

Wenn die Installation abgeschlossen ist, können Sie sich auf der MySQL-Website registrieren. Wenn Sie registriert sind, können Sie Mitteilungen an die MySQL-Foren unter forums.mysql.com schicken, Bugs unter bugs.mysql.com melden und unseren Newsletter abonnieren. Der Abschlussbildschirm des Installationsprogramms zeigt eine Zusammenfassung der Installation und erlaubt Ihnen den Aufruf des MySQL-Konfigurations-Assistenten, mit dem Sie eine Konfigurationsdatei erstellen, den MySQL-Dienst installieren und die Sicherheitseinstellungen konfigurieren können.

Wenn Sie auf die Schaltfläche Install klicken, startet der MySQL-Installations-Assistent den Installationsvorgang und nimmt bestimmte Änderungen an Ihrem System vor, die in den nachfolgenden Abschnitten beschrieben sind.

Änderungen in der Registrierung

Der MySQL-Installations-Assistent erstellt bei Auswahl der Standardinstallation einen Schlüssel in der Windows-Registrierung. Dieser befindet sich unter HKEY_LOCAL_MACHINE\SOFTWARE\MySQL AB.

Der MySQL-Installations-Assistent richtet einen Schlüssel ein, der nach der Hauptversion des installierten Servers benannt ist (z. B. MySQL Server 5.1). Dieser enthält zwei Zeichenfolgenwerte namens Location und Version. Die Zeichenfolge Location enthält den Pfad zum Installationsverzeichnis. Bei einer Standardinstallation heißt der Wert C:\Programme\MySQL\MySQL Server 5.1\. Die Zeichenfolge Version enthält die Release-Nummer. Wird etwa MySQL Server 5.1.5-alpha installiert, dann enthält der Schlüssel den Wert 5.1.5-alpha.

Diese Registrierungsschlüssel ermöglichen es externen Programmen, das Installationsverzeichnis des MySQL Servers zu ermitteln; hierdurch wird eine zeitaufwändige vollständige Durchsuchung der Festplatte zur Ermittlung des Installationspfads des MySQL Servers unnötig. Die Registrierungsschlüssel sind für die Ausführung des Servers nicht erforderlich und werden, wenn Sie MySQL aus dem Noinstall-Archiv installieren, auch nicht erstellt.

Änderungen im Startmenü

Der MySQL-Installations-Assistent erstellt im Windows-Menü Start einen neuen Eintrag in einem MySQL-Menü, welches nach der installierten MySQL-Hauptversion benannt ist. Installieren Sie beispielsweise MySQL 5.1, dann erstellt der Installations-Assistent einen Abschnitt namens MySQL Server 5.1 im Menü Start.

In diesem neuen Abschnitt im Menü Start werden die folgenden Einträge eingerichtet:

Änderungen am Dateisystem

Der MySQL-Installations-Assistent installiert den MySQL 5.1 Server standardmäßig im Verzeichnis C:\Programme\MySQL\MySQL Server 5.1. Hierbei ist Programme das Standardverzeichnis für Anwendungen auf Ihrem System und 5.1 die Hauptversion Ihres MySQL Servers. Dies ist das empfohlene Verzeichnis für den MySQL Server. Es ersetzt die vormalige Standardposition C:\mysql.

Standardmäßig werden alle MySQL-Anwendungen in einem gemeinsamen Verzeichnis in C:\Programme\MySQL gespeichert. Hierbei ist Programme in Ihrer Windows-Installation das Standardverzeichnis für Anwendungen. Bei einer typischen MySQL-Installation auf einem Entwicklersystem könnte dies wie folgt aussehen:

C:\Programme\MySQL\MySQL Server 5.1
C:\Programme\MySQL\MySQL Administrator 1.0
C:\Programme\MySQL\MySQL Query Browser 1.0

Dieser Ansatz erleichtert Verwaltung und Pflege aller auf einem System installierten MySQL-Anwendungen.

Der MySQL-Installations-Assistent kann Server-Upgrades automatisch mithilfe der MSI-Aktualisierungsfunktionen durchführen. Das bedeutet, dass Sie eine vorhandene Installation nicht mehr manuell entfernen müssen, bevor Sie einen neuen Release installieren. Das Installationsprogramm beendet und entfernt den vorhandenen MySQL-Dienst selbsttätig, bevor die neue Version installiert wird.

Automatische Upgrades sind nur dann verfügbar, wenn Sie Aktualisierungen zwischen Installationen durchführen, die die gleiche Haupt- und Unterversionsnummern aufweisen. So kann etwa ein automatisches Upgrade von MySQL 4.1.5 auf MySQL 4.1.6 erfolgen, nicht jedoch von MySQL 5.0 auf MySQL 5.1.

Siehe auch Abschnitt 2.3.15, „Upgrade von MySQL unter Windows“.

Der MySQL-Konfigurations-Assistent hilft Ihnen bei der Automatisierung der Serverkonfiguration unter Windows. Der Konfigurations-Assistent erstellt eine benutzerdefinierte Datei my.ini. Hierzu stellt er Ihnen eine Reihe von Fragen und verknüpft Ihre Antworten dann mit einer Vorlage, um eine Datei my.ini zu erzeugen, die für Ihre Installation maßgeschneidert ist.

Der MySQL-Konfigurations-Assistent ist Bestandteil des MySQL 5.1-Servers und derzeit nur für Windows-Benutzer verfügbar.

Der MySQL-Konfigurations-Assistent ist zu einem Großteil Ergebnis des Feedbacks, das MySQL AB über viele Jahre hinweg von Benutzern erhalten hat. Sollten Sie feststellen, dass eine für Sie wesentliche Funktionalität fehlt, dann melden Sie dies bitte in unserer Bugdatenbank. Hinweise zur Vorgehensweise finden Sie in Abschnitt 1.8, „Wie man Bugs oder Probleme meldet“.

Der MySQL-Konfigurations-Assistent wird normalerweise über den MySQL-Installations-Assistenten gestartet, wenn dieser beendet wird. Sie können den Konfigurations-Assistenten aber auch durch Auswahl des Eintrags MySQL Server Instance Config Wizard im Abschnitt MySQL des Windows-Menüs Start aufrufen.

Alternativ navigieren Sie zum Verzeichnis bin Ihrer MySQL-Installation und rufen die Datei MySQLInstanceConfig.exe direkt auf.

Wenn der MySQL-Konfigurations-Assistent eine vorhandene Datei my.ini erkennt, können Sie wahlweise den vorhandenen Server umkonfigurieren oder die Serverinstanz durch Löschen von my.ini entfernen und den MySQL-Dienst beenden und entfernen.

Wenn Sie den vorhandenen Server umkonfigurieren wollen, wählen Sie die Option Re-configure Instance und klicken dann auf die Schaltfläche Next. Ihre vorhandene Datei my.ini wird nun in mytimestamp.ini.bak umbenannt, wobei timestamp ein Zeitstempel mit dem Datum und der Uhrzeit des Zeitpunkts ist, an dem die vorhandene my.ini erstellt worden ist. Wenn Sie die vorhandene Serverinstanz entfernen wollen, wählen Sie die Option Remove Instance und klicken dann auf die Schaltfläche Next.

Wählen Sie die Option Remove Instance, dann wird ein Bestätigungsfenster aufgerufen. Klicken Sie auf die Schaltfläche Execute. Der MySQL-Konfigurations-Assistent beendet und entfernt nun den MySQL-Dienst. Nachfolgend löscht er die Datei my.ini. Die Serverinstallation und ihr Ordner data werden nicht entfernt.

Wenn Sie die Option Re-configure Instance auswählen, wird das Dialogfeld Configuration Type angezeigt. Hier können Sie den Installationstyp auswählen, den Sie konfigurieren wollen.

Wenn Sie den MySQL-Konfigurations-Assistenten für eine neue MySQL-Installation aufrufen oder die Option Re-configure Instance für eine vorhandene Installation auswählen, wird das Dialogfeld Configuration Type aufgerufen.

Es stehen zwei Konfigurationsmethoden zur Verfügung: Detailed Configuration und Standard Configuration. Die Option Standard Configuration ist für Neubenutzer vorgesehen, die direkt mit MySQL arbeiten wollen, ohne sich vorher Gedanken zur Serverkonfiguration machen zu müssen. Die Option Detailed Configuration ist hingegen für fortgeschrittene Benutzer gedacht, die eine exaktere Kontrolle über die Serverkonfiguration wünschen.

Wenn Sie noch nicht mit MySQL gearbeitet haben und einen Server benötigen, der als Entwicklersystem für genau einen Benutzer vorgesehen ist, dann ist Standard Configuration die richtige Wahl für Ihre Bedürfnisse. Wenn Sie die Option Standard Configuration wählen, stellt der MySQL-Konfigurations-Assistent alle Konfigurationsoptionen mit Ausnahme von Service Options (Dienstoptionen) und Security Options (Sicherheitsoptionen) automatisch ein.

Unter Umständen werden bei Auswahl von Standard Configuration Optionseinstellungen vorgenommen, die mit Systemen, auf denen bereits MySQL-Installationen vorhanden sind, nicht kompatibel sind. Ist auf dem System, auf dem Sie eine MySQL-Installation konfigurieren wollen, bereits eine andere MySQL-Installation vorhanden, dann wird die Auswahl Detailed Configuration empfohlen.

Um die Auswahl Standard Configuration fertig zu stellen, lesen Sie bitte die Abschnitte zu Service Options und Security Options in Abschnitt 2.3.5.11, „Der Dialog zu Dienstoptionen“, bzw. Abschnitt 2.3.5.12, „Der Dialog zu Sicherheitsoptionen“.

Sie können zwischen drei verschiedenen Servertypen wählen. Welchen Servertyp Sie wählen, wirkt sich auf die Entscheidungen aus, die der MySQL-Konfigurations-Assistent in den Bereichen Speicher-, Festplatten- und Prozessornutzung trifft.

Das Dialogfeld Database Usage erlaubt Ihnen die Angabe von Speicher-Engines, die Sie bei der Erstellung von MySQL-Tabellen voraussichtlich verwenden werden. Die hier gewählte Option bestimmt, ob die InnoDB-Speicher-Engine verfügbar ist und welcher Anteil der Serverressourcen für InnoDB bereitgestellt wird.

Manche Benutzer wollen die InnoDB-Tablespace-Dateien an einer anderen Position als im MySQL Serverdatenverzeichnis speichern. Dies kann wünschenswert sein, wenn Ihr System über ein Speichergerät mit höherer Kapazität oder mehr Leistung verfügt (z. B. ein RAID-Speichersystem).

Um die Standardposition der InnoDB-Tablespace-Dateien zu ändern, wählen Sie ein anderes Laufwerk aus der Dropdown-Liste mit den Laufwerksbuchstaben aus und stellen dann in der Dropdown-Liste mit den Pfaden einen anderen Pfad ein. Um einen benutzerdefinierten Pfad zu erstellen, klicken Sie auf die Schaltfläche ....

Wenn Sie die Konfiguration eines vorhandenen Servers modifizieren, müssen Sie auf die Schaltfläche Modify klicken, bevor Sie den Pfad ändern. In dieser Situation müssen Sie die vorhandenen Tablespace-Dateien manuell an die neue Position verschieben, bevor Sie den Server starten.

Um zu verhindern, dass der Server keine Ressourcen mehr zugewiesen bekommt, ist es wichtig, die Anzahl gleichzeitiger Verbindungen zum MySQL Server zu begrenzen. Das Dialogfeld Concurrent Connections ermöglicht Ihnen die Angabe der erwarteten Auslastung Ihres Servers und stellt die Anzahl gleichzeitiger Verbindungen entsprechend ein. Es ist ferner möglich, die Anzahl gleichzeitiger Verbindungen manuell zu ändern.

Im Dialogfeld Networking Options aktivieren oder deaktivieren Sie die TCP/IP-Netzwerkunterstützung und konfigurieren die Portnummer, die zur Verbindung mit dem MySQL Server verwendet wird.

Standardmäßig ist die TCP/IP-Netzwerkunterstützung aktiviert. Um sie zu deaktivieren, entfernen Sie die Markierung des Kontrollkästchen Enable TCP/IP Networking.

Standardmäßig ist Port 3306 gewählt. Um den für den MySQL-Zugriff verwendeten Port zu ändern, wählen Sie im Dropdown-Feld eine neue Portnummer aus und geben die gewünschte Nummer direkt in das Dropdown-Feld ein. Wird die eingetragene Portnummer bereits verwendet, dann werden Sie aufgefordert, Ihre Eingabe zu bestätigen.

Über Server SQL Mode können Sie den strikten SQL-Servermodus aktivieren oder deaktivieren. Bei aktiviertem striktem Modus (Standard) verhält sich MySQL ähnlich wie andere Datenbankmanagementsysteme. Wenn Sie Anwendungen ausführen, die auf das vorherige „nachsichtige“ Verhalten von MySQL angewiesen sind, müssen Sie diese Anwendungen entweder anpassen oder den strikten Modus deaktivieren. Weitere Informationen finden Sie in Abschnitt 5.2.5, „Der SQL-Modus des Servers“.

Der MySQL Server unterstützt mehrere Zeichensätze. In diesem Zusammenhang ist es möglich, einen Standardzeichensatz einzustellen, der für alle Tabellen, Spalten und Datenbanken verwendet wird, soweit nichts anderes explizit festgelegt ist. Im Dialogfeld Character Set können Sie den Standardzeichensatz des MySQL Servers ändern.

Auf Windows NT-basierten Plattformen kann der MySQL Server als Windows-Dienst installiert werden. Wenn der Server auf diese Weise installiert wird, kann er beim Systemstart automatisch gestartet werden. Zudem ist auch ein automatischer Neustart des Dienstes durch Windows nach einem Ausfall möglich.

Der MySQL-Konfigurations-Assistent installiert den MySQL Server standardmäßig als Dienst mit dem Dienstnamen MySQL. Wollen Sie den Dienst nicht installieren, dann deaktivieren Sie das Kontrollkästchen Install As Windows Service . Sie können den Namen des Dienstes ändern, indem Sie einen anderen Namen im vorhandenen Dropdown-Feld auswählen oder einen neuen Dienstnamen direkt in das Feld eintragen.

Um den MySQL Server als Dienst zu installieren, der aber beim Systemstart nicht automatisch gestartet wird, deaktivieren Sie das Kontrollkästchen Launch the MySQL Server Automatically .

Es wird dringend empfohlen, ein root-Passwort für Ihren MySQL Server einzurichten. Der MySQL-Konfigurations-Assistent fordert Sie standardmäßig dazu auf. Wollen Sie kein root-Passwort erstellen, dann deaktivieren Sie das Kontrollkästchen Modify Security Settings .

Um das root-Passwort einzurichten, geben Sie das gewünschte Passwort in die Felder New root password und Confirm ein. Wenn Sie einen vorhandenen Server umkonfigurieren, müssen Sie das vorhandene root-Passwort in das Feld Current root password eingeben.

Um root-Anmeldungen über das Netzwerk zu verhindern, markieren Sie das Kontrollkästchen Root may only connect from localhost. Dies erhöht die Sicherheit Ihres root-Kontos.

Um ein anonymes Benutzerkonto einzurichten, markieren Sie das Kontrollkästchen Create An Anonymous Account . Die Erstellung eines solchen Kontos kann die Serversicherheit verringern und Probleme mit der Anmeldung und mit Berechtigungen verursachen. Aus diesem Grund wird davon abgeraten.

Das letzte Dialogfeld im MySQL-Konfigurations-Assistent ist Confirmation Dialog. Um den Konfigurationsvorgang zu starten, klicken Sie auf die Schaltfläche Execute. Wenn Sie zu einem der vorherigen Dialogfelder zurückkehren wollen, klicken Sie auf die Schaltfläche Back. Um den MySQL-Konfigurations-Assistenten zu verlassen, ohne MySQL zu konfigurieren, klicken Sie auf die Schaltfläche Cancel.

Wenn Sie auf die Schaltfläche Execute geklickt haben, führt der MySQL-Konfigurations-Assistent eine Reihe von Aufgaben aus, deren Fortschritt auf dem Bildschirm angezeigt wird.

Der MySQL-Konfigurations-Assistent ermittelt zunächst die Konfigurationsdateioptionen basierend auf Ihren Einstellungen. Hierzu verwendet er eine Vorlage, die von Entwicklern und Technikern bei MySQL AB erstellt wurde. Diese Vorlage heißt my-template.ini und befindet sich in Ihrem Serverinstallationsverzeichnis.

Der Konfigurations-Assistent schreibt diese Optionen dann in eine Datei namens my.ini. Die endgültige Position von my.ini wird neben der Aufgabe Write configuration file angezeigt.

Wenn Sie angegeben haben, dass ein Dienst für den MySQL Server eingerichtet werden soll, erstellt und startet der MySQL-Konfigurations-Assistent diesen Dienst. Konfigurieren Sie einen vorhandenen Dienst um, dann startet der MySQL-Konfigurations-Assistent den Dienst neu, um Ihre Konfigurationsänderungen anzuwenden.

Haben Sie angegeben, dass ein root-Passwort eingerichtet werden soll, dann stellt der MySQL-Konfigurations-Assistent eine Verbindung mit dem Server her, richtet Ihr neues root-Passwort ein und übernimmt ggf. weitere von Ihnen gewählte Sicherheitseinstellungen.

Wenn der MySQL-Konfigurations-Assistent seine Aufgaben abgeschlossen hat, wird eine Zusammenfassung angezeigt. Klicken Sie auf die Schaltfläche Finish, um den MySQL-Konfigurations-Assistenten zu beenden.

Der MySQL-Konfigurations-Assistent legt die Datei my.ini im Installationsverzeichnis des MySQL Servers ab. Dies erleichtert die Zuordnung von Konfigurationsdateien zu bestimmten Serverinstanzen.

Um sicherzustellen, dass der MySQL Server weiß, wo er nach der Datei my.ini suchen muss, wird im Zuge der Dienstinstallation ein Argument ähnlich dem folgenden an den MySQL Server übergeben: --defaults-file="C:\Programme\MySQL\MySQL Server 5.1\my.ini". Hierbei wird C:\Programme\MySQL\MySQL Server 5.1 durch den Installationspfad des MySQL Servers ersetzt.

Die Option --defaults-file weist den MySQL Server an, beim Start die Konfigurationsoptionen aus der angegebenen Datei auszulesen.

Um die Datei my.ini zu ändern, öffnen Sie sie mit einem Texteditor und nehmen die erforderlichen Änderungen vor. Sie können die Serverkonfiguration auch mit dem Hilfsprogramm MySQL Administrator bearbeiten.

MySQL-Clients und Hilfsprogramme wie die Befehlszeilenclients mysql und mysqldump können die Datei my.ini im Serverinstallationsverzeichnis nicht lokalisieren. Um die Client- und Hilfsanwendungen zu konfigurieren, erstellen Sie eine neue Datei my.ini im Verzeichnis C:\WINDOWS bzw. C:\WINNT (je nachdem, welches Verzeichnis für Ihre Windows-Version gültig ist).

Hinweis: VC++-Arbeitsbereichsdateien für MySQL 4.1 und höher sind kompatibel mit den Microsoft Visual Studio 2003-Editionen und wurden von MySQL AB-Mitarbeitern vor der Freigabe getestet.

Gehen Sie wie folgt vor, um MySQL zu erstellen:

Wenn Sie zu der Ansicht gekommen sind, dass die von Ihnen erstellten Programme korrekt laufen, beenden Sie den Server. Installieren Sie nun wie folgt MySQL:

Konfigurieren und starten Sie den Server auf die gleiche Weise wie bei einer Windows-Distribution. Siehe auch Abschnitt 2.3, „Installation von MySQL unter Windows“.

Um ein Windows-Quellcodepaket aus dem BitKeeper-Source-Tree zu erstellen, verwenden Sie die nachfolgenden Anweisungen. Dieser Vorgang muss auf einem System unter Unix oder einem Unix-Derivat durchgeführt werden, da einige der Konfigurations- und Erstellungsschritte das Vorhandensein von Tools voraussetzen, die nur unter Unix laufen. Die folgende Vorgehensweise funktioniert etwa unter Linux einwandfrei.

Der Zweck des Skripts mysql_install_db besteht in der Generierung neuer MySQL-Berechtigungstabellen. Hierbei werden vorhandene MySQL-Berechtigungstabellen nicht überschrieben, und auch andere Daten werden nicht beeinträchtigt.

Wollen Sie Ihre Berechtigungstabellen neu erstellen, dann beenden Sie zunächst den mysqld-Server, sofern dieser läuft. Benennen Sie das Verzeichnis mysql im Datenverzeichnis dann um, um es zu speichern, und führen Sie nachfolgend mysql_install_db aus. Nehmen wir an, Ihr aktuelles Verzeichnis ist das MySQL-Installationsverzeichnis, mysql_install_db befindet sich im Verzeichnis bin und das Datenverzeichnis heißt data. Um die mysql-Datenbank umzubenennen und mysql_install_db erneut auszuführen, verwenden Sie die folgenden Befehle:

shell> mv data/mysql data/mysql.old
shell> bin/mysql_install_db --user=mysql

Wenn Sie mysql_install_db ausführen, können die folgenden Probleme auftreten:

Es gibt einige Alternativen zur Ausführung des Skripts mysql_install_db, welches Bestandteil der MySQL-Distribution ist:

Normalerweise starten Sie den mysqld-Server unter Verwendung einer der folgenden Möglichkeiten:

Die Skripten mysqld_safe und mysql.server und das Mac OS X-Startobjekt können für den manuellen Start des Servers oder für seinen automatischen Start beim Systemstart verwendet werden. mysql.server und das Startobjekt erlauben zudem das Beenden des Servers.

Um den Server mit mysql.server manuell zu starten oder zu beenden, rufen Sie es mit dem Argument start bzw. stop auf:

shell> mysql.server start
shell> mysql.server stop

Bevor mysql.server den Server startet, wechselt es in das MySQL-Installationsverzeichnis und ruft dann mysqld_safe auf. Wenn Sie wollen, dass der Server als ein bestimmter Benutzer ausgeführt wird, fügen Sie die entsprechende Option user im Abschnitt [mysqld] der Optionsdatei /etc/my.cnf hinzu. Eine Erklärung erhalten Sie im weiteren Verlauf dieses Abschnitts. (Unter Umständen müssen Sie mysql.server bearbeiten, wenn Sie eine Binärdistribution von MySQL in einem anderen als dem Standardverzeichnis installiert haben. Ändern Sie es so, dass es via cd in das korrekte Verzeichnis wechselt, bevor es mysqld_safe ausführt. Beachten Sie allerdings, dass Ihre geänderte Version von mysql.server bei einem zukünftigen MySQL-Upgrade überschrieben werden könnte; deswegen sollten Sie eine Kopie der editierten Version erstellen, die Sie bei Bedarf neu installieren können.)

mysql.server stop beendet den Server, indem es ein Signal an ihn schickt. Sie können den Server auch manuell beenden, indem Sie mysqladmin shutdown ausführen.

Um MySQL automatisch auf Ihrem Server zu starten und zu beenden, müssen Sie Start- und Stoppbefehle an den entsprechenden Stellen Ihrer /etc/rc*-Dateien einfügen.

Wenn Sie das Linux-Server-RPM-Paket (MySQL-server-VERSION.rpm) verwenden, wird das Skript mysql.server im Verzeichnis /etc/init.d unter dem Namen mysql installiert. Sie müssen die Installation also nicht manuell vornehmen. Weitere Informationen zu Linux-RPM-Paketen finden Sie in Abschnitt 2.4, „MySQL unter Linux installieren“.

Manche Anbieter stellen RPM-Pakete bereit, die ein Startskript unter einem anderen Namen wie etwa mysqld installieren.

Wenn Sie MySQL aus einer Quelldistribution installieren oder ein Binärdistributionsformat verwenden, das mysql.server nicht automatisch installiert, können Sie es manuell installieren. Sie finden das Skript im Verzeichnis support-files, das sich im MySQL-Installationsverzeichnis befindet, oder in einem MySQL-Source-Tree.

Um mysql.server manuell zu installieren, kopieren Sie es unter dem Namen mysql in das Verzeichnis /etc/init.d und machen es dann ausführbar. Dies tun Sie, indem Sie in das entsprechende Verzeichnis wechseln, in dem sich mysql.server befindet, und dann die folgenden Befehle ausführen:

shell> cp mysql.server /etc/init.d/mysql
shell> chmod +x /etc/init.d/mysql

Ältere Red Hat-Systeme verwenden das Verzeichnis /etc/rc.d/init.d statt /etc/init.d. In diesem Fall müssen Sie die obigen Befehle entsprechend ändern. Alternativ erstellen Sie zunächst /etc/init.d als symbolische Verknüpfung, die auf /etc/rc.d/init.d verweist:

shell> cd /etc
shell> ln -s rc.d/init.d .

Nach der Installation des Skripts hängt der Befehl, der zur Aktivierung der Ausführung beim Systemstart erforderlich ist, von Ihrem Betriebssystem ab. Unter Linux können Sie chkconfig verwenden:

shell> chkconfig --add mysql

Unter manchen Linux-Systemen scheint auch der folgende Befehl notwendig zu sein, um das Skript mysql vollständig zu aktivieren:

shell> chkconfig --level 345 mysql on

Unter FreeBSD sollten Startskripten generell in /usr/local/etc/rc.d/ abgelegt werden. Die Manpage rc(8) gibt an, dass Skripten in diesem Verzeichnis nur dann ausgeführt werden, wenn ihr Basisname dem Shell-Muster für Dateinamen *.sh entspricht. Alle anderen Dateien oder Verzeichnisse, die in diesem Verzeichnis vorhanden sind, werden stillschweigend ignoriert. Mit anderen Worten: Unter FreeBSD müssen Sie das Skript mysql.server als /usr/local/etc/rc.d/mysql.server.sh installieren, um den automatischen Start zu aktivieren.

Als Alternative zur obigen Konfiguration verwenden manche Betriebssysteme auch /etc/rc.local oder /etc/init.d/boot.local, um zusätzliche Dienste beim Systemstart zu starten. Um MySQL auf diese Weise zu starten, könnten Sie einen Befehl wie den folgenden an die entsprechende Startdatei anhängen:

/bin/sh -c 'cd /usr/local/mysql; ./bin/mysqld_safe --user=mysql &'

Bei anderen Systemen lesen Sie in der Dokumentation zu Ihrem Betriebssystem nach, um zu erfahren, wie Startskripten installiert werden.

Sie können Optionen für mysql.server in einer globalen Datei /etc/my.cnf ablegen. Eine /etc/my.cnf-Datei sieht normalerweise so aus:

[mysqld]
datadir=/usr/local/mysql/var
socket=/var/tmp/mysql.sock
port=3306
user=mysql

[mysql.server]
basedir=/usr/local/mysql

Das Skript mysql.server versteht die folgenden Optionen: basedir, datadir und pid-file. Sofern angegeben, müssen diese in einer Optionsdatei und nicht an der Befehlszeile abgelegt sein. mysql.server versteht nur start und stop als Befehlszeilenargumente.

Die folgende Tabelle zeigt, welche Optionsgruppen der Server und die jeweiligen Startskripten aus den Optionsdateien auslesen:

[mysqld-major_version] bedeutet, dass Abschnitte mit Namen wie [mysqld-5.0] und [mysqld-5.1] von Servern der Versionen 5.0.x, 5.1.x usw. ausgelesen werden. Diese Funktion kann verwendet werden, um Optionen anzugeben, die nur von Servern einer bestimmten Release-Serie ausgelesen werden können.

Zwecks Abwärtskompatibilität liest mysql.server auch den Abschnitt [mysql_server] und mysqld_safe den Abschnitt [safe_mysqld] aus. Allerdings sollten Sie Ihre Optionsdateien so aktualisieren, dass sie stattdessen die Abschnitte [mysql.server] und [mysqld_safe] auslesen, wenn Sie MySQL 5.1 verwenden.

Siehe auch Abschnitt 4.3.2, „my.cnf-Optionsdateien“.

Dieser Abschnitt enthält Vorschläge zur Fehlersuche, wenn unter Unix Probleme beim Start des Servers auftreten. Wenn Sie Windows verwenden, finden Sie Informationen in Abschnitt 2.3.14, „Troubleshooting einer MySQL-Installation unter Windows“.

Haben Sie Probleme beim Starten des Servers, dann probieren Sie folgende Schritte:

Einige Speicher-Engines haben Optionen, die ihr Verhalten steuern. Sie können eine Datei my.cnf erstellen und darin die Startoptionen der Engines angeben, die Sie zu verwenden beabsichtigen. Wenn Sie Speicher-Engines verwenden wollen, die transaktionssichere Tabellen (InnoDB, BDB, NDB) unterstützen, dann vergewissern Sie sich, dass diese wie gewünscht konfiguriert sind, bevor Sie den Server starten:

Speicher-Engines verwenden, sofern keine Optionswerte definiert sind, die Vorgabewerte. Wir empfehlen deswegen, die verfügbaren Optionen zu prüfen und explizite Werte für diejenigen Optionen anzugeben, bei denen die Vorgabewerte nicht für Ihre Installation geeignet sind.

Wenn der mysqld-Server startet, wechselt er in das Datenverzeichnis. In diesem Verzeichnis erwartet er das Vorhandensein der Datenbanken, und hier wird er auch seine Logdateien speichern. Auch die PID-Datei (Process ID, Prozesskennung) wird im Datenverzeichnis abgelegt.

Das Datenverzeichnis wird bei der Kompilierung des Servers fest zugeordnet. Standardmäßig sucht der Server deswegen an der angegebenen Position nach diesem Verzeichnis. Befindet sich das Datenverzeichnis in Ihrem System an anderer Stelle, dann funktioniert der Server nicht einwandfrei. Durch Aufruf des Befehls mysqld mit den Optionen --verbose und --help können Sie die Vorgaben für die Pfadeinstellungen ermitteln.

Wenn die Standardpositionen dem MySQL-Installationslayout auf Ihrem System nicht entsprechen, können Sie sie durch Angabe von Optionen für mysqld oder mysqld_safe auf der Befehlszeile oder in einer Optionsdatei außer Kraft setzen.

Um die Position des Datenverzeichnisses explizit anzugeben, verwenden Sie die Option --datadir. Allerdings können Sie mysqld die Position des Basisverzeichnisses angeben, in dem MySQL installiert ist; mysqld wird dann in diesem Verzeichnis nach dem Datenverzeichnis suchen. Die Angabe erfolgt mit der Option --basedir.

Um die Auswirkungen der Optionen zur Pfadangabe zu überprüfen, rufen Sie mysqld mit diesen Optionen auf, gefolgt von den Optionen --verbose und --help. Wenn Sie beispielsweise in das Verzeichnis wechseln, in dem mysqld installiert ist, und dann den folgenden Befehl ausführen, werden die Auswirkung des Serverstarts bei einem Basisverzeichnis /usr/local angezeigt:

shell> ./mysqld --basedir=/usr/local --verbose --help

Sie können auch andere Optionen wie --datadir spezifizieren; beachten Sie aber, dass --verbose und --help jeweils als letzte Optionen aufzuführen sind.

Wenn Sie die gewünschten Pfadeinstellungen ermittelt haben, starten Sie den Server ohne --verbose und --help.

Wird mysqld gerade ausgeführt, dann können Sie die verwendeten Pfadeinstellungen durch Absetzen des folgenden Befehls ermitteln:

shell> mysqladmin variables

Oder:

shell> mysqladmin -h host_name variables

host_name ist der Name des MySQL Server-Hosts.

Erhalten Sie beim Starten von mysqld die Fehlermeldung Errcode 13 (Permission denied, Berechtigung verweigert), dann gestatten die Berechtigungen des Datenverzeichnisses oder seiner Inhalte keinen Serverzugriff. In diesem Fall ändern Sie die Berechtigungen für die betreffenden Dateien und Verzeichnisse so, dass der Server das Recht hat, sie zu verwenden. Sie können den Server auch als root starten, wovon aus sicherheitstechnischer Sicht jedoch dringend abgeraten wird.

Wechseln Sie unter Unix in das Datenverzeichnis und überprüfen Sie die Besitzrechte für das Datenverzeichnis und seinen Inhalt, um den Serverzugriff zu gewährleisten. Verwenden Sie etwa folgenden Befehl, wenn das Datenverzeichnis /usr/local/mysql/var ist:

shell> ls -la /usr/local/mysql/var

Wenn die Besitzrechte für das Datenverzeichnis oder seine Unterverzeichnisse nicht bei dem Anmeldekonto liegen, das Sie zur Ausführung des Servers verwenden, dann müssen Sie die Besitzrechte für diese Ressourcen dem Konto zuweisen. Heißt das Konto mysql, dann verwenden Sie folgende Befehle:

shell> chown -R mysql /usr/local/mysql/var
shell> chgrp -R mysql /usr/local/mysql/var

Wenn der Server nicht korrekt startet, prüfen Sie das Fehlerlog. Logdateien befinden sich im Datenverzeichnis (unter Windows normalerweise C:\Programme\MySQL\MySQL Server 5.1\data, bei Unix-Binärdistributionen in /usr/local/mysql/data und bei Unix-Quelldistributionen in /usr/local/var). Suchen Sie im Datenverzeichnis nach Dateien mit Namen des Typs host_name.err und host_name.log, wobei host_name der Name des Serverhosts ist. Überprüfen Sie nun die letzten paar Zeilen dieser Dateien. Unter Unix können Sie sie mit tail anzeigen:

shell> tail host_name.err
shell> tail host_name.log

Das Fehlerlog sollte Informationen dazu enthalten, warum der Server nicht starten konnte. Beispielsweise könnte das Log etwa Folgendes enthalten:

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 der Option --bdb-no-recover gestartet haben; Berkeley DB hat dann, als es versuchte, Ihre Datenbanken wiederherzustellen, Ungereimtheiten in Bezug auf die eigenen Logdateien erkannt. Um fortzufahren, sollten Sie die alten Berkeley DB-Logdateien aus dem Datenbankverzeichnis an einen anderen Ort verschieben, wo Sie sie später untersuchen können. Die BDB-Logdateien werden in chronologischer Reihenfolge beginnend mit log.0000000001 benannt; die Zahl im Namen wird dabei stets erhöht.

Wenn Sie mysqld mit Unterstützung für BDB-Tabellen ausführen und beim Start von mysqld ein Speicherauszug auftritt, könnte dies auf Probleme in Verbindung mit dem BDB-Wiederherstellungslog hinweisen. In diesem Fall können Sie versuchen, mysqld mit der Option --bdb-no-recover zu starten. Wenn das klappt, sollten Sie alle BDB-Logdateien aus dem Datenverzeichnis entfernen und dann versuchen, mysqld ohne die Option --bdb-no-recover neu zu starten.

Tritt einer der folgenden Fehler auf, dann bedeutet dies, dass ein anderes Programm (vielleicht ein anderer mysqld-Server) den TCP/IP-Port bzw. die Unix-Socketdatei verwendet, die mysqld für sich beansprucht:

Can't start server: Bind on TCP/IP port: Address already in use
Can't start server: Bind on unix socket ...

Ermitteln Sie mit dem Befehl ps, ob ein anderer mysqld-Server ausgeführt wird. Ist dies der Fall, dann fahren Sie den Server herunter, bevor Sie mysqld erneut starten. (Wenn ein anderer Server ausgeführt wird und Sie tatsächlich mehrere Server gleichzeitig betreiben wollen, finden Sie Informationen zur Vorgehensweise in Abschnitt 5.13, „Mehrere MySQL-Server auf derselben Maschine laufen lassen“.)

Läuft kein anderer Server, dann führen Sie den Befehl telnet your_host_name tcp_ip_port_number aus. (Die Standardportnummer von MySQL ist 3306.) Betätigen Sie dann mehrfach die Eingabetaste. Erhalten Sie keine Fehlermeldung in der Art von telnet: Unable to connect to remote host: Connection refused, dann verwendet ein anderes Programm den TCP/IP-Port, den mysqld nutzen will. Sie müssen dann ermitteln, welches Programm dies ist, und es deaktivieren; alternativ können Sie mysqld mit der Option --port auch anweisen, an einem anderen Port zu lauschen. In diesem Fall müssen Sie auch die Portnummer für Clientprogramme angeben, die über TCP/IP eine Verbindung mit dem Server herstellen wollen.

Ein anderer Grund, warum kein Zugriff auf den Port möglich ist, könnte eine laufende Firewall sein, die Verbindungen zu diesem Port unterbindet. In diesem Fall müssen Sie die Firewall-Einstellungen so abändern, dass ein Zugriff möglich ist.

Wenn der Server startet, Sie aber keine Verbindung zu ihm herstellen können, dann sollten Sie sicherstellen, dass ein Eintrag wie der folgende in /etc/hosts vorhanden ist:

127.0.0.1       localhost

Dieses Problem tritt nur bei Systemen auf, die über keine funktionierende Thread-Bibliothek verfügen und für die MySQL zur Verwendung von MIT-pthreads konfiguriert sein muss.

Wenn Sie mysqld nicht zum Laufen bringen, können Sie versuchen, unter Verwendung der Option --debug eine Trace-Datei zu erstellen, um das Problem zu ermitteln. Siehe auch Abschnitt E.1.2, „Trace-Dateien erzeugen“.

MySQL setzt die Linux-Version 2.0 oder höher voraus.

Warnung: Auf SMP-Systemen sind merkwürdige Probleme bei der Kombination Linux 2.2.14 und MySQL aufgetreten. Ferner haben uns einige MySQL-Benutzer mitgeteilt, dass sie schwerwiegende Stabilitätsprobleme bei der Verwendung von MySQL mit dem Kernel 2.2.14 hatten. Wenn Sie diesen Kernel verwenden, sollten Sie auf die Kernel-Version 2.2.19 (oder höher) oder auf Version 2.4 aktualisieren. Bei Multiprozessorsystemen sollten Sie die Verwendung der Kernel-Version 2.4 in jedem Fall in Betracht ziehen, da Sie dadurch einen erheblichen Geschwindigkeitszuwachs erfahren werden. Außerdem wird sich so die Stabilität Ihres Systems erhöhen.

Wenn Sie LinuxThreads verwenden, sollten mindestens drei laufende mysqld-Prozesse angezeigt werden. Das sind tatsächlich Threads. Ein Thread ist für den LinuxThreads-Manager, ein weiterer zur Verwaltung der Verbindungen und der dritte zur Verwaltung von Alarmmeldungen und Signalen.

Die MySQL-Binär- und -RPM-Releases für die Linux-Intel-Kombination sind für optimale Geschwindigkeit konfiguriert. Wir versuchen immer, den schnellsten stabilen Compiler zu finden, der verfügbar ist.

Der Binär-Release wird mit -static verknüpft, d. h., Sie müssen sich in der Regel keine Gedanken darüber machen, welche Version der Systembibliotheken Sie haben. Sie müssen auch LinuxThreads nicht installieren. Ein mit -static verknüpftes Programm ist ein wenig größer als ein dynamisch verknüpftes Programm, aber auch ein bisschen schneller (ca. 3 bis 5 Prozent). Allerdings besteht ein Problem bei statisch verknüpften Programmen darin, dass Sie keine UDFs (User-Defined Functions, benutzerdefinierte Funktionen) verwenden können. Wenn Sie UDFs schreiben oder verwenden wollen (dies ist nur etwas für C- oder C++-Programmierer), dann müssen Sie MySQL selbst mit dynamischer Verknüpfung kompilieren.

Ein bekanntes Problem bei Binärdistributionen besteht darin, dass auf älteren Linux-Systemen, die libc verwenden (also z. B. Red Hat 4.x oder Slackware), gelegentlich Schwierigkeiten in Verbindung mit der Auflösung der Hostnamen auftreten (diese sind jedoch nicht schwerwiegend). Verwendet Ihr System libc statt glibc2, dann werden Sie wahrscheinlich Probleme in Verbindung mit der Hostnamensauflösung und getpwnam() haben. Diese treten auf, weil glibc (leider) auf einige externe Bibliotheken angewiesen ist, um die Namensauflösung und getpwent() implementieren zu können – und zwar auch dann, wenn mit der Option -static kompiliert wurde. Diese Probleme äußern sich auf zweierlei Weise:

Eine andere Lösung, die beide Probleme behebt, besteht darin, keine Binärdistribution zu verwenden. Beschaffen Sie sich eine MySQL-Quelldistribution (im RPM- oder tar.gz-Format) und installieren Sie diese stattdessen.

Bei manchen Linux 2.2-Versionen erhalten Sie unter Umständen die Fehlermeldung Resource temporarily unavailable, wenn Clients über TCP/IP sehr schnell viele neue Verbindungen mit einem mysqld-Server herstellen. Das Problem besteht darin, dass bei Linux zwischen dem Moment, zu dem ein TCP/IP-Socket von Ihnen geschlossen wird, und dem Zeitpunkt der tatsächlichen Freigabe des Sockets eine Verzögerung auftritt. Es ist nur für eine endliche Anzahl von TCP/IP-Slots Platz vorhanden; deswegen sind zu wenig Ressourcen vorhanden, wenn Clients innerhalb kurzer Zeit zu viele neue TCP/IP-Verbindungen anfordern. Beispielsweise tritt dieser Fehler auf, wenn Sie den MySQL-Benchmark test-connect über TCP/IP ausführen.

Wir haben dieses Problem einige Male auf verschiedenen Linux-Mailinglisten beschrieben, konnten aber niemals eine geeignete Lösung finden. Der einzige bekannte „Fix“ besteht darin, dass Clients Permanentverbindungen verwenden oder Sie, wenn Sie den Datenbankserver und die Clients auf demselben Rechner ausführen, Verbindungen via Unix-Socketdatei statt TCP/IP-Verbindungen einsetzen.

Die folgenden Anmerkungen zu glibc betreffen Sie nur, wenn Sie MySQL selbst erstellen. Wenn Sie Linux auf einem x86-Computer ausführen, sollten Sie in den meisten Fällen besser unsere Binärdistribution verwenden. Wir verknüpfen unsere Binärdateien zur jeweils am besten gepatchten Version von glibc, die wir finden können, und mit den bestmöglichen Compiler-Einstellungen, um sie so für hochbeanspruchte Server zu optimieren. Für normale Benutzer ist unsere Binärdistribution auch in Setups mit vielen gleichzeitigen Verbindungen oder Tabellen, die die 2-Gbyte-Grenze sprengen, in den meisten Fällen erste Wahl. Wenn Sie nach der Lektüre des folgenden Texts nicht genau wissen, wie Sie vorgehen sollen, probieren Sie zunächst unsere Binärdatei aus, um zu ermitteln, ob diese für Ihre Anforderungen geeignet ist. Sollten Sie feststellen, dass dies nicht der Fall ist, dann sollten Sie eine selbsterstellte Version erproben. In diesem Fall würden wir uns freuen, wenn Sie uns dies mitteilen würden, damit wir beim nächsten Mal eine bessere Binärdistribution erstellen können.

MySQL verwendet LinuxThreads unter Linux. Wenn Sie eine alte Linux-Version verwenden, die glibc2 nicht enthält, dann müssen Sie LinuxThreads installieren, bevor Sie MySQL zu kompilieren versuchen. Sie bekommen LinuxThreads unter http://dev.mysql.com/downloads/os-linux.html.

Beachten Sie, dass glibc-Versionen bis einschließlich 2.1.1 beim Umgang mit pthread_mutex_timedwait(), welches beim Absetzen von INSERT DELAYED-Anweisungen verwendet wird, einen schweren Bug aufweisen. Wir empfehlen Ihnen, INSERT DELAYED erst nach der Aktualisierung von glibc zu verwenden.

Beachten Sie, dass der Linux-Kernel und die LinuxThread-Bibliothek standardmäßig maximal 1024 Threads verwalten können. Wenn Sie mehr als 1000 gleichzeitige Verbindungen vorsehen, dann müssen Sie wie folgt ein paar Änderungen an LinuxThreads vornehmen:

Weitere Informationen dazu, wie Sie Thread-Beschränkungen in LinuxThreads umgehen, finden Sie unter http://www.volano.com/linuxnotes.html.

Es gibt noch ein weiteres Problem, dass die Performance von MySQL insbesondere auf SMP-Systemen erheblich beeinträchtigt. glibc 2.1 weist eine sehr schwache Mutex-Implementierung in LinuxThreads für Programme mit vielen Threads auf, die das Mutex nur für eine kurze Zeit halten. Die Folgen sind paradox: Wenn Sie MySQL mit einer nicht modifizierten LinuxThreads-Version verbinden, können Sie die Leistungsfähigkeit von MySQL in vielen Fällen verbessern, indem Sie Prozessoren aus dem SMP entfernen! Wir haben für glibc 2.1.3 unter http://dev.mysql.com/Downloads/Linux/linuxthreads-2.1-patch einen Patch bereitgestellt, um dieses Verhalten zu korrigieren.

Bei glibc 2.2.2 verwendet MySQL das adaptive Mutex, welches wesentlich besser ist als bei glibc 2.1.3 (auch in der gepatchten Version). Wir wollen aber darauf hinweisen, dass der aktuelle Mutex-Code in glibc 2.2.2 gelegentlich zu viel des Guten tut, wodurch die MySQL-Performance wieder beeinträchtigt wird. Die Wahrscheinlichkeit, dass ein solches Verhalten auftritt, kann dadurch verringert werden, dass man dem Prozess mysqld die höchste Priorität zuweist. Wir konnten das Problem zudem ebenfalls mit einem Patch beheben, den Sie unter http://dev.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch finden. Dieser Patch korrigiert alle drei hier beschriebenen Probleme: das STACK_SIZE-Problem, das Problem der Thread-Beschränkung und das Mutex-Problem. Er muss im Verzeichnis linuxthreads mit patch -p0 </tmp/linuxthreads-2.2.2.patch angewendet werden. Wir hoffen, dass er in irgendeiner Form in zukünftigen Releases von glibc 2.2 enthalten sein wird. In jedem Fall müssen Sie bei der Verknüpfung mit glibc 2.2.2 STACK_SIZE und PTHREAD_THREADS_MAX korrigieren. Wir hoffen, dass die Standardeinstellungen in Zukunft auf Werte korrigiert werden, die für hochbeanspruchte MySQL Server geeigneter sind; in diesem Fall ließen sich die Befehle zur Erstellung eines eigenen Builds auf ./configure; make; make install beschränken.

Wir empfehlen Ihnen, diese Patches zur Erstellung einer speziellen statischen Version von libpthread.a zu verwenden und diese dann nur für die statische Verknüpfung mit MySQL zu verwenden. Wir wissen, dass diese Patches in Verbindung mit MySQL einwandfrei funktionieren und die Leistungsfähigkeit erheblich verbessern, können jedoch nichts zu ihren Auswirkungen auf andere Anwendungen sagen. Wenn Sie andere Anwendungen verknüpfen, die LinuxThreads mit einer anderen als der gepatchten statischen Version der Bibliothek benötigen, oder eine gepatchte gemeinsame Version erstellen und diese auf Ihrem System installieren, dann tun Sie dies auf eigenes Risiko.

Sollten während der Installation von MySQL merkwürdige Probleme auftreten oder bestimmte gängige Hilfsprogramme stehen bleiben, dann ist dies mit hoher Wahrscheinlichkeit durch die Bibliothek oder den Compiler verursacht. Wenn dies der Fall ist, dann können Sie diese Probleme mithilfe unserer Binärdistribution lösen.

Wenn Sie eigene MySQL-Clientprogramme verknüpfen, dann wird unter Umständen die folgende Fehlermeldung zur Laufzeit angezeigt:

ld.so.1: fatal: libmysqlclient.so.#:
open failed: No such file or directory

Dieses Problem lässt sich auf eine der folgenden Weisen lösen:

Wenn Sie den Fujitsu-Compiler (fcc/FCC) verwenden, treten unter Umständen Probleme bei der Kompilierung von MySQL auf, weil die Linux-Header-Dateien sehr stark auf gcc ausgerichtet sind. Der folgende configure-Befehl sollte auch für fcc/FCC funktionieren:

CC=fcc CFLAGS="-O -K fast -K lib -K omitfp -Kpreex -D_GNU_SOURCE \
    -DCONST=const -DNO_STRTOLL_PROTO" \
CXX=FCC CXXFLAGS="-O -K fast -K lib \
    -K omitfp -K preex --no_exceptions --no_rtti -D_GNU_SOURCE \
    -DCONST=const -Dalloca=__builtin_alloca -DNO_STRTOLL_PROTO \
    '-D_EXTERN_INLINE=static __inline'" \
./configure \
    --prefix=/usr/local/mysql --enable-assembler \
    --with-mysqld-ldflags=-all-static --disable-shared \
    --with-low-memory

mysql.server finden Sie im Verzeichnis support-files, das sich im MySQL-Installationsverzeichnis befindet, oder in einem MySQL-Source-Tree. Sie können es als /etc/init.d/mysql installieren, um MySQL automatisch zu starten und zu beenden. Siehe auch Abschnitt 2.9.2.2, „MySQL automatisch starten und anhalten“.

Wenn MySQL nicht genügend Dateien oder Verbindungen öffnen kann, haben Sie Linux möglicherweise nicht so konfiguriert, dass es genug Dateien verwalten kann.

Unter Linux 2.2 und höher können Sie die Anzahl zugewiesener Datei-Handles wie folgt überprüfen:

shell> cat /proc/sys/fs/file-max
shell> cat /proc/sys/fs/dquot-max
shell> cat /proc/sys/fs/super-max

Wenn Sie mehr als 16 Mbyte Speicher haben, sollten Sie Ihre Skripten durch einen Zusatz in der Art des folgenden ergänzen (z. B. /etc/init.d/boot.local unter SuSE Linux):

echo 65536 > /proc/sys/fs/file-max
echo 8192 > /proc/sys/fs/dquot-max
echo 1024 > /proc/sys/fs/super-max

Sie können die echo-Befehle auf der Befehlszeile auch als root ausführen, aber diese Einstellungen gehen beim nächsten Neustart Ihres Computers verloren.

Alternativ stellen Sie diese Parameter für den Start mithilfe des Tools sysctl ein, welches von vielen Linux-Distributionen (einschließlich SuSE Linux 8.0 und höher) verwendet wird. Tragen Sie die folgenden Werte in eine Datei namens /etc/sysctl.conf ein:

# Increase some values for MySQL
fs.file-max = 65536
fs.dquot-max = 8192
fs.super-max = 1024

Außerdem sollten Sie Folgendes in /etc/my.cnf ergänzen:

[mysqld_safe]
open-files-limit=8192

Auf diese Weise konfigurieren Sie für den Server eine Gesamtbeschränkung der Verbindungen und offenen Dateien auf 8192.

Die Konstante STACK_SIZE in LinuxThreads steuert das Spacing von Thread-Stapeln im Adressraum. Dieses muss groß genug sein, um genügend Raum für jeden einzelnen Thread-Stapel bereitzustellen, aber auch klein genug, um zu verhindern, dass der Stapel bestimmter Threads mit den globalen mysqld-Daten kollidiert. Leider trennt, wie wir durch Experimentieren festgestellt haben, die Linux-Implementierung von mmap() einen bereits zugeordneten Bereich wieder auf, wenn Sie sie anweisen, die Zuordnung einer derzeit verwendeten Adresse aufzulösen: Es wird kein Fehler zurückgegeben, sondern alle Daten auf der gesamten Seite werden auf null gesetzt. Insofern hängt die Sicherheit von mysqld und allen anderen Thread-basierten Anwendungen vom „wohlwollenden“ Verhalten des Codes ab, der die Threads erstellt. Der Benutzer muss Maßnahmen ergreifen, um sicherzustellen, dass die Anzahl laufender Threads jederzeit so niedrig ist, dass es nicht zum Konflikt zwischen den Thread-Stapeln und dem globalen Bereich kommt. Bei mysqld sollten Sie dieses Verhalten erzwingen, indem Sie der Variablen max_connections einen sinnvollen Wert zuweisen.

Wenn Sie MySQL selbst erstellen, können Sie LinuxThreads für eine bessere Stapelnutzung patchen. Siehe auch Abschnitt 2.12.1.3, „Anmerkungen zur Linux-Quelldistribution“. Wenn Sie LinuxThreads aber nicht patchen wollen, sollten Sie max_connections auf einen Wert von maximal 500 setzen. Arbeiten Sie mit einem großen Schlüsselpuffer, großen Heap-Tabellen oder anderen Materialien, die zu einer umfassenden Speicherzuweisung durch mysqld führen, oder verwenden Sie die Kernel-Version 2.2 mit einem 2-Gbyte-Patch, dann sollte der Wert noch kleiner sein. Wenn Sie unsere Binär- oder RPM-Version verwenden, können Sie max_connections beruhigt auf 1500 setzen, sofern Sie weder große Schlüsselpuffer noch datenintensive Heap-Tabellen benutzen. Je stärker Sie STACK_SIZE in LinuxThreads verringern, desto mehr Threads können Sie gefahrlos erstellen. Wir empfehlen Werte zwischen 128 und 256 Kbyte.

Wenn Sie zahlreiche nebenläufige Verbindungen verwenden, können Sie einem „Feature“ im Kernel 2.2 zum Opfer fallen, das Fork-Bomb-Angriffe verhindern soll, indem Prozesse, die untergeordnete Prozesse aufspalten oder klonen, eine Strafe erhalten. Hierdurch wird die Skalierbarkeit zunehmend beeinträchtigt, je größer die Anzahl nebenläufiger Clients ist. Auf Systemen mit nur einem Prozessor manifestiert sich dies unseren Beobachtungen zufolge in einer sehr langsamen Thread-Erstellung: Die Verbindungsherstellung mit MySQL kann sehr lange (bis zu einer Minute) dauern; Gleiches gilt für das Abbauen der Verbindung. Auf Multiprozessorsystemen haben wir bei steigender Clientanzahl eine allmähliche Abnahme der Abfragegeschwindigkeit feststellen können. Im Zuge der Lösung dieses Problems haben wir von einem unserer Benutzer einen Kernel-Patch erhalten, der seinen Angaben zufolge auf seiner Site geholfen haben soll. Dieser Patch ist unter http://dev.mysql.com/Downloads/Patches/linux-fork.patch verfügbar. Wir haben den Patch sowohl in Entwicklungs- als auch in Produktionssystemen umfassend getestet und festgestellt, dass sich die MySQL-Performance hierdurch erheblich verbessert, ohne dass es zu Problemen kommt. Deswegen empfehlen wir Benutzern, die hochbeanspruchte Server mit Kernel-Version 2.2 betreiben, seine Anwendung.

In der Kernel-Version 2.4 wurde das Problem behoben; wenn Sie also nicht mit der aktuellen Leistungsfähigkeit Ihres Systems zufrieden sind, ist es unter Umständen einfacher, ein Upgrade auf Version 2.4 durchzuführen, statt Ihren 2.2-Kernel zu patchen. Auf SMP-Systemen erhalten Sie neben der Problembehandlung zusätzlich noch eine beträchtliche SMP-Steigerung.

Wir haben MySQL mit dem Kernel 2.4 auf einem System mit zwei Prozessoren getestet und festgestellt, dass sich MySQL wesentlich besser skalieren lässt. Es gab im gesamten Testbereich bis 1000 Clients praktisch keine Verringerung des Abfragedurchsatzes, und der MySQL-Skalierungsfaktor (berechnet als Verhältnis des maximalen Durchsatzes zum Durchsatz pro Client) lag bei 180 %. Ähnliche Ergebnisse konnten wir auf einem System mit vier CPUs beobachten: praktisch keine Verlangsamung, während die Anzahl der Clients auf 1000 erhöht wurde, und dazu ein Skalierungsfaktor von 300 %. Basierend auf diesen Ergebnissen empfehlen wir für hochbeanspruchte SMP-Server mit dem Kernel 2.2 derzeit in jedem Fall eine Aktualisierung auf Kernel 2.4.

Unseren Beobachtungen zufolge ist es unumgänglich, den Prozess mysqld unter dem Kernel 2.4 mit höchstmöglicher Priorität auszuführen, um maximale Leistung zu erzielen. Dies ist möglich, indem der Befehl renice -20 $$ zu mysqld_safe hinzugefügt wird. Bei unseren Tests mit einem 4-CPU-Rechner haben wir eine 60-prozentige Durchsatzsteigerung bei 400 Clients erzielt.

Ferner versuchen wir derzeit auch, weitere Informationen dazu zu sammeln, wie gut MySQL mit dem Kernel 2.4 auf 4-Wege- und 8-Wege-Systemen funktioniert. Wenn Sie Zugang zu einem solchen System haben und einige Benchmarks erstellt haben, möchten wir Sie bitten, eine E-Mail mit den Ergebnissen an <benchmarks@mysql.com> zu senden. Wir werden diese prüfen und ggf. in das Handbuch aufnehmen.

Wenn Sie einen abgestürzten mysqld-Serverprozess mit ps erkennen, dann weist dies normalerweise darauf hin, dass Sie einen Bug in MySQL entdeckt haben oder eine Tabelle beschädigt ist. Siehe auch Abschnitt A.4.2, „Was zu tun ist, wenn MySQL andauernd abstürzt“.

Um, wenn mysqld mit einem SIGSEGV-Signal abstürzt, unter Linux einen Speicherauszug zu erhalten, können Sie mysqld mit der Option --core-file starten. Beachten Sie, dass Sie wahrscheinlich auch die Größe der Speicherauszugsdatei erhöhen müssen, indem Sie ulimit -c 1000000 zu mysqld_safe hinzufügen oder mysqld_safe mit --core-file-size=1000000 starten. Siehe auch Abschnitt 5.4.1, „mysqld_safe — Startskript für den MySQL-Server“.

MySQL erfordert libc 5.4.12 oder höher. Bekanntermaßen funktioniert es mit libc 5.4.46. glibc 2.0.6 und höher sollten ebenfalls keine Probleme bereiten. Es hat in der Vergangenheit einige Probleme mit den glibc-RPMs von Red Hat gegeben. Prüfen Sie also bei Auftreten von Problemen, ob Updates vorhanden sind. Die glibc-RPMs 2.0.7-19 und 2.0.7-29 RPMs funktionieren ebenfalls einwandfrei.

Wenn Sie Red Hat 8.0 oder eine neue glibc 2.2.x-Bibliothek verwenden, werden Sie unter Umständen feststellen, dass sich mysqld in gethostbyaddr() aufhängt. Dies geschieht, weil die neue glibc-Bibliothek eine Stapelgröße von mehr als 128 Kbyte für diesen Aufruf benötigt. Um das Problem zu beheben, starten Sie mysqld mit der Option --thread-stack=192K. (Verwenden Sie -O thread_stack=192K bei MySQL vor Version 4.) Diese Stapelgröße ist bei MySQL 4.0.10 und höher voreingestellt, weswegen das Problem bei diesen Versionen nicht auftreten sollte.

Wenn Sie zur Kompilierung von MySQL gcc 3.0 und höher verwenden, müssen Sie die Bibliothek libstdc++v3 vor der MySQL-Kompilierung installieren, da Sie andernfalls bei der Verknüpfung eine Fehlermeldung zu einem fehlenden __cxa_pure_virtual-Symbol erhalten.

Bei einigen älteren Linux-Distributionen erzeugt configure unter Umständen einen Fehler wie den folgenden:

Syntax error in sched.h. Change _P to __P in the
/usr/include/sched.h file.
See the Installation chapter in the Reference Manual.

Tun Sie einfach, was die Fehlermeldung vorschlägt: Ergänzen Sie den Makronamen _P, der nur einen Unterstrich aufweist, um einen weiteren Unterstrich und probieren Sie es dann erneut.

Bei der Kompilierung werden unter Umständen Warnungen angezeigt. Die folgenden können dabei ignoriert werden:

mysqld.cc -o objs-thread/mysqld.o
mysqld.cc: In function `void init_signals()':
mysqld.cc:315: warning: assignment of negative value `-1' to
`long unsigned int'
mysqld.cc: In function `void * signal_hand(void *)':
mysqld.cc:346: warning: assignment of negative value `-1' to
`long unsigned int'

Wenn mysqld beim Start immer einen Speicherauszug erzeugt, kann dies möglicherweise durch eine veraltete /lib/libc.a verursacht worden sein. Versuchen Sie sie umzubenennen, entfernen Sie sql/mysqld, führen Sie ein neues make install durch und probieren Sie es dann erneut. Dieses Problem wurde für einige Slackware-Installationen gemeldet.

Wenn Sie die folgende Fehlermeldung beim Verknüpfen von mysqld erhalten, ist Ihre libg++.a nicht korrekt installiert:

/usr/lib/libc.a(putc.o): In function `_IO_putc':
putc.o(.text+0x0): multiple definition of `_IO_putc'

Sie können die Verwendung von libg++.a vermeiden, indem Sie configure wie folgt ausführen:

shell> CXX=gcc ./configure

Bei einigen Implementierungen ist readdir_r() fehlerhaft. Das Symptom besteht darin, dass die SHOW DATABASES-Anweisung immer eine leere Menge zurückgibt. Dies lässt sich durch Entfernen von HAVE_READDIR_R aus der Datei config.h nach der Konfiguration, aber vor der Kompilierung durchführen.

Wir haben MySQL 5.1 unter Linux Alpha mit unseren Benchmarks und unserer Testsuite getestet, und es scheint gut zu funktionieren.

Derzeit erstellen wir die MySQL-Binärpakete unter SuSE Linux 7.0 für AXP, Kernel 2.4.4-SMP, Compaq C-Compiler (V6.2-505) und Compaq C++-Compiler (V6.3-006) auf einem Compaq DS20-Computer mit einem Alpha EV6-Prozessor.

Sie finden die genannten Compiler unter http://www.support.compaq.com/alpha-tools/. Durch Verwendung dieser Compiler anstelle von gcc erhalten wir eine um ca. 9 bis 14 Prozent bessere MySQL-Performance.

Bei MySQL unter Alpha verwenden wir das Flag -arch generic für unsere Kompilierungsoptionen. Hierdurch ist sichergestellt, dass die Binärdatei auf allen Alpha-Prozessoren läuft. Wir kompilieren auch statisch, um Probleme mit Bibliotheken zu vermeiden. Der configure-Befehl sieht wie folgt aus:

CC=ccc CFLAGS="-fast -arch generic" CXX=cxx \
CXXFLAGS="-fast -arch generic -noexceptions -nortti" \
./configure --prefix=/usr/local/mysql --disable-shared \
    --with-extra-charsets=complex --enable-thread-safe-client \
    --with-mysqld-ldflags=-non_shared --with-client-ldflags=-non_shared

Wenn Sie egcs benutzen wollen, funktioniert unserer Erfahrung nach folgende configure-Zeile:

CFLAGS="-O3 -fomit-frame-pointer" CXX=gcc \
CXXFLAGS="-O3 -fomit-frame-pointer -felide-constructors \
    -fno-exceptions -fno-rtti" \
./configure --prefix=/usr/local/mysql --disable-shared

Es gibt ein paar bekannte Probleme bei der Ausführung von MySQL unter Linux-Alpha:

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

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

Um MySQL unter Linux IA-64 kompilieren zu können, verwenden wir den folgenden configure-Befehl zur Erstellung mit gcc 2.96:

CC=gcc \
CFLAGS="-O3 -fno-omit-frame-pointer" \
CXX=gcc \
CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors \
    -fno-exceptions -fno-rtti" \
    ./configure --prefix=/usr/local/mysql \
    "--with-comment=Official MySQL binary" \
    --with-extra-charsets=complex

Unter IA-64 verwenden die MySQL-Clientbinärdateien gemeinsame Bibliotheken. Das bedeutet, dass Sie, wenn Sie unsere Binärdistribution in einem anderen Verzeichnis als /usr/local/mysql installieren, den Pfad des Verzeichnisses, in dem libmysqlclient.so installiert ist, entweder der Datei /etc/ld.so.conf oder dem Wert der Umgebungsvariablen LD_LIBRARY_PATH hinzufügen müssen.

Siehe auch Abschnitt A.3.1, „Probleme beim Linken mit der MySQL-Clientbibliothek“.

MySQL sollte unter Mac OS X 10.x (Darwin) ohne größere Probleme funktionieren.

Die folgenden Probleme sind bekannt:

Unsere Binärdatei für Mac OS X wird unter Darwin 6.3 mit der folgenden configure-Zeile kompiliert:

CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc \
CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors \
    -fno-exceptions -fno-rtti" \
    ./configure --prefix=/usr/local/mysql \
    --with-extra-charsets=complex --enable-thread-safe-client \
    --enable-local-infile --disable-shared

Siehe auch Abschnitt 2.5, „Installation von MySQL unter Mac OS X“.

Bei aktuellen Versionen von Mac OS X Server sind vor der Kompilierung keine Betriebssystemänderungen erforderlich. Die Kompilierung für die Serverplattform ist mit der für die Clientversion von Mac OS X identisch.

Bei älteren Versionen (Mac OS X Server 1.2, auch bekannt als „Rhapsody“) müssen Sie zunächst ein pthread-Paket installieren, bevor Sie MySQL konfigurieren können.

Siehe auch Abschnitt 2.5, „Installation von MySQL unter Mac OS X“.

Normalerweise können Sie eine Binärdatei für Solaris 2.6 auch unter Solaris 2.7 oder 2.8 verwenden. Auch betreffen Probleme, die für Solaris 2.6 gelistet sind, meist ebenfalls Solaris 2.7 und 2.8.

MySQL sollte neue Versionen von Solaris automatisch erkennen können und für die im Folgenden beschriebenen Probleme Workarounds aktivieren.

Solaris 2.7 und 2.8 haben einige Bugs bei den Include-Dateien. Bei Verwendung von gcc erhalten Sie unter Umständen folgende Fehlermeldung:

/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of the previous
definition

In diesem Fall können Sie das Problem beheben, indem Sie /usr/include/widec.h nach .../lib/gcc-lib/os/gcc-version/include kopieren. Die Zeile 41

#if     !defined(lint) && !defined(__lint)

ändern Sie wie folgt:

#if     !defined(lint) && !defined(__lint) && !defined(getwc)

Alternativ können Sie /usr/include/widec.h auch direkt editieren. Wenn Sie das Problem auf eine der beschriebenen Weisen behoben haben, sollten Sie config.cache entfernen und configure erneut ausführen.

Wenn Sie bei der Ausführung von make die folgenden Fehlermeldungen erhalten, liegt das daran, dass configure die Datei curses.h nicht erkannt hat (wahrscheinlich aufgrund des Fehlers in /usr/include/widec.h):

In file included from mysql.cc:50:
/usr/include/term.h:1060: syntax error before `,'
/usr/include/term.h:1081: syntax error before `;'

Dieses Problem lässt sich auf mehreren Wegen lösen:

Wenn Ihr Linker beim Verknüpfen von Clientprogrammen -lz nicht finden kann, besteht das Problem wahrscheinlich darin, dass Ihre Datei libz.so in /usr/local/lib installiert ist. Dieses Problem lässt sich auf eine der folgenden Weisen lösen:

Unter Solaris 8 auf x86 erzeugt mysqld einen Speicherauszug, wenn Sie die Debugsymbole mithilfe von strip entfernen.

Wenn Sie gcc oder egcs unter Solaris x86 verwenden und bei hoher Belastung Probleme mit Speicherauszügen haben, sollten Sie folgenden configure-Befehl verwenden:

CC=gcc CFLAGS="-O3 -fomit-frame-pointer -DHAVE_CURSES_H" \
CXX=gcc \
CXXFLAGS="-O3 -fomit-frame-pointer -felide-constructors \
    -fno-exceptions -fno-rtti -DHAVE_CURSES_H" \
./configure --prefix=/usr/local/mysql

Hierdurch vermeiden Sie Probleme mit der Bibliothek libstdc++ und mit C++-Ausnahmefehlern.

Sollte dies nicht helfen, dann sollten Sie eine Debugversion kompilieren und diese mit einer Trace-Datei oder unter gdb ausführen. Siehe auch Abschnitt E.1.3, „mysqld unter gdb debuggen“.

FreeBSD 4.x oder neuer wird für die Ausführung von MySQL empfohlen, da das Thread-Paket wesentlich besser integriert ist. Um ein sicheres und stabiles System zu erhalten, sollten Sie nur FreeBSD-Kernels verwenden, die mit -RELEASE gekennzeichnet sind.

Die einfachste (und deswegen empfohlene) Vorgehensweise zur Installation von MySQL besteht in der Verwendung der mysql-server- und mysql-client-Ports, die unter http://www.freebsd.org/ verfügbar sind. Die Verwendung dieser Ports hat die folgenden Vorteile:

Wir empfehlen die Verwendung von MIT-pthreads unter FreeBSD 2.x und von nativen Threads unter FreeBSD 3 und höher. Zwar können auch spätere Versionen von Release 2.2.x mit nativen Threads betrieben werden, aber dann kann es zu Problemen beim Herunterfahren von mysqld kommen.

Leider sind bestimmte Funktionsaufrufe unter FreeBSD noch nicht vollständig Thread-sicher. Dies betrifft vor allem die Funktion gethostbyname(), die von MySQL zur Umwandlung von Hostnamen in IP-Adressen verwendet wird. Unter bestimmten Umständen verursacht der Prozess mysqld unvermittelt eine Prozessorauslastung von 100 Prozent und reagiert nicht mehr. Wenn dieses Problem auftritt, versuchen Sie MySQL mit der Option --skip-name-resolve zu starten.

Alternativ können Sie MySQL unter FreeBSD 4.x mit der LinuxThreads-Bibliothek verknüpfen, wodurch einige der Probleme vermieden werden, die die native Thread-Implementierung von FreeBSD hat. Einen sehr guten Vergleich von LinuxThreads und nativen Threads finden Sie in Jeremy Zawodnys Artikel FreeBSD or Linux for your MySQL Server? unter http://jeremy.zawodny.com/blog/archives/000697.html.

Es gibt ein bekanntes Problem bei der Verwendung von LinuxThreads unter FreeBSD:

Damit der MySQL-Erstellungsprozess funktioniert, ist GNU make (gmake) erforderlich. Wenn GNU make nicht vorhanden ist, müssen Sie es vor der Kompilierung von MySQL installieren.

Die empfohlene Vorgehensweise zur Kompilierung und Installation von MySQL unter FreeBSD mit gcc (2.95.2 und höher) ist die folgende:

CC=gcc CFLAGS="-O2 -fno-strength-reduce" \
    CXX=gcc CXXFLAGS="-O2 -fno-rtti -fno-exceptions \
    -felide-constructors -fno-strength-reduce" \
    ./configure --prefix=/usr/local/mysql --enable-assembler
gmake
gmake install
cd /usr/local/mysql
bin/mysql_install_db --user=mysql
bin/mysqld_safe &

Wenn Sie feststellen, dass configure MIT-pthreads verwendet, lesen Sie die Anmerkungen zu MIT-pthreads. Siehe auch Abschnitt 2.8.5, „Anmerkungen zu MIT-pthreads“.

Wenn make install die Fehlermeldung ausgibt, dass es /usr/include/pthreads nicht finden kann, dann hat configure nicht erkannt, dass Sie MIT-pthreads benötigen. Um dieses Problem zu beheben, entfernen Sie config.cache und führen configure dann erneut mit der Option --with-mit-threads aus.

Achten Sie darauf, dass Ihre Namensauflösung korrekt ist. Andernfalls werden Verzögerungen oder Fehler bei der Auflösung auftreten, wenn Sie die Verbindung mit mysqld herzustellen versuchen. Ferner müssen Sie sicherstellen, dass der Eintrag localhost in der Datei /etc/hosts korrekt ist. Am Anfang der Datei sollte eine Zeile ähnlich der folgenden stehen:

127.0.0.1       localhost localhost.your.domain

FreeBSD hat bekanntermaßen einen sehr niedrigen Standardwert für Datei-Handles. Siehe auch Abschnitt A.2.17, „Datei nicht gefunden“. Starten Sie den Server unter Verwendung der Option --open-files-limit für mysqld_safe oder heben Sie den Wert für den Benutzer mysqld in /etc/login.conf an und erstellen Sie die Datei dann mit cap_mkdb /etc/login.conf neu. Achten Sie außerdem darauf, die passende Klasse für diesen Benutzer in der Passwortdatei zu konfigurieren, sofern Sie die Vorgabe nicht verwenden (benutzen Sie chpass mysqld-user-name). Siehe auch Abschnitt 5.4.1, „mysqld_safe — Startskript für den MySQL-Server“.

FreeBSD beschränkt die Größe eines Prozesses auch dann auf 512 Mbyte, wenn auf Ihrem System wesentlich mehr Arbeitsspeicher vorhanden ist. Insofern kann ein Fehler wie der folgende auftreten:

Out of memory (Needed 16391 bytes)

Bei den aktuellen Versionen von FreeBSD (mindestens seit 4.x) können Sie den Grenzwert auch anheben, indem Sie die folgenden Einträge in der Datei /boot/loader.conf hinzufügen und den Computer neu starten (diese Einstellungen lassen sich nicht zur Laufzeit mit dem Befehl sysctl ändern):

kern.maxdsiz="1073741824" # 1GB
kern.dfldsiz="1073741824" # 1GB
kern.maxssiz="134217728" # 128MB

Bei älteren FreeBSD-Versionen müssen Sie Ihren Kernel neu kompilieren, um die maximale Datensegmentgröße für einen Prozess zu ändern. In diesem Fall sollten Sie sich die Option MAXDSIZ in der Konfigurationsdatei LINT näher ansehen, um weitere Informationen zu erhalten.

Wenn es Probleme mit dem aktuellen Daten in MySQL gibt, sollte eine Einstellung der Variablen TZ Abhilfe leisten können. Siehe auch Anhang F, Umgebungsvariablen.

Zur Kompilierung unter NetBSD benötigen Sie GNU make. Andernfalls schlägt der Erstellungsprozess fehl, wenn make versucht, lint für C++-Dateien auszuführen.

Unter OpenBSD 2.5 können Sie MySQL mit nativen Threads kompilieren. Hierzu verwenden Sie die folgenden Optionen:

CFLAGS=-pthread CXXFLAGS=-pthread ./configure --with-mit-threads=no

Wenn Sie die folgende Fehlermeldung bei der Kompilierung von MySQL erhalten, ist der Wert ulimit für den virtuellen Speicher auf Ihrem System zu niedrig:

item_func.h: In method
`Item_func_ge::Item_func_ge(const Item_func_ge &)':
item_func.h:28: virtual memory exhausted
make[2]: *** [item_func.o] Error 1

Verwenden Sie beispielsweise ulimit -v 80000 und führen Sie make erneut aus. Funktioniert dies nicht und Sie verwenden bash, dann probieren Sie stattdessen csh oder sh aus. Einige BSDI-Benutzer haben Probleme mit bash und ulimit gemeldet.

Wenn Sie gcc einsetzen, müssen Sie unter Umständen auch das Flag --with-low-memory verwenden, damit configure sql_yacc.cc kompilieren kann.

Wenn es Probleme mit den aktuellen Daten in MySQL gibt, sollte eine Einstellung der Variablen TZ Abhilfe leisten können. Siehe auch Anhang F, Umgebungsvariablen.

Aktualisieren Sie auf BSD/OS 3.1. Sollte dies nicht möglich sein, dann installieren Sie BSDIpatch M300-038.

Verwenden Sie den folgenden Befehl zur Konfiguration von MySQL:

env CXX=shlicc++ CC=shlicc2 \
./configure \
    --prefix=/usr/local/mysql \
    --localstatedir=/var/mysql \
    --without-perl \
    --with-unix-socket-path=/var/mysql/mysql.sock

Auch die folgende Variante funktioniert bekanntermaßen:

env CC=gcc CXX=gcc CXXFLAGS=-O3 \
./configure \
    --prefix=/usr/local/mysql \
    --with-unix-socket-path=/var/mysql/mysql.sock

Sie können die Verzeichnispositionen auf Wunsch ändern oder die Voreinstellungen übernehmen (hierzu geben Sie einfach keine Positionen an).

Sollten Leistungsprobleme unter starker Belastung auftreten, dann probieren Sie die Option --skip-thread-priority für mysqld. Hierdurch werden alle Threads mit derselben Priorität ausgeführt. Unter BSDI 3.1 können Sie auf diese Weise die Performance verbessern – zumindest so lange, bis BSDI den Thread-Scheduler in Ordnung bringt.

Wird bei der Kompilierung die Fehlermeldung virtual memory exhausted angezeigt, dann sollten Sie ulimit -v 80000 ausprobieren und make erneut ausführen. Funktioniert dies nicht und Sie verwenden bash, dann probieren Sie stattdessen csh oder sh aus. Einige BSDI-Benutzer haben Probleme mit bash und ulimit gemeldet.

BSDI 4.x weist einige Bugs in Bezug auf Threads auf. Wenn Sie MySQL hierunter verwenden wollen, sollten Sie alle Thread-spezifischen Patches installieren. Dis gilt zumindest für M400-023.

Auf einigen BSDI 4.x-Systemen treten Probleme mit gemeinsamen Bibliotheken auf. Sie erkennen dies daran, dass Sie keine Clientprogramme wie etwa mysqladmin ausführen können. In diesem Fall müssen Sie das System so umkonfigurieren, dass es keine gemeinsamen Bibliotheken verwendet; dies tun Sie mit der Option --disable-shared für configure.

Ferner haben Kunden Probleme unter BSDI 4.0.1 damit gehabt, dass die Binärdatei mysqld nach einer Weile keine Tabellen mehr öffnen konnte. Ursache hierfür ist ein bibliotheks- oder systembezogener Bug, aufgrund dessen mysqld das aktuelle Verzeichnis wechselt, ohne hierfür zuvor eine Bestätigung angefordert zu haben.

Sie beseitigen das Problem, indem Sie entweder MySQL auf Version 3.23.34 oder höher aktualisieren oder nach der Ausführung von configure die Zeile #define HAVE_REALPATH aus der Datei config.h entfernen, bevor Sie make starten.

Beachten Sie, dass dies bedeutet, dass Sie in diesem Fall unter BSDI keine symbolischen Verknüpfungen zwischen Datenbankverzeichnissen oder von einer Tabelle zu einer anderen Datenbank erstellen können. (Symbolische Verknüpfungen zu anderen Festplatten hingegen sind unproblematisch.)

Wenn Sie MySQL unter HP-UX kompilieren, gibt es ein paar kleinere Probleme. Wir empfehlen die Verwendung von gcc anstelle des nativen Compilers von HP-UX, da gcc einen besseren Code erzeugt.

Verwenden Sie unter HP-UX am besten gcc 2.95. Verwenden Sie keine Hochoptimierungsflags (wie etwa -O6), da dies unter Umständen unter HP-UX nicht sicher ist.

Der folgende configure-Befehl sollte für gcc 2.95 funktionieren:

CFLAGS="-I/opt/dce/include -fpic" \
CXXFLAGS="-I/opt/dce/include -felide-constructors -fno-exceptions \
-fno-rtti" \
CXX=gcc \
./configure --with-pthread \
    --with-named-thread-libs='-ldce' \
    --prefix=/usr/local/mysql --disable-shared

Der folgende configure-Befehl sollte für gcc 3.1 funktionieren:

CFLAGS="-DHPUX -I/opt/dce/include -O3 -fPIC" CXX=gcc \
CXXFLAGS="-DHPUX -I/opt/dce/include -felide-constructors \
    -fno-exceptions -fno-rtti -O3 -fPIC" \
./configure --prefix=/usr/local/mysql \
    --with-extra-charsets=complex --enable-thread-safe-client \
    --enable-local-infile  --with-pthread \
    --with-named-thread-libs=-ldce --with-lib-ccflags=-fPIC
    --disable-shared

Aufgrund einiger kritischer Bugs in den HP-UX-Standardbibliotheken sollten Sie die folgenden Patches installieren, bevor Sie MySQL unter HP-UX 11.0 ausführen:

PHKL_22840 Streams cumulative
PHNE_22397 ARPA cumulative

Hierdurch können Sie das Problem beheben, EWOULDBLOCK aus recv() und EBADF aus accept() in Thread-basierten Anwendungen zu erhalten.

Wenn Sie gcc 2.95.1 auf einem nicht gepatchten HP-UX 11.x-System einsetzen, wird unter Umständen die folgende Fehlermeldung angezeigt:

In file included from /usr/include/unistd.h:11,
                 from ../include/global.h:125,
                 from mysql_priv.h:15,
                 from item.cc:19:
/usr/include/sys/unistd.h:184: declaration of C function ...
/usr/include/sys/pthread.h:440: previous declaration ...
In file included from item.h:306,
                 from mysql_priv.h:158,
                 from item.cc:19:

Das Problem besteht darin, dass HP-UX pthreads_atfork() nicht konsistent definiert. Es liegt ein Prototypkonflikt in /usr/include/sys/unistd.h:184 und /usr/include/sys/pthread.h:440 vor.

Eine Lösung besteht darin, /usr/include/sys/unistd.h nach mysql/include zu kopieren und unistd.h so zu editieren, dass es zur Definition in pthread.h passt. Suchen Sie nach der folgenden Zeile:

extern int pthread_atfork(void (*prepare)(), void (*parent)(),
                                          void (*child)());

Ändern Sie sie wie folgt ab:

extern int pthread_atfork(void (*prepare)(void), void (*parent)(void),
                                          void (*child)(void));

Wenn Sie die Änderung vorgenommen haben, sollte die folgende configure-Zeile funktionieren:

CFLAGS="-fomit-frame-pointer -O3 -fpic" CXX=gcc \
CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti -O3" \
./configure --prefix=/usr/local/mysql --disable-shared

Verwenden Sie den HP-UX-Compiler, dann können Sie den folgenden Befehl verwenden (dieser wurde mit cc B.11.11.04 getestet):

CC=cc CXX=aCC CFLAGS=+DD64 CXXFLAGS=+DD64 ./configure \
    --with-extra-character-set=complex

Sie können alle Fehler des folgenden Typs ignorieren:

aCC: warning 901: unknown option: `-3': use +help for online
documentation

Wenn die folgende Fehlermeldung von configure ausgegeben wird, dann stellen Sie sicher, dass der Pfad zum K&R-Compiler nicht vor dem Pfad zum HP-UX-C- und C++-Compiler steht:

checking for cc option to accept ANSI C... no
configure: error: MySQL requires an ANSI C compiler (and a C++ compiler).
Try gcc. See the Installation chapter in the Reference Manual.

Ein anderer Grund dafür, dass eine Kompilierung nicht möglich ist, besteht darin, dass Sie die +DD64-Flags nicht wie eben beschrieben definiert haben.

Eine andere Möglichkeit für HP-UX 11 besteht darin, die unter http://dev.mysql.com/downloads/ verfügbaren MySQL-Binärdateien zu verwenden, die wir selbst erstellt und getestet haben. Ferner wurde uns mitgeteilt, dass die von MySQL angebotenen Binärdateien für HP-UX 10.20 auch unter HP-UX 11 erfolgreich ausgeführt werden können. Wenn Sie hierbei auf Probleme treffen, sollten Sie überprüfen, ob HP-UX-Patches verfügbar sind.

Die automatische Erkennung von xlC fehlt bei Autoconf. Aus diesem Grund muss eine Reihe von Variablen eingestellt werden, bevor configure ausgeführt wird. Das folgende Beispiel verwendet den IBM-Compiler:

export CC="xlc_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192 "
export CXX="xlC_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192"
export CFLAGS="-I /usr/local/include"
export LDFLAGS="-L /usr/local/lib"
export CPPFLAGS=$CFLAGS
export CXXFLAGS=$CFLAGS

./configure --prefix=/usr/local \
                --localstatedir=/var/mysql \
                --sbindir='/usr/local/bin' \
                --libexecdir='/usr/local/bin' \
                --enable-thread-safe-client \
                --enable-large-files

Obige Optionen werden zur Kompilierung der MySQL-Distribution verwendet, die unter http://www-frec.bull.com/ verfügbar ist.

Wenn Sie in obiger configure-Zeile die Option -O3 auf -O2 setzen, müssen Sie auch die Option -qstrict entfernen. Dies ist eine Einschränkung des C-Compilers von IBM.

Wenn Sie gcc oder egcs zur Kompilierung von MySQL verwenden, müssen Sie das Flag -fno-exceptions benutzen, weil die Fehlerbehandlung in gcc/egcs nicht Thread-sicher ist! (Dies wurde mit egcs 1.1 getestet.) Es gibt ferner einige bekannte Probleme mit dem IBM-Assembler, die in Verbindung mit gcc zu fehlerhaftem Code führen können.

Wir empfehlen die folgende configure-Zeile bei egcs und gcc 2.95 unter AIX:

CC="gcc -pipe -mcpu=power -Wa,-many" \
CXX="gcc -pipe -mcpu=power -Wa,-many" \
CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti" \
./configure --prefix=/usr/local/mysql --with-low-memory

Die Option -Wa,-many ist erforderlich, damit die Kompilierung erfolgreich verläuft. Bei IBM ist dieses Problem bekannt, man sieht sich aber mit der Behebung nicht unter Zeitdruck, da ein Workaround verfügbar ist. Wir wissen nicht, ob -fno-exceptions bei gcc 2.95 erforderlich ist, aber weil MySQL keine Ausnahmen verwendet und die Option einen schnelleren Code erzeugt, empfehlen wir ihre generelle Verwendung bei egcs und gcc.

Wenn ein Problem mit dem Assemblercode auftritt, versuchen Sie die Option -mcpu=xxx so zu ändern, dass sie zu Ihrer CPU passt. Normalerweise müssen power2, power oder powerpc verwendet werden. Möglicherweise müssen Sie aber auch 604 oder 604e einsetzen. Wir wissen es nicht genau, nehmen aber an, dass power mit hoher Wahrscheinlichkeit in den meisten Fällen sicher ist (und zwar auch auf power2-Systemen).

Wenn Sie nicht wissen, welchen Prozessor Sie haben, führen Sie den Befehl uname -m aus. Er erzeugt einen String, der etwa so aussieht: 000514676700. Das Format ist xxyyyyyymmss, wobei xx und ss immer 00, yyyyyy eine eindeutige Systemkennung und mm die Kennung des CPU-Planars sind. Eine Übersicht über diese Werte finden Sie unter http://www16.boulder.ibm.com/pseries/en_US/cmds/aixcmds5/uname.htm.

Dort erhalten Sie Angaben zu Rechnertyp und -modell, auf deren Basis Sie die CPU in Ihrem Rechner ermitteln können.

Wenn Sie Probleme mit Signalen haben (weil sich MySQL unter hoher Belastung unerwartet aufhängt), haben Sie unter Umständen einen Betriebssystembug bei den Threads oder Signalen gefunden. In diesem Fall können Sie MySQL wie folgt anweisen, Signale nicht zu verwenden:

CFLAGS=-DDONT_USE_THR_ALARM CXX=gcc \
CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti \
-DDONT_USE_THR_ALARM" \
./configure --prefix=/usr/local/mysql --with-debug \
    --with-low-memory

Hierdurch wird die Leistungsfähigkeit von MySQL nicht beeinträchtigt; ein Nebeneffekt besteht aber darin, dass Sie Clients, die an einer Verbindung „schlafen“, mit mysqladmin kill oder mysqladmin shutdown nicht terminieren können. Stattdessen hängt sich der Client auf, wenn er den nächsten Befehl absetzt.

Bei einigen Versionen von AIX führt eine Verknüpfung mit libbind.a bei getservbyname() zu einem Speicherauszug. Dies ist ein AIX-Bug, der IBM gemeldet werden sollte.

Bei AIX 4.2.1 und gcc müssen Sie die folgenden Änderungen vornehmen.

Bearbeiten Sie nach der Konfiguration config.h und include/my_config.h. Die Zeile

#define HAVE_SNPRINTF 1

ändern Sie wie folgt:

#undef HAVE_SNPRINTF

Schließlich müssen Sie in mysqld.cc noch einen Prototyp für initgroups() hinzufügen.

#ifdef _AIX41
extern "C" int initgroups(const char *,int);
#endif

Wenn Sie dem Prozess mysqld viel Speicher zuweisen müssen, reicht es nicht aus, einfach ulimit -d unlimited zu verwenden. Sie müssen vielmehr auch mysqld_safe mit einer Zeile wie der folgenden ergänzen:

export LDR_CNTRL='MAXDATA=0x80000000'

Weitere Informationen zur Verwendung einer großen Menge Speicher finden Sie unter http://publib16.boulder.ibm.com/pseries/en_US/aixprggd/genprogc/lrg_prg_support.htm.

Benutzer von AIX 4.3 sollten gmake statt des in AIX enthaltenen make-Hilfsprogramms verwenden.

Unter SunOS 4 ist MIT-pthreads zur Kompilierung von MySQL erforderlich. Das wiederum bedeutet, dass Sie GNU make benötigen.

Einige SunOS 4-Systeme haben Probleme mit dynamischen Bibliotheken und libtool. Dieses Problem können Sie mit der folgenden configure-Zeile beheben:

./configure --disable-shared --with-mysqld-ldflags=-all-static

Wenn Sie readline kompilieren, erhalten Sie unter Umständen Warnungen zu Doppeldefinitionen. Diese können Sie getrost ignorieren.

Wenn Sie mysqld kompilieren, erscheinen einige Warnungen des Typs implicit declaration of function. Diese können Sie getrost ignorieren.

Wenn Sie egcs 1.1.2 unter Digital Unix verwenden, sollten Sie auf gcc 2.95.2 aktualisieren, weil egcs unter DEC einige schwerwiegende Bugs aufweist!

Wenn Sie Thread-basierte Programme unter Digital Unix kompilieren, empfiehlt die Dokumentation die Verwendung der Option -pthread für cc und cxx und die -lmach -lexc-Bibliotheken (zusätzlich zu -lpthread). Sie sollten configure etwa wie folgt ausführen:

CC="cc -pthread" CXX="cxx -pthread -O" \
./configure --with-named-thread-libs="-lpthread -lmach -lexc -lc"

Wenn Sie mysqld kompilieren, werden unter Umständen einige Warnungen wie die folgenden angezeigt:

mysqld.cc: In function void handle_connections()':
mysqld.cc:626: passing long unsigned int *' as argument 3 of
accept(int,sockadddr *, int *)'

Diese können Sie getrost ignorieren. Sie erscheinen, weil configure nur Fehler, nicht jedoch Warnungen erkennen kann.

Wenn Sie den Server direkt über die Befehlszeile starten, kann es bei der Abmeldung zu Abstürzen kommen. (Wenn Sie sich abmelden, erhalten Ihre ausstehenden Prozesse ein SIGHUP-Signal.) Versuchen Sie, den Server wie folgt zu starten:

nohup mysqld [options] &

nohup sorgt dafür, dass der Befehl, der darauf folgt, alle ggf. vom Terminal gesendeten SIGHUP-Signale ignoriert. Alternativ starten Sie den Server durch Ausführung von mysqld_safe. Hierdurch wird mysqld unter Verwendung von nohup für Sie aufgerufen. Siehe auch Abschnitt 5.4.1, „mysqld_safe — Startskript für den MySQL-Server“.

Wenn ein Problem bei der Kompilierung von mysys/get_opt.c auftritt, entfernen Sie einfach die Zeile #define _NO_PROTO am Anfang dieser Datei.

Wenn Sie den CC-Compiler von Compaq einsetzen, sollte die folgende configure-Zeile problemlos funktionieren:

CC="cc -pthread"
CFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed all -arch host"
CXX="cxx -pthread"
CXXFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed all \
    -arch host -noexceptions -nortti"
export CC CFLAGS CXX CXXFLAGS
./configure \
    --prefix=/usr/local/mysql \
    --with-low-memory \
    --enable-large-files \
    --enable-shared=yes \
    --with-named-thread-libs="-lpthread -lmach -lexc -lc"
gnumake

Tritt ein Problem mit libtool auf, wenn Sie wie gerade gezeigt mit gemeinsamen Bibliotheken kompilieren und mysql verknüpfen, sollten Sie dieses durch Absetzen der folgenden Befehle umgehen können:

cd mysql
/bin/sh ../libtool --mode=link cxx -pthread  -O3 -DDBUG_OFF \
    -O4 -ansi_alias -ansi_args -fast -inline speed \
    -speculate all \ -arch host  -DUNDEF_HAVE_GETHOSTBYNAME_R \
    -o mysql  mysql.o readline.o sql_string.o completion_hash.o \
    ../readline/libreadline.a -lcurses \
    ../libmysql/.libs/libmysqlclient.so  -lm
cd ..
gnumake
gnumake install
scripts/mysql_install_db

Wenn Sie Probleme beim Kompilieren haben und DEC CC und gcc installiert sind, probieren Sie einmal, configure wie folgt auszuführen:

CC=cc CFLAGS=-O CXX=gcc CXXFLAGS=-O3 \
./configure --prefix=/usr/local/mysql

Treten Probleme in Verbindung mit der Datei c_asm.h auf, dann können Sie wie folgt eine Dummyversion von c_asm.h erstellen:

touch include/c_asm.h
CC=gcc CFLAGS=-I./include \
CXX=gcc CXXFLAGS=-O3 \
./configure --prefix=/usr/local/mysql

Beachten Sie, dass die folgenden Probleme beim Programm ld sich durch den Download des aktuellen DEC-(Compaq-)Patch-Kits beheben lassen. Dieses finden Sie unter http://ftp.support.compaq.com/public/unix/.

Unter OSF/1 V4.0D tritt bei Verwendung des Compilers "DEC C V5.6-071 on Digital Unix V4.0 (Rev. 878)" ein seltsames Verhalten auf (undefinierte asm-Symbole). /bin/ld scheint ebenfalls beschädigt zu sein (Probleme mit _exit undefined-Fehlern, die beim Verknüpfen von mysqld auftreten). Es ist uns gelungen, MySQL auf diesem System mit der folgenden configure-Zeile zu kompilieren, nachdem wir /bin/ld durch die Version aus OSF 4.0C ersetzt haben:

CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql

Beim Digital-Compiler "C++ V6.1-029" sollte Folgendes funktionieren:

CC=cc -pthread
CFLAGS=-O4 -ansi_alias -ansi_args -fast -inline speed \
       -speculate all -arch host
CXX=cxx -pthread
CXXFLAGS=-O4 -ansi_alias -ansi_args -fast -inline speed \
         -speculate all -arch host -noexceptions -nortti
export CC CFLAGS CXX CXXFLAGS
./configure --prefix=/usr/mysql/mysql \
            --with-mysqld-ldflags=-all-static --disable-shared \
            --with-named-thread-libs="-lmach -lexc -lc"

Bei einigen Versionen von OSF/1 ist die Funktion alloca() beschädigt. Dieses Problem können Sie beheben, indem Sie die Zeile in config.h entfernen, die 'HAVE_ALLOCA' definiert.

Die Funktion alloca() weist unter Umständen auch einen falschen Prototyp in /usr/include/alloca.h auf. Sich hierauf beziehende Warnmeldungen können Sie ignorieren.

configure verwendet die folgenden Thread-Bibliotheken automatisch: --with-named-thread-libs="-lpthread -lmach -lexc -lc".

Wenn Sie gcc verwenden, können Sie auch versuchen, configure wie folgt auszuführen:

CFLAGS=-D_PTHREAD_USE_D4 CXX=gcc CXXFLAGS=-O3 ./configure ...

Wenn Sie Probleme mit Signalen haben (weil sich MySQL unter hoher Belastung unerwartet aufhängt), haben Sie unter Umständen einen Betriebssystembug bei den Threads oder Signalen gefunden. In diesem Fall können Sie MySQL wie folgt anweisen, Signale nicht zu verwenden:

CFLAGS=-DDONT_USE_THR_ALARM \
CXXFLAGS=-DDONT_USE_THR_ALARM \
./configure ...

Hierdurch wird die Leistungsfähigkeit von MySQL nicht beeinträchtigt; ein Nebeneffekt besteht aber darin, dass Sie Clients, die an einer Verbindung „schlafen“, mit mysqladmin kill oder mysqladmin shutdown nicht terminieren können. Stattdessen hängt sich der Client auf, wenn er den nächsten Befehl absetzt.

Bei gcc 2.95.2 erhalten Sie möglicherweise den folgenden Kompilierungsfehler:

sql_acl.cc:1456: Internal compiler error in `scan_region',
at except.c:2566
Please submit a full bug report.

Um dies zu beheben, sollten Sie in das Verzeichnis sql wechseln und dort die letzte gcc-Zeile ausschneiden und einfügen, die Option -O3 dabei jedoch zu -O0 ändern (oder -O0 direkt nach gcc hinzufügen, wenn Ihre compile-Zeile gar keine -O-Option enthält). Danach können Sie wieder zum obersten Verzeichnis wechseln und make erneut ausführen.

Wenn Sie Irix 6.5.3 oder höher verwenden, kann mysqld Threads nur dann erstellen, wenn Sie es als Benutzer mit CAP_SCHED_MGT-Berechtigungen (z. B. als root) ausführen oder dem Server mysqld diese Berechtigung mit dem folgenden Shell-Befehl zuweisen:

chcap "CAP_SCHED_MGT+epi" /opt/mysql/libexec/mysqld

Unter Umständen müssen Sie die Definitionen einiger Symbole in config.h nach der Ausführung von configure, aber vor der Kompilierung aufheben.