Inhaltsverzeichnis
Dieses Kapitel beschreibt, woher man MySQL bezieht und wie man MySQL installiert:
Eine Liste der Site, von denen Sie MySQL beziehen können, finden Sie unter Abschnitt 3.2.1, „Wie man MySQL erhält“.
Um festzustellen, welche Plattformen unterstützt werden, siehe Abschnitt 3.2.2, „Betriebssysteme, die von MySQL unterstützt werden“. Beachten Sie bitte, dass nicht alle unterstützten Systeme gleich gut sind, um MySQL laufen zu lassen. Auf einigen läuft es sehr viel robuster und effizienter als auf anderen - siehe Abschnitt 3.2.2, „Betriebssysteme, die von MySQL unterstützt werden“ für Details.
Mehrere Versionen von MySQL sind sowohl als Binär- als auch als Quellcode-Distributionen erhältlich. Wir stellen auch öffentlichen Zugriff auf unseren aktuellen Quellcode-Baum für diejenigen zur Verfügung, die die aktuellsten Entwicklungen sehen und uns helfen wollen, neuen Code zu testen. Um festzustellen, welche Version und welche Art von Distribution Sie benutzen sollten, siehe Abschnitt 3.2.3, „Welche MySQL-Version Sie benutzen sollten“. Im Zweifelsfall benutzen Sie die Binärdistribution.
Installationsanleitungen für Binär- und Quelldistributionen sind beschrieben in Abschnitt 3.2.6, „MySQL-Binärdistributionen, die von MySQL AB kompiliert wurden“ und Abschnitt 3.3, „Installation der Quelldistribution“. Jede Anleitung enthält einen Abschnitt über System-spezifische Probleme, denen Sie begegnen können.
Prozeduren, die nach der Installation durchgeführt werden sollen / müssen, finden Sie unter Abschnitt 3.4, „Einstellungen und Tests nach der Installation“. Diese Prozeduren gelten, egal ob Sie MySQL von einer Binär- oder einer Quellcode-Distribution installieren.
Die empfohlene Vorgehensweise für die Installation von MySQL
auf Linux ist die Benutzung einer RPM-Datei. Die MySQL-RPMs
werden aktuell auf einer RedHat-Version 6.2 gebaut, sollten aber
auch auf anderen Linux-Versionen funktionieren, die
rpm
unterstützen und
glibc
benutzen.
Wenn Sie Probleme mit einer RPM-Datei haben, wenn Sie
beispielsweise den Fehler ``Sorry, the host 'xxxx'
could not be looked up
'' erhalten, sehen Sie bitte
unter Abschnitt 3.1.1, „MySQL auf Linux installieren“ nach.
Die RPM-Dateien, die Sie benutzen sollten, sind:
MySQL-VERSION.i386.rpm
Der MySQL-Server. Sie brauchen diese, es sei denn, Sie wollen sich lediglich mit einem MySQL-Server verbinden, der auf einer anderen Maschine läuft.
MySQL-client-VERSION.i386.rpm
Die Standard-MySQL-Client-Programme. Dieses Paket sollten Sie wohl immer installieren.
MySQL-bench-VERSION.i386.rpm
Tests und Benchmarks. Erfordert Perl und msql-mysql-modules RPMs.
MySQL-devel-VERSION.i386.rpm
Bibliotheken und Include-Dateien, die benötigt werden, wenn Sie andere MySQL-Clients kompilieren wollen, beispielsweise Perl-Module.
MySQL-VERSION.src.rpm
Dieses Paket enthält den Quelltext für alle obigen Pakete. Es kann auch dazu benutzt werden, um RPMs für andere Architekturen zu bauen (zum Beispiel für Alpha oder SPARC).
Um alle Dateien in einem RPM-Paket zu sehen, geben Sie folgendes ein:
shell> rpm -qpl MySQL-VERSION.i386.rpm
Um eine minimale Standard-Installation durchzuführen, geben Sie folgendes ein:
shell> rpm -i MySQL-VERSION.i386.rpm MySQL-client-VERSION.i386.rpm
Um nur das Client-Paket zu installieren, geben Sie folgendes ein:
shell> rpm -i MySQL-client-VERSION.i386.rpm
Das RPM legt Dateien in /var/lib/mysql
ab.
Ausserdem erzeugt das RPM die entsprechenden Einträge in
/etc/rc.d/
, um den Server beim Booten
automatisch zu starten. (Falls Sie bereits vorher eine
Installation durchgeführt haben, bedeutet das, dass Sie eine
Kopie Ihrer vorher installierten MySQL-Startdateien machen
sollten, falls Sie darin Änderungen vorgenommen haben, damit
Sie diese Änderungen nicht verlieren.)
Nach der Installation der RPM-Datei(en) sollte der
mysqld
-Daemon laufen und Sie sollten jetzt in
der Lage sein, mit der Benutzung von MySQL zu beginnen. See
Abschnitt 3.4, „Einstellungen und Tests nach der Installation“.
Wenn etwas schief geht, finden Sie weitere Informationen im Kapitel über die Binär-Installationen. See Abschnitt 3.2.6, „MySQL-Binärdistributionen, die von MySQL AB kompiliert wurden“.
Der MySQL-Server für Windows ist in zwei Distributionstypen erhältlich:
Die Binärdistribution enthält ein Setup-Programm, das alles Benötigte installiert, so dass Sie den Server sofort starten können.
Die Quelldistribution enthält den gesamten Code und Unterstützungsdateien, um die ausführbaren Dateien unter Benutzung des VC++-6.0-Kompilers zu bauen. See Abschnitt 3.3.7, „Windows-Quelldistribution“.
Im Allgemeinen sollten Sie die Binärdistribution benutzen.
Sie benötigen folgendes:
Ein Windows-32-Bit-Betriebssystem der Familien Windows 9x, ME, NT oder Windows 2000. Die NT-Familie gestattet, den MySQL-Server als Systemdienst laufen zu lassen. See Abschnitt 3.6.2.2, „MySQL auf Windows NT oder Windows 2000 starten“.
Wenn Sie Tabellen benutzen, die größer als 4 GB sind,
sollten Sie MySQL auf NTFS oder einem neueren Dateisystem
installieren. Vergessen Sie bei der Erzeugung der Tabellen
nicht, MAX_ROWS
und
AVG_ROW_LENGTH
zu benutzen. See
Abschnitt 7.5.3, „CREATE TABLE
-Syntax“.
TCP/IP-Protokollunterstützung.
Die MySQL-Binär- oder Quelldistribution für Windows kann von http://www.mysql.com/downloads/ herunter geladen werden.
Hinweis: Die Distributionsdateien werden in einem komprimierten Format zur Verfügung gestellt. Wir empfehlen die Benutzung eines FTP-Clients, der in der Lage ist, abgebrochene FTP-Downloads wieder aufzunehmen (resume).
Ein ZIP
-Programm, um die
Distributionsdatei zu entpacken.
Genug Platz auf der Festplatte, um die Datenbanken entsprechend Ihren Anforderungen zu entpacken, zu installieren und zu erzeugen.
Wenn Sie planen, sich über ODBC
mit dem
MySQL-Server zu verbinden, benötigen Sie zusätzlich den
MyODBC
-Treiber. See
Abschnitt 9.3, „MySQL-ODBC-Unterstützung“.
Wenn Sie auf einem NT- oder Windows-2000-Server arbeiten, melden Sie sich als Benutzer mit Administrationsrechten an.
Wenn Sie ein Upgrade einer früheren MySQL-Installation durchführen, müssen Sie den Server anhalten. Wenn Sie den Server als Systemdienst laufen lassen, geben Sie ein:
C:\> NET STOP MySQL
Ansonsten geben Sie folgendes ein:
C:\mysql\bin> mysqladmin -u root shutdown
Auf NT-/Windows-2000-Maschinen müssen Sie auch den Systemdienst entfernen, wenn Sie die ausführbare Datei des Servers (z. B. -max or -nt) austauschen wollen:
C:\mysql\bin> mysqld-max-nt --remove
Entpacken Sie die Distributionsdatei in ein temporäres Verzeichnis.
Starten Sie setup.exe
, um den
Installationsprozess zu beginnen. Wenn Sie in ein anderes
Verzeichnis als das vorgabemäßige
(c:\mysql
) installieren wollen, legen
Sie mit der Schaltfläche Durchsuchen
das gewünschte Verzeichnis fest.
Beenden Sie den Installationsprozess.
Seit MySQL 3.23.38 enthält die Windows-Distribution sowohl
die normalen als auch die
MySQL-Max-Binärdateien. Der
wichtigste Vorteil der Benutzung der normalen
mysqld.exe
-Binärdatei liegt darin, dass
sie etwas schneller ist und weniger Ressourcen belegt.
Hier ist eine Liste der unterschiedlichen MySQL-Server, die Sie benutzen können:
mysqld | Kompiliert mit komplettem Debugging und automatischer Überprüfung der Speicherzuordnung (memory allocation), symbolischen Links, InnoDB- und BDB-Tabellen. |
mysqld-opt | Optimierte Binärdistribution ohne Unterstützung von Transaktionstabellen. |
mysqld-nt | Optimierte Binärdatei für NT mit Unterstützung von Named Pipes. Man kann diese Version auf Windows 98 laufen lassen, aber in diesem Fall werden keine Named Pipes angelegt und man muss TCP/IP installiert haben. |
mysqld-max | Optimierte Binärdistribution mit Unterstützung symbolischer Links, InnoDB und BDB-Tabellen. |
mysqld-max-nt | Wie mysqld-max , aber mit Unterstützung von Named
Pipes kompiliert. |
Alle genannten Binärdistributionen sind für den Pentium Pro Prozessor optimiert, sollten aber auf jedem Intel-Prozessor >= 386 laufen.
ACHTUNG: Wenn Sie InnoDB-Tabellen benutzen wollen, müssen Sie
bestimmte Start-Optionen in Ihrer
my.ini
-Datei festlegen! See
Abschnitt 8.5.2, „Mit InnoDB anfangen - Optionen“.
Sehen Sie wegen Informationen zur aktuellen Version und für Download-Anweisungen auf MySQL home page nach.
Unser Haupt-Mirror-Server für den Download ist hier:
http://mirrors.sunsite.dk/mysql/
Wenn Sie Interesse haben, eine MySQL-Mirror-Site beizusteuern,
können Sie anonymes rsync mit
rsync://sunsite.dk/ftp/mirrors/mysql/
machen.
Schicken Sie bitte eine E-Mail an
<webmaster@mysql.com>
und geben Sie uns Bescheid,
wo Ihr Mirror liegt, damit wir ihn der unten stehenden Liste
hinzufügen können.
Wenn Sie Probleme beim Download von unserer Hauptseite aus haben, probieren Sie eine der unten stehenden Mirror-Sites.
Geben Sie bitte <webmaster@mysql.com>
Bescheid,
wenn Sie auf schlechte oder veraltete Mirror-Sites stoßen.
Wir benutzen GNU Autoconf, daher ist es möglich, MySQL auf alle modernen Betriebssysteme zu portieren, auf denen Posix-Threads und ein C++-Kompiler funktionieren. (Um nur den Client-Code zu kompilieren, wir lediglich ein C++-Kompiler benötigt.) Wir benutzen und entwickeln die Software selbst hauptsächlich auf Sun Solaris (Versionen 2.5 - 2.7) und SuSE Linux Version 7.x.
Beachten Sie, dass die native Thread-Unterstützung für viele Betriebssysteme nur mit den neuesten Versionen funktioniert. Es wurde berichtet, dass MySQL erfolgreich auf folgenden Betriebssystemen / Thread-Paket-Kombinationen kompiliert wurde:
AIX 4.x mit nativen Threads. See Abschnitt 3.6.6.4, „Anmerkungen zu IBM-AIX“.
Amiga.
BSDI 2.x mit enthaltenem MIT-pThreads-Paket. See Abschnitt 3.6.4.6, „Anmerkungen zu BSD/OS“.
BSDI 3.0, 3.1 und 4.x mit nativen Threads. See Abschnitt 3.6.4.6, „Anmerkungen zu BSD/OS“.
DEC Unix 4.x mit nativen Threads. See Abschnitt 3.6.6.6, „Anmerkungen zu Alpha-DEC-UNIX (Tru64)“.
FreeBSD 2.x mit enthaltenem MIT-pThreads-Paket. See Abschnitt 3.6.4.1, „Anmerkungen zu FreeBSD“.
FreeBSD 3.x und 4.x mit nativen Threads. See Abschnitt 3.6.4.1, „Anmerkungen zu FreeBSD“.
HP-UX 10.20 mit enthaltenem MIT-pThreads-Paket. See Abschnitt 3.6.6.2, „Anmerkungen zu HP-UX Version 10.20“.
HP-UX 11.x mit nativen Threads. See Abschnitt 3.6.6.3, „Anmerkungen zu HP-UX Version 11.x“.
Linux 2.0+ mit LinuxThreads 0.7.1+ oder
glibc
2.0.7+. See
Abschnitt 3.6.1, „Linux (alle Linux-Versionen)“.
Mac OS X Server. See Abschnitt 3.6.5, „Anmerkungen zu Mac OS X“.
NetBSD 1.3/1.4 Intel und NetBSD 1.3 Alpha (benötigt GNU make). See Abschnitt 3.6.4.2, „Anmerkungen zu NetBSD“.
OpenBSD > 2.5 mit nativen Threads. OpenBSD < 2.5 mit enthaltenem MIT-pThreads-Paket. See Abschnitt 3.6.4.3, „Anmerkungen zu OpenBSD“.
OS/2 Warp 3, FixPack 29 und OS/2 Warp 4, FixPack 4. See Abschnitt 3.6.7, „Anmerkungen zu OS/2“.
SGI Irix 6.x mit nativen Threads. See Abschnitt 3.6.6.8, „Anmerkungen zu SGI Irix“.
Solaris 2.5 und höher mit nativen Threads auf SPARC und x86. See Abschnitt 3.6.3, „Anmerkungen zu Solaris“.
SunOS 4.x mit enthaltenem MIT-pThreads-Paket. See Abschnitt 3.6.3, „Anmerkungen zu Solaris“.
Caldera (SCO) OpenServer mit einem aktuellen Port des FSU-PThreads-Pakets. See Abschnitt 3.6.6.9, „Anmerkungen zu Caldera“.
Caldera (SCO) UnixWare 7.0.1. See Abschnitt 3.6.6.10, „Anmerkungen zu Caldera Unixware Version 7.0“.
Tru64 Unix
Windows 95, Windows 98, NT und Windows 2000. See Abschnitt 3.6.2, „Anmerkungen zu Windows“.
Beachten Sie, dass nicht alle Plattformen gleichermaßen gut geeignet sind, um MySQL laufen zu lassen. Wie gut eine bestimmte Plattform für hohe Last und geschäftskritische Anwendungen geeignet ist, hängt von folgenden Faktoren ab:
Allgemeine Stabilität der Thread-Bibliothek. Eine Plattform mag in anderer Hinsicht einen exzellenten Ruf haben, aber wenn die Thread-Bibliothek unstabil ist, die von MySQL aufgerufen wird, läuft MySQL nur so stabil wie die Thread-Bibliothek, selbst wenn alles Sonstige perfekt ist.
Fähigkeit des Kernels und / oder der Thread-Bibliothek, die Vorteile von SMP auf Mehrprozessor-Systemen wahrzunehmen. Mit anderen Worten: Wenn ein Prozess einen Thread anlegen, sollte es für diesen Thread möglich sein, auf anderen Prozessoren zu laufen als der Original-Prozess.
Fähigkeit des Kernels und / oder der Thread-Bibliothek,
viele Threads laufen zu lassen, die häufig einen Mutex
über eine kurze, kritische Region anlegen / lösen können
ohne exzessive Kontext-Umschaltungen. Mit anderen Worten:
Wenn die Implementation von
pThread_mutex_lock()
zu sehr darauf
bedacht ist, CPU zu erlangen, wird das MySQL gewaltig
schmerzen. Wenn man sich dieser Tatsache nicht bewusst ist,
machen zusätzliche Prozessoren MySQL in der Tat langsamer.
Allgemeine Stabilität und Performance des Dateisystems.
Fähigkeit des Dateisystems, überhaupt mit großen Dateien umgehend zu können, und zwar effizient, wenn Ihre Tabellen Groß sind.
Unser Grad von Erfahrung, hier bei MySQL AB, mit der Plattform. Wenn wir eine Plattform gut kennen, setzen wir plattformspezifische Optimierungen / Verbesserungen (Fixes) ein, die zur Kompilierzeit aktiv werden. Darüber hinaus können wir Sie beraten, wie Sie Ihr System optimal für MySQL konfigurieren.
Umfang des Testens ähnlicher Konfigurationen, das wir intern durchgeführt haben.
Anzahl von Benutzern, die MySQL auf dieser Plattform erfolgreich mit ähnlichen Konfigurationen haben laufen lassen. Wenn diese Zahl Groß ist, ist die Wahrscheinlichkeit viel geringer, plattformspezifische Überraschungen zu erleben.
Nach den genannten Kriterien sind die besten Plattformen für
MySQL bislang x86 mit SuSE Linux 7.1, 2.4 Kernel und ReiserFS
(oder jede ähnliche Linux-Distribution) und Sparc mit Solaris
2.7 oder 2.8. FreeBSD kommt als drittes, aber wir hoffen
wirklich, dass es zur Spitze aufschließt, sobald erst einmal
die Thread-Bibliothek verbessert ist. Wir hoffen auch, dass wir
alle anderen Plattformen, auf denen MySQL kompiliert werden kann
und korrekt läuft, die aber nicht ganz denselben Grad an
Stabilität und Performance aufweisen, in die Spitzenkategorie
aufnehmen können. Das erfordert von unserer Seite aus einige
Kooperationsbemühungen mit den Entwicklern der
Betriebssystem-Bibliothek-Komponenten, von denen MySQL abhängt.
Wenn Sie Interesse daran haben, eine dieser Komponenten zu
verbessern und in der Lage sind, ihre Entwicklung zu
beeinflussen, und detailliertere Informationen darüber
brauchen, was MySQL benötigt, um besser zu laufen, schicken Sie
eine E-Mail an <internals@lists.mysql.com>
.
Beachten Sie bitte auch, dass der obige Vergleich nichts darüber aussagen will, dass ein Betriebssystem allgemein besser oder schlechter als ein anderes sei. Wir reden hier über die Auswahl eines bestimmten Betriebssystems für einen ganz bestimmten Zweck - nämlich, MySQL laufen zu lassen, und vergleichen die Betriebssysteme nur in dieser Hinsicht. Folglich wäre das Ergebnis dieses Vergleichs ein anderes, wenn wir weitere Belange berücksichtigen würden. In manchen Fällen liegt der Grund, warum ein Betriebssystem besser als ein anderes geeignet ist, schlicht darin, dass wir auf dieser speziellen Plattform mehr Tests und Optimierungen durchgeführt haben. Wir stellen hier nur unsere Beobachtungen dar, um Ihnen bei der Entscheidung zu helfen, auf welcher Plattform Sie MySQL benutzen sollten.
Zunächst müssen Sie entscheiden, ob Sie das letzte Entwicklungs-Release oder das letzte stabile Release benutzen wollen:
Normalerweise, wenn Sie MySQL zum ersten Mal benutzen, oder wenn Sie versuchen, MySQL auf ein System zu portieren, für das es keine Binärdistribution gibt, empfehlen wir, das stabile (stable) Release zu nehmen. Beachten Sie, dass alle MySQL-Releases mit den MySQL-Benchmarks und einer umfassenden Test-Suite getestet sind, bevor das Release heraus gegeben wird.
Wenn Sie ein altes System laufen lassen und es aktualisieren möchten, aber nicht riskieren wollen, dass ein Update nicht reibungslos klappt, sollten Sie zur aktuellsten Version des Zweiges aktualisieren, den Sie benutzen (bei dem nur die letzte Versionsnummer neuer ist als Ihre, also z. B. von 3.23.36 auf 3.23.44, wenn 3.23.44 die neueste Version des Zweigs ist). Wir haben uns innerhalb der Versions-Zweige bemüht, nur schwere Fehler zu beseitigen und kleine, relativ sichere Änderungen zu machen.
Als nächstes müssen Sie entscheiden, ob Sie eine Quelldistribution oder eine Binärdistribution nehmen wollen. In den meisten Fällen ist es ratsam, eine Binärdistribution zu nehmen, wenn eine für Ihre Plattform existiert, weil sich diese im Allgemeinen leichter installieren läßt als eine Quelldistribution.
In folgenden Fällen fahren Sie mit einer Quellinstallation wahrscheinlich besser:
Wenn Sie MySQL an einer ganz bestimmten Stelle installieren wollen. (Die Standard-Binärdistributionen sind an jeder Stelle lauffähig, aber vielleicht wollen Sie noch mehr Flexibilität haben.)
Um unterschiedlichen Bedürfnissen von Benutzern entgegen zu
kommen, stellen wir zwei unterschiedliche Binärversionen
zur Verfügung: Eine, die mit den nicht transaktionalen
Tabellen-Handlern kompiliert ist (eine kleine, schnelle
Binärdatei), sowie eine, die mit den wichtigsten
erweiterten Optionen wie transaktionssicheren Tabellen
kompiliert ist. Beide Versionen sind aus derselben
Quelldistribution kompiliert. Alle nativen
MySQL
-Clients können sich mit beiden
MySQL-Versionen verbinden.
Die erweiterte MySQL-Binärdistribution ist mit dem
-max
-Suffix gekennzeichnet und ist mit
denselben Optionen konfiguriert wie
mysqld-max
. See
Abschnitt 5.7.5, „mysqld-max, ein erweiterter mysqld-Server“.
Wenn Sie das MySQL-Max
-RPM benutzen
wollen, müssen Sie zuerst das
Standard-MySQL
-RPM installieren.
Wenn Sie mysqld
mit einigen zusätzlichen
Features konfigurieren wollen, die NICHT in den
Standard-Binärdistributionen enthalten sind. Hier ist eine
Liste der gebräuchlichsten Zusatzoptionen, die Sie
vielleicht nutzen wollen:
--with-berkeley-db
--with-innodb
--with-raid
--with-libwrap
--with-named-z-lib (ist in einigen
Binärdateien enthalten)
--with-debug[=full]
Die vorgabemäßige Binärdistribution wird normalerweise mit Unterstützung für alle Zeichensätze kompiliert und sollte auf einer Vielzahl von Prozessoren derselben Prozessorfamilie laufen.
Wenn Sie einen schnelleren MySQL-Server erhalten wollen,
können Sie ihn erneut kompilieren und nur die Zeichensätze
benutzen, die Sie brauchen. Sie können auch einen besseren
Kompiler (wie pgcc
) oder andere
Kompilieroptionen benutzen, die besser auf Ihren Prozessor
optimiert sind.
Wenn Sie einen Bug gefunden und dem MySQL-Entwicklungsteam mitgeteilt haben, werden Sie wahrscheinlich einen Patch erhalten, den Sie mit der Quelldistribution verwenden müssen, um den Bug zu beheben.
Wenn Sie den C- und C++-Code lesen (und / oder ändern) wollen, aus dem MySQL besteht, müssten Sie eine Quelldistribution laden. Der Quellcode ist immer das ''letzte Handbuch''. Quelldistributionen enthalten auch mehr Tests und Beispiele als Binärdistributionen.
Das MySQL Benennungsschema benutzt Release-Nummern, die aus drei
Zahlen und einem Suffix bestehen. Ein Release-Name wie
mysql-3.21.17-beta
zum Beispiel wird wie
folgt interpretiert:
Die erste Zahl (3
) beschreibt das
Dateiformat. Alle Version-3-Releases haben dasselbe
Dateiformat.
Die zweite Zahl (21
) ist die
Release-Ebene (Level). Normalerweise kann man hier zwischen
zweien auswählen. Einer ist der stabile Zweig des Releases
(aktuell 23
), der andere ist der
Entwicklungs-Zweig (aktuell 4.0
).
Normalerweise sind beide stabil, aber die
Entwicklungsversion kann Macken oder fehlende Dokumentation
neuer Features haben oder sich auf einigen Systemen nicht
kompilieren lassen.
Die dritte Zahl (17
) ist die
Versionsnummer innerhalb der Release-Ebene. Diese wird für
jede neue Distribution hochgezählt. Üblicherweise werden
Sie die neueste Version der Release-Ebene einsetzen wollen,
die Sie gewählt haben.
Das Suffix (beta
) zeigt den
Stabilitätsgrad des Releases an. Mögliche Suffixe sind:
alpha
zeigt an, dass das Release
größere Abschnitte von neuem Code enthält, der noch
nicht zu 100% getestet wurde. Bekannte Bugs
(üblicherweise gibt es keine) sind im News-Abschnitt
dokumentiert. See Anhang C, MySQL-Änderungsverlauf (Change History). In den meisten
Alpha-Releases gibt es neue Befehle und Erweiterungen.
Bei einem Alpha-Release können durch aktive
Weiterentwicklung größere Code-Änderungen vorkommen,
aber alles wird getestet, bevor ein Release
veröffentlicht wird. Es sollte in keinem MySQL-Release
bekannte Bugs geben.
beta
bedeutet, dass jeglicher neue
Code getestet wurde. Es wurden keine neuen Features
hinzugefügt, die bei altem Code Probleme verursachen
könnten. Es sollte keine bekannten Bugs geben. Eine
Version wird von Alpha auf Beta gesetzt, wenn innerhalb
der Alpha-Version mindestens einen Monat lang keine
schweren Fehler mehr berichtet wurden. Wir planen für
eine solche Version dann keine neuen Features mehr, die
einen alten Befehl unzuverlässiger machen könnten.
gamma
ist eine Beta-Version, die eine
ganze Weile draussen war und offensichtlich gut
funktioniert. Nur kleinere Problembehebungen wurden
hinzugefügt. So etwas nennen viele andere Unternehmen
ein Release.
Wenn eine Version kein Suffix besitzt, bedeutet das, dass diese Version schon eine ganze Weile auf vielen unterschiedlichen Sites eingesetzt wird, wobei keine Bugs ausser plattformspezifischen Bugs berichtet wurden. Für ein solches Release werden nur kritische Fehlerbehebungen durchgeführt. So etwas nennen wir ein stabiles Release.
Alle Versionen von MySQL laufen durch unsere Standard-Tests und -Benchmarks, um sicherzustellen, dass man sie relativ sicher benutzen kann. Weil die Standard-Tests im Laufe der Zeit erweitert werden, um auf alle früher gefundenen Bugs zu prüfen, wird die Test-Suite immer besser.
Beachten Sie, dass alle Releases mindestens wie folgt getestet wurden:
Mit der internen Test-Suite
Diese ist Teil unseres Produktionssystems für einen Kunden. Sie besitzt viele Tabellen mit Hunderten Megabytes an Daten.
Mit der MySQL-Benchmark-Suite
Diese läßt eine Reihe gebräuchlicher Anfragen laufen. Das ist zusätzlich ein Test darauf, ob die letzten Optimierungen den Code tatsächlich schneller gemacht haben. See Abschnitt 6.1.4, „Die MySQL-Benchmark-Suite“.
Mit dem crash-me
-Test
Dieser Test versucht festzustellen, welche Features die Datenbank unterstützt und was ihre Fähigkeiten und Beschränkungen sind. See Abschnitt 6.1.4, „Die MySQL-Benchmark-Suite“.
Ein weiterer Test besteht darin, dass wir die neueste MySQL-Version in unserer internen Entwicklungsumgebung einsetzen, mindestens auf einer Maschine. Wir arbeiten hierbei mit mehr als 100 Gigabytes an Daten.
Dieser Abschnitt beschreibt das vorgabemäßige Layout der Verzeichnisse, die durch die Installation von Binär- und Quelldistributionen angelegt werden.
Eine Binärdistribution wird installiert, indem sie an die
Installationsstelle entpackt wird, die Sie auswählen (typischer
Weise /usr/local/mysql
). Die Installation
erstellt folgende Verzeichnisse an dieser Stelle:
Verzeichnis | Verzeichnisinhalt |
bin | Client-Programme und der mysqld -Server |
data | Log-Dateien, Datenbanken |
include | Include-(Header)-Dateien |
lib | Bibliotheken |
scripts | mysql_install_db |
share/mysql | Dateien mit Fehlernachrichten |
sql-bench | Benchmarks |
Eine Quelldistribution wird installiert, nachdem Sie sie
konfiguriert und kompiliert haben. Vorgabemäßig werden Dateien
unter /usr/local
installiert, und zwar in
den folgenden Unterverzeichnissen:
Verzeichnis | Verzeichnisinhalt |
bin | Client-Programme und -Skripte |
include/mysql | Include-(Header)-Dateien |
info | Dokumentation im Info-Format |
lib/mysql | Bibliotheken |
libexec | Der mysqld -Server |
share/mysql | Dateien mit Fehlernachrichten |
sql-bench | Benchmarks und crash-me -Test |
var | Datenbanken und Log-Dateien |
Innerhalb eines Installationsverzeichnisses weicht das Layout einer Quellinstallation von dem einer Binärinstallation wie folgt ab:
Der mysqld
-Server wird in das
libexec
-Verzeichnis installiert und
nicht in das bin
-Verzeichnis.
Das Daten-Verzeichnis ist var
und nicht
data
.
mysql_install_db
wird in das
/usr/local/bin
Verzeichnis installiert
und nicht in /usr/local/mysql/Skripts
.
Die Header-Datei und Bibliotheksverzeichnisse sind
include/mysql
und
lib/mysql
und nicht
include
und lib
.
Sie können Ihre eigene Binärinstallation aus einer
kompilierten Quelldistribution erzeugen, indem Sie das Skript
Skripts/make_binary_Distribution
ausführen.
MySQL entwickelt sich ziemlich schnell hier bei MySQL AB und wir wollen, dass andere MySQL-Benutzer daran teilhaben. Wir versuchen, immer dann ein neues Release heraus zu bringen, wenn wir sehr nützliche Features haben, für die offensichtlich ein Bedarf besteht.
Auch versuchen wir, unseren Benutzern zu helfen, wenn Sie nach Features anfragen, die einfach zu implementieren sind. Wir notieren, was unsere lizensierten Nutzer haben wollen, und insbesondere, was unsere Benutzer mit erweitertem E-Mail-Support haben wollen, und versuchen ihnen, eben das zu bieten.
Niemand muss einen neuen Release herunter laden. Im News-Abschnitt steht stets, ob das neue Release etwas beinhaltet, was Sie wirklich brauchen. See Anhang C, MySQL-Änderungsverlauf (Change History).
Wenn wir MySQL aktualisieren, fahren wir folgende Politik:
Bei kleineren Updates wird die letzte Zahl (von rechts) in der Versionsnummer herauf gezählt (Minor Release). Wenn es größere neue Features gibt oder kleinere Inkompatibilitäten mit vorherigen Versionen, wird die zweite Zahl der Versionsnummer herauf gezählt (Major Release). Wenn sich das Dateiformat ändert, wird die erste Zahl herauf gezählt.
have to do with "small bugs" => minor releases? Stable tested releases are meant to appear about 1-2 times a year, but if small bugs are found, a release mit only bug fixes will be released. Als stabil getestete Releases sollten etwa ein- bis zweimal im Jahr erscheinen, aber wenn kleinere Fehler gefunden werden, wird nur ein Release mit Bug-Fixes heraus gegeben.
Funktionierende Releases sollten etwa alle 1 bis 8 Wochen erscheinen.
Binärdistributionen für einige Plattformen werden von uns für größere Releases (Major) heraus gegeben. Andere Leute stellen vielleicht auch Binärdistributionen für andere Systeme her, aber nicht so häufig.
Patches stellen wir üblicherweise zur Verfügung, sobald wir kleinere Bugs ausfindig gemacht und behoben haben.
Für nicht kritische, aber störende Bugs machen wir Patches verfügbar, wenn sie uns zugesandt werden. Ansonsten kombinieren wir mehrere davon in einem größeren Patch.
Wenn durch unglückliche Umstände ein Release einen schweren Fehler enthält, erstellen wir sobald wie möglich ein neues Release. Das würden wir auch gern bei anderen Unternehmen so sehen.
The current stable release ist Version 3.23; We have already moved active Entwicklung to Version 4.0. Bugs will still be fixed in the stable version. We don't believe in a complete freeze, as this also leaves out bug fixes und things that ``must be done.'' ``Somewhat frozen'' means that we may add small things that ``almost surely will not affect anything that's already working.''
Als Service stellen wir bei MySQL AB einen Satz von Binärdistributionen von MySQL zur Verfügung, die auf unserer Site kompiliert wurden oder auf Sites von Kunden, die uns freundlicherweise Zugang zu Ihren Maschinen gewährt haben.
Diese Distributionen werden mit
Skripts/make_binary_distribution
erzeugt und
mit folgenden Kompilern und Optionen konfiguriert:
SunOS 4.1.4 2 sun4c mit gcc
2.7.2.1
CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors"
./configure --prefix=/usr/local/mysql --disable-shared
--with-extra-charsets=complex --enable-assembler
SunOS 5.5.1 (und höher) sun4u mit egcs
1.0.3a oder 2.90.27 oder gcc 2.95.2 und neuer
CC=gcc CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3
-felide-constructors -fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --with-low-memory
--with-extra-charsets=complex --enable-assembler
SunOS 5.6 i86pc mit gcc
2.8.1
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql --with-low-memory
--with-extra-charsets=complex
Linux 2.0.33 i386 mit pgcc
2.90.29
(egcs
1.0.3a)
CFLAGS="-O3 -mpentium -mstack-align-double" CXX=gcc
CXXFLAGS="-O3 -mpentium -mstack-align-double
-felide-constructors -fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --enable-assembler
--with-mysqld-ldflags=-all-static
--with-extra-charsets=complex
Linux 2.2.x mit x686 mit gcc
2.95.2
CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3
-mpentiumpro -felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql --enable-assembler
--with-mysqld-ldflags=-all-static --disable-shared
--with-extra-charset=complex
SCO 3.2v5.0.4 i386 mit gcc
2.7-95q4
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex
AIX 2 4 mit gcc
2.7.2.2
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex
OSF1 V4.0 564 alpha mit gcc
2.8.1
CC=gcc CFLAGS=-O CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql --with-low-memory
--with-extra-charsets=complex
Irix 6.3 IP32 mit gcc
2.8.0
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex
BSDI BSD/OS 3.1 i386 mit gcc
2.7.2.1
CC=gcc CXX=gcc CXXFLAGS=-O ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex
BSDI BSD/OS 2.1 i386 mit gcc
2.7.2
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex
Wenn jemand optimalere Optionen für die obigen Konfigurationen
hat, können diese jederzeit der Entwickler-Mailing-Liste unter
<internals@lists.mysql.com>
mitgeteilt werden.
RPM-Distributionen von MySQL-Version 3.22 wurden durch Benutzer beigesteuert. Ab Version 3.22 werden die RPMs von uns bei MySQL AB erzeugt.
Wenn Sie eine Debug-Version von MySQL kompilieren wollen,
müssen Sie den oben genannten Kompilierzeilen
--with-debug
oder
--with-debug=full
hinzufügen und jegliche
-fomit-frame-pointer
-Optionen entfernen.
Bevor Sie mit der Quellinstallation fortfahren, sehen Sie nach, ob eine Binärdistribution für Ihre Plattform verfügbar ist, die so wie Sie wollen funktioniert. Wir geben uns viel Mühe, die Binärdistributionen mit den bestmöglichen Optionen zu bauen.
Sie benötigen folgende Werkzeuge, um MySQL aus der Quelldistribution zu bauen und zu installieren:
GNU gunzip
, um die Distribution zu
entpacken.
Ein vernünftiges tar
, um die Distribution
zu entpacken. Von GNU tar
ist bekannt, dass
es funktioniert. Sun tar
ist dafür
bekannt, dass es Probleme verursacht.
Einen funktionierenden ANSI-C++-Kompiler.
gcc
>= 2.95.2, egcs
>= 1.0.2 oder egcs 2.91.66
, SGI C++ und
SunPro C++ sind einige der Kompiler, von denen bekannt ist,
dass sie funktionieren. libg++
wird nicht
benötigt, wenn Sie gcc
benutzen.
gcc
2.7.x hat einen Bug, der es
verunmöglicht, einige perfekt der vorgeschriebenen Form
entsprechende C++-Dateien zu kompilieren, zum Beispiel
sql/sql_base.cc
. Wenn Sie nur
gcc
2.7.x zur Verfügung haben, müssen Sie
Ihren gcc
aktualisieren, um MySQL
kompilieren zu können. gcc
2.8.1 ist
ebenfalls für Probleme auf einigen Plattformen bekannt, daher
sollten Sie auch diesen vermeiden, wenn Sie einen neueren
Kompiler für diese Plattform zur Verfügung haben.
gcc
>= 2.95.2 wird für das Kompilieren
von MySQL-Versionen 3.23.x empfohlen.
Ein gutes make
-Programm. GNU
make
wird stets empfohlen und ist manchmal
erforderlich. Wenn Sie Probleme bekommen, empfehlen wir, es
mit GNU make
3.75 oder neuer zu versuchen.
Wenn Sie eine aktuelle Version von
gcc verwenden (aktuell genug, um
die -fno-exceptions
-Option zu verstehen), ist
es SEHR WICHTIG, dass Sie diese
Option benutzen. Ansonsten könnte es sein, dass Sie eine
Binärdatei kompilieren, die zu zufälligen Zeitpunkten abstürzt.
Wir empfehlen zusätzlich, dass Sie
-felide-contructors
und
-fno-rtti
zusammen mit
-fno-exceptions
benutzen. Im Zweifel gehen Sie
wie folgt vor:
CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static
Für die meisten Systeme werden Sie dadurch eine schnelle, stabile Binärinstallation erhalten.
Wenn Sie Probleme bekommen, BITTE BENUTZEN
SIE IMMER mysqlbug
zum Fragenstellen
die Liste <mysql@lists.mysql.com>
. Selbst wenn das
Problem kein Bug ist, sammelt mysqlbug
Systeminformationen, die anderen helfen werden, Ihr Problem zu
lösen. Wenn Sie mysqlbug
nicht benutzen,
verringern Sie die Möglichkeit, eine Lösung Ihres Problems zu
bekommen! mysqlbug
finden Sie im
scripts
-Verzeichnis, nachdem Sie die
Distribution entpackt haben. See Abschnitt 2.6.2.3, „Wie man Bugs oder Probleme berichtet“.
Die grundlegenden Befehle, die Sie ausführen müssen, um eine MySQL-Quelldistribution zu installieren, sind:
shell>groupadd mysql
shell>useradd -g mysql mysql
shell>gunzip < mysql-VERSION.tar.gz | tar -xvf -
shell>cd mysql-VERSION
shell>./configure --prefix=/usr/local/mysql
shell>make
shell>make install
shell>scripts/mysql_install_db
shell>chown -R root /usr/local/mysql
shell>chown -R mysql /usr/local/mysql/var
shell>chgrp -R mysql /usr/local/mysql
shell>cp support-files/my-medium.cnf /etc/my.cnf
shell>/usr/local/mysql/bin/safe_mysqld --user=mysql &
Wenn Sie Unterstützung für InnoDB-Tabellen haben wollen,
sollten Sie die Datei /etc/my.cnf
editieren
und die ‘#
’-Zeichen vor den
Parametern entfernen, der mit innodb_...
beginnen. See Abschnitt 5.1.2, „my.cnf-Optionsdateien“. See
Abschnitt 8.5.2, „Mit InnoDB anfangen - Optionen“.
Wenn Sie mit einem Quell-RPM anfangen, gehen Sie wie folgt vor:
shell> rpm --rebuild MySQL-VERSION.src.rpm
Das erzeugt ein Binär-RPM, das Sie installieren können.
Sie können neue Benutzer hinzufügen, indem Sie das
bin/mysql_setpermission
-Skript benutzen,
falls Sie die DBI
- und
Msql-Mysql-modules
-Perl-Module installieren.
Eine detailliertere Beschreibung folgt.
Um eine Quelldistribution zu installieren, führen Sie die unten stehenden Schritte aus und gehen dann weiter zu Abschnitt 3.4, „Einstellungen und Tests nach der Installation“, um die Schritte nach der Installation und ein paar Tests durchzuführen.
Wählen Sie das Verzeichnis, in dem Sie die Distribution entpacken wollen, und wechseln Sie dort hinein.
Holen Sie sich eine Distributionsdatei von einer der Sites, die unter Abschnitt 3.2.1, „Wie man MySQL erhält“ aufgelistet sind.
Wenn Sie Berkeley-DB-Tabellen mit MySQL verwenden wollen, müssen Sie sich eine gepatchte Version des Berkeley-DB-Quellcodes besorgen. Bitte lesen Sie das Kapitel über Berkeley-DB-Tabellen, bevor Sie fortfahren. See Abschnitt 8.6, „BDB- oder Berkeley_db-Tabellen“.
MySQL-Quelldistributionen stehen als komprimierte
tar
-Archive zur Verfügung und haben
Namen wie mysql-VERSION.tar.gz
, wobei
VERSION
eine Zahl ist, wie 5.0.6-beta.
Fügen Sie einen Benutzer (User) und eine Gruppe (Group)
hinzu, unter dem / der mysqld
laufen
soll:
shell>groupadd mysql
shell>useradd -g mysql mysql
Diese Befehle fügen den Benutzer mysql
und die Gruppe mysql
hinzu. Die Syntax
für useradd
und
groupadd
kann sich auf unterschiedlichen
Unix-Systemen geringfügig unterscheiden. Die Befehle
können adduser
und
addgroup
heißen. Wenn Sie wollen,
können Sie Benutzer und Gruppe auch anders nennen als
mysql
.
Entpacken Sie die Distribution ins aktuelle Verzeichnis:
shell> gunzip < /pfad/zu/mysql-VERSION.tar.gz | tar xvf -
Dieser Befehl erzeugt ein Verzeichnis namens
mysql-VERSION
.
Wechseln Sie in das oberste Verzeichnis der entpackten Distribution:
shell> cd mysql-VERSION
Beachten Sie, dass Sie aktuell MySQL aus diesem obersten Verzeichnis konfigurieren und bauen müssen. Sie können MySQL nicht in ein anderes Verzeichnis bauen.
Konfigurieren Sie das Release und kompilieren Sie alles:
shell>./configure --prefix=/usr/local/mysql
shell>make
Wenn Sie configure
laufen lassen, können
Sie dabei einige Optionen angeben. Geben Sie
./configure --help
ein, um eine Liste von
Optionen zu erhalten. Abschnitt 3.3.3, „Typische configure
-Optionen“
erörtert einige der nützlicheren Optionen.
Wenn configure
fehlschlägt und Sie sich
wegen Hilfe an <mysql@lists.mysql.com>
wenden,
geben Sie bitte alle Zeilen aus
config.log
an, von denen Sie annehmen,
dass sie bei der Problembehebung hilfreich sein könnten.
Fügen Sie auch die letzten Zeilen der Ausgabe von
configure
hinzu, wenn
configure
abbricht. Schicken Sie den
Bug-Bericht ein, indem Sie das
mysqlbug
-Skript benutzen. See
Abschnitt 2.6.2.3, „Wie man Bugs oder Probleme berichtet“.
Wenn das Kompilieren fehlschlägt, sehen Sie unter Abschnitt 3.3.5, „Probleme beim Kompilieren?“ nach, was bei einer Reihe geläufiger Probleme hilft.
Installieren Sie alles:
shell> make install
Eventuell müssen Sie diesen Befehl als
root
ausführen.
Erzeugen Sie die MySQL-Berechtigungstabellen (Grant Tables, nur notwendig, wenn Sie MySQL noch nie vorher installiert haben):
shell> scripts/mysql_install_db
Beachten Sie, dass bei MySQL-Versionen vor Version 3.22.10
der MySQL-Server startet, wenn Sie
mysql_install_db
laufen lassen. Das gilt
für neuere Versionen nicht mehr!
Ändern Sie den Besitzer der Binärdateien zu
root
und den Besitzer des
Daten-Verzeichnisses zu dem Benutzer, unter dem Sie
mysqld
laufen lassen wollen:
shell>chown -R root /usr/local/mysql
shell>chown -R mysql /usr/local/mysql/var
shell>chgrp -R mysql /usr/local/mysql
Der erste Befehl ändert die
owner
-Attribute der Dateien auf den
Benutzer root
, der zweite ändert die
owner
-Attribute des Daten-Verzeichnisses
auf den Benutzer mysql
und der dritte
ändert die group
-Attribute auf die
Gruppe mysql
.
Wenn Sie die Unterstützung für die
Perl-DBI
/DBD
-Schnittstelle
hinzufügen wollen, sehen Sie unter Abschnitt 9.2, „MySQL-Perl-API“
nach.
Wenn Sie wollen, dass MySQL automatisch startet, wenn Sie
Ihre Maschine hoch fahren, kopieren Sie
support-files/mysql.server
an die Stelle,
wo Ihr System seine Startdateien hat. Weitere Informationen
finden Sie im
support-files/mysql.server
-Skript selbst
sowie unter Abschnitt 3.4.3, „MySQL automatisch starten und anhalten“.
Nachdem alles installiert wurde, sollten Sie Ihre Distribution initialisieren und testen:
shell> /usr/local/mysql/bin/safe_mysqld --user=mysql &
Wenn dieser Befehl sofort mit mysqld daemon
ended
fehlschlägt, finden Sie einige Informationen
dazu in der Datei
mysql-Daten-Verzeichnis/'hostname'.err
. Der
wahrscheinliche Grund ist der, dass bereits ein anderer
mysqld
-Server läuft. See
Abschnitt 5.1.4, „Viele MySQL-Server auf derselben Maschine laufen lassen“.
See Abschnitt 3.4, „Einstellungen und Tests nach der Installation“.
Manchmal erscheinen Patches auf der Mailing-Liste oder werden auf Patches-Bereich auf der MySQL-Website eingestellt.
Um einen Patch aus der Mailing-Liste anzuwenden, speichern Sie die Nachricht, in der der Patch enthalten ist, in eine Datei. Wechseln Sie dann ins oberste Verzeichnis Ihres MySQL-Source-Trees und geben Sie folgende Befehle ein:
shell>patch -p1 < patch-datei-name
shell>rm config.cache
shell>make clean
Patches von der FTP-Site werden als Klartextdateien (Plain Text)
oder als mit gzip
komprimierte Dateien
distribuiert. Ein Klartext-Patch wenden Sie genau so an, wie
oben für die Patches von der Mailing-Liste beschrieben. Um ein
komprimiertes Patch anzuwenden, wechseln Sie ins oberste
Verzeichnis Ihres MySQL-Source-Trees und geben Sie folgende
Befehle ein:
shell>gunzip < patch-datei-name.gz | patch -p1
shell>rm config.cache
shell>make clean
Nachdem Sie einen Patch angewendet haben, folgen Sie den
Anweisungen für eine normale Installation vom Quellcode, indem
Sie mit dem Schritt ./configure
anfangen.
Nach dem Schritt make install
, starten Sie
den MySQL-Server neu.
Es kann sein, dass Sie jeden laufenden Server anhalten müssen,
bevor Sie make install
laufen lassen können.
(Das machen Sie mit mysqladmin shutdown
.)
Einige Systeme lassen es nicht zu, dass eine neue
Programmversion installiert wird, wenn diese eine Version
ersetzt, die momentan ausgeführt wird.
Das configure
-Skript gibt Ihnen in großem
Umfang Kontrolle über die Konfigurationsmöglichkeiten Ihrer
MySQL-Distribution. Typischerweise machen Sie das unter
Verwendung der Optionen auf der
configure
-Kommandozeile. Sie können
ausserdem configure
beeinflussen, indem Sie
bestimmte Umgebungsvariablen benutzen. See
Anhang E, Umgebungsvariablen. Um eine Liste der
Optionen zu erhalten, die configure
unterstützt, geben Sie folgendes ein:
shell> ./configure --help
Einige der gebräuchlicheren
configure
-Optionen sind im Folgenden
beschrieben:
Um nur die MySQL-Client Bibliotheken und Client-Programme
und nicht den Server zu kompilieren, benutzen Sie die
--ohne-server
-Option:
shell> ./configure --without-server
Wenn Sie keinen C++-Kompiler haben, können Sie
mysql
nicht kompilieren (MySQL ist das
einzige Client-Programm, das C++ erfordert). In diesem Fall
können Sie den Code in configure
entfernen, der auf den C++-Kompiler testet, und dann
./configure
mit der
--without-server
-Option eingeben. Dieser
Kompilierschritt wird nach wie vor versuchen,
mysql
zu bauen, aber Sie können alle
Warnungen zu mysql.cc
ignorieren. (Wenn
make
anhält, versuchen Sie make
-k
, um ihm mitzuteilen, dass es mit dem Rest des
Builds fortfahren soll, auch wenn Fehler auftreten.)
Wenn Sie nicht wollen, dass Ihre Log-Dateien und
Datenbankverzeichnisse unter
/usr/local/var
liegen, benutzen Sie ein
configure
-Kommando wie folgendes:
shell>./configure --prefix=/usr/local/mysql
shell>./configure --prefix=/usr/local \
--localstatedir=/usr/local/mysql/data
Der erste Befehl ändert das Installationspräfix, so dass
alles unter /usr/local/mysql
statt
unter /usr/local
installiert wird. Der
zweite Befehl bewahrt das vorgabemäßige
Installationspräfix, aber überschreibt die vorgabemäßige
Stelle für Datenbankverzeichnisse (normalerweise
/usr/local/var
) und ändert sie zu
/usr/local/mysql/data
.
Wenn Sie Unix benutzen und wollen, dass der MySQL-Socket an
anderer Stelle liegt als vorgabemäßig (normalerweise im
Verzeichnis /tmp
oder
/var/run
), benutzen Sie ein
configure
-Kommando wie folgendes:
shell> ./configure --with-unix-socket-path=/usr/local/mysql/tmp/mysql.sock
Beachten Sie, dass die angegebene Datei mit einem absoluten
Pfadnamen angegeben werden muss! Sie können den Speicherort
von mysql.sock
auch später noch
ändern, indem Sie die MySQL Optionsdateien benutzen. See
Abschnitt A.4.5, „Wie Sie die MySQL-Socket-Datei /tmp/mysql.sock
schützen oder ändern“.
Wenn Sie statisch gelinkte Programme kompilieren wollen (um
zum Beispiel eine Binärdistribution zu machen, mehr
Geschwindigkeit zu erhalten oder Probleme mit
RedHat-Linux-Distributionen zu umgehen (Workaround)), geben
Sie configure
wie folgt ein:
shell>./configure --with-client-ldflags=-all-static \
--with-mysqld-ldflags=-all-static
Wenn Sie gcc
benutzen und
libg++
oder libstdc++
nicht installiert haben, können Sie
configure
mitteilen,
gcc
als Ihren C++-Kompiler zu benutzen:
shell> CC=gcc CXX=gcc ./configure
Wenn Sie gcc
als C++-Kompiler benutzen,
versucht dieser nicht, libg++
oder
libstdc++
zu linken.
Hier sind einige gebräuchliche Umgebungsvariablen, die man in Abhängigkeit vom verwendeten Kompiler setzen kann:
gcc 2.7.2.1 | CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors" |
egcs 1.0.3a | CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" |
gcc 2.95.2 | CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro -felide-constructors -fno-exceptions -fno-rtti" |
pgcc 2.90.29 oder newer | CFLAGS="-O3 -mpentiumpro -mstack-align-double" CXX=gcc CXXFLAGS="-O3 -mpentiumpro -mstack-align-double -felide-constructors -fno-exceptions -fno-rtti" |
In den meisten Fällen erhalten Sie eine ziemlich optimale MySQL-Binärdatei, indem Sie die Optionen von weiter oben nutzen und die folgenden Optionen zur Konfigurationszeile hinzufügen:
--prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static
Die komplette Konfigurationszeile würde also etwa wie folgt aussehen (für alle aktuellen gcc-Versionen):
CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static
Die Binärdistributionen, die wir auf der MySQL-Website unter http://www.mysql.com zur Verfügung stellen, sind allesamt mit voller Optimierung kompiliert und sollten daher für die meisten Benutzer perfekt sein. See Abschnitt 3.2.6, „MySQL-Binärdistributionen, die von MySQL AB kompiliert wurden“. Einiges können Sie noch fein justieren, um noch schnellere Binärdistributionen zu erhalten, aber das ist nur etwas für fortgeschrittene Benutzer. See Abschnitt 6.5.3, „Wie Kompilieren und Linken die Geschwindigkeit von MySQL beeinflusst“.
Wenn der Build fehlschlägt und Fehler produziert, die
aussagen, dass Ihr Kompiler oder Linker nicht in der Lage
ist, die gemeinsam benutzte (shared) Bibliothek
libmysqlclient.so.#
(‘#
’ ist eine Versionsnummer)
zu erzeugen, können Sie dieses Problem umgehen, indem Sie
die --disable-shared
-Option von
configure
benutzen. In diesem Fall baut
configure
keine gemeinsam benutzte
libmysqlclient.so.#
-Bibliothek.
Sie können MySQL so konfigurieren, dass keine
DEFAULT
-Spaltenwerte für
Nicht-NULL
-Spalten benutzt werden (also
Spalten, bei denen nicht zulässig ist, dass sie
NULL
sind). Das führt dazu, dass
INSERT
-Statements einen Fehler erzeugen,
ausser wenn ausdrücklich Werte für Spalten angegeben
werden, die einen Nicht-NULL
-Werte
verlangen. Um die Benutzung von Vorgabewerten zu
unterdrücken, geben Sie configure
wie
folgt ein:
shell> CXXFLAGS=-DDONT_USE_DEFAULT_FIELDS ./configure
Als Vorgabe benutzt MySQL den Zeichensatz ISO-8859-1
(Latin1). Um diesen Vorgabesatz zu ändern, benutzen Sie die
--with-charset
-Option:
shell> ./configure --with-charset=CHARSET
CHARSET
kann einer der folgenden sein:
big5
, cp1251
,
cp1257
, czech
,
danish
, dec8
,
dos
, euc_kr
,
gb2312
, gbk
,
german1
, hebrew
,
hp8
, hungarian
,
koi8_ru
, koi8_ukr
,
latin1
, latin2
,
sjis
, swe7
,
tis620
, ujis
,
usa7
oder win1251ukr
.
See Abschnitt 5.6.1, „Der für Daten und Sortieren benutzte Zeichensatz“.
Wenn Sie Zeichen zwischen Server und Client konvertieren
wollen, sollten Sie sich den SET OPTION CHARACTER
SET
-Befehl ansehen. See
Abschnitt 6.5.6, „SET
-Syntax“.
Achtung: Wenn Sie
Zeichensätze ändern, nachdem Sie irgend welche Tabellen
angelegt haben, müssen Sie myisamchk -r
-q
über jede Tabelle laufen lassen, denn
ansonsten könnten Ihre Indexe falsch sortiert werden. (Das
kann passieren, wenn Sie MySQL installieren, ein paar
Tabellen erzeugen und danach MySQL rekonfigurieren, so dass
es einen anderen Zeichensatz benutzt, und dann neu
installieren.)
Mit der Option --with-extra-charset=LIST
können Sie zusätzliche Zeichensätze definieren, die in
den Server einkompiliert werden sollen.
Hierbei ist LIST
entweder eine Liste
eines Zeichensatzes, die durch Leerzeichen getrennt ist,
oder complex
, um alle Zeichen
einzuschließen, die nicht dynamisch geladen werden können,
oder all
, um alle Zeichensätze in die
Binärdateien einzuschließen.
Um MySQL mit Debug-Code zu konfigurieren, benutzen Sie die
--with-debug
-Option:
shell> ./configure --with-debug
Das bewirkt, dass eine sichere Speicherzuweisung (Memory Allocator) eingeschlossen wird, die einige Fehler finden kann und die Ausgaben liefert, was passiert ist. See Abschnitt D.1, „Einen MySQL-Server debuggen“.
Wenn Ihre Client-Programme Threads benutzen, müssen Sie
zusätzlich eine Thread-sichere Version der
MySQL-Client-Bibliothek mit der
--enable-Thread-safe-client
-configure-Option
kompilieren. Hierdurch wird eine
libmysqlclient_r
-Bibliothek angelegt, mit
der Sie Ihre threaded Applikationen linken können. See
Abschnitt 9.4.8, „Wie man einen threaded Client herstellt“.
Optionen, die zu bestimmten Systemen gehören, finden sich im systemspezifischen Abschnitt dieses Handbuchs. See Abschnitt 3.2.2, „Betriebssysteme, die von MySQL unterstützt werden“.
VORSICHT: Sie sollten diesen Abschnitt nur lesen, wenn Sie daran interessiert sind, uns beim Testen von neuem Code zu helfen. Wenn Sie nur wollen, dass MySQL auf Ihrem System läuft, sollten Sie eine Standard-Distribution wählen (entweder eine Quell- oder eine Binärdistribution).
Um unseren aktuellsten Entwicklungs-Source-Tree zu bekommen, folgen Sie diesen Anweisungen:
Laden Sie BitKeeper von http://www.bitmover.com/cgi-bin/download.cgi herunter. Sie benötigen Bitkeeper 2.0 oder neuer, um auf unser Repository zuzugreifen.
Folgen Sie den Anweisungen, um BitKeeper zu installieren.
Nachdem BitKeeper installiert ist, benutzen Sie diesen Befehl, um den MySQL-3.23-Branch zu klonen:
shell> bk clone bk://mysql.bkbits.net/mysql-3.23 mysql-3.23
Um den 4.0-Branch zu klonen, benutzen Sie statt dessen diesen Befehl:
shell> bk clone bk://mysql.bkbits.net/mysql-4.0 mysql-4.0
Um den 4.1-Branch zu klonen, benutzen Sie statt dessen diesen Befehl:
shell> bk clone bk://mysql.bkbits.net/mysql-4.1 mysql-4.1
Um den 5.0-Branch zu klonen, benutzen Sie statt dessen diesen Befehl:
shell> bk clone bk://mysql.bkbits.net/mysql-5.0 mysql-5.0
Das erstmalige Herunterladen des Source-Trees kann eine Weile dauern, abhängig von Ihrer Verbindungsgeschwindigkeit. Bitte Geduld.
Sie brauchen GNU autoconf
,
automake
, libtool
und
m4
, um die nächsten Befehle
auszuführen. Wenn Sie in diesem Stadium seltsame Fehler
erhalten, überprüfen Sie bitte, ob Sie wirklich
libtool
installiert haben!
shell>cd mysql
shell>bk -r edit
shell>aclocal; autoheader; autoconf; automake;
shell>./configure # Geben Sie hier Ihre Lieblingsoptionen an
shell>make
Eine Sammlung unserer Standard-configure-Skripts befindet
sich im BUILD/
Unterverzeichnis. Wenn
Sie faul sind, können Sie
BUILD/compile-pentium-debug
benutzen.
Um für unterschiedliche Architekturen zu kompilieren,
ändern Sie das Skript ab und entfernen die Flags, die
Pentium-spezifisch sind.
Wenn der Build fertig ist, lassen Sie make
install
laufen. Seien Sie damit vorsichtig auf
Produktionsmaschinen, denn dieser Befehl kann Ihre
Live-Release-Installation überschreiben! Wenn Sie eine
weitere Installation von MySQL haben, empfehlen wir, dass
Sie ./configure
mit anderen Werten für
die prefix
-, tcp-port
-
und unix-socket-path
-Optionen ausführen
als die, die für Ihren Produktionsserver benutzt werden.
Spielen Sie reichlich mit Ihrer neuen Installation herum und
versuchen Sie, die neuen Features zum Absturz zu bringen.
Fangen Sie an, indem Sie make test
laufen
lassen. See Abschnitt 10.3.2, „MySQL-Test-Suite“.
Wenn Sie bis zum make
-Stadium gekommen
sind und die Distribution sich nicht kompilieren läßt,
berichten Sie das bitte an
<bugs@lists.mysql.com>
. Wenn Sie die letzten
Versionen der erforderlichen GNU-Werkzeuge installiert haben
und sie abstürzen, wenn Sie versuchen, Ihre
Konfigurationsdateien zu verarbeiten, berichten Sie das
bitte ebenfalls. Wenn Sie jedoch aclocal
und einen Befehl nicht gefunden
-Fehler
erhalten, berichten Sie diesen nicht. Stellen Sie statt
dessen sicher, dass alle notwendigen Werkzeuge installiert
sind und dass Ihre PATH
-Variable korrekt
gesetzt ist, damit Ihre Shell diese finden kann.
Nach der erstmaligen bk clone
-Operation,
um den Source-Tree zu erhalten, sollten Sie in
regelmäßigen Abständen bk pull
laufen
lassen, um Aktualisierungen zu erhalten.
Sie erhalten die Änderungen-Geschichte (Change History) des
Trees mit allen Diffs, indem Sie bk
sccstool
benutzen. Wenn Sie seltsame Diffs sehen
oder Code, zu dem Sie Fragen haben, zögern Sie nicht, uns
eine E-Mail an <internals@lists.mysql.com>
zu
schicken. Auch wenn Sie meinen, eine bessere Idee zu haben,
wie etwas gemacht werden sollte, schicken Sie uns eine
E-Mail an dieselbe Adresse, mit einem Patch. bk
diffs
erzeugt ein Patch für Sie, nachdem Sie
Änderungen am Quellcode durchgeführt haben. Wenn Sie keine
Zeit haben, Ihre Idee zu kodieren, schicken Sie einfach eine
Beschreibung.
BitKeeper hat ein nettes
Hilfe-Dienstprogramm, auf das Sie über bk
helptool
zugreifen können.
Alle MySQL-Programme lassen sich sauber ohne Warnungen auf
Solaris mit gcc
kompilieren. Auf anderen
Systemen können Warnungen wegen Unterschieden in
System-Include-Dateien auftreten. Siehe
Abschnitt 3.3.6, „Anmerkungen zu MIT-pThreads“ wegen Warnungen, die auftreten
können, wenn Sie MIT-pThreads verwenden. Wegen anderer Probleme
sehen Sie bitte in der unten stehenden Liste nach.
Die Lösung für viele Probleme beinhaltet Rekonfigurieren. Wenn Sie rekonfigurieren müssen, beachten Sie Folgendes:
Wenn configure
laufen gelassen wird,
nachdem es schon einmal lief, benutzt es möglicherweise
Informationen, die bei vorherigen Aufrufen gesammelt wurden.
Diese Information wird in der Datei
config.cache
gespeichert. Wenn
configure
startet, sucht es diese Datei
und liest ihren Inhalt, wenn sie existiert, unter der
Annahme, dass diese Information immer noch stimmt. Diese
Annahme ist falsch, wenn Sie rekonfigurieren.
Immer, wenn Sie configure
laufen lassen,
müssen Sie auch make
laufen lassen, um
erneut zu kompilieren. Sie werden jedoch einige alte
Objektdateien vorheriger Builds entfernen wollen, denn diese
wurden mit anderen Konfigurationsoptionen kompiliert.
Um zu verhindern, dass alte Konfigurationsinformationen oder
Objektdateien benutzt werden, geben Sie vor dem erneuten Aufruf
von configure
folgende Befehle ein:
shell>rm config.cache
shell>make clean
Alternativ können Sie auch make distclean
laufen lassen.
Die unten stehende Liste beschreibt einige der Probleme, die beim Kompilieren von MySQL am häufigsten auftreten:
Wenn Sie Probleme beim Kompilieren von
sql_yacc.cc
erhalten, die den unten
gezeigten ähneln, haben Sie wahrscheinlich keinen
Arbeitsspeicher oder Swap-Platz (Auslagerungsdatei) mehr.
Internal compiler error: Programm cc1plus got fatal signal 11 oder Out of virtual memory oder Virtual memory exhausted
Das Problem liegt darin, dass gcc
riesige
Mengen von Arbeitsspeicher benötigt, um
sql_yacc.cc
mit Inline-Funktionen zu
kompilieren. Versuchen Sie, configure
mit
der --with-low-memory
-Option auszuführen:
shell> ./configure --with-low-memory
Diese Option veranlasst, dass -fno-inline
zur Kompilierzeile hinzugefügt wird, wenn Sie
gcc
benutzen, bzw.
-O0
, wenn Sie etwas anderes benutzen. Sie
sollten die --with-low-memory
-Option selbst
dann benutzen, wenn Sie glauben, so viel Arbeitsspeicher und
Swap-Platz zu haben, dass Ihnen diese unmöglich ausgehen
können. Das Problem wurde selbst auf Systemen mit
großzügiger Hardware-Ausstattung beobachtet, und die
--with-low-memory
-Option behebt es
üblicherweise.
Vorgabemäßig sucht configure
c++
als Kompiler-Namen aus und GNU
c++
linkt mit -lg++
.
Wenn Sie gcc
benutzen, kann dieses
Verhalten Probleme bei Konfigurationen wie dieser
verursachen:
configure: error: installation oder configuration problem: c++ compiler cannot create executables.
Eventuell stoßen Sie beim Kompilieren auch auf Probleme,
die mit g++
, libg++
oder libstdc++
zu tun haben.
Eine Ursache dieser Probleme liegt darin, dass Sie kein
g++
haben dürfen, oder Sie dürfen
g++
haben, aber nicht
libg++
oder libstdc++
.
Schauen Sie in die config.log
-Datei!
Sie sollten die genaue Ursache enthalten, warum Ihr
C++-Kompiler nicht funktioniert! Um dieses Problem zu
umgehen, können Sie gcc
als Ihren
C++-Kompiler benutzen. Versuchen Sie, die Umgebungsvariable
CXX
auf "gcc -O3"
zu
setzen. Beispiel:
shell> CXX="gcc -O3" ./configure
Das funktioniert, weil gcc
C++-Quellen
genau so gut wie g++
kompiliert, aber
vorgabemäßig weder libg++
noch
libstdc++
linkt.
Eine andere Möglichkeit, das Problem zu beheben, besteht
natürlich darin, g++
,
libg++
und libstdc++
zu installieren.
Wenn Ihr Kompilieren mit Fehlern wie dem folgenden
fehlschlägt, müssen Sie Ihre Version von
make
auf GNU make
aktualisieren:
making all in mit-pThreads make: Fatal error in reader: Makefile, line 18: Badly formed macro assignment oder make:Datei `Makefile' line 18: Must be a separator (: oder pThread.h: No such file or directory
Von Solaris und FreeBSD ist bekannt, dass sie
problembehaftete make
-Programme haben.
GNU make
Version 3.75 funktioniert
bekanntermaßen.
Wenn Sie Flags definieren wollen, die von Ihrem C- oder
C++-Kompiler benutzt werden, fügen Sie die Flags den
CFLAGS
- und
CXXFLAGS
-Umgebungsvariablen hinzu. Sie
können auf diese Weise auch die Kompilernamen festlegen,
indem Sie CC
und CXX
benutzen. Beispiel:
shell>CC=gcc
shell>CFLAGS=-O3
shell>CXX=gcc
shell>CXXFLAGS=-O3
shell>export CC CFLAGS CXX CXXFLAGS
Siehe Abschnitt 3.2.6, „MySQL-Binärdistributionen, die von MySQL AB kompiliert wurden“: Eine Liste von Flag-Definitionen, die sich auf verschiedenen Systemen als nützlich erwiesen haben.
Wenn Sie einen Fehler wie den folgenden erhalten, müssen
Sie Ihren gcc
-Kompiler aktualisieren:
client/libmysql.c:273: parse error before `__attribute__'
gcc
2.8.1 funktioniert bekanntermaßen,
aber wir empfehlen statt dessen gcc
2.95.2 oder egcs
1.0.3a.
Wenn Sie Fehler wie die unten stehenden erhalten, wenn Sie
mysqld
kompilieren, hat
configure
den Typ des letzten Arguments
für accept()
,
getsockname()
oder
getpeername()
nicht korrekt erkannt:
cxx: Error: mysqld.cc, line 645: In this statement, the referenced type of the pointer value "&length" is "unsigned long", which is not compatible with "int". new_sock = accept(sock, (struct sockaddr *)&cAddr, &length);
Um das zu beheben, editieren Sie die
config.h
-Datei (die von
configure
angelegt wird). Suchen Sie nach
folgenden Zeilen:
/* Define as the base type of the last arg to accept */ #define SOCKET_SIZE_TYPE XXX
Ändern Sie XXX
zu
size_t
oder int
,
abhängig von Ihrem Betriebssystem. (Beachten Sie, dass Sie
das jedes Mal tun müssen, wenn Sie
configure
laufen lassen, weil
configure
die Datei
config.h
neu erzeugt.)
Die sql_yacc.cc
-Datei wird von
sql_yacc.yy
erzeugt. Normalerweise muss
der Build-Prozess keine sql_yacc.cc
erzeugen, weil MySQL schon mit einer fertig erzeugten Kopie
daher kommt. Wenn Sie sie jedoch neu erzeugen müssen,
könnten Sie folgenden Fehler erhalten:
"sql_yacc.yy", line xxx fatal: default action causes potential...
Das ist ein Indiz dafür, dass Ihre Version von
yacc
fehlerhaft ist. Sie müssen statt
dessen wahrscheinlich bison
(die
GNU-Version von yacc
) installieren und
benutzen.
Wenn Sie mysqld
oder einen MySQL-Client
debuggen wollen, lassen Sie configure
mit
der --with-debug
-Option laufen. Kompilieren
Sie danach neu und linken Sie Ihre Clients mit der neuen
Client-Bibliothek. See Abschnitt D.2, „Einen MySQL-Client debuggen“.
Dieser Abschnitt beschreibt einige der Themen im Zusammenhang mit MIT-pThreads.
Beachten Sie, dass Sie auf Linux KEINE MIT-pThreads benutzen, sondern statt dessen LinuxThreads installieren sollten! See Abschnitt 3.6.1, „Linux (alle Linux-Versionen)“.
Wenn Ihr System keine native Thread-Unterstützung bietet, müssen Sie MySQL unter Verwendung des MIT-pThread-Pakets bauen. Das betrifft ältere FreeBSD-Systeme, SunOS 4.x, Solaris 2.4 und früher und einige andere. See Abschnitt 3.2.2, „Betriebssysteme, die von MySQL unterstützt werden“.
Auf den meisten Systemen können Sie die Benutzung von
erzwingen, indem Sie configure
mit der
--with-mit-Threads
-Option laufen lassen:
shell> ./configure --with-mit-threads
Wenn Sie MIT-pThreads benutzen, wird das Bauen (Building) in ein Nicht-Quellcode-Verzeichnis nicht unterstützt, weil wir die Änderungen an diesem Code minimal halten wollen.
Die Überprüfungen, die festlegen, ob MIT-pThreads benutzt
werden sollten oder nicht, finden nur in dem Teil des
Konfigurationsprozesses statt, der mit dem Server-Code zu
tun hat. Wenn Sie die Distribution mit
--without-server
konfigurieren, um nicht
den Client-Code zu bauen, wissen die Clients nicht, ob sie
MIT-pThreads benutzen sollen oder nicht und werden
vorgabemäßig Unix-Socket-Verbindungen benutzen. Weil
Unix-Sockets unter MIT-pThreads nicht laufen, heißt das,
dass Sie -h
oder --host
benutzen müssen, wenn Sie Client-Programme laufen lassen.
Wenn MySQL so kompiliert wird, dass es MIT-pThreads benutzt,
wird System-Sperren (System Locking) vorgabemäßig aus
Performance-Gründen ausgeschaltet. Mit der
--use-locking
-Option können Sie dem Server
mitteilen, System-Sperren zu benutzen.
Manchmal schlägt der
pThread-bind()
-Befehl fehl und bindet
nicht an ein Socket, ohne jede Fehlermeldung (zumindest auf
Solaris). Als Ergebnis schlagen alle Verbindungen zum Server
fehl. Beispiel:
shell> mysqladmin version
mysqladmin: connect to server at '' failed;
error: 'Can't connect to mysql server on localhost (146)'
Die Lösung besteht darin, den
mysqld
-Server zu killen und neu zu
starten. Uns ist das nur dann passiert, wenn wir den Server
gezwungen haben, herunter zu fahren und sofort danach einen
Neustart durchgeführt haben.
Bei MIT-pThreads läßt sich der
sleep()
-Systemaufruf nicht mit
SIGINT
(break) unterbrechen. Das merken
Sie nur, wenn Sie mysqladmin --sleep
ausführen. Sie müssen dann warten, bis der
sleep()
-Aufruf beendet wurde, bevor die
Unterbrechungsanforderung (Interrupt) bedient wird und der
Prozess anhält.
Wenn Sie linken, erhalten Sie möglicherweise Warnmeldungen wie diese (zumindest auf Solaris). Sie können sie ignorieren:
ld: warning: symbol `_iob' hat differing sizes: (file /my/local/pThreads/lib/libpThread.a(findfp.o) value=0x4; file /usr/lib/libc.so value=0x140); /my/local/pThreads/lib/libpThread.a(findfp.o) definition taken ld: warning: symbol `__iob' hat differing sizes: (file /my/local/pThreads/lib/libpThread.a(findfp.o) value=0x4; file /usr/lib/libc.so value=0x140); /my/local/pThreads/lib/libpThread.a(findfp.o) definition taken
Einige weitere Warnungen können ebenfalls ignoriert werden:
implicit declaration of function `int strtoll(...)' implicit declaration of function `int strtoul(...)'
Wir haben es bislang nicht geschafft,
readline
mit MIT-pThreads zum Laufen zu
bringen. (Das wird zwar nicht benötigt, mag aber für
einige interessant sein.)
Sie benötigen folgendes:
VC++-6.0-Kompiler (aktualisiert mit Service-Pack 4 oder 5 und dem Präprozessor-Paket). Das Präprozessor-Paket wird für den Makro-Assembler benötigt. Weitere Details finden Sie unter: http://msdn.microsoft.com/vstudio/sp/vs6sp5/faq.asp.
Die MySQL-Quelldistribution für Windows, die von http://www.mysql.com/downloads/ herunter geladen werden kann.
MySQL bauen
Erzeugen Sie ein Arbeitsverzeichnis (z. B. workdir).
Entpacken Sie die Quelldistribution in dieses Verzeichnis.
Starten Sie den VC++-6.0-Kompiler.
Wählen Sie im File
-Menü Open
Workspace
.
Öffnen Sie den mysql.dsw
-Workspace,
den Sie im Arbeitsverzeichnis finden.
Wählen Sie im Build
-Menü das
Set Active Configuration
- Menü.
Wählen Sie mysqld - Win32 Debug
und
klicken Sie auf OK.
Drücken Sie F7
, um mit dem Bauen des
Debug-Servers, der Bibliotheken und einiger
Client-Applikationen zu beginnen.
Wenn das Kompilieren beendet ist, kopieren Sie die Bibliotheken und die ausführbaren Dateien in ein separates Verzeichnis.
Kompilieren Sie die Release-Versionen, die Sie haben wollen, auf dieselbe Art.
Erzeugen Sie das Verzeichnis für die MySQL-Dateien, z. B.
c:\mysql
.
Kopieren Sie aus dem Arbeitsverzeichnis folgende Verzeichnisse in das c:\mysql-Verzeichnis:
Data
Docs
Share
Erzeugen Sie das Verzeichnis
c:\mysql\bin
und kopieren Sie alle
Server und Clients, die Sie vorher kompiliert haben, hinein.
Wenn Sie wollen, können Sie auch das
lib
-Verzeichnis erzeugen und die vorher
kompilierten Bibliotheken hinein kopieren.
Führen Sie mit Visual Studio ein Clean durch.
Konfigurieren und starten Sie den Server auf dieselbe Weise wie bei der Windows-Binärdistribution. See Abschnitt 3.3.6.1, „Vorbereitung der Windows-Umgebung“.
Wenn Sie MySQL erst einmal installiert haben (aus einer Binär- oder einer Quelldistribution), müssen Sie die Berechtigungstabellen (Grant Tables) initialisieren, den Server starten und sicherstellen, dass der Server korrekt funktioniert. Eventuell wollen Sie auch einrichten, dass der Server automatisch gestartet und angehalten wird, wenn Ihr System startet oder herunter gefahren wird.
Normalerweise installieren Sie die Berechtigungstabellen und starten den Server wie folgt: Bei der Installation einer Quelldistribution:
shell>./scripts/mysql_install_db
shell>cd mysql_installations_verzeichnis
shell>./bin/safe_mysqld --user=mysql &
Bei einer Binärdistribution (nicht RPM- oder pkg-Pakete) tun Sie folgendes:
shell>cd mysql_installations_verzeichnis
shell>./bin/mysql_install_db
shell>./bin/safe_mysqld --user=mysql &
Das legt die mysql
-Datenbank an, die alle
Zugriffsrechte auf Datenbanken enthält, die
test
-Datenbank, die Sie benutzen können, um
MySQL zu testen und zusätzlich Berechtigungseinträge für den
Benutzer, der mysql_install_db
ausführt sowie
einen root
-Benutzer (ohne Passworte!). Durch
den letzten Befehl wird der mysqld
-Server
gestartet.
mysql_install_db
überschreibt keine alten
Berechtigungstabellen, deshalb sollte es unter allen Umständen
sicher sein. Wenn Sie die test
-Datenbank nicht
haben wollen, können Sie sie mit mysqladmin -u root drop
test
entfernen.
Am einfachsten läßt sich das Durchtesten vom obersten
Verzeichnis der MySQL-Distribution durchführen. Bei einer
Binärdistribution ist das Ihr Installationsverzeichnis
(üblicherweise etwas wie /usr/local/mysql
).
Bei einer Quelldistribution ist es das Hauptverzeichnis Ihres
MySQL-Source-Trees.
In den unten dargestellten Befehlen dieses Abschnitts und der
folgenden Unterabschnitte ist BINDIR
der Pfad
zu dem Speicherort, wo Programme wie mysqladmin
und safe_mysqld
installiert sind. Bei einer
Binärdistribution ist das bin
-Verzeichnis
innerhalb der Distribution. Bei einer Quelldistribution ist
BINDIR
wahrscheinlich
/usr/local/bin
, es sei denn, Sie haben ein
anderes Installationsverzeichnis als
/usr/local
angegeben, als Sie
configure
laufen ließen.
EXECDIR
ist der Speicherort, in dem der
mysqld
-Server installiert ist. Bei einer
Binärdistribution ist das derselbe wie BINDIR
.
Bei einer Quelldistribution ist EXECDIR
wahrscheinlich /usr/local/libexec
.
Das Durchtesten wird im Folgenden detailliert beschrieben.
Falls notwendig, starten Sie den
mysqld
-Server und richten die anfänglichen
MySQL-Berechtigungstabellen ein, die alle Zugriffsrechte
enthalten, die festlegen, wie sich Benutzer mit dem Server
verbinden dürfen. Das wird normalerweise mit dem
mysql_install_db
-Skript gemacht:
shell> scripts/mysql_install_db
Typischerweise müssen Sie mysql_install_db
nur laufen lassen, wenn Sie MySQL zum ersten Mal installieren.
Wenn Sie eine existierende Installation aktualisieren
(Update), können Sie deshalb diesen Schritt überspringen.
(mysql_install_db
ist jedoch ziemlich
sicher und aktualisiert keine bereits existierenden Tabellen,
daher können Sie im Zweifel immer
mysql_install_db
laufen lassen.)
mysql_install_db
erzeugt sechs Tabellen
(user
, db
,
host
, tables_priv
,
columns_priv
und func
)
in der mysql
-Datenbank. Eine Beschreibung
der anfänglichen Zugriffsrechte wird in
Abschnitt 5.2.5, „Wie das Berechtigungssystem funktioniert“ festgelegt. Kurz gesagt erlauben
diese Zugriffsrechte dem MySQL-Benutzer
root
, alles zu tun, und jedem, Datenbanken
anzulegen oder zu benutzen, deren Name
'test'
ist oder mit
'test_'
beginnt.
Wenn Sie die Zugriffsberechtigungstabellen (Grant Tables) nicht einrichten, wird folgender Fehler in der Logdatei erscheinen, wenn Sie den Server starten:
mysqld: Can't find file: 'host.frm'
Dasselbe kann auch bei einer MySQL-Binärdistribution
passieren, wenn Sie MySQL nicht mit exakt
./bin/safe_mysqld
starten! See
Abschnitt 5.7.2, „safe_mysqld, der Wrapper um mysqld“.
Eventuell müssen Sie mysql_install_db
als
root
laufen lassen. Wenn Sie wollen,
können Sie jedoch den MySQL-Server als unprivilegierter
(non-root
)-Benutzer laufen lassen,
vorausgesetzt, dieser Benutzer darf Dateien im
Datenbank-Verzeichnis lesen und schreiben. Anweisungen, wie
Sie MySQL als unprivilegierter Benutzer laufen lassen können,
finden Sie in Abschnitt 5.3.3, „Wann Berechtigungsänderungen wirksam werden“.
Wenn Sie Probleme mit mysql_install_db
bekommen, sehen Sie bitte unter
Abschnitt 3.4.1, „Probleme mit mysql_install_db
“ nach.
Es gibt eine Reihe von Alternativen zum Laufenlassen des
mysql_install_db
-Skripts, was mit der
MySQL-Distribution mitgeliefert wird:
Sie können mysql_install_db
editieren,
bevor Sie es laufen lassen, um die anfänglichen
Zugriffsrechte zu ändern, die in die Rechtetabellen
installiert werden. Das ist nützlich, wenn Sie MySQL auf
einer großen Zahl von Maschinen mit denselben
Zugriffsrechten installieren wollen. In diesem Fall
müssen Sie wahrscheinlich nur ein paar zusätzliche
INSERT
-Statements für die
mysql.user
- und
mysql.db
-Tabellen hinzufügen!
Wenn Sie Dinge in den Berechtigungstabellen ändern
wollen, nachdem diese installiert wurden, lassen Sie
mysql_install_db
laufen und geben dann
den Befehl mysql -u root mysql
ein, um
sich als MySQL-root
-Benutzer mit den
Berechtigungstabellen zu verbinden. Danach können Sie
SQL-Statements eingeben, um die Tabellen direkt zu
verändern.
Es ist möglich, die Berechtigungstabellen komplett neu zu
erzeugen, nachdem Sie angelegt wurden. Das werden Sie zum
Beispiel tun wollen, wenn Sie die Tabellen bereits
angelegt haben, Sie nun aber neu anlegen wollen, weil Sie
mysql_install_db
editiert haben.
Zu weiteren Informationen über diese Alternativen siehe Abschnitt 5.2, „Allgemeine Sicherheitsthemen und das MySQL-Zugriffsberechtigungssystem“.
Starten Sie den MySQL-Server wie folgt:
shell>cd mysql_installations_verzeichnis
shell>bin/safe_mysqld &
Wenn Sie Probleme haben, den Server zu starten, sehen Sie unter Abschnitt 3.4.2, „Probleme mit dem Start des MySQL-Servers“ nach.
Benutzen Sie mysqladmin
, um
sicherzustellen, dass der Server läuft. Die folgenden Befehle
sind ein einfacher Test, um zu überprüfen, ob der Server
läuft und auf Verbindungen reagiert:
shell>BINDIR/mysqladmin version
shell>BINDIR/mysqladmin variables
Die Ausgabe von mysqladmin version
kann
geringfügig variieren, abhängig von Ihrer Plattform und der
Version von MySQL, sollte aber etwa wie folgt aussehen:
shell> BINDIR/mysqladmin version
mysqladmin Ver 8.14 Distrib 3.23.32, for linux on i586
Copyright (C) 2000 MySQL AB & MySQL Finnland AB & TCX DataKonsult AB
This software comes mit ABSOLUTELY NO WARRANTY. This ist free software,
und you are welcome to modify und redistribute it under the GPL license
Server version 3.23.32-debug
Protokoll version 10
Connection Localhost via Unix socket
TCP port 3306
UNIX socket /tmp/mysql.sock
Uptime: 16 sec
Threads: 1 Questions: 9 Slow queries: 0 Opens: 7 Flush tables: 2 Open tables: 0 Queries per second avg: 0.000 Memory in use: 132K Max memory used: 16773K
Um ein Gefühl dafür zu bekommen, was Sie sonst noch mit
BINDIR/mysqladmin
tun können, rufen Sie es
mit der --help
-Option auf.
Stellen Sie sicher, dass Sie den Server herunter fahren können:
shell> BINDIR/mysqladmin -u root shutdown
Stellen Sie sicher, dass Sie den Server erneut starten
können. Tun Sie das unter Benutzung von
safe_mysqld
oder indem Sie
mysqld
direkt aufrufen. Beispiel:
shell> BINDIR/safe_mysqld --log &
Wenn safe_mysqld
fehlschlägt, versuchen
Sie, es vom MySQL-Installationsverzeichnis aus zu starten
(falls Sie noch nicht dort sind). Wenn das nicht funktioniert,
sehen Sie unter see Abschnitt 3.4.2, „Probleme mit dem Start des MySQL-Servers“ nach.
Lassen Sie ein paar einfache Tests ablaufen um sicherzustellen, dass der Server funktioniert. Die Ausgabe sollte ähnlich der folgenden sein:
shell>BINDIR/mysqlshow
+-----------+ | Databases | +-----------+ | mysql | +-----------+ shell>BINDIR/mysqlshow mysql
Datenbank: mysql +--------------+ | Tables | +--------------+ | columns_priv | | db | | func | | host | | tables_priv | | user | +--------------+ shell>BINDIR/mysql -e "select host,db,user from db" mysql
+------+--------+------+ | host | db | user | +------+--------+------+ | % | test | | | % | test_% | | +------+--------+------+
Zusätzlich gibt es eine Benchmark-Suite im
sql-bench
-Verzeichnis (unterhalb des
MySQL-Installationsverzeichnisses), die Sie benutzen können,
um die Leistungsdaten von MySQL auf verschiedenen Plattformen
zu vergleichen. Das
sql-bench/Results
-Verzeichnis enthält
die Ergebnisse vieler Testläufe mit verschiedenen Datenbanken
und Plattformen. Um alle Tests durchzuführen, geben Sie
folgende Befehle ein:
shell>cd sql-bench
shell>run-all-tests
Wenn Sie kein sql-bench
-Verzeichnis
haben, benutzen Sie wahrscheinlich ein RPM für eine
Binärdistribution. (Quelldistributions-RPMs beinhalten das
Benchmark-Verzeichnis.) In diesem Fall müssen Sie die
Benchmark-Suite zuerst installieren, bevor Sie sie benutzen
können. Ab MySQL Version 3.22 gibt es Benchmark-RPM-Dateien,
die mysql-bench-VERSION-i386.rpm
benannt
sind, die Benchmark-Code und Daten enthalten.
Wenn Sie eine Quelldistribution haben, können Sie auch die
Tests im tests
-Unterverzeichnis
ausführen. Um beispielsweise
auto_increment.tst
auszuführen, geben
Sie folgendes ein:
shell> BINDIR/mysql -vvf test < ./tests/auto_increment.tst
Die Ergebnisse stehen dann in der
./tests/auto_increment.res
-Datei.
Der Zweck des mysql_install_db
-Skripts ist,
neue MySQL-Berechtigungstabellen zu erzeugen. Es betrifft keine
anderen Daten! Es tut nichts, wenn Sie bereits
MySQL-Berechtigungstabellen installiert haben!
Wenn Sie Ihre Berechtigungstabellen neu erzeugen wollen, sollten
Sie den mysqld
-Server herunter fahren, falls
er läuft, und dann etwas Ähnliches wie folgendes tun:
mv mysql-data-verzeichnis/mysql mysql-data-verzeichnis/mysql-old mysql_install_db
Dieser Abschnitt listet Probleme auf, denen Sie vielleicht
begegnen, wenn Sie mysql_install_db
laufen
lassen:
mysql_install_db
installiert die Berechtigungstabellen nicht.
Eventuell stellen Sie fest, dass
mysql_install_db
bei der Installations
der Berechtigungstabellen fehlschlägt und mit folgenden
Meldungen endet:
starting mysqld daemon with databases from XXXXXX mysql daemon ended
In diesem Fall sollten Sie einen gründlichen Blick in die
Log-Datei werfen! Diese sollte sich im Verzeichnis
XXXXXX
befinden, das in der
Fehlermeldung ausgegeben wird, und sollte anzeigen, warum
mysqld
nicht startete. Wenn Sie nicht
verstehen, was passiert ist, schicken Sie einen Bug-Bericht
inklusive Log. Benutzen Sie hierfür
mysqlbug
! See
Abschnitt 2.6.2.3, „Wie man Bugs oder Probleme berichtet“.
Es läuft bereits ein
mysqld
-Daemon.
In diesem Fall müssen Sie wahrscheinlich
mysql_install_db
überhaupt nicht
starten. Sie müssen mysql_install_db
nur
einmal starten, und zwar, wenn Sie MySQL zum ersten Mal
installieren.
Die Installation eines zweiten
mysqld
-Daemons schlägt fehl,
wenn bereits ein Daemon läuft.
Das kann vorkommen, wenn Sie bereits eine existierende
MySQL-Installation haben, aber eine neue Installation an
einem anderen Speicherort unterbringen wollen (zum Beispiel
für Testzwecke, oder vielleicht wollen Sie auch einfach
zwei Installationen zugleich laufen lassen. Im Allgemeinen
ist der Grund für das Problem, wenn Sie versuchen, den
zweiten Server laufen zu lassen, dass der zweite Server
versucht, denselben Socket und Port wie der alte zu
benutzen. In diesem Fall erhalten Sie als Fehlermeldung:
Can't start server: Bind on TCP/IP port: Address
already in use
oder Can't start server :
Bind on unix socket...
. See
Abschnitt 5.1.4, „Viele MySQL-Server auf derselben Maschine laufen lassen“.
Sie haben keinen Schreibzugriff auf
/tmp
.
Wenn Sie keinen Schreibzugriff haben, um eine Socket-Datei
am vorgabemäßigen Ort anzulegen (in
/tmp
) oder keine Berechtigung, um
temporäre Dateien in /tmp
anzulegen,
erhalten Sie einen Fehler, wenn Sie
mysql_install_db
laufen lassen oder
starten oder wenn Sie mysqld
benutzen.
So können Sie einen anderen Socket und ein anderes temporäres Verzeichnis festlegen:
shell>TMPDIR=/irgendein_temporaeres_verzeichnis/
shell>MYSQL_UNIX_PORT=/irgendein_temporaeres_verzeichnis/mysqld.sock
shell>export TMPDIR MYSQL_UNIX_PORT
See Abschnitt A.4.5, „Wie Sie die MySQL-Socket-Datei /tmp/mysql.sock
schützen oder ändern“.
irgendein_temporaeres_verzeichnis
sollte der Pfad zu einem Verzeichnis sein, für das Sie
Schreibberechtigung haben. See
Anhang E, Umgebungsvariablen.
Danach sollten Sie in der Lage sein,
mysql_install_db
laufen zu lassen und den
Server zu starten, und zwar mit folgenden Befehlen:
shell>scripts/mysql_install_db
shell>BINDIR/safe_mysqld &
mysqld
stürzt
sofort ab
Wenn Sie RedHat Version 5.0 mit einer Version von
glibc
laufen lassen, die älter als
2.0.7-5 ist, sollten Sie sicherstellen, dass Sie alle
glibc
-Patches installiert haben! Darüber
gibt es jede Menge Informationen in den MySQL-Mail-Archiven.
Links zu den Mail-Archiven finden Sie online unter
http://www.mysql.com/documentation/.
Siehe auch Abschnitt 3.6.1, „Linux (alle Linux-Versionen)“.
Sie können mysqld
auch manuell starten,
dabei die --skip-grant-tables
-Option
benutzen und dann die Berechtigungsinformationen selbst mit
mysql
eintragen:
shell>BINDIR/safe_mysqld --skip-grant-tables &
shell>BINDIR/mysql -u root mysql
Von mysql
aus geben Sie die SQL-Befehle
ein, die in mysql_install_db
stehen.
Stellen Sie sicher, dass Sie danach mysqladmin
flush-privileges
oder mysqladmin
reload
laufen lassen, um dem Server mitzuteilen,
die Berechtigungstabellen neu zu laden.
Wenn Sie Tabellen einsetzen werden, die Transaktionen unterstützen (InnoDB, BDB), sollten Sie zuerst eine my.cnf-Datei anlegen und die Startoptionen für die Tabellentypen setzen, die Sie einsetzen wollen. See Kapitel 8, MySQL-Tabellentypen.
Im allgemeinen starten Sie den mysqld
-Server
auf eine der drei folgenden Weisen:
Indem Sie mysql.server
aufrufen. Dieses
Skript wird hauptsächlich beim Systemstart und
-herunterfahren eingesetzt. Es wird ausführlicher in
Abschnitt 3.4.3, „MySQL automatisch starten und anhalten“ beschrieben.
Indem Sie safe_mysqld
aufrufen. Dieses
Skript versucht die korrekten Optionen für
mysqld
festzustellen und läßt den
Server dann mit diesen Optionen laufen. See
Abschnitt 5.7.2, „safe_mysqld, der Wrapper um mysqld“.
Auf Windows NT sollten Sie mysqld
wie
folgt als Systemdienst starten:
bin\mysqld-nt --install # MySQL als Systemdienst installieren
Jetzt können Sie mysqld
wie folgt
starten / anhalten:
NET START mysql NET STOP mysql
Beachten Sie, dass Sie in diesem Fall keine weiteren
Optionen für mysqld
benutzen können!
Sie können den Systemdienst wie folgt entfernen:
bin\mysqld-nt --remove # MySQL als Systemdienst entfernen
Indem Sie mysqld
direkt aufrufen.
Wenn der mysqld
-Daemon hoch fährt, wechselt
er in das Daten-Verzeichnis. Dort erwartet er, Log-Dateien und
die (process ID)-Datei schreiben zu können. Ebenfalls erwartet
er dort, Datenbanken zu finden.
Der Speicherort des Daten-Verzeichnisses wird zum Zeitpunkt des
Kompilierens der Distribution fest verdrahtet. Wenn
mysqld
jedoch erwartet, das Daten-Verzeichnis
irgendwo sonst als an der Stelle zu finden, wo es auf Ihrem
System tatsächlich ist, funktioniert er nicht richtig. Wenn Sie
Probleme mit fehlerhaften Pfaden haben, können Sie durch den
Aufruf von mysqld
mit der
--help
-Option herausfinden, welche Optionen
mysqld
erlaubt und was die vorgabemäßigen
Pfad-Einstellung sind. Sie können die Vorgaben überschreiben,
indem Sie die korrekten Pfadnamen als Kommandozeilen-Argumente
für mysqld
festlegen. (Diese Optionen
können auch bei safe_mysqld
benutzt werden.)
Normalerweise sollte es lediglich nötig sein,
mysqld
das Basis-Verzeichnis mitzuteilen, wo
MySQL installiert ist. Das können Sie mit der Option
--basedir
machen. Zusätzlich können Sie
--help
benutzen, um die Auswirkung der
Pfadänderungsoptionen zu überprüfen (beachten Sie, dass
--help
die letzte Option des
mysqld
-Befehls wein
muss. Beispiel:
shell> EXECDIR/mysqld --basedir=/usr/local --help
Wenn Sie die Pfadeinstellungen erst einmal festgelegt haben, die
Sie wollen, starten Sie den Server ohne die
--help
-Option.
Mit welcher Methode auch immer Sie den Server starten: Wenn er
nicht korrekt hoch fährt, untersuchen Sie die Log-Datei, um zu
sehen, ob Sie den Grund dafür herausfinden können. Log-Dateien
liegen im Daten-Verzeichnis (typischerweise
/usr/local/mysql/data
bei einer
Binärdistribution, /usr/local/var
bei
einer Quelldistribution und
\mysql\data\mysql.err
unter Windows).
Suchen Sie im Daten-Verzeichnis nach Dateien mit Namen der Form
host_name.err
und
host_name.log
, wobei
host_name
der Name Ihres Server-Hosts ist.
Sehen Sie in den letzten paar Zeilen dieser Dateien nach:
shell>tail host_name.err
shell>tail host_name.log
Wenn Sie etwas wie das Folgende in der Log-Datei finden:
000729 14:50:10 bdb: Recovery function for LSN 1 27595 failed 000729 14:50:10 bdb: warning: ./test/t1.db: No such file or directory 000729 14:50:10 Can't init databases
Das bedeutet, dass Sie mysqld
nicht mit
--bdb-no-recover
gestartet haben und Berkeley
DB findet, dass etwas mit seinen Log-Dateien nicht in Ordnung
ist, als es versuchte, Ihre Datenbanken wiederherzustellen. Um
weitermachen zu können, sollten Sie alle alten
Berkeley-DB-Log-Dateien aus dem Datenbankverzeichnis an eine
andere Stelle verschieben, wo Sie sie später untersuchen
können. Die Log-Dateien sind wie
log.0000000001
benannt, wobei die Nummer im
Zeitablauf hochgezählt wird.
Wenn Sie mysqld
mit
BDB-Tabellenunterstützung laufen lassen und
mysqld
beim Start einen Speicherauszug (Core
Dump) liefert, könnte das an Problemen mit den
BDB-Wiederherstellungs-Logs liegen. In diesem Fall können Sie
versuchen, mysqld
mit
--bdb-no-recover
zu starten. Wenn das hilft,
sollten Sie danach alle log.*
-Dateien aus
dem Daten-Verzeichnis entfernen und versuchen,
mysqld
erneut zu starten.
Wenn Sie folgenden Fehler bekommen, bedeutet das, dass ein
anderes Programm (oder ein anderer
mysqld
-Server) bereits den TCP/IP-Port oder
-Socket benutzt, den mysqld
versucht zu
benutzen:
Can't start server: Bind on TCP/IP-Port: Address already in use oder Can't start server : Bind on unix socket...
Benutzen Sie ps
, um sicherzustellen, dass
kein weiterer mysqld
-Server läuft. Wenn Sie
keinen weiteren Server finden, können Sie den Befehl
telnet ihr-host-name tcp-ip-port-nummer
eingeben und mehrere Male EINGABE
drücken.
Wenn Sie keine Fehlermeldung wie telnet: Unable to
connect to remote host: Connection refused
erhalten,
benutzt irgend etwas anderes den TCP/IP-Port, den
mysqld
versucht zu benutzen. Siehe
Abschnitt 3.4.1, „Probleme mit mysql_install_db
“ und
Abschnitt 5.1.4, „Viele MySQL-Server auf derselben Maschine laufen lassen“.
Wenn mysqld
gerade läuft, können Sie
herausfinden, welche Pfadeinstellungen er benutzt, indem Sie
folgenden Befehl ausführen:
shell> mysqladmin variables
oder
shell> mysqladmin -h 'ihr-host-name' variables
Wenn safe_mysqld
hoch den Server hoch fährt,
Sie sich aber nicht mit ihm verbinden können, stellen Sie
sicher, dass Sie einen Eintrag wie den folgenden in
/etc/hosts
haben:
127.0.0.1 localhost
Dieses Problem tritt nur auf Systemen auf, die keine funktionierende Thread-Bibliothek besitzen, und für die MySQL so konfiguriert werden muss, dass es MIT-pThreads benutzt.
Wenn Sie es nicht schaffen, mysqld
zu
starten, können Sie versuchen, eine Trace-Datei anzulegen, um
das Problem zu finden. See Abschnitt D.1.2, „Trace-Dateien erzeugen“.
Wenn Sie InnoDB-Tabellen benutzen, sehen Sie bei den InnoDB-spezifischen Startoptionen nach. See Abschnitt 8.5.2, „Mit InnoDB anfangen - Optionen“.
Wenn Sie BDB-(Berkeley DB)-Tabellen benutzen, sollten Sie sich mit den verschiedenen Startoptionen von BDB vertraut machen. See Abschnitt 8.6.3, „BDB-Startoptionen“.
Die mysql.server
- und
safe_mysqld
-Skripte können benutzt werden,
um den Server automatisch beim Hochfahren des Systems zu
starten. mysql.server
kann ebenfalls dazu
benutzt werden, den Server anzuhalten.
Das mysql.server
-Skript kann benutzt werden,
um den Server zu starten oder anzuhalten, indem man es mit den
start
- oder
stop
-Argumenten aufruft:
shell>mysql.server start
shell>mysql.server stop
mysql.server
liegt im
share/mysql
-Verzeichnis unterhalb des
MySQL-Installationsverzeichnisses oder im
support-files
-Verzeichnis des
MySQL-Source-Trees.
Bevor mysql.server
den Server startet,
wechselt es in das MySQL-Installationsverzeichnis. Dann ruft es
safe_mysqld
auf. Eventuell müssen Sie
mysql.server
editieren, wenn Sie eine
Binärdistribution haben, die Sie an eine nicht stardardmäßige
Stelle installiert haben. Ändern Sie es so ab, dass es in das
richtige Verzeichnis wechselt (cd
), bevor es
safe_mysqld
startet. Wenn Sie wollen, dass
der Server unter einem bestimmten Benutzer läuft, fügen Sie
eine entsprechende user
-Zeile zur
/etc/my.cnf
-Datei hinzu, so wie weiter
unten in diesem Abschnitt dargestellt.
mysql.server stop
hält den Server an, indem
es ihm ein Signal sendet. Sie können den Server auch
automatisch herunter fahren, indem Sie mysqladmin
shutdown
ausführen.
Wenn Sie möchten, können Sie diese Start- und Stop-Befehle an
den entsprechenden Stellen Ihrer
/etc/rc*
-Dateien einfügen, wenn Sie MySQL
für Produktions-Applikationen benutzen. Beachten Sie, wenn Sie
mysql.server
editieren und dann gelegentlich
MySQL aktualisieren (Update), dass dann Ihre geänderte Version
überschrieben wird. Daher sollten Sie eine Kopie Ihrer
editierten Version machen, die Sie erneut installieren können.
Wenn Ihr System /etc/rc.local
benutzt, um
externe Skripte zu starten, sollten Sie folgendes anhängen:
/bin/sh -c 'cd /usr/local/mysql ; ./bin/safe_mysqld --user=mysql &'
Sie können Optionen für mysql.server
in
einer globalen /etc/my.cnf
-Datei
hinzufügen. Eine typische
/etc/my.cnf
-Datei sieht wie folgt aus:
[mysqld] datadir=/usr/local/mysql/var socket=/var/tmp/mysql.sock port=3306 user=mysql [mysql.server] basedir=/usr/local/mysql
Das mysql.server
-Skript kennt folgende
Optionen: datadir
, basedir
und pid-file
.
Folgende Tabelle zeigt, welche Optionsgruppen jedes der Startskripts aus den Optionsdateien liest:
Skript | Optionsgruppen |
mysqld | mysqld und server |
mysql.server | mysql.server , mysqld , und
server |
safe_mysqld | mysql.server , mysqld , und
server |
Sie können die MySQL-form- und data-Dateien jederzeit für
verschiedene Versionen auf derselben Architektur benutzen, solange
Sie dieselbe Grundversion von MySQL haben. Die aktuelle
Grundversion ist 3. Wenn Sie den Zeichensatz ändern, während
MySQL läuft (was auch die Sortierreihenfolge betreffen kann),
müssen Sie myisamchk -r -q
auf alle Tabellen
ausführen. Ansonsten könnte es sein, dass Ihre Indexe nicht
korrekt sortiert werden.
Wenn Sie vor neuen Versionen zurück schrecken, können Sie Ihren
alten mysqld
zu etwas wie
mysqld
-'alte-versions-nummer' umbenennen. Wenn
Ihr neuer mysqld
dann etwas Unerwartetes tut,
können Sie ihn einfach anhalten und mit Ihrem alten
mysqld
neu starten!
Wenn Sie ein Upgrade vornehmen, sollte Sie natürlich Ihre alten Datenbanken sichern.
Wenn Sie nach einem Upgrade auf Probleme mit neu kompilierten
Client-Programmen stoßen, zum Beispiel Commands out of
sync
oder unerwartete Speicherauszüge (Core Dumps),
haben sie wahrscheinlich einen alten Header oder eine alte
Bibliotheksdatei benutzt, als Sie die Programme kompilierten. In
diesem Fall sollten Sie das Datum Ihrer
mysql.h
-Datei und
libmysqlclient.a
-Bibliothek überprüfen, um
sicherzustellen, dass sie aus der neuen MySQL-Distribution
stammten. Wenn nicht, kompilieren sie Ihre Programme bitte neu!
Wenn Sie Probleme der Art erhalten, dass Ihr neuer
mysqld
-Server nicht startet oder dass Sie sich
nicht ohne Passwort verbinden können, überprüfen Sie, ob Sie
nicht etwa noch die alte my.cnf
-Datei Ihrer
alten Installation haben! Sie können das mit
program-name --print-defaults
tun. Wenn es
irgend etwas anderes als den Programmnamen ausgibt, haben Sie eine
aktive my.cnf
-Datei, die sich auf die Dinge
auswirkt!
Es ist eine gute Idee, die
Msql-Mysql-modules
-Distribution neu zu bauen
und neu zu installieren, wann immer Sie ein neues Release von
MySQL installieren, speziell dann, wenn Sie Symptome wie die
bemerken, dass alle Ihre DBI
-Skripte mit
Core-Dumps abbrechen, nachdem Sie MySQL aktualisiert haben.
Sie können Ihre alten data-Dateien ohne jede Änderung mit
Version 4.0 benutzen. Wenn Sie Ihre Daten eines
MySQL-4.0-Servers für einen älteren Server verwenden wollen,
müssen Sie mysqldump
benutzen.
Alte Clients sollen mit einem Server Version 4.0 ohne jedes Problem funktionieren.
Die folgende Liste stellt dar, auf was Sie aufpassen müssen, wenn Sie auf Version 4.0 aktualisieren (Upgrade):
safe_mysqld
wurde zu
mysqld_safe
umbenannt.
Die alten C-API-Funktionen mysql_drop_db
,
mysql_create_db
und
mysql_connect
werden nicht mehr
unterstützt, es sei denn, MySQL wird mit
USE_OLD_FUNCTIONS
kompiliert.
Sie sollten TRUNCATE TABLE
benutzen, wenn
Sie alle Zeilen aus einer Tabelle löschen wollen und Ihnen
egal ist, wie viele Zeilen gelöscht wurden.
(TRUNCATE TABLE
ist schneller als
DELETE FROM tabelle
).
Sie bekommen einen Fehler, wenn Sie ein aktives
LOCK TABLES
oder eine aktive Transaktion
am Laufen haben, wenn Sie versuchen, TRUNCATE
TABLE
oder DROP DATABASE
auszuführen.
Sie sollten Ganzzahl-(Integer)-Werte in BIGINT-Spalten benutzen (anstelle von Zeichenketten wie in MySQL 3.23). Man kann immer noch Zeichenketten benutzen, aber die Benutzung von Ganzzahlen ist viel effizienter.
Das Format von SHOW OPEN TABLE
hat sich
geändert.
Multithreaded Clients sollten
mysql_thread_init()
und
mysql_thread_end()
benutzen. See
Abschnitt 9.4.8, „Wie man einen threaded Client herstellt“.
MySQL-Version 3.23 unterstützt Tabellen des neuen
MyISAM
-Typs und des alten
ISAM
-Typs. Sie müssen Ihre alten Tabellen
nicht konvertieren, um sie mit Version 3.23 einsetzen zu
können. Vorgabemäßig werden alle neuen Tabellen mit dem Typ
MyISAM
angelegt (es sei denn, Sie starten
mysqld
mit der
--default-table-type=isam
-Option). Sie können
eine ISAM
-Tabelle zu einer
MyISAM
-Tabelle mit ALTER TABLE
tabelle TYPE=MyISAM
konvertieren oder mit dem
Perl-Skript mysql_convert_table_format
.
Clients der Versionen 3.22 und 3.21 funktionieren ohne jedes Problem mit einem Server der Version 3.23.
Die folgende Liste stellt dar, auf was Sie aufpassen müssen, wenn Sie auf Version 3.23 aktualisieren (Upgrade):
Alle Tabellen, die den tis620
-Zeichensatz
benutzen, müssen mit myisamchk -r
oder
REPAIR TABLE
in Ordnung gebracht werden.
Wenn Sie ein DROP DATABASE
auf eine mit
symbolischem Link verknüpfte Datenbank ausführen, werden
sowohl der symbolische Links als auch die Datenbank
gelöscht. (Das war in Version 3.22 nicht der Fall, weil
configure den readlink
-Systemaufruf nicht
erkannte).
OPTIMIZE TABLE
funktioniert jetzt nur bei
MyISAM-Tabellen. Bei
anderen Tabellentypen können Sie ALTER
TABLE
benutzen, um die Tabelle zu optimieren.
Während der Ausführung von OPTIMIZE
TABLE
wird die Tabelle jetzt vor dem Zugriff
anderer Threads gesperrt.
Der MySQL-Client mysql
wir jetzt
vorgabemäßig mit der Option --no-named-commands
(-g)
gestartet. Diese Option kann mit
--enable-named-commands (-G)
abgeschaltet
werden. Dies kann ein paar Inkompatibilitätsprobleme
verursachen, zum Beispiel in SQL-Skripten, die benannte
(named) Befehle ohne ein Semikolon! Befehle im Langformat
dagegen funktionieren noch auf der ersten Zeile.
some cases, für Beispiel in SQL Skripts that use named Befehle ohne a semicolon! Long format Befehle still work from the first line.
If you are using the german
character
sort order, you must repair all your Tabellen mit
isamchk -r
, as we have made some changes
in the sort order!
The default return type of IF
will now
depend on both arguments und not only the first argument.
AUTO_INCREMENT
funktioniert nicht mit
negativen Zahlen. Der Grund liegt darin, dass negative
Zahlen beim Übergang von -1 auf 0 Probleme verursachen.
AUTO_INCREMENT
wird jetzt bei
MyISAM-Tabellen auf einem niedrigeren Level gehandhabt und
ist viel schneller als vorher. Bei MyISAM-Tabellen werden
alte Zahlen auch nicht mehr wieder benutzt, selbst wenn Sie
einige Zeilen aus der Tabelle löschen.
CASE
, DELAYED
,
ELSE
, END
,
FULLTEXT
, INNER
,
RIGHT
, THEN
und
WHEN
sind jetzt reservierte Wörter.
FLOAT(X)
ist jetzt ein echter
Fließkomma-Typ und kein Wert mit einer festen Anzahl von
Dezimalstellen.
Wenn Sie DECIMAL(length,dec)
deklarieren,
beinhaltet das Längen-Argument nicht mehr den Platz für
das Vorzeichen oder den Dezimalpunkt.
Eine TIME
-Zeichenkette muss jetzt von
einem der folgenden Formate sein: [[[DAYS]
[H]H:]MM:]SS[.bruchteil]
oder
[[[[[H]H]H]H]MM]SS[.bruchteil]
LIKE
vergleicht jetzt Zeichenketten unter
Verwendung derselben Vergleichsregeln wie
'='
. Wenn Sie das alte Verhalten
benötigen, können Sie MySQL mit dem
CXXFLAGS=-DLIKE_CMP_TOUPPER
-Flag
kompilieren.
REGEXP
arbeitet jetzt bei normalen (nicht
binären) Zeichenketten unabhängig von der
Groß-/Kleinschreibung.
Wenn Sie Tabellen prüfen / reparieren, sollten Sie
CHECK TABLE
oder
myisamchk
für
MyISAM
-Tabellen (.MYI
)
benutzen und isamchk
für ISAM-Tabellen
(.ISM
).
Wenn Sie wollen, dass mysqldump
-Dateien
zwischen MySQL-Version 3.22 und Version 3.23 kompatibel
sind, sollten Sie nicht die --opt
- oder
--full
-Option für
mysqldump
benutzen.
Überprüfen Sie Ihre Aufrufe von
DATE_FORMAT()
und stellen Sie sicher,
dass vor jedem Formatierungszeichen ein
‘%
’ steht. (Spätere
MySQL-Versionen 3.22 ließen diese Syntax zu.)
mysql_fetch_fields_direct
ist jetzt eine
Funktion (es war ein Makro) und gibt einen Zeiger auf
MYSQL_FIELD
anstelle eines
MYSQL_FIELD
zurück.
mysql_num_fields()
kann nicht mehr für
ein MYSQL*
-Objekt benutzt werden (es ist
jetzt eine Funktion, die MYSQL_RES*
als
Argument nimmt. Sie sollten jetzt statt dessen
mysql_field_count()
benutzen.
In MySQL-Version 3.22 war die Ausgabe von SELECT
DISTINCT ...
fast immer sortiert. In Version 3.23
müssen Sie GROUP BY
oder ORDER
BY
benutzen, um eine sortierte Ausgabe zu
erhalten.
SUM()
gibt jetzt NULL
zurück statt 0, wenn es keine überein stimmenden Zeilen
gibt. Das ist in Übereinstimmung mit ANSI-SQL.
Ein AND
oder OR
mit
NULL
-Werten gibt jetzt
NULL
anstelle von 0 zurück. Das betrifft
hauptsächlich Anfragen, die NOT
bei
einem AND/OR
-Ausdruck wie NOT
NULL
= NULL
benutzen.
LPAD()
und RPAD()
kürzen die Ergebnis-Zeichenkette, wenn sie länger als das
Längen-Argument ist.
Nichts, was die Kompatibilität betrifft, hat sich zwischen
Version 3.21 und 3.22 geändert. Die einzige Falle ist die, dass
neue Tabellen, die unter Verwendung des
DATE
-Typs erzeugt werden, die neue Art der
Datenspeicherung benutzen. Diese neuen Felder kann man daher
nicht von einer alten Version von mysqld
ansprechen.
Nachdem Sie MySQL-Version 3.22 installiert haben, starten Sie
den neuen Server und lassen dann das
mysql_fix_privilege_tables
-Skript laufen.
Dieses fügt die neuen Zugriffsberechtigungen ein, die Sie
benötigen, um den GRANT
-Befehl zu benutzen.
Wenn Sie das vergessen, erhalten Sie ein Access
denied
, wenn Sie versuchen, ALTER
TABLE
, CREATE INDEX
oder
DROP INDEX
zu benutzen. Wenn Ihr MySQL-Root
ein Passwort benötigt, müssen Sie dieses als Argument zu
mysql_fix_privilege_tables
angeben.
Die C-API-Schnittstelle für
mysql_real_connect()
hat sich geändert. Wenn
Sie ein altes Client-Programm haben, das diese Funktion aufruft,
müssen Sie eine 0
als neues
db
-Argument einfügen (oder den Client neu
kodieren, so dass er das db
-Element für
schnellere Verbindungen benutzt). Zusätzlich müssen Sie
mysql_init()
aufrufen, bevor Sie
mysql_real_connect()
aufrufen! Diese
Änderung wurde durchgeführt, damit die neue
mysql_options()
-Funktion in der
MYSQL
-Handler-Struktur Optionen speichern
kann.
The mysqld
-Variable
key_buffer
wurde umbenannt in
key_buffer_size
, Sie können aber in Ihren
Startdateien immer noch den alten Namen verwenden.
Wenn Sie eine Version benutzen, die älter als Version 3.20.28 ist, und auf Version 3.21 umstellen wollen, müssen Sie folgendes tun:
Sie können den mysqld
-Server Version 3.21
mit safe_mysqld --old-protocol
starten, um
ihn mit Clients aus einer Distribution Version 3.20 zu benutzen.
In diesem Fall gibt die neue Client-Funktion
mysql_errno()
überhaupt keine Server-Fehler
zurück, nur CR_UNKNOWN_ERROR
(funktioniert
aber bei Client-Fehlern), und der Server benutzt die alte
password()
-Überprüfung statt der neuen.
Wenn Sie die --old-protocol
-Option
NICHT für
mysqld
benutzen, müssen Sie folgende
Änderungen durchführen:
Jeder Client-Code muss neu kompiliert werden. Wenn Sie ODBC benutzen, müssen Sie die neuen MyODBC-2.x-Treiber verwenden.
Sie müssen das Skript
Skripts/add_long_password
laufen lassen,
um das Password
-Feld in der
mysql.user
-Tabelle zu
CHAR(16)
zu ändern.
Alle Passwörter müssen in der
mysql.user
-Tabelle neu zugewiesen werden
(um 62-Bit- statt 31-Bit-Passwörter zu erhalten).
Das Tabellenformat hat sich nicht geändert, daher müssen Sie keinerlei Tabellen konvertieren.
MySQL-Version 3.20.28 und höher kann das neue
user
-Tabellenformat handhaben, ohne sich auf
Clients auszuwirken. Wenn Sie eine MySQL-Version vor Version
3.20.28 haben, funktionieren Passwörter damit nicht mehr, wenn
Sie die user
-Tabelle konvertieren. Um auf
Nummer Sicher zu gehen, sollten Sie mindestens auf Version
3.20.28 aktualisieren und erst dann auf Version 3.21.
Der neue Client-Code funktioniert bei einem 3.20.x
mysqld
-Server. Wenn Sie daher Probleme mit
3.21.x bekommen, können Sie den alten 3.20.x-Server benutzen,
ohne die Clients neu kompilieren zu müssen.
Wenn Sie nicht die --old-protocol
-Option für
mysqld
benutzen, werden alte Clients folgende
Fehlermeldung ausgeben:
ERROR: Protocol mismatch. Server Version = 10 Client Version = 9
Die neue
Perl-DBI
/DBD
-Schnittstelle
unterstützt auch die alte
mysqlperl
-Schnittstelle. Die einzige
Änderung, die Sie machen müssen, wenn Sie
mysqlperl
benutzen, ist, die Argumente für
die connect()
-Funktion zu ändern. Die neuen
Argumente sind: host
,
database
, user
und
password
(die user
- und
password
-Argumente haben die Plätze
getauscht. See Abschnitt 9.2.2, „Die DBI
-Schnittstelle“.
Folgende Änderungen können Anfragen in alten Applikationen betreffen:
HAVING
muss jetzt vor einer möglichen
ORDER BY
-Klausel spezifiziert werden.
Die Parameter für LOCATE()
wurden
getauscht.
Es gibt einige neue reservierte Wörter. Die wichtigsten
sind DATE
, TIME
und
TIMESTAMP
.
Wenn Sie MySQL-Version 3.23 benutzen, können Sie die
.frm
-, .MYI
- und
.MYD
-Dateien zwischen verschiedenen
Architekturen kopieren, die dasselbe Fließkomma-Format
unterstützen. (MySQL kümmert sich um eventuelle
Byte-Tausch-Belange.)
Die MySQL-ISAM
-Daten und Index-Dateien
(.ISD
und *.ISM
, je
nachdem) sind Architektur-abhängig und in manchen Fällen
Betriebssystem-abhängig. Wenn Sie Ihre Applikationen auf eine
andere Maschine mit einer unterschiedlichen Architektur oder
einem anderen Betriebssystem verlagern wollen, wollten Sie nicht
einfach eine Datenbank verschieben, indem Sie deren Dateien auf
die andere Maschine kopieren. Benutzen Sie statt dessen
mysqldump
.
Vorgabemäßig erzeugt mysqldump
eine Datei
mit SQL-Statements. Sie können diese Datei auf die andere
Maschine übertragen und Sie als Eingabe für den
mysql
-Client benutzen.
mysqldump --help
zeigt Ihnen, welche Optionen
verfügbar sind. Wenn Sie die Daten mit einer neueren Version
von MySQL benutzen werden, sollten Sie mysqldump
--opt
mit der neueren Version benutzen, um einen
schnellen, kompakten Dump zu erhalten.
Die einfachste (wenngleich nicht schnellste) Art, eine Datenbank von einer Maschine auf eine andere zu bringen, ist, die folgenden Befehle auf der Maschine auszuführen, auf der die Datenbank liegt:
shell>mysqladmin -h 'anderer hostname' create db_name
shell>mysqldump --opt db_name \
| mysql -h 'anderer hostname' db_name
Wenn Sie eine Datenbank von einer entfernten Maschine über ein langsames Netzwerk kopieren wollen, können Sie folgendes benutzen:
shell>mysqladmin create db_name
shell>mysqldump -h 'anderer hostname' --opt --compress db_name \
| mysql db_name
Sie können das Ergebnis auch in einer Datei speichern, diese Datei auf die Zielmaschine übertragen und dort in die Datenbank laden. Sie können zum Beispiel wie folgt die Datenbank in eine Datei auf der Quellmaschine ausgeben (dumpen):
shell> mysqldump --quick db_name | gzip > db_name.inhalte.gz
(Die in diesem Beispiel erzeugte Datei ist komprimiert.) Übertragen Sie die Datei, die die Datenbankinhalte enthält, auf die Zielmaschine und geben Sie dort diese Befehle ein:
shell>mysqladmin create db_name
shell>gunzip < db_name.inhalte.gz | mysql db_name
Sie können auch mysqldump
und
mysqlimport
benutzen, um den
Datenbank-Transfer zu bewerkstelligen. Das ist bei großen
Tabellen wesentlich schneller als die Benutzung von
mysqldump
. In den unten dargestellten
Befehlen repräsentiert DUMPDIR
den vollen
Pfadnamen des Verzeichnisses, das Sie benutzen, um die Ausgabe
von mysqldump
zu speichern.
Legen Sie zunächst das Verzeichnis für die Ausgabe-Dateien an und geben Sie die Datenbank aus (Dump):
shell>mkdir DUMPDIR
shell>mysqldump --tab=DUMPDIR db_name
Übertragen Sie dann die Dateien des
DUMPDIR
-Verzeichnisses in ein entsprechendes
Verzeichnis auf der Zielmaschine und laden Sie dort die Dateien
in MySQL:
shell>mysqladmin create db_name # Datenbank erzeugen
shell>cat DUMPDIR/*.sql | mysql db_name # Tabellen in der Datenbank erzeugen
shell>mysqlimport db_name DUMPDIR/*.txt # Daten in die Tabellen laden
Vergessen Sie auch nicht, die mysql
-Datenbank
zu kopieren, den dort befinden Sie die Berechtigungstabellen
(user
, db
,
host
). Eventuell müssen Sie die Befehle als
MySQL-root
-Benutzer auf der neuen Maschine
eingeben, um die mysql
-Datenbank angelegt zu
bekommen.
Nachdem Sie die mysql
-Datenbank auf die neue
Maschine kopiert haben, führen Sie mysqladmin
flush-privileges
aus, damit der Server die
Berechtigungsinformationen neu einliest.
Die Anmerkungen weiter unten, die glibc betreffen, gelten nur dann, wenn Sie MySQL selbst bauen. Wenn Sie Linux auf einer x86-Maschine fahren, ist es in den meisten Fällen wesentlich besser, einfach unsere Binärdateien zu benutzen. Wir linken unsere Binärdateien an die am besten gepatchte Version von glibc, die wir bieten können, und mit den besten Kompiler-Optionen, wobei wir versuchen, MySQL für Hochlast-Server geeignet zu machen. Wenn Sie also den Text unten lesen und sich nicht sicher sind, was Sie tun sollen, sollten Sie zunächst unsere Binärdateien ausprobieren, um zu sehen, ob diese Ihren Anforderungen entsprechen. Kümmern Sie sich nur dann um einen eigenen Build, wenn Sie feststellen, dass unsere Binärdateien nicht gut genug sind. In diesem Fall wären wir für einen Hinweis dazu dankbar, damit wir beim nächsten Mal eine bessere Binärdatei bauen können. Für eine typische Benutzung, selbst bei einer großen Zahl gleichzeitiger Verbindungen und / oder Tabellen, die größer als 2 GB sind, sind unsere Binärdateien in den meisten Fällen die beste Wahl.
MySQL benutzt auf Linux LinuxThreads. Wenn Sie eine alte
Linux-Version benutzen, die keine glibc2
hat,
müssen Sie LinuxThreads installieren, bevor Sie MySQL
kompilieren. Sie erhalten LinuxThreads unter
http://www.mysql.com/downloads/os-linux.html.
ACHTUNG: Wir haben einige seltsame Probleme bei Linux 2.2.14 und MySQL auf SMP-Systemen festgestellt. Wenn Sie ein SMP-System haben, empfehlen wir, so schnell wie möglich auf Linux 2.4 zu aktualisieren (Upgrade)! Dadurch wird Ihr System ausserdem schneller und stabiler!
Beachten Sie, dass glibc
-Versionen vor und
einschließlich Version 2.1.1 einen schweren Fehler im
pThread_mutex_timedwait
-Handling haben, was
benutzt wird, wenn Sie INSERT DELAYED
verwenden. Wir empfehlen, vor einem Upgrade der glibc
INSERT DELAYED
nicht zu verwenden.
Wenn Sie planen, mehr als 1000 gleichzeitige Verbindungen zu
haben, müssen Sie einige Änderungen an LinuxThreads vornehmen,
es neu kompilieren und mit der neuen
libpThread.a
linken. Setzen Sie
PTHREAD_THREADS_MAX
in
sysdeps/unix/sysv/linux/bits/local_lim.h
auf 4096 herauf und setzen Sie STACK_SIZE
in
linuxThreads/internals.h
auf 256 KB
herunter. Die Pfade sind relativ zum Wurzelverzeichnis von
glibc
. Beachten Sie, dass MySQL bei etwa 600
bis 1000 Verbindungen nicht stabil läuft, wenn
STACK_SIZE
auf den Vorgabewert von 2 MB
gesetzt wird.
Wenn Sie Probleme damit bekommen, dass MySQL nicht genug Dateien oder Verbindungen öffnen kann, haben Sie möglicherweise Linux nicht so konfiguriert, dass es genug Dateien handhaben kann.
In Linux 2.2 und Folgenden können Sie die Anzahl der allozierten Datei-Handler herausbekommen, wenn Sie folgendes eingeben:
cat /proc/sys/fs/file-max cat /proc/sys/fs/dquot-max cat /proc/sys/fs/super-max
Wenn Sie mehr als 16M Speicher haben, sollten Sie etwas
Ähnliches wie folgendes in Ihr Boot-Skript
(/etc/rc/boot.local
auf SuSE) eintragen:
echo 65536 > /proc/sys/fs/file-max echo 8192 > /proc/sys/fs/dquot-max echo 1024 > /proc/sys/fs/super-max
Das können Sie auch von der Kommandozeile aus als Root eingeben, aber in diesem Fall werden die alten Beschränkungen wieder benutzt, wenn Sie Ihren Computer neu starten.
Zusätzlich sollten Sie in /etc/my.cnf einfügen:
[safe_mysqld] open-files-limit=8192
Das sollte MySQL erlauben, bis zu 8192 Verbindungen und Dateien zu erzeugen.
Die STACK_SIZE
-Konstante in LinuxThreads
steuert das Spacing von Thread-Stacks im Adressraum. Sie muss
Groß genug sein, damit reichlich Platz für den Stack jedes
individuellen Threads bleibt, aber klein genug, um den Stack
irgend eines Threads davon abzuhalten, mit den globalen
mysqld
-Daten zu kollidieren. Wie wir durch
Experimentieren heraus fanden, unmappt die Linux-Implementation
von mmap()
erfolgreich eine bereits gemappte
Region, wenn Sie sie anweisen, eine Adresse auszumappen, die
bereits in Benutzung ist, wobei sie alle Daten der gesamten
Seite auf Null setzt, statt einen Fehler zurück zu geben. Daher
beruht die Sicherheit von mysqld
oder jeder
anderen Thread-Applikation auf dem "Gentleman"-Verhalten des
Codes, der Threads erzeugt. Der Benutzer muss Vorkehrungen
treffen, die sicherstellen, dass die Anzahl laufender Threads
jederzeit ausreichend gering ist, damit die Thread-Stacks sich
vom globalen Heap fernhalten. Bei mysqld
sollten Sie dieses "Gentleman"-Verhalten forcieren, indem Sie
einen vernünftigen Wert für die the
max_connections
-Variable setzen.
Wenn Sie MySQL selbst bauen und sich nicht mit dem Patchen von
LinuxThreads herum plagen wollen, sollten Sie
max_connections
auf einen Wert nicht größer
als 500 setzen. Dieser Wert sollte sogar noch kleiner sein, wenn
Sie einen großen Schlüsselpuffer (Key Buffer), große
Heap-Tabellen oder andere Dinge haben, die
mysqld
dazu bringen könnten, eine Menge
Speicher zu allozieren, oder wenn Sie einen 2.2-Kernel mit einem
2GB-Patch fahren. Wenn Sie unsere Binärdateien oder
RPM-Versionen 3.23.23 oder später benutzen, können Sie
max_connections
sicher auf 1500 setzen, unter
der Annahme, dass es keine großen Schlüsselpuffer oder
Heap-Tabellen mit vielen Daten gibt. Je mehr Sie
STACK_SIZE
in LinuxThreads reduzieren
können, desto mehr können Sie sicher Threads erzeugen. Wir
empfehlen einen Wert zwischen 128K und 256K.
Wenn Sie viele gleichzeitige Verbindungen benutzen, bekommen Sie
vielleicht Probleme durch ein "Feature" im 2.2-Kernel, der einen
Prozess dafür bestraft, dass er sich aufspaltet (fork) oder
einen Kindprozess klont, um einen Fork-Bombenangriff (Fork Bomb
Attack) zu verhindern. Das bringt MySQL dazu, nicht so gut zu
skalieren, wenn Sie die Anzahl gleichzeitiger Clients erhöhen.
Wir konnten beobachten, dass sich das auf Einprozessor-Systemen
mit sehr langsamer Thread-Erzeugung bemerkbar macht, was sich
darin zeigt, dass es sehr lange dauern kann, sich mit MySQL zu
verbinden (bis zu einer Minute), und genau so lange, um es
herunter zu fahren. Auf Multiprozessor-Systemen haben wir einen
allmählichen Abfall der Anfrage-Geschwindigkeit beobachtet,
wenn die Anzahl der Clients zunimmt. Im Verlauf der Suche nach
einer Lösung haben wir von einem unserer Benutzer einen
Kernel-Patch erhalten, von dem dieser sagt, dass er auf seiner
Site eine beträchtliche Rolle spielt. Der Patch ist hier
verfügbar
(http://www.mysql.com/Downloads/Patches/linux-fork.patch).
Inzwischen haben wir recht ausführliche Tests dieses Patchs
sowohl auf Entwicklungs- als auch auf Produktionssystemen
gemacht. Er hat die Performance von MySQL
erheblich verbessert, ohne irgend welche Probleme zu
verursachen, und wir empfehlen ihn jetzt denjenigen unserer
Benutzer, die immer noch Hochlast-Server auf 2.2-Kerneln fahren.
Dieses Problem wurde im 2.4-Kernel behoben. Wenn Sie daher nicht
zufrieden mit der momentanen Performance Ihres Systems sind, ist
es wahrscheinlich einfacher, auf 2.4 zu aktualisieren, statt den
2.2-Kernel zu patchen, was zusätzlich zur Behebung dieses
Fairness-Bugs auch noch Multiprozessor-Systemen einen netten
Schub gibt.
Wir haben MySQL auf dem 2.4-Kernel auf einer
Zweiprozessor-Maschine getestet und haben festgestellt, dass
MySQL VIEL bessere Leistungsdaten bringt - es gab praktisch
keine Verlangsamung bei Anfragen bis ganz herauf zu 1000
Clients, und der Skalierungsfaktor von MySQL (berechnet als
Verhältnis von maximalem Durchsatz zum Durchsatz mit 1 Client)
war 100%. Ähnliches haben wir auf einer Vierprozessor-Maschine
beobachtet - praktisch keine Verlangsamung, während die Anzahl
der Clients bis auf 1000 stieg sowie ein Skalierungsfaktor von
300%. Für einen unter Hochlast fahrenden Multiprozessor-Server
empfehlen wir daher ausdrücklich den 2.4-Kernel. Weiter haben
wir festgestellt, dass es essentiell wichtig ist, den
mysqld
-Prozess auf dem 2.4-Kernel mit der
höchstmöglichen Priorität laufen zu lassen, um maximale
Performance zu erreichen. Das kann dadurch erreicht werden, dass
man den renice -20 $$
-Befehl zu
safe_mysqld
hinzufügt. Bei unseren Tests auf
der Vierprozessor-Maschine ergab die Erhöhung der Priorität
eine 60%-ige Steigerung des Durchsatzes bei 400 Clients.
Wir sind derzeit dabei, mehr Informationen über die Performance
von MySQL
auf dem 2.4-Kernel auf 4-Weg- und
8-Weg-Systemen zu bekommen. Wenn Sie Zugang zu einem solchen
System haben und einige Benchmarks gemacht haben, schicken Sie
bitte eine Mail mit den Ergebnissen an
<docs@mysql.com>
- wir werden Sie dem Handbuch
hinzufügen.
Es gibt eine weitere Sache, die die Performance von MySQL stark beeinträchtigt, besonders auf SMP-Systemen. Die Implementation von mutex in LinuxThreads in glibc-2.1 ist sehr schlecht für Programme mit vielen Threads, die den mutex nur für kurze Zeit behalten. Wenn Sie MySQL mit unveränderten LinuxThreads linken, führt ironischerweise auf einem SMP-System in manchen Fällen das Entfernen von Prozessoren zu einer Leistungssteigerung von MySQL. Für glibc 2.1.3 haben wir ein Patch bereit gestellt, um dieses Verhalten zu korrigieren: linuxthreads-2.1-patch
Bei Verwendung von glibc-2.2.2
benutzt MySQL-Version 3.23.36 den adaptiven mutex, der sogar
viel besser als der gepatchte von
glibc-2.1.3 ist. Seien Sie
jedoch davor gewarnt, dass unter bestimmten Umständen der
aktuelle mutex-Code in
glibc-2.2.2 überdrehen kann,
was die Performance von MySQL beeinträchtigt. Die Gefahr, dass
solche Umstände eintreten, kann dadurch verringert werden, dass
der mysqld
-Prozess auf die höchste
Priorität gesetzt wird. Zusätzlich konnten wir das
Überdrehverhalten mit einem Patch korrigieren, der
hier
erhältlich ist. Der Patch kombiniert die Korrektur des
Überdrehens, die maximale Anzahl von Threads und das
Stack-Spacing in einem. Sie wenden es auf das
linuxThreads
-Verzeichnis mit patch
-p0 </tmp/linuxThreads-2.2.2.patch
an. Wir hoffen,
dass der Patch in irgend einer Form in zukünftigen Releases von
glibc-2.2
enthalten sein wird. Wie es auch
sei, wenn Sie mit glibc-2.2.2
linken, müssen
Sie immer noch STACK_SIZE
und
PTHREAD_THREADS_MAX
korrigieren. Wir hoffen,
dass diese Vorgabewerte zukünftig auf akzeptablere Werte für
eine MySQL-Hochlast-Einrichtung gesetzt werden, so dass Ihr
eigener Build auf ./configure; make; make
install
reduziert werden kann.
Wir empfehlen, dass Die die oben genannten Patches benutzen, um
eine spezielle statische Version von
libpThread.a
zu bauen, die Sie nur für
statisches Linken mit MySQL
benutzen. Wir
wissen, dass die Patches für MySQL
sicher
sind und seine Performance erheblich verbessern, aber wir
können diesbezüglich nichts über andere Applikationen sagen.
Wenn Sie andere Applikationen mit der gepatchten Version der
Bibliothek linken oder eine gepatchte gemeinsam benutzte
(shared) Version bauen und auf Ihrem System installieren, tun
Sie das auf eigenes Risiko, was andere Applikationen betrifft,
die von LinuxThreads
abhängen.
Wenn Sie während der Installation von MySQL irgend welche seltsamen Probleme bekommen oder gebräuchliche Utilities hängen bleiben, ist es sehr wahrscheinlich, dass diese entweder Bibliotheks- oder Compiler-bezogen sind. In diesem Fall wird die Benutzung unserer Binärdatei sie beheben.
Ein bekanntes Problem der Binärdistribution ist, dass Sie auf
älteren Linux-Systemen, die libc
benutzen
(wie RedHat 4.x oder Slackware) nicht-schwere (non-fatal)
Probleme mit der Auflösung von Hostnamen bekommen. See
Abschnitt 3.1.1, „MySQL auf Linux installieren“.
Wenn Sie LinuxThreads benutzen, werden Sie feststellen, dass mindestens drei Prozesse laufen. Das sind in Wirklichkeit Threads. Es gibt einen Thread für den LinuxThreads-Manager, einen Thread, um Verbindungen zu handhaben und einen Thread, um Alarme und Signale zu handhaben.
Beachten Sie, dass der Linux-Kernel und die LinuxThread-Bibliothek vorgabemäßig nur 1024 Threads haben können. Das bedeutet, dass Sie auf einem ungepatchten System nur höchstens 1021 Verbindungen zu MySQL haben können. Die Seite http://www.volano.com/linuxnotes.html enthält Informationen, wie man diese Beschränkung umgeht.
Wenn Sie einen toten mysqld
-Daemon-Prozess
mit ps
sehen, bedeutet das üblicherweise,
dass Sie einen Bug in MySQL oder eine zerstörte Tabelle
gefunden haben. See Abschnitt A.4.1, „Was zu tun ist, wenn MySQL andauernd abstürzt“.
Um auf Linux einen Speicherauszug (Core Dump) zu erhalten, wenn
mysqld
mit einem SIGSEGV-Signal stirbt,
können Sie mysqld
mit der
--core-file
-Option starten. Beachten Sie, dass
Sie wahrscheinlich core file size
hoch setzen
müssen, indem Sie ulimit -c 1000000
zu
safe_mysqld
hinzufügen oder
safe_mysqld
mit
--core-file-sizes=1000000
starten. See
Abschnitt 5.7.2, „safe_mysqld, der Wrapper um mysqld“.
Wenn Sie Ihren eigenen MySQL-Client linken und bei der Ausführung diesen Fehler erhalten,
ld.so.1: ./my: fatal: libmysqlclient.so.4: open failed: No such file or directory
kann das Problem durch eine der folgenden Methoden behoben werden:
Wenn Sie den Fujitsu-Compiler (fcc / FCC)
benutzen, werden Sie beim Kompilieren von MySQL einige Probleme
bekommen, weil die Linux-Header-Dateien sehr
gcc
-orientiert sind.
Folgende configure
-Zeile sollte mit
fcc/FCC
funktionieren:
CC=fcc CFLAGS="-O -K fast -K lib -K omitfp -Kpreex -D_GNU_SOURCE -DCONST=konstante -DNO_STRTOLL_PROTO" CXX=FCC CXXFLAGS="-O -K fast -K lib -K omitfp -K preex --no_exceptions --no_rtti -D_GNU_SOURCE -DCONST=konstante -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 benötigt zumindest Linux-Version 2.0.
ACHTUNG: Wir haben Berichte von MySQL-Benutzern erhalten, die schwer wiegende Stabilitätsprobleme mit Linux-Kernel 2.2.14 mitgeteilt haben. Wenn Sie diesen Kernel benutzen, sollten Sie auf 2.2.19 (oder neuer) oder auf einen 2.4-Kernel aktualisieren. Wenn Sie eine Mehrprozessormaschine haben, sollten Sie auf jeden Fall in Betracht ziehen, 2.4 zu benutzen, weil Ihnen das erhebliche Geschwindigkeitssteigerung geben wird.
Die Binärdistribution wird mit -static
gelinkt, was normalerweise heißt, dass Sie sich nicht um die
Version der Systembibliotheken kümmern müssen, die Sie
haben. Ausserdem brauchen Sie nicht LinuxThread installieren.
Ein Programm, das mit -static
gelinkt ist,
ist etwas größer als ein dynamisch gelinktes Programm, und
gleichzeitig etwas schneller (3-5%). Ein Problem liegt jedoch
darin, dass Sie bei einem statisch gelinkten Programm keine
benutzerdefinierten Funktionen (UDF) benutzen können. Wenn
Sie UDF-Funktionen schreiben oder benutzen wollen (das ist nur
etwas für C- oder C++-Programmierer), müssen Sie MySQL
selbst kompilieren und das dynamische Linken benutzen.
Wenn Sie ein libc
-basierendes System
benutzen (statt eines glibc2
-Systems),
bekommen Sie bei der Binärdistribution wahrscheinlich
Probleme mit der Auflösung von Hostnamen und mit
getpwnam()
. (Das liegt daran, dass
glibc
leider von einigen externen
Bibliotheken abhängt, um Hostnamen aufzulösen und und
getpwent()
, selbst wenn es mit
-static
kompiliert wird.) In diesem Fall
erhalten Sie wahrscheinlich folgende Fehlermeldung, wenn Sie
mysql_install_db
ausführen:
Sorry, the host 'xxxx' could not be looked up
oder den folgenden Fehler, wenn Sie versuchen,
mysqld
mit der
--user
-Option laufen zu lassen:
getpwnam: No such file or directory
Sie können dieses Problem auf eine der folgenden Weisen lösen:
Holen Sie sich eine MySQL-Quelldistribution (eine RPM oder
die tar.gz
-Distribution) und
installieren Sie statt dessen diese.
Führen Sie mysql_install_db --force
aus. Das führt nicht den
resolveip
-Test in
mysql_install_db
aus. Der Nachteil ist,
dass Sie keine Hostnamen in the Berechtigungstabellen
benutzen können, sondern nur IP-Nummern (ausser für
localhost
). Wenn Sie ein altes
MySQL-Release benutzen, das --force
nicht
unterstützt, müssen Sie den
resolveip
-Test in
mysql_install
mit einem Editor
deaktivieren.
Starten Sie mysqld
mit
su
anstelle von
--user
.
Die Linux-Intel-Binärdatei und die RPM-Releases von MySQL sind für höchst mögliche Geschwindigkeit konfiguriert. Wir versuchen immer, den schnellsten stabilen Kompiler zu benutzen, der verfügbar ist.
MySQL-Perl-Unterstützung erfordert Perl-Version 5.004_03 oder neuer.
Auf einigen Linux-2.2-Versionen erhalten Sie womöglich den
Fehler Resource temporarily unavailable
,
wenn Sie eine Menge neuer Verbindungen zu einem
mysqld
-Server über TCP/IP aufmachen.
Das Problem liegt darin, dass Linux eine Verzögerung zwischen
dem Schließen eines TCP/IP-Sockets und dem tatsächlichen
Freigeben durch das System hat. Da es nur Platz für eine
bestimmte Anzahl von TCP/IP-Slots gibt, bekommen Sie den
genannten Fehler, wenn Sie viele neue TCP/IP-Verbindungen
innerhalb kurzer Zeit aufbauen, zum Beispiel, wenn Sie den
MySQL-test-connect
-Benchmark über TCP/IP
laufen lassen.
Wir haben dieses Problem mehrfach an verschiedene Linux-Mailing-Listen geschrieben, konnten aber bislang keine saubere Lösung erhalten.
Die einzige bekannte 'Behebung' des Problems liegt darin,
persistente Verbindungen bei Ihren Clients zu verwenden oder
Sockets zu benutzen, wenn Sie den Datenbankserver und die
Clients auf derselben Maschine laufen lassen. Wir hoffen, dass
zukünftig der Linux 2.4
-Kernel dieses
Problem lösen wird.
MySQL erfordert libc
-Version 5.4.12 oder
neuer. Bekannt ist, dass libc
5.4.46
funktioniert. glibc
-Version 2.0.6 und
später sollten ebenfalls funktionieren. Es hat einige
Probleme mit den glibc
-RPMs von RedHat
gegeben. Wenn Sie Probleme haben, prüfen Sie daher, ob es
Updates gibt! Die glibc
-2.0.7-19- und
-2.0.7-29-RPMs funktionieren bekanntermaßen ebenfalls.
Bei einigen älteren Linux-Distributionen kann
configure
einen Fehler wie folgt
produzieren:
Syntaxfehler in sched.h. Ändern Sie _P zu __P in der /usr/include/sched.h-Datei. Siehe das Installationskapitel im Referenzhandbuch.
Machen Sie, was die (englischsprachige) Fehlermeldung sagt.
Fügen Sie also einen zusätzlichen Unterstrich zum
_P
-Makro hinzu, das nur einen Unterstrich
hat, und versuchen Sie es noch einmal.
Möglicherweise erhalten Sie beim Kompilieren Warnungen. Die folgenden davon können ignoriert werden:
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'
In Debian-GNU/Linux müssen Sie folgendes tun, damit MySQL beim Hochfahren des Systems automatisch startet:
shell>cp support-files/mysql.server /etc/init.d/mysql.server
shell>/usr/sbin/update-rc.d mysql.server defaults 99
mysql.server
befindet sich im
share/mysql
-Verzeichnis unterhalb des
MySQL-Installationsverzeichnisses oder im
support-files
-Verzeichnis des
MySQL-Source-Trees.
Wenn mysqld
beim Start immer einen
Speicherauszug (Core Dump) erzeugt, kann das Problem darin
liegen, dass Sie eine alte /lib/libc.a
haben. Versuchen Sie sie umzubenennen, entfernen Sie dann
sql/mysqld
, führen Sie ein neues
make install
durch und versuchen Sie es
noch einmal. Dieses Problem wurde von einigen
Slackware-Installationen berichtet.
Wenn Sie beim Linken von mysqld
folgenden
Fehler erhalten, bedeutet das, dass Ihre
libg++.a
nicht korrekt installiert ist:
/usr/lib/libc.a(putc.o): In function `_IO_putc': putc.o(.text+0x0): multiple definition of `_IO_putc'
Sie können vermeiden, dass libg++.a
benutzt wird, indem Sie configure
wie folgt
ablaufen lassen:
shell> CXX=gcc ./configure
Bei einigen Implementationen ist
readdir_r()
fehlerhaft. Das äußert sich
darin, dass SHOW DATABASES
immer einen
leeren Satz (Empty Set) zurück gibt. Das kann behoben werden,
indem HAVE_READDIR_R
aus
MySQL-Version 3.23.12 ist die erste MySQL-Version, die auf Linux-Alpha getestet wurde. Wenn Sie planen, MySQL auf Linux-Alpha einzusetzen, stellen Sie sicher, dass Sie diese oder eine neuere Version haben.
Wir haben MySQL auf Alpha mit unseren Benchmarks und unserer Test-Suite getestet, und es scheint gut zu funktionieren. Hauptsächlich noch nicht getestet haben wird, wie die Dinge mit vielen gleichzeitigen Verbindungen funktionieren.
Wir kompilieren die Standard-MySQL-Binärdatei mit SuSE 6.4, Kernel 2.2.13-SMP, Compaq-C-Kompiler Version 6.2-504 und Compaq-C++-Kompiler Version 6.3-005 auf einer Compaq-DS20-Maschine mit einem Alpha-EV6-Prozessor.
Sie finden die genannten Kompiler auf http://www.support.compaq.com/alpha-tools). Durch die Verwendung dieser Kompiler anstelle von gcc erhalten wir eine 9% bis 14% bessere Performance für MySQL.
Beachten Sie, dass die Konfigurationszeile die Binärversion auf die aktuelle CPU optimiert. Das heißt, dass Sie unsere Binärdatei nur benutzen können, wenn Sie einen Alpha-EV6-Prozessor haben. Ausserdem haben wir statisch kompiliert, um Bibliothek-Probleme zu vermeiden.
CC=ccc CFLAGS="-fast" CXX=cxx CXXFLAGS="-fast -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
Bei Benutzung von egcs funktionierte bei uns die folgende Konfigurationszeile:
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
Einige bekannte Probleme, wenn MySQL auf Linux-Alpha läuft:
Das Debuggen von threaded Applikationen wie MySQL
funktioniert nicht mit gdb 4.18
. Statt
dessen sollten Sie gdb 5.0 herunter laden und benutzen!
Wenn Sie versuchen, mysqld
unter
Benutzung von gcc
statisch zu linken,
wird das resultierende Image beim Starten einen
Speicherauszug (Core Dump) erzeugen. Mit anderen Worten:
Benutzen Sie NICHT
--with-mysqld-ldflags=-all-static
mit
gcc
.
MySQL sollte auf MkLinux mit dem neuesten
glibc
-Paket funktionieren (getestet mit
glibc
2.0.7).
Um MySQL auf Qube2 zum Laufen zu bringen (Linux Mips),
benötigen Sie die neuesten
glibc
-Bibliotheken
(glibc-2.0.7-29C2
funktioniert
bekanntermaßen). Ausserdem müssen Sie den
egcs
-C++-Kompiler
(egcs-1.0.2-9
, gcc
2.95.2
oder neuer) benutzen.
Um MySQL auf Linux Ia64 zu kompilieren, mussten wir folgendes tun (wir vermuten, dass das leichter wird, wenn die neue gcc-Version für ia64 herausgebracht wird).
Unter Verwendung von gcc-2.9-final
:
CFLAGS="-O2" CXX=gcc CXXFLAGS="-O2 -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static --disable-shared --with-extra-charsets=complex
Nach make
werden Sie einen Fehler erhalten,
dass sql/opt_range.cc
nicht kompiliert
(interner Kompiler-Fehler). Um das zu beheben, gehen Sie ins
sql-Verzeichnis und tippen Sie erneut make
ein. Kopieren Sie die Kompilierzeile, ändern Sie aber -O2 zu
-O0. Die Datei sollte nunmehr kompilieren.
Jetzt können Sie folgendes tun:
cd .. make make_install
und mysqld
sollte lauffähig sein.
Auf Ia64 benutzen die MySQL-Client-Binärdateien gemeinsam
genutzte (shared) Bibliotheken. Wenn Sie daher unsere
Binärdistribution an anderer Stelle als
/usr/local/mysql
benutzen, müssen Sie
entweder /etc/ld.so.conf
ändern oder den
Pfad zum Verzeichnis hinzufügen, wo Sie
libmysqlclient.so
haben, und zwar in der
LD_LIBRARY_PATH
-Umgebungsvariablen.
See Abschnitt A.3.1, „Probleme beim Linken mit der MySQL-Client-Bibliothek“.
Dieser Abschnitt beschreibt Installation und Benutzung von MySQL
auf Windows. Diese Information steht zusätzlich in der
README
-Datei, die mit der
MySQL-Windows-Distribution mitgeliefert wird.
MySQL benutzt TCP/IP, um einen Client mit einem Server zu verbinden. (Das erlaubt jeder beliebigen Maschine in Ihrem Netzwerk, sich mit Ihrem MySQL-Server zu verbinden.) Aus diesem Grund müssen Sie MySQL auf Ihrer Maschine installieren, bevor Sie MySQL starten. Sie finden TCP/IP auf Ihrer Windows-CD-ROM.
Beachten Sie, dass Sie bei Verwendung eines alten Win95-Releases (zum Beispiel OSR2) wahrscheinlich ist, dass Sie ein altes Winsock-Paket haben! MySQL erfordert Winsock 2! Sie erhalten das neueste Winsock von http://www.microsoft.com/. Win98 enthält die neue Winsock-2-Bibliothek, deshalb trifft das Gesagte nicht auf Win98 zu.
Um den mysqld
-Server zu starten, öffnen
Sie ein MS-DOS-Fenster (MS-DOS-Eingabeaufforderung) und geben
Sie ein:
C:\> C:\mysql\bin\mysqld
Das startet mysqld
im Hintergrund ohne
Fenster.
Sie können den MySQL-Server killen, indem Sie eingeben:
C:\> C:\mysql\bin\mysqladmin -u root shutdown
Beachten Sie, dass Win95 und Win98 die Erzeugung von Named
Pipes nicht unterstützen. Auf Win95 und Win98 können Sie
Named Pipes nur benutzen, um sich zu einem entfernten
MySQL-Server zu verbinden, der auf einem NT-Server-Host
läuft. (Natürlich muss auch der MySQL-Server Named Pipes
unterstützen. Beispielsweise läßt die Verwendung von
mysqld-opt
unter NT keine
Named-Pipe-Verbindungen zu. Sie sollten daher entweder
mysqld-nt
oder
mysqld-max-nt
verwenden.)
Wenn mysqld
nicht startet, überprüfen Sie
bitte die \mysql\data\mysql.err
-Datei um
zu sehen, ob der Server eine Meldung ausgegeben hat, die auf
die Ursache des Problems hinweist. Sie können auch versuchen,
den Server mit mysqld --standalone
zu
starten. In diesem Fall erscheinen vielleicht nützliche
Informationen auf dem Bildschirm, die Ihnen bei der Lösung
des Problems helfen.
Die letzte Option besteht darin, mysqld
mit
--standalone --debug
zu starten. In diesem
Fall schreibt mysqld
eine Log-Datei
C:\mysqld.trace
, die die Ursache
enthalten könnte, warum mysqld
nicht
startet. See Abschnitt D.1.2, „Trace-Dateien erzeugen“.
Der Win95-/Win98-Abschnitt trifft auch auf NT/Win2000 zu, mit folgenden Unterschieden:
Damit MySQL mit TCP/IP auf NT läuft, müssen Sie Service-Pack 3 (oder neuer) installieren!
Beachten Sie, dass alles Folgende, das für NT zutrifft, ebenfalls für Win2000 zutrifft!
Für NT/Win2000 ist der Servername
mysqld-nt
. Normalerweise sollten Sie MySQL
auf NT/Win2000 als Systemdienst installieren:
C:\> C:\mysql\bin\mysqld-nt --install
oder
C:\> C:\mysql\bin\mysqld-max-nt --install
(Unter Windows NT können Sie in der Tat jede der
Server-Binärdateien als Systemdienst installieren, aber nur
diejenigen, die Namen haben, die auf
-nt.exe
enden, bieten Unterstützung für
Named Pipes.)
Sie können MySQL mit diesen Befehlen starten und anhalten:
C:\>NET START mysql
C:\>NET STOP mysql
Beachten Sie, dass Sie in diesem Fall keine weiteren Optionen
für mysqld-nt
angeben können!
Sie können mysqld-nt
auf NT auch als
allein ablaufendes Programm (Stand-alone) laufen lassen, wenn
Sie mysqld-nt
mit irgend welchen Optionen
starten wollen! Wenn Sie mysqld-nt
auf NT
ohne Optionen laufen lassen, versucht
mysqld-nt
, sich mit den Vorgabeoptionen als
Systemdienst zu starten. Wenn Sie mysqld-nt
angehalten haben, müssen Sie es mit NET START
mysql
neu starten.
Der Systemdienst wird installiert mit dem Namen
MySQL
. Einmal installiert, muss er mit dem
Systemdienst-Steuerungs-Manager (SCM) in der Systemsteuerung
gestartet werden, oder indem Sie den NET START
MySQL
-Befehl benutzen. Wenn irgend welche Optionen
angegeben werden sollen, müssen diese als ``Startparameter''
im SCM-Dienstprogramm angegeben werden, bevor Sie den
MySQL-Dienst starten. Wenn mysqld-nt
läuft, kann er mit mysqladmin
oder dem
SCM-Dienstprogramm angehalten werden, oder indem Sie den
Befehl NET STOP MySQL
benutzen. Wenn Sie
SCM benutzen mysqld-nt
, um den Server
anzuhalten, gibt es eine seltsame Meldung von SCM über
mysqld shutdown normally
. Wenn er als
Systemdienst läuft, hat mysqld-nt
keinen
Zugriff auf die Konsole. Daher werden auch keine Meldungen
angezeigt.
Auf NT erhalten Sie möglicherweise folgende Systemdienst-Fehlermeldungen:
Zugriff verboten | Bedeutung: mysqld-nt.exe kann nicht gefunden werden. |
Kann nicht registrieren | Bedeutung: Der Pfad ist falsch. |
Installation des Systemdienstes fehlgeschlagen. | Bedeutung: Der Systemdienst ist bereits installiert oder der Systemdienst-Steuerungs-Manager ist in einem schlechten Zustand. |
Wenn Sie Problem haben, mysqld-nt
als
Systemdienst zu installieren, versuchen Sie, ihn mit dem
vollen Pfad zu installieren:
C:\> C:\mysql\bin\mysqld-nt --install
Wenn das nicht funktioniert, können Sie erreichen, dass
mysqld-nt
korrekt startet, indem Sie den
Pfad in der Registrierung korrigieren!
Wenn Sie nicht wollen, dass mysqld-nt
als
Systemdienst startet, können Sie ihn wie folgt starten:
C:\> C:\mysql\bin\mysqld-nt --standalone
oder
C:\> C:\mysql\bin\mysqld --standalone --debug
Letztgenanntes gibt Ihnen eine Debug-Spur in
C:\mysqld.trace
. See
Abschnitt D.1.2, „Trace-Dateien erzeugen“.
MySQL unterstützt TCP/IP auf allen Windows-Plattformen und Named Pipes auf NT. Vorgabemäßig werden Named Pipes für lokale Verbindungen auf NT und TCP/IP für alle anderen Fälle benutzt, wenn der Client TCP/IP installiert hat. Der Hostname legt fest, welches Protokoll benutzt wird:
Hostname | Protokoll |
NULL (keiner) | Auf NT zuerst Named Pipes versuchen. Wenn das nicht funktioniert, TCP/IP benutzen. Auf Win95/Win98 wird TCP/IP benutzt. |
. | Named Pipes |
localhost | TCP/IP zum aktuellen Host |
hostname | TCP/IP |
Sie können erzwingen, dass ein MySQL-Client Named Pipes
benutzt, indem Sie die --pipe
-Option oder
.
als Hostnamen angeben. Benutzen Sie die
--socket
-Option, um den Namen der Pipe
festzulegen.
Sie können feststellen, ob MySQL funktioniert, indem Sie die folgenden Befehle eingeben:
C:\>C:\mysql\bin\mysqlshow
C:\>C:\mysql\bin\mysqlshow -u root mysql
C:\>C:\mysql\bin\mysqladmin version status proc
C:\>C:\mysql\bin\mysql test
Wenn mysqld
nur langsam auf Verbindungen
auf Win95/Win98 antwortet, gibt es wahrscheinlich ein Problem
mit Ihrem DNS. Starten Sie in diesem Fall
mysqld
mit
--skip-name-resolve
und benutzen Sie nur
localhost
und IP-Nummern in den MySQL
Berechtigungstabellen. Sie können DNS bei einer Verbindung zu
einem mysqld-nt
-MySQL-Server, der auf NT
läuft, ebenfalls dadurch vermeiden, dass Sie das
--pipe
-Argument verwenden, um die Benutzung
von Named Pipes festzulegen. Das funktioniert bei den meisten
MySQL-Clients.
Es gibt zwei Versionen des MySQL-Kommadozeilen-Werkzeugs:
mysql | Kompiliert auf nativem Windows, was sehr eingeschränkte Texteditiermöglichkeiten bietet. |
mysqlc | Kompiliert mit dem Cygnus-GNU-Kompiler und -Bibliotheken, was
readline -Editiermöglichkeit
bietet. |
Wenn Sie mysqlc.exe
benutzen wollen,
müssen Sie C:\mysql\lib\cygwinb19.dll
in
Ihr Windows-Systemverzeichnis kopieren
(\windows\system
oder ein ähnlicher
Ort).
Vorgabemäßig geben die Berechtigungen auf Windows allen
lokalen Benutzern volle Zugriffsrechte auf alle Datenbanken,
ohne ein Passwort anzugeben. Um MySQL sicherer zu machen,
sollten Sie für alle Benutzer ein Passwort setzen und die
Zeile in der Tabelle mysql.user
, die
Host='localhost'
und
User=''
enthält, löschen.
Sie sollten auch für den root
-Benutzer ein
Passwort vergeben. Das folgende Beispiel entfernt den anonymen
Benutzer, der von jedem genutzt werden kann, um auf die
test
-Datenbank zuzugreifen und setzt dann
für den root
-Benutzer ein Passwort:
C:\>C:\mysql\bin\mysql mysql
mysql>DELETE FROM user WHERE Host='localhost' AND User='';
mysql>QUIT
C:\>C:\mysql\bin\mysqladmin reload
C:\>C:\mysql\bin\mysqladmin -u root password ihr_passwort
Nachdem Sie das Passwort gesetzt haben, sollten Sie den
mysqld
-Server herunter fahren, was Sie mit
folgendem Befehl bewerkstelligen können:
C:\> mysqladmin --user=root --password=ihr_passwort shutdown
Wenn Sie die alte Shareware-Version von MySQL-Version 3.21
unter Windows benutzen, schlägt der genannte Befehl mit einem
Fehler fehl: parse error near 'SET OPTION
password'
. Die Lösung besteht darin, auf die
aktuelle MySQL-Version zu aktualisieren, die frei verfügbar
ist.
Mit den neuen MySQL-Versionen können Sie auf einfache Art
neue Benutzer hinzufügen und Zugriffsrechte mit den
GRANT
- und
REVOKE
-Befehlen ändern. See
Abschnitt 5.3.1, „GRANT
- und REVOKE
-Syntax“.
Hier ist eine Anmerkung dazu, wie man sich über eine sichere
Verbindung zu einem entfernten MySQL-Server mit SSH verbindet
(von David Carlson <dcarlson@mplcomm.com>
):
Installieren Sie einen SSH-Client auf Ihrer
Windows-Maschine. Das beste nicht kostenlose Werkzeug, das
ich gefunden habe, ist SecureCRT
von
http://www.vundyke.com/.
Eine andere Option ist f-secure
von
http://www.f-secure.com/.
Sie finden kostenlose Werkzeuge über
Google auf
http://directory.google.com/Top/Computers/Security/Products_and_Tools/Cryptography/SSH/Clients/Windows/.
Starten Sie Ihren Windows-SSH-Client. Konfigurieren Sie:
Host_Name =
ihr_mysql_server_URL_oder_IP
. Konfigurieren Sie:
userid=ihre_userid
, um sich an Ihrem
Server anzumelden (wahrscheinlich nicht dasselbe wie Ihr
MySQL-Benutzername / -Passwort).
Konfigurieren Sie Port-Forwarding. Machen Sie entweder ein
Remote Forward (einstellen: local_port:
3306
, remote_host:
ihr_mysql_servername_oder_ip
,
remote_port: 3306
) oder ein lokales
Forward (einstellen: port: 3306
,
host: localhost
, remote port:
3306
).
Speichern Sie alles, damit Sie es beim nächsten Mal nicht noch einmal eingeben müssen.
Melden Sie sich an Ihrem Server mit der SSH-Sitzung, die Sie gerade erzeugt haben.
Starten Sie auf Ihrer Windows-Maschine irgend eine Applikation wie Access.
Erzeugen Sie unter Windows eine neue Datei und stellen Sie
eine Verknüpfung zu MySQL her, indem Sie den ODBC-Treiber
so benutzen, wie Sie es normalerweise tun, AUSSER dass Sie
localhost
als MySQL-Host-Server
eingeben - NICHT yourmysqlservername
.
Jetzt sollten Sie eine ODBC-Verbindung zu MySQL haben, die mit SSH verschlüsselt ist.
Ab MySQL-Version 3.23.16 werden die
mysqld-max
- und
mysql-max-nt
-Server in der
MySQL-Distribution mit der
-DUSE_SYMDIR
-Option kompiliert. Das gibt
Ihnen die Möglichkeit, Datenbanken auf verschiedene
Festplatten zu verteilen, indem Sie symbolische Links darauf
machen (in ähnlicher Weise, wie symbolische Links unter Unix
funktionieren).
Unter Windows legen Sie einen symbolischen Link auf eine
Datenbank an, indem Sie eine Datei erzeugen, die den Pfad zum
Zielverzeichnis enthält, und diese Datei im
mysql_data
-Verzeichnis unter dem
Dateiname Datenbank.sym
speichern.
Beachten Sie, dass der symbolische Link nur dann benutzt wird,
wenn das Verzeichnis
mysql_data_dir\datenbank
nicht existiert.
Wenn Ihr MySQL-Daten-Verzeichnis beispielsweise
C:\mysql\data
ist und Sie die Datenbank
foo
dort haben wollen, die aber in
D:\data\foo
liegt, erzeugen Sie die Datei
C:\mysql\data\foo.sym
, die als Text
D:\data\foo\
enthält. Dann werden alle
Tabellen, die in der Datenbank foo
sind, in
D:\data\foo
erzeugt.
Beachten Sie, dass wir dieses Feature nicht vorgabemäßig
aktiviert haben, weil es mit Geschwindigkeitsnachteilen
verbunden ist. Es ist selbst dann nicht aktiviert, wenn Sie
MySQL mit Unterstützung dafür kompiliert haben. Um
symbolische Links zu aktivieren, müssen Sie in Ihre
my.cnf
- oder
my.ini
-Datei folgenden Eintrag machen:
[mysqld] use-symbolic-links
In MySQL 4.0 werden symbolische Links vorgabemäßig aktiviert
sein. Wenn Sie dies deaktivieren wollen, benutzen Sie die
skip-symlink
-Option.
In Ihren Quell-Dateien sollten Sie
windows.h
einschließen, bevor Sie
mysql.h
einschließen:
#if defined(_WIN32) || defined(_WIN64) #include <windows.h> #endif #include <mysql.h>
Sie können Ihren Code entweder mit der dynamischen
libmysql.lib
-Bibliothek linken, die nur
ein Wrapper zum Laden der libmysql.dll
bei Bedarf ist, oder mit der statischen
mysqlclient.lib
-Bibliothek.
Beachten Sie, dass MySQL-Client-Bibliotheken als threaded Bibliotheken kompiliert werden, daher sollten Sie auch Ihren Code so kompilieren, dass er multi-threaded ist!
MySQL-Windows hat sich mittlerweile als sehr stabil erwiesen. Diese Version von MySQL hat dieselben Features wie die entsprechende Unix-Version, allerdings mit folgenden Ausnahmen:
Windows 95 und Threads
Windows 95 hat ein etwa 200 Bytes großes
Hauptspeicher-Leck (Memory Leak) für jede
Thread-Erzeugung. Jede Verbindung zu MySQL erzeugt eine
neues Thread, daher sollten Sie mysqld
nicht für längere Zeiträume auf Windows 95 laufen
lassen, wenn Ihr Server viele Verbindungen handhabt!
Windows NT und Windows 98 haben diesen Bug nicht.
Gleichzeitige Lesezugriffe
MySQL vertraut auf pread()
- und
pwrite()
-Aufrufe, um in der Lage zu
sein, INSERT
und
SELECT
zu mischen. Momentan benutzen
wir mutexes, um pread()
/
pwrite()
zu emulieren. Langfristig
werden wir die Dateiebenen-Schnittstelle durch eine
virtuelle Schnittstelle ersetzen, um die
readfile()
- /
writefile()
-Schnittstelle auf NT mit
höherer Geschwindigkeit benutzen zu können. Die aktuelle
Implementation begrenzt die Anzahl offener Dateien, die
MySQL benutzen kann, auf 1024, was bedeutet, dass Sie
nicht so viele gleichzeitige Threads auf NT benutzen
können wie auf Unix.
Blockierendes Lesen
MySQL benutzt blockierendes Lesen (Blocking Read) für jede Verbindung. Das bedeutet in der Anwendung:
Eine Verbindung wird nicht automatisch nach 8 Stunden abgebaut, wie es unter der Unix-Version von MySQL der Fall ist.
Wenn eine Verbindung hängen bleibt, ist es unmöglich, sie abzubrechen, ohne MySQL zu killen.
mysqladmin kill
funktioniert
nicht für schlafende Verbindungen.
mysqladmin shutdown
kann nicht
abgebrochen werden, solange es noch schlafende
Verbindungen gibt.
Geplant ist, dieses Problem zu beheben, sobald unsere Windows-Entwickler ein nettes Workaround heraus gefunden haben.
UDF-Funktionen
Momentan unterstützt MySQL-Windows keine benutzerdefinierten Funktionen (UDF, user defined functions).
DROP
DATABASE
Sie können keine Datenbank löschen, die durch irgend einen Thread in Benutzung ist.
MySQL vom Task-Manager aus killen
Sie können MySQL nicht vom Task-Manager oder mit dem
Shutdown-Dienstprogramm unter Windows 95 killen. Sie
müssen es mit mysqladmin shutdown
herunter fahren.
Von Groß-/Kleinschreibung unabhängige Namen
Unter Windows sind Dateinamen unabhängig von der Groß-/Kleinschreibung. Daher sind Datenbank- und Tabellennamen in MySQL für Windows ebenfalls unabhängig von der Groß-/Kleinschreibung. Die einzige Einschränkung ist die, dass Datenbank- und Tabellennamen innerhalb eines bestimmten Statements dieselbe Groß-/Kleinschreibung haben müssen. See Abschnitt A.5.1, „Groß-/Kleinschreibung beim Suchen“.
Das
‘\
’-Verzeichnis-Zeichen
Bestandteile von Pfadnamen werden unter Windows mit dem
‘\
’-Zeichen getrennt, das
in MySQL als Fluchtzeichen (Escape Character) dient. Wenn
Sie LOAD DATA INFILE
oder
SELECT ... INTO OUTFILE
benutzen,
müssen Sie ‘\
’ an solchen
Stellen doppelt eingeben:
mysql>LOAD DATA INFILE "C:\\tmp\\skr.txt" INTO TABLE skr;
mysql>SELECT * INTO OUTFILE 'C:\\tmp\\skr.txt' FROM skr;
Alternativ können Sie auch Dateinamen im Unix-Stil mit
‘/
’-Zeichen benutzen:
mysql>LOAD DATA INFILE "C:/tmp/skr.txt" INTO TABLE skr;
mysql>SELECT * INTO OUTFILE 'C:/tmp/skr.txt' FROM skr;
Can't open named
pipe
-Fehler
Wenn Sie MySQL-Version 3.22 auf NT mit den neuesten MySQL-Clients benutzen, erhalten Sie folgende Fehlermeldung:
error 2017: can't open named pipe to host: . pipe...
Das liegt daran, dass die MySQL-Version für NT auf NT
vorgabemäßig Named Pipes benutzt. Sie können diesen
Fehler vermeiden, indem Sie bei den neuen MySQL-Clients
die --host=localhost
-Option benutzen oder
eine Optionsdatei C:\my.cnf
anlegen,
die folgendes enthält:
[client] host = localhost
Access denied for
user
-Fehler
Wenn Sie den Fehler Access denied for user:
'ein-benutzer@unknown' to database 'mysql'
erhalten, wenn Sie auf einen MySQL-Server auf derselben
Maschine zugreifen, heißt das, dass MySQL Ihren Hostnamen
nicht richtig auflösen kann.
Um das zu beheben, legen Sie eine Datei
\windows\hosts
mit folgender Zeile
an:
127.0.0.1 localhost
ALTER
TABLE
Wenn Sie ein ALTER TABLE
-Statement
ausführen, ist die Tabelle gegen Benutzung durch andere
Threads gesperrt. Das hat damit zu tun, dass Sie unter
Windows keine Datei löschen können, die durch andere
Threads in Benutzung ist. (Zukünftig finden wir
möglicherweise einen Weg, dieses Problem zu umgehen.)
DROP TABLE
auf
eine Tabelle, die durch eine
MERGE
-Tabelle in Benutzung ist,
funktioniert nicht. Der MERGE
-Handler
führt sein Tabellen-Mapping versteckt vor MySQL durch.
Weil Windows das Löschen von Dateien verbietet, die offen
sind, müssen Sie zuerst alle
MERGE
-Tabellen flushen (mit
FLUSH TABLES
) oder die
MERGE
-Tabelle löschen, bevor Sie die
Tabelle löschen. Wir werden das zusammen mit der
Einführung von Sichten (VIEW
s)
beheben.
Hier sind einige Themen für diejenigen, die uns beim Windows-Release helfen wollen:
Einen Ein-Benutzer-Server MYSQL.DLL
herstellen. Das könnte alles beinhalten, was einen
Standard-Server ausmacht, ausser Thread-Erzeugung. Das
würde es erheblich erleichtern, MySQL in Applikationen zu
benutzen, die keinen echten Client/Server und keinen
Zugriff auf den Server von anderen Hosts benötigen.
Ein paar nette Start- und Stop-Icons zur MySQL-Installation hinzufügen.
Ein Werkzeug bauen, das Registrierungseinträge für die
MySQL-Startoptionen handhabt. Das Lesen der
Registrierungseinträge ist bereits in
mysqld.cc
kodiert, sollte aber
umgeschrieben werden, damit es mehr Parameter-orientiert
ist. Das Werkzeug sollte auch in der Lage sein, die
C:\my.cnf
-Optionsdatei zu
aktualisieren, wenn der Benutzer diese lieber als die
Registrierungsdatei benutzen will.
Wenn man mysqld
als Systemdienst mit
--install
(auf NT) installiert, wäre es
nett, wenn man vorgabemäßige Optionen auf der
Kommandozeile hinzufügen könnte. Im Moment muss man
diese fehlende Möglichkeit durch eine Liste der Parameter
in der C:\my.cnf
-Datei ersetzen.
Es wäre eine feine Sache, wenn man
mysqld
vom Task-Manager aus killen
könnte. Momentan muss man mysqladmin
shutdown
benutzen.
readline
auf Windows portieren, damit
es im mysql
-Kommandozeilen-Werkzeug
benutzt werden kann.
GUI-Versionen der Standard-MySQL-Clients
(mysql
, mysqlshow
,
mysqladmin
und
mysqldump
) wären nett.
Nett wäre auch, wenn die Socket-Lese- und
Schreib-Funktionen in net.c
unterbrechbar wären. Das würde es ermöglichen, offen
Threads mit mysqladmin kill
auf Windows
zu killen.
following two lines? mysqld
always
starts in the "C" locale und not in the default locale. We
would like to have mysqld
use the
current locale für the sort order.
Benutzerdefinierte Funktionen (UDF) mit
.DLL
s implementieren.
Makros hinzufügen, um die schnelleren, Thread-sicheren Inkrementierungs-/Dekrementierungsmethoden nutzen zu können, die Windows bietet.
Weitere Windows-spezifische Themen sind in der
README
-Datei beschrieben, die mit der
MySQL-Windows-Distribution ausgeliefert wird.
Auf Solaris bekommen Sie vielleicht schon Probleme, bevor Sie
überhaupt Ihre MySQL-Distribution entpackt haben!
Solaris-tar
kann nicht mit langen Dateinamen
umgehen. Daher sehen Sie vielleicht einen Fehler wie den
folgenden, wenn Sie MySQL entpacken:
x mysql-3.22.12-beta/bench/Results/ATIS-mysql_odbc-NT_4.0-cmp-db2,informix,ms-sql,mysql,oracle,solid,sybase, 0 Bytes, 0 tape blocks tar: directory checksum error (Verzeichnis-Prüfsummenfehler)
In diesem Fall müssen Sie GNU-tar
(gtar
) benutzen, um die Distribution zu
entpacken. Sie finden eine vorkompilierte Version für Solaris
auf
http://www.mysql.com/downloads/.
Native Sun-Threads funktinieren nur auf Solaris 2.5 und höher. Auf 2.4 und früher benutzt MySQL automatisch MIT-pThreads. See Abschnitt 3.3.6, „Anmerkungen zu MIT-pThreads“.
Vielleicht erhalten Sie von configure folgenden Fehler:
checking for restartable system calls... configure: error can not run test programs while cross compiling
Das bedeutet, dass mit Ihrer Kompiler-Installation etwas nicht
stimmt! In diesem Fall sollten Sie Ihren Kompiler auf eine
neuere Version aktualisieren. Eventuell sind Sie in der Lage,
das Problem zu lösen, indem Sie folgende Zeile in die
config.cache
-Datei einfügen:
ac_cv_sys_restartable_syscalls=${ac_cv_sys_restartable_syscalls='no'}
Wenn Sie Solaris auf einer SPARC benutzen, ist der empfohlene
Kompiler gcc
2.95.2. Sie finden ihn auf
http://gcc.gnu.org/.
Beachten Sie, dass egcs
1.1.1 und
gcc
2.8.1 auf SPARC nicht zuverlässig
laufen!
Die empfohlene configure
-Zeile ist bei der
Benutzung von gcc
2.95.2:
CC=gcc CFLAGS="-O3" \ CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql --with-low-memory --enable-assembler
Wenn Sie eine Ultra-Sparc haben, erhalten Sie 4 % mehr Performance, wenn Sie "-mcpu=v8 -Wa,-xarch=v8plusa" zu CFLAGS und CXXFLAGS hinzufügen.
Wenn Sie einen Sun Workshop (Fortre) 5.3 (oder neueren) Kompiler
haben, können Sie configure
wie folgt laufen
lassen:
CC=cc CFLAGS="-Xa -fast -xO4 -native -xstrconst -mt" \ CXX=CC CXXFLAGS="-noex -xO4 -mt" \ ./configure --prefix=/usr/local/mysql --enable-assembler
In den MySQL-Benchmarks haben wir auf einer Ultra-Sparc 6% Geschwindigkeitssteigerung erreicht, wenn wir Sun Workshop 5.3 benutzen, im Vergleich mit der Benutzung von gcc mit -mcpu-Flags.
Wenn Sie Probleme mit fdatasync
oder
sched_yield
bekommen, können Sie diese
beheben, indem Sie LIBS=-lrt
zur
Konfigurationszeile hinzufügen.
Der folgende Absatz ist nur für ältere Kompiler als WorkShop 5.3 relevant:
Eventuell müssen Sie auch das
configure
-Skript editieren und folgende Zeile
ändern:
#if !defined(__STDC__) || __STDC__ != 1
Ändern zu:
#if !defined(__STDC__)
Wenn Sie __STDC__
mit der
-Xc
-Option anschalten, kann der Sun-Kompiler
nicht mit der
Solaris-pThread.h
-Header-Datei kompilieren.
Das ist ein Bug von Sun (Kompiler-Problem oder beschädigte
Include-Datei).
Wenn mysqld
beim Laufenlassen eine
Fehlermeldung wie die unten stehende ausgibt, haben Sie
versucht, MySQL mit dem Sun-Kompiler zu kompilieren, ohne die
Multi-Thread-Option (-mt
) anzuschalten:
libc internal error: _rmutex_unlock: rmutex not held
Fügen Sie -mt
zu CFLAGS
und CXXFLAGS
hinzu und versuchen Sie es noch
einmal.
Wenn Sie folgenden Fehler beim Kompilieren von MySQL mit
gcc
erhalten, ist Ihr gcc
nicht für Ihre Version von Solaris konfiguriert:
shell> gcc -O3 -g -O2 -DDBUG_OFF -o thr_alarm ...
./thr_alarm.c: In function `signal_hand':
./thr_alarm.c:556: too many arguments to function `sigwait'
Die einzige richtige Möglichkeit in diesem Fall ist, sich die
neueste Version von gcc
zu besorgen und Sie
mit Ihrem aktuellen gcc
-Kompiler zu
kompilieren. Zumindest auf Solaris 2.5 haben fast alle
Binärversionen von gcc
alte, unbrauchbare
Include-Dateien, die alle Programme beschädigen, die Threads
benutzen (und möglicherweise auch andere Programme)!
Solaris stellt keine statischen Versionen aller
Systembibliotheken zur Verfügung
(libpThreads
und libdl
).
Daher können Sie MySQL nicht mit --static
kompilieren. Wenn Sie es dennoch versuchen, erhalten Sie
folgenden Fehler:
ld: fatal: library -ldl: not found oder undefined reference to `dlopen' oder cannot find -lrt
Wenn zu viele Prozesse zu schnell hintereinander versuchen, sich
mit mysqld
zu verbinden, werden Sie folgenden
Fehler im MySQL-Log sehen:
Error in accept: Protocol error
Als Workaround können Sie versuchen, den Server mit der
--set-variable back_log=50
-Option zu starten.
See Abschnitt 5.1.1, „mysqld-Kommandozeilenoptionen“.
Wenn Sie Ihren eigenen MySQL-Client linken, erhalten Sie möglicherweise folgenden Fehler, wenn Sie versuchen, ihn auszuführen:
ld.so.1: ./my: fatal: libmysqlclient.so.#: open failed: No such file or directory
Dieses Problem kann mit einer der folgenden Methoden vermieden werden:
Wenn Sie die --with-libwrap
-configure-Option
benutzen, müssen Sie auch die Bibliotheken einschließen, die
libwrap.a
benötigt:
--with-libwrap="/opt/NUtcpwrapper-7.6/lib/libwrap.a -lnsl -lsocket
Wenn Sie Probleme mit configure haben, wenn Sie versuchen, mit
-lz
zu linken und keine
zlib
installiert haben, haben Sie zwei
Möglichkeiten:
Wenn Sie in der Lage sein wollen, dass komprimierte Kommunikationsprotokoll zu benutzen, müssen Sie zlib von ftp.gnu.org laden und installieren.
Konfigurieren Sie mit
--with-named-z-libs=no
.
Wenn Sie gcc benutzen und Probleme mit dem Laden von
UDF
-Funktionen in MySQL haben, versuchen Sie,
-lgcc
zur Link-Zeile für die
UDF
-Funktion hinzuzufügen.
Wenn Sie wollen, dass MySQL automatisch startet, kopieren Sie
Support-files/mysql.server
nach
/etc/init.d
und erzeugen Sie einen
symbolischen Link darauf, den Sie
/etc/rc3.d/S99mysql.server
nennen.
Normalerweise können Sie eine Solaris-2.6-Binärdatei für Solaris 2.7 und 2.8 benutzen. Die meisten Dinge, die Solaris 2.6 betreffen, treffen auch für Solaris 2.7 und 2.8 zu.
Beachten Sie, dass MySQL-Version 3.23.4 und höher in der Lage sein sollte, automatisch neue Versionen von Solaris zu erkennen und Workarounds für die folgenden Probleme zu aktivieren!
Solaris 2.7 / 2.8 hat einige Bugs in den Include-Dateien.
Eventuell sehen Sie folgenden Fehler, wenn Sie
gcc
benutzen:
/usr/include/widec.h:42: warning: `getwc' redefined /usr/include/wchar.h:326: warning: this is the location of the previous definition
Wenn das auftritt, können Sie folgendes tun, um das Problem zu lösen:
Kopieren Sie /usr/include/widec.h
nach
.../lib/gcc-lib/os/gcc-version/include
und
ändern Sie Zeile 41 von:
#if !defined(lint) && !defined(__lint) nach #if !defined(lint) && !defined(__lint) && !defined(getwc)
Alternativ können Sie
/usr/include/widec.h
direkt editieren.
Egal, wie Sie vorgehen: Nachdem Sie die Fehlerbehebung
durchgeführt haben, sollten Sie
config.cache
entfernen und
configure
noch einmal laufen lassen!
Wenn Sie beim Laufenlassen von make
folgende Fehler bekommen, liegt das daran, dass
configure
die
curses.h
-Datei nicht erkannte (vermutlich
aufgrund des Fehlers in
/usr/include/widec.h
):
In file included by mysql.cc:50: /usr/include/term.h:1060: syntax error before `,' /usr/include/term.h:1081: syntax error before `;'
Das Problem lösen Sie auf eine der folgenden Weisen:
Konfigurieren Sie mit CFLAGS=-DHAVE_CURSES_H
CXXFLAGS=-DHAVE_CURSES_H ./configure
.
Editieren Sie /usr/include/widec.h
,
wie weiter oben gezeigt, und lassen Sie configure noch
einmal laufen.
Entfernen Sie die #define
HAVE_TERM
-Zeile aus der
config.h
-Datei und lassen Sie
make
noch einmal laufen.
Wenn Sie das Problem bekommen, dass Ihr Linker
-lz
nicht finden kann, wenn Sie Ihr
Client-Programm linken, liegt das wahrscheinlich daran, dass
Ihre libz.so
-Datei in
/usr/local/lib
installiert ist. Sie
können das mit einer der folgenden Methoden beheben:
Fügen Sie /usr/local/lib
zu
LD_LIBRARY_PATH
hinzu.
Fügen Sie einen Link auf libz.so
von
/lib
hinzu.
Wenn Sie Solaris 8 benutzen, können Sie die optionale zlib aus Ihrer Solaris-8-CD-Distribution installieren.
Konfigurieren Sie MySQL mit der
--with-named-z-libs=no
-Option.
Auf Solaris 2.8 auf x86 erzeugt mysqld
einen Speicherauszug (Core Dump), wenn Sie darin 'strip'
laufen lassen.
Wenn Sie gcc
oder egcs
auf Solaris x86 benutzen und Probleme mit Speicherauszügen
(Core Dumps) unter Last erleben, sollten Sie folgenden
configure
-Befehl benutzen:
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
Das vermeidet Probleme mit der
libstdc++
-Bibliothek und mit
C++-Ausnahmefehlern.
Wenn das nicht hilft, sollten Sie eine Debug-Version
kompilieren und sie mit einer Trace-Datei oder unter
gdb
laufen lassen. See
Abschnitt D.1.3, „mysqld unter gdb debuggen“.
FreeBSD 3.x wird für MySQL empfohlen, weil das Thread-Paket sehr viel integrierter ist.
Die einfachste und daher empfohlene Art der Installation ist die Benutzung der mysql-server- und mysql-client-Ports, die auf http://www.freebsd.org verfügbar sind.
Durch deren Benutzung erhalten Sie:
Ein funktionierendes MySQL mit allen Optimierungen bereits aktiviert, von denen bekannt ist, dass Sie auf Ihrer Version von FreeBSD funktionieren.
Automatische Konfiguration, automatisches Build.
Start-Skripte, die in /usr/local/etc/rc.d installiert werden.
Die Möglichkeit festzustellen, welche Dateien installiert sind, mit pkg_info -L. Und die Möglichkeit, sie mit pkg_delete zu entfernen, wenn Sie MySQL nicht mehr auf dieser Maschine haben wollen.
Empfohlen wird die Benutzung von MIT-pThreads auf FreeBSD 2.x
und von nativen Threads auf Version 3 und höher. Es ist
möglich, auf einigen späten 2.2.x-Versionen mit nativen
Threads zu arbeiten, aber Sie können beim Herunterfahren von
mysqld
Probleme bekommen.
Die MySQL-Makefile
-Dateien erfordern
GNU-make (gmake
). Wenn Sie MySQL
kompilieren wollen, müssen Sie zuerst
GNU-make
installieren.
Stellen Sie sicher, dass Ihr Namensauflöser (Name Resolver)
korrekt eingerichtet ist. Ansonsten erleben Sie vielleicht
Resolver-Verzögerungen oder -Fehler, wenn Sie sich mit
mysqld
verbinden.
Stellen Sie sicher, dass der
localhost
-Eintrag in der
/etc/hosts
-Datei stimmt. Ansonsten werden
Sie Probleme haben, sich mit der Datenbank zu verbinden. Die
/etc/hosts
-Datei sollte mit folgender
Zeile beginnen:
127.0.0.1 localhost localhost.ihre.domain
Wenn Sie bemerken, dass configure
MIT-pThreads benutzen wird, lesen Sie die Anmerkungen zu
MIT-pThreads. See Abschnitt 3.3.6, „Anmerkungen zu MIT-pThreads“.
Wenn make install
meldet, dass es
/usr/include/pThreads
nicht finden kann,
hat configure
nicht entdeckt, dass Sie
MIT-pThreads benötigen. Das kann durch die Ausführung
folgender Befehle behoben werden:
shell>rm config.cache
shell>./configure --with-mit-threads
FreeBSD ist dafür bekannt, dass es vorgabemäßig einen sehr
niedrigen Wert für Datei-Handles eingestellt hat. See
Abschnitt A.2.16, „File Not Found“. Kommentieren Sie
den Abschnitt ulimit -n section in safe_mysqld aus oder
erhöhen Sie die Werte für den
mysqld
-Benutzer in /etc/login.conf (und
bauen Sie es neu mit cap_mkdb /etc/login.conf). Stellen Sie
ausserdem sicher, dass Sie die korrekte Klasse für diesen
Benutzer in der Passwort-Datei einstellen, wenn Sie nicht den
Vorgabewert benutzen (benutzen Sie chpass mysqld-user-name).
See Abschnitt 5.7.2, „safe_mysqld, der Wrapper um mysqld“.
Wenn Sie Probleme mit dem aktuellen Datum in MySQL erhalten,
wird das Setzen der TZ
-Variablen das
wahrscheinlich beheben. See
Anhang E, Umgebungsvariablen.
Um ein sicheres, stabiles System zu erhalten, sollten Sie
ausschließlich FreeBSD-Kernels benutzen, die als
-STABLE
markiert sind.
Um auf NetBSD zu kompilieren, benötigen Sie GNU
make
. Ansonsten wird das Kompilieren
abstürzen, wenn make
versucht,
lint
auf C++Dateien laufen zu lassen.
Auf OpenBSD-Version 2.5 können Sie MySQL mit nativen Threads mit folgenden Optionen kompilieren:
CFLAGS=-pThread CXXFLAGS=-pThread ./configure --with-mit-threads=no
Unsere Benutzer haben berichtet, dass OpenBSD 2.8 einen Thread-Bug hat, der Probleme mit MySQL verursacht. Die OpenBSD-Entwickler haben das Problem behoben, aber seit dem 25. Januar 2001 ist es nur im ``-current''-Zweig verfügbar. Die Symptome dieses Thread-Bugs sind langsames Antworten, hohe Lase, hohe Prozessorauslastung und Abstürze.
Wenn Sie folgenden Fehler beim Kompilieren von MySQL erhalten,
ist Ihr ulimit
-Wert für virtuellen
Speicher 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
Versuchen Sie, ulimit -v 80000
zu benutzen,
und lassen Sie make
erneut laufen. Wenn das
nicht funktioniert und Sie bash
benutzen,
versuchen Sie, statt dessen csh
oder
sh
zu benutzen. Einige BSDI-Benutzer haben
Probleme mit bash
und
ulimit
berichtet.
Wenn Sie gcc
benutzen, müssen Sie
eventuell auch den --with-low-memory
-Flag
für configure
benutzen, um in der Lage zu
sein, sql_yacc.cc
zu kompilieren.
Wenn Sie Probleme mit dem aktuellen Datum in MySQL erhalten,
wird das Setzen der TZ
-Variablen das
wahrscheinlich beheben. See
Anhang E, Umgebungsvariablen.
Aktualisieren Sie auf BSD/OS Version 3.1. Wenn das nicht möglich ist, installieren Sie BSDI-Patch M300-038.
Benutzen Sie zur Konfiguration von MySQL folgenden Befehl:
shell>env CXX=shlicc++ CC=shlicc2 \
./configure \
--prefix=/usr/local/mysql \
--localstatedir=/var/mysql \
--without-perl \
--with-unix-socket-path=/var/mysql/mysql.sock
Folgendes funktioniert bekanntermaßen ebenfalls:
shell>env CC=gcc CXX=gcc CXXFLAGS=-O3 \
./configure \
--prefix=/usr/local/mysql \
--with-unix-socket-path=/var/mysql/mysql.sock
Wenn Sie wollen, können Sie die Verzeichnisorte ändern oder aber die Vorgabewerte benutzen, indem Sie einfach keine Speicherorte angeben.
Wenn Sie Performance-Probleme unter Hochlast bekommen,
versuchen Sie die
--skip-thread-priority
-Option für
mysqld
! Dies führt alle Threads mit
derselben Priorität aus. Auf BSDI-Version 3.1 gibt Ihnen das
bessere Performance (zumindest solange, bis BSDI ihren
Thread-Scheduler in Ordnung bringt).
Wenn Sie beim Kompilieren den Fehler virtual memory
exhausted
erhalten, probieren Sie es mit
ulimit -v 80000
und lassen Sie
make
noch einmal laufen. Wenn das nicht
funktioniert und Sie bash
benutzen,
versuchen Sie, statt dessen csh
oder
sh
zu benutzen. Einige BSDI-Benutzer haben
Probleme mit bash
und
ulimit
berichtet.
BSDI-Version 4.x hat einige auf Threads bezogene Bugs. Wenn Sie auf dieser Plattform MySQL benutzen wollen, sollten Sie alle Patches installieren, die sich auf Threads beziehen. Zumindest M400-023 sollte installiert sein.
Auf einigen Systemen mit BSDI-Version 4.x bekommen Sie
vielleicht Probleme mit gemeinsam verwendeten (shared)
Bibliotheken. Das äußert sich darin, dass Sie keinerlei
Client-Programme wie mysqladmin
ausführen
können. In diesem Fall müssen Sie MySQL so rekonfigurieren,
dass keine gemeinsam genutzten Bibliotheken benutzt werden,
indem Sie die --disable-shared
-Option für
configure benutzen.
Einige Kunden hatten auf BSDI 4.0.1 Probleme damit, dass die
mysqld
-Binärdatei nach einiger Zeit keine
Tabellen mehr öffnen konnte. Das liegt an einigen Bugs, die
sich auf Bibliothek / System beziehen, und die
mysqld
veranlassen, das aktuelle
Verzeichnis zu wechseln, ohne danach gefragt zu haben!
Die Lösung besteht darin, entweder auf 3.23.34 zu
aktualisieren oder nach dem Laufenlassen von
configure
die Zeile #define
HAVE_REALPATH
aus config.h
zu
entfernen, bevor Sie make laufen lassen.
Beachten Sie, dass sich aus dem Gesagten ergibt, dass Sie auf BSDI keine symbolischen Links von Datenbankverzeichnissen zu einem anderen Datenbankverzeichnis oder symbolische Links von einer Tabelle zu einer anderen Datenbank herstellen können! (Ein symbolischer Link auf eine andere Platte ist okay.)
MySQL sollte ohne jedes Problem auf Mac OS X Public Beta (Darwin) laufen. Die pThread-Patches für dieses Betriebssystem benötigen Sie nicht!
Bevor Sie versuchen, MySQL auf Mac OS X Server zu konfigurieren, müssen Sie das pThread-Paket von http://www.prnet.de/RegEx/mysql.html installieren.
Unsere Binärdatei für Mac OS X wird kompiliert auf Rhapsody 5.5, mit folgender Konfigurationszeile:
CC=gcc CFLAGS="-O2 -fomit-frame-pointer" CXX=gcc CXXFLAGS="-O2 -fomit-frame-pointer" ./configure --prefix=/usr/local/mysql "--with-comment=Official MySQL binary" --with-extra-charsets=complex --disable-shared
Wenn Sie der Ressourcen-Datei Ihrer Shell Aliase hinzufügen
wollen, um auf mysql
und
mysqladmin
von der Kommandozeile aus
zuzugreifen, geben Sie ein:
alias mysql '/usr/local/mysql/bin/mysql' alias mysqladmin '/usr/local/mysql/bin/mysqladmin'
Einige Binärdistributionen von MySQL für HP-UX werden als HP-Depot-Datei und als Tar-Datei ausgeliefert. Um die Depot-Datei benutzen zu können, müssen Sie mindestens HP-UX 10.x haben, um auf HP's Software-Depot-Werkzeuge zugreifen zu können.
Die HP-Version von MySQL wurde auf einem HP 9000/8xx-Server unter HP-UX 10.20 kompiliert und benutzt MIT-pThreads. Unter dieser Konfiguration arbeitet sie bekanntermaßen gut. MySQL-Version 3.22.26 und neuer kann auch mit HP's nativem Thread-Paket gebaut werden.
Weitere Konfigurationen, die ebenfalls funktionieren können:
HP 9000/7xx mit HP-UX 10.20+
HP 9000/8xx mit HP-UX 10.30
Folgende Konfigurationen werden fast mit Sicherheit nicht laufen:
HP 9000/7xx oder 8xx mit HP-UX 10.x, wobei x < 2
HP 9000/7xx oder 8xx mit HP-UX 9.x
Um die Distribution zu installieren, benutzen Sie die unten
stehenden Befehle, wobei /pfad/zum/depot
der volle Pfadname der Depot-Datei ist:
Um alles inklusive Server, Client- und Entwicklungs-Werkzeuge zu installieren:
shell> /usr/sbin/swinstall -s /pfad/zum/depot mysql.full
Um nur den Server zu installieren:
shell> /usr/sbin/swinstall -s /pfad/zum/depot mysql.server
Um nur das Client-Paket zu installieren:
shell> /usr/sbin/swinstall -s /pfad/zum/depot mysql.client
Um nur die Entwicklungs-Werkzeuge zu installieren:
shell> /usr/sbin/swinstall -s /pfad/zum/depot mysql.developer
Das Depot speichert Binärdateien und Bibliotheken in
/opt/mysql
und Daten in
/var/opt/mysql
. Es legt auch die
entsprechenden Einträge in /etc/init.d
und /etc/rc2.d
an, um den Server
automatisch beim Hochfahren zu starten. Das setzt
root
-Rechte zum Installieren voraus.
Um die HP-UX-tar.gz-Distribution zu installieren, müssen Sie
GNU tar
haben.
Es gibt einige kleine Probleme, wenn Sie MySQL auf HP-UX
kompilieren. Wir empfehlen, anstelle des nativen
HP-UX-Kompilers gcc
zu benutzen, weil
gcc
besseren Code produziert!
Wir empfehlen die Benutzung von gcc 2.95 auf HP-UX. Benutzen Sie keine hohen Optimierungs-Flags (wie -O6), weil das eventuell für HP-UX nicht sicher ist.
Beachten Sie, dass MIT-pThreads nicht mit dem HP-UX-Kompiler
kompiliert werden können, weil dieser keine
.S
-(Assembler)-Dateien kompilieren kann.
Folgende Konfigurationszeile sollte funktionieren:
CFLAGS="-DHPUX -I/opt/dce/include" CXXFLAGS="-DHPUX -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
Wenn Sie gcc
2.95 selbst kompilieren,
sollten Sie ihn NICHT mit den DCE-Bibliotheken
(libdce.a
oder libcma.a
)
linken, wenn Sie MySQL mit MIT-pThreads kompilieren wollen.
Wenn Sie DCE- und MIT-pThreads-Pakete mischen, erhalten Sie
einen mysqld
, mit dem Sie sich nicht
verbinden können. Entfernen Sie die DCE-Bibliotheken,
während Sie gcc
2.95 kompilieren!
Für HP-UX Version 11.x empfehlen wir MySQL-Version 3.23.15 oder später.
Wegen einiger kritischer Bugs in den Standard-HP-UX-Bibliotheken sollten Sie folgende Patches installieren, bevor Sie MySQL auf HP-UX 11.0 laufen lassen:
PHKL_22840 Streams cumulative PHNE_22397 ARPA cumulative
Das löst das Problem, dass man EWOULDBLOCK
von recv()
und EBADF
von
accept()
in threaded Applikationen erhält.
Wenn Sie gcc
2.95.1 auf einem
nicht-gepatchten HP-UX-11.x-System benutzen, erhalten Sie den
Fehler:
In file included by /usr/include/unistd.h:11, by ../include/global.h:125, by mysql_priv.h:15, by item.cc:19: /usr/include/sys/unistd.h:184: declaration of C function ... /usr/include/sys/pThread.h:440: previous declaration ... In file included by item.h:306, by mysql_priv.h:158, by item.cc:19:
Das Problem liegt darin, dass HP-UX
pThreads_atfork()
nicht konsistent
definiert. Es hat konfliktbehaftete Prototypes in
/usr/include/sys/unistd.h
:184 und
/usr/include/sys/pThread.h
:440 (Details
weiter unten).
Eine Lösung besteht darin,
/usr/include/sys/unistd.h
nach
mysql/include
zu kopieren und
unistd.h
zu editieren, wobei es so
abgeändert wird, dass es der Definition in
pThread.h
entspricht. Hier ist der Diff:
183,184c183,184 < extern int pThread_atfork(void (*prepare)(), void (*parent)(), < void (*child)()); --- > extern int pThread_atfork(void (*prepare)(void), void (*parent)(void), > void (*child)(void));
Danach sollte folgende Konfigurationszeile funktionieren:
CFLAGS="-fomit-frame-pointer -O3 -fpic" CXX=gcc CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti -O3" ./configure --prefix=/usr/local/mysql --disable-shared
Hier sind ein paar Informationen über das Kompilieren von MySQL mit dem HP-UX:x-Kompiler, die uns ein Benutzer der HP-UX-Version 11.x geschickt hat:
Environment: proper compilers. setenv CC cc setenv CXX aCC flags setenv CFLAGS -D_REENTRANT setenv CXXFLAGS -D_REENTRANT setenv CPPFLAGS -D_REENTRANT % aCC -V aCC: HP ANSI C++ B3910B X.03.14.06 % cc -V /tmp/empty.c cpp.ansi: HP92453-01 A.11.02.00 HP C Preprocessor (ANSI) ccom: HP92453-01 A.11.01.00 HP C Compiler cc: "/tmp/empty.c", line 1: warning 501: Empty source file. configuration: ./configure --with-pThread \ --prefix=/source-control/mysql \ --with-named-Thread-libs=-lpThread \ --with-low-memory added '#define _CTYPE_INCLUDED' to include/m_ctype.h. This symbol ist the one defined in HP's /usr/include/ctype.h: /* Don't include std ctype.h when this is included */ #define _CTYPE_H #define __CTYPE_INCLUDED #define _CTYPE_INCLUDED #define _CTYPE_USING /* Don't put names in global namespace. */
Ich muss den Compile-Time-Flag
-D_REENTRANT
benutzen, um den Kompiler
dazu zu bringen, den Prototype für
localtime_r
zu erkennen. Alternativ
hätte ich auch den Prototype für
localtime_r
bereit stellen können.
Aber ich wollte weitere Bugs abfangen, in die ich sonst
gerannt wäre. Ich war nicht sicher, wo ich es benötigen
würde, daher fügte ich es zu allen Flags hinzu.
Die Optimierungs-Flags, die MySQL benutzt (-O3), werden von den HP-Kompilern nicht erkannt. Ich habe die Flags nicht geändert.
Wenn Sie folgenden Fehler von configure
erhalten:
checking for cc option to accept ANSI C... no configure: error: MySQL requires a ANSI C compiler (and a C++ compiler). Try gcc. See the installation chapter in the reference manual.
Überprüfen Sie, dass Sie den Pfad zum K&R-Kompiler nicht vor dem Pfad zum HP-UX-C- und C++-Kompiler haben.
Automatische Erkennung von xlC
fehlt bei
Autoconf, daher wird ein configure
-Befehl
wie folgender benötigt, wenn Sie MySQL kompilieren (dieses
Beispiel benutzt den IBM-Kompiler):
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 LDLFAGS="-L /usr/local/lib" export CPPFLAGS=$CFLAGS export CXXFLAGS=$CFLAGS ./configure --prefix=/usr/local \ --localstatedir=/var/mysql \ --sysconfdir=/etc/mysql \ --sbindir='/usr/local/bin' \ --libexecdir='/usr/local/bin' \ --enable-thread-safe-client \ --enable-large-files
Das sind die Optionen, die benutzt werden, um die MySQL-Distribution zu kompilieren, die sich auf http://www-frec.bull.com/ befindet.
Wenn Sie in obiger Konfigurationszeile -O3
zu -O2
ändern, müssen Sie auch die
-qstrict
-Option entfernen (das ist eine
Beschränkung im IBM-C-Kompiler).
Wenn Sie gcc
oder egcs
benutzen, um MySQL zu kompilieren,
MÜSSEN Sie den
-fno-exceptions
-Flag benutzen, weil das
Exception-Handling in gcc
/
egcs
nicht Thread-sicher ist! (Das wurde
mit egcs
1.1. getestet.) Es gibt auch ein
paar bekannte Probleme mit dem IBM-Assembler, die dazu führen
können, dass schlechter Code erzeugt wird, wenn er zusammen
mit gcc benutzt wird.
Wir empfehlen folgende configure
-Zeile für
egcs
und gcc 2.95
auf
AIX:
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
-Wa,-many
ist notwendig, damit das
Kompilieren gelingt. Das Problem ist IBM bekannt, hat es aber
nicht eilig, es zu beheben, weil ein Workaround verfügbar
ist. Wir wissen nicht, ob -fno-exceptions
für gcc 2.95
erforderlich ist, aber weil
MySQL keine Exceptions benutzt und die obige Option
schnelleren Code erzeugt, empfehlen wir, dass Sie diese Option
für egcs / gcc
immer benutzen.
Wenn Sie ein Problem mit Assembler-Code bekommen, versuchen Sie, -mcpu=xxx so anzupassen, dass es zu Ihrem Prozessor passt. Typischerweise wird man power2, power oder powerpc benutzen, alternativ kann man eventuell 604 oder 604e benutzen. Ich bin nicht ganz sicher, aber ich würde sagen, dass "power" meist sicher sein sollte, selbst auf einer power2-Maschine.
Wenn Sie nicht wissen, welchen Prozessor Sie haben, geben Sie "uname -m" ein. Das gibt eine Zeichenkette zurück, die etwa wie "000514676700" aussieht, mit dem Format xxyyyyyymmss, wobei xx und ss immer die Nullen sind (0). yyyyyy ist eine eindeutige System-ID und mm ist die ID des CPU-Planars. Eine Tabelle dieser Werte liegt auf http://www.rs6000.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds5/uname.htm. Darin finden Sie Maschinentyp und Maschinenmodell, was Sie benutzen können, um herauszufinden, welchen Prozessortyp Sie haben.
Wenn Sie Probleme mit Signalen haben (MySQL stirbt unerwartet unter hoher Last), haben Sie vielleicht einen Betriebssystem-Bug bei Threads und Signalen gefunden. In diesem Fall können Sie MySQL anweisen, keine Signale zu benutzen, indem Sie es wie folgt konfigurieren:
shell>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
Das berührt nicht die Performance von MySQL, hat aber den
Nebeneffekt, dass Sie keine Clients auf einer Verbindung mit
mysqladmin kill
oder mysqladmin
shutdown
killen können, die ``schlafen''. Statt
dessen wird der Client sterben, wenn er den nächsten Befehl
sendet.
Bei einigen Versionen von AIX für das Linken mit
libbind.a
bei
getservbyname
zu einem Speicherauszug (Core
Dump). Das ist ein AIX-Bug, der IBM berichtet werden sollte.
Bei AIX 4.2.1 und gcc müssen Sie folgende Änderungen durchführen:
Nach dem Konfigurieren müssen Sie
config.h
und
include/my_config.h
editieren und die
Zeile ändern, in der steht:
#define HAVE_SNPRINTF 1
zu
#undef HAVE_SNPRINTF
Schließlich müssen Sie in mysqld.cc
einen Prototype für initgoups hinzufügen:
#ifdef _AIX41 extern "C" int initgroups(const char *,int); #endif
Auf SunOS 4 werden MIT-pThreads benötigt, um MySQL zu
kompilieren, was letztlich bedeutet, dass Sie
GNU-make
benötigen.
Einige SunOS-4-Systeme haben Probleme mit dynamischen
Bibliotheken und libtool
. Sie können
folgende configure
-Zeile benutzen, um das
Problem zu vermeiden:
shell> ./configure --disable-shared --with-mysqld-ldflags=-all-static
Wenn Sie readline
kompilieren, erhalten Sie
vielleicht Warnungen über duplizierte Defines. Diese können
ignoriert werden.
Wenn Sie mysqld
kompilieren, gibt es ein
paar implicit declaration of
function
-Warnungen. Diese können ignoriert werden.
Wenn Sie egcs 1.1.2 auf Digital Unix benutzen, sollten Sie auf gcc 2.95.2 aktualisieren, weil egcs auf DEC einige schwer wiegende Bugs hat!
Wenn Sie threaded Programme unter Digital Unix kompilieren,
empfiehlt die Dokumentation, die
-pThread
-Option für cc
und cxx
und die Bibliotheken
-lmach -lexc
zu benutzen (zusätzlich zu
-lpThread
). Sie sollten
configure
wie folgt laufen lassen:
CC="cc -pThread" CXX="cxx -pThread -O" \ ./configure --with-named-thread-libs="-lpThread -lmach -lexc -lc"
Wenn Sie mysqld
kompilieren, sehen Sie
eventuell eine Reihe von Warnungen wie die folgende:
mysqld.cc: In function void handle_connections()': mysqld.cc:626: passing long unsigned int *' as argument 3 of accept(int,sockadddr *, int *)'
Sie können diese Warnungen ignorieren. Sie treten auf, weil
configure
nur Fehler entdecken kann, keine
Warnungen.
Wenn Sie den Server direkt von the Kommandozeile starten,
haben Sie vielleicht Probleme, dass er stirbt, wenn Sie sich
ausloggen. (Wenn Sie sich ausloggen, erhalten Ihre offenen
Prozesse ein SIGHUP
-Signal.) Wenn das der
Fall ist, starten Sie den Server wie folgt:
shell> nohup mysqld [options] &
nohup
bewirkt, dass der folgende Befehl
jegliche SIGHUP
-Signale, die vom Terminal
gesendet werden, ignoriert. Alternativ starten Sie den Server
mit safe_mysqld
, was
mysqld
mit nohup
für
Sie aufruft. See Abschnitt 5.7.2, „safe_mysqld, der Wrapper um mysqld“.
Wenn Sie ein Problem beim Kompilieren von mysys/get_opt.c bekommen, entfernen Sie einfach die Zeile #define _NO_PROTO am Anfang dieser Datei!
Wenn Sie den CC-Kompiler von Compaq benutzen, sollte die folgende Konfigurationszeile funktionieren:
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" 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
Wenn Sie ein Problem mit libtool beim Kompilieren mit
gemeinsam genutzten (shared) Bibliotheken bekommen wie oben,
wenn Sie mysql
linken, sollten Sie dies
folgendermaßen umgehen können:
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 Skripts/mysql_install_db
Wenn Sie Probleme beim Kompilieren haben und DEC
CC
und gcc
installiert
sind, versuchen Sie, configure
wie folgt
laufen zu lassen:
CC=cc CFLAGS=-O CXX=gcc CXXFLAGS=-O3 \ ./configure --prefix=/usr/local/mysql
Wenn Sie Probleme mit der c_asm.h
-Datei
bekommen, können Sie wie folgt eine
'dummy'-c_asm.h
-Datei erzeugen und
benutzen:
touch include/c_asm.h CC=gcc CFLAGS=-I./include \ CXX=gcc CXXFLAGS=-O3 \ ./configure --prefix=/usr/local/mysql
Beachten Sie, dass die im Folgenden beschriebenen Probleme mit
dem ld
-Programm behoben werden können,
indem Sie das neueste DEC-(Compaq)-Patch-Kit herunterladen,
und zwar von folgender Seite:
http://ftp.Support.compaq.com/public/unix/.
Auf OSF1 V4.0D und Kompiler "DEC C V5.6-071 auf Digital Unix
V4.0 (Rev. 878)" zeigt der Kompiler einige seltsame
Verhaltensweisen (undefinierte
asm
-Symbole). Ausserdem scheint
/bin/ld
beschädigt zu sein (Probleme mit
_exit undefined
-Fehlern, die auftreten,
wenn Sie mysqld
linken). Auf diesem System
konnten wir MySQL mit folgender
configure
-Zeile kompilieren, nachdem wir
/bin/ld
mit der Version von OSF 4.0C
ersetzt haben:
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
Beim Digital-Kompiler "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"
In einigen Versionen von OSF1 ist die
alloca()
-Funktion beschädigt. Beheben Sie
dies, indem Sie die Zeile in config.h
entfernen, die 'HAVE_ALLOCA'
definiert.
Die alloca()
-Funktion kann ebenfalls einen
falschen Prototyp in /usr/include/alloca.h
haben. Die Warnung, die hieraus resultiert, kann ignoriert
werden.
configure
benutzt automatisch folgenden
Thread-Bibliotheken:
--with-named-thread-libs="-lpThread -lmach -lexc
-lc"
.
Wenn Sie gcc
benutzen, können Sie auch
versuchen, configure
wie folgt laufen zu
lassen:
shell> CFLAGS=-D_PTHREAD_USE_D4 CXX=gcc CXXFLAGS=-O3 ./configure ....
Wenn Sie Probleme mit Signalen haben (MySQL stirbt unerwartet unter Hochlast), haben Sie vielleicht einen Betriebssystem-Bug bei Threads und Signalen gefunden. In diesem Fall können Sie MySQL anweisen, keine Signale zu benutzen, indem Sie es wie folgt konfigurieren:
shell>CFLAGS=-DDONT_USE_THR_ALARM \
CXXFLAGS=-DDONT_USE_THR_ALARM \
./configure ...
Das berührt nicht die Performance von MySQL, hat aber den
Nebeneffekt, dass Sie keine Clients auf einer Verbindung mit
mysqladmin kill
oder mysqladmin
shutdown
killen können, die ``schlafen''. Statt
dessen wird der Client sterben, wenn er den nächsten Befehl
sendet.
Bei gcc
2.95.2 erhalten Sie wahrscheinlich
folgenden Kompilierfehler:
sql_acl.cc:1456: Internal compiler error in `scan_region', at except.c:2566 Please submit a full bug report.
Um das zu beheben, wechseln Sie ins
sql
-Verzeichnis und machen ein ``Kopieren
und Einfügen'' der letzten gcc
-Zeile,
ändern aber -O3
zu -O0
(oder fügen -O0
unmittelbar nach
gcc
hinzu, falls Sie keine
-O
-Option auf Ihrer Kompilierzeile haben.)
Danach wechseln Sie einfach direkt zurück in oberste
Verzeichnis und lassen make
noch einmal
laufen.
Wenn Sie Irix-Version 6.5.3 oder neuer benutzen, kann
mysqld
nur dann Threads erzeugen, wenn Sie
ihn als Benutzer mit
CAP_SCHED_MGT
-Zugriffsrechten (wie
root
) laufen lassen oder dem
mysqld
-Server dieses Recht mit dem
folgenden Befehl geben:
shell> chcap "CAP_SCHED_MGT+epi" /opt/mysql/libexec/mysqld
Sie müssen eventuell in config.h
einige
Dinge umdefinieren, nachdem Sie configure
laufen gelassen haben und vor dem Kompilieren.
In einigen Irix-Implementationen ist die
alloca()
-Funktion beschädigt. Wenn der
mysqld
-Server bei manchen
SELECT
-Statements stirbt, entfernen Sie die
Zeilen aus config.h
, die
HAVE_ALLOC
und
HAVE_ALLOCA_H
definieren. Wenn
mysqladmin create
nicht funktioniert,
entfernen Sie die Zeile aus config.h
, die
HAVE_READDIR_R
definiert. Eventuell müssen
Sie auch die HAVE_TERM_H
-Zeile entfernen.
SGI empfiehlt, dass Sie alle Patches auf dieser Seite auf einmal installieren: http://Support.sgi.com/surfzone/patches/patchset/6.2_indigo.rps.html
Als absolutes Minimum sollten Sie das letzte Kernel-Rollup
installieren, das letzte rld
-Rollup und das
letzte libc
-Rollup.
In jedem Fall brauchen Sie für die pThread-Unterstützung alle POSIX-Patches auf dieser Seite:
http://Support.sgi.com/surfzone/patches/patchset/6.2_posix.rps.html
Wenn Sie beim Kompilieren von mysql.cc
etwa folgenden Fehler erhalten:
"/usr/include/curses.h", line 82: error(1084): invalid combination of type
Geben Sie folgendes im obersten Verzeichnis Ihres MySQL-Source-Trees ein:
shell>extra/replace bool curses_bool < /usr/include/curses.h > include/curses.h
shell>make
Es wurden ausserdem Scheduling-Probleme berichtet. Wenn nur ein Thread läuft, läuft alles recht langsam. Das können Sie vermeiden, indem Sie einen weiteren Client-Starten. Daraus kann sich eine zwei- bis zehnfache Geschwindigkeitssteigerung für den anderen Thread ergeben. Das liegt an einem Problem mit Irix-Threads, das kaum zu verstehen ist. Eventuell müssen Sie improvisieren, um eine Lösung zu finden, bis dies behoben ist.
Wenn Sie mit gcc
kompilieren, können Sie
folgenden configure
-Befehl benutzen:
CC=gcc CXX=gcc CXXFLAGS=-O3 \ ./configure --prefix=/usr/local/mysql --enable-thread-safe-client --with-named-thread-libs=-lpThread
Auf Irix 6.5.11 mit nativen Irix-C- und C++-Kompilern der Version 7.3.1.2 soll auch folgendes funktionieren:
CC=cc CXX=CC CFLAGS='-O3 -n32 -TARG:platform=IP22 -I/usr/local/include \ -L/usr/local/lib' CXXFLAGS='-O3 -n32 -TARG:platform=IP22 \ -I/usr/local/include -L/usr/local/lib' ./configure --prefix=/usr/local/mysql \ --with-berkeley-db --with-innodb \ --with-libwrap=/usr/local --with-named-curses-libs=/usr/local/lib/libncurses.a
Die aktuelle Portierung wird auf ``sco3.2v5.0.4''- und-``sco3.2v5.0.5''-Systemen getestet. Die Portierung auf ``sco 3.2v4.2'' ist ebenfalls weit fortgeschritten.
Momentan ist der empfohlene Kompiler auf OpenServer gcc 2.95.2. Damit sollten Sie in der Lage sein, MySQL einfach durch folgendes zu kompilieren:
CC=gcc CXX=gcc ./configure ... (options)
Bei OpenServer 5.0.X müssen Sie GDS in Skunkware 95
(95q4c) benutzen. Das ist deshalb notwendig, weil
GNU-gcc
2.7.2 in Skunkware 97 kein
GNU-as
hat. Sie können auch
egcs
1.1.2 oder neuer benutzen
http://www.egcs.com/.
Wenn Sie egcs
1.1.2 benutzen, müssen
Sie folgenden Befehl eingeben:
shell> cp -p /usr/include/pThread/stdtypes.h /usr/local/lib/gcc-lib/i386-pc-sco3.2v5.0.5/egcs-2.91.66/include/pThread/
Sie brauchen die Portierung von GCC 2.5.x für dieses Produkt und das Entwicklungssystem. Sie werden auf dieser Version von Caldera (SCO) Unix benötigt. Sie können nicht lediglich das GCC-Dev-System benutzen.
Sie sollten zuerst das FSU-PThreads-Paket holen und installieren. Dieses finden Sie auf http://www.cs.wustl.edu/~schmidt/ACE_wrappers/FSU-threads.tar.gz. Sie finden ein vorkompiliertes Paket auf http://www.mysql.com/Downloads/SCO/FSU-threads-3.5c.tar.gz.
FSU-PThreads kann mit SCO Unix 4.2 mit TCP/IP kompiliert werden. Oder mit OpenServer 3.0 oder Open Desktop 3.0 (OS 3.0 ODT 3.0), mit installiertem Caldera (SCO) Entwicklungssystem unter Benutzung einer guten Portierung von GCC 2.5.x ODT oder OS 3.0. Hierbei brauchen Sie eine gute Portierung von GCC 2.5.x. Ohne gute Portierung gibt es eine Menge Probleme. Die Portierung für dieses Produkt erfordert das Caldera (SCO) Unix-Entwicklungssystem. Ohne dieses fehlen die Bibliotheken und der Linker, die benötigt werden.
Um FSU-PThreads auf Ihrem System zu bauen, tun Sie folgendes:
Lassen Sie ./configure
im
Threads/src
-Verzeichnis laufen
und wählen Sie die SCO-OpenServer-Option. Dieser
Befehl kopiert Makefile.SCO5
nach
Makefile
.
Lassen Sie make
laufen.
Um in das vorgabemäßige
/usr/include
-Verzeichnis zu
installieren, loggen Sie sich als Root ein und
wechseln (cd
) Sie in das
thread/src
-Verzeichnis. Führen
Sie dann make install
aus.
Denken Sie daran, GNU make
zu benutzen,
wenn Sie MySQL machen.
Wenn Sie safe_mysqld
nicht als Root
starten, erhalten Sie wahrscheinlich nur die 110 offenen
Dateien pro Prozess. mysqld
macht
darüber in der Log-Datei einen Eintrag.
Bei SCO 3.2V5.0.5 sollten Sie FSU-PThreads-Version 3.5c oder neuer benutzen. Ausserdem sollten Sie gcc 2.95.2 oder neuer benutzen!
Folgender configure
-Befehl sollte
funktionieren:
shell> ./configure --prefix=/usr/local/mysql --disable-shared
Bei SCO 3.2V4.2 sollten Sie FSU-PThreads-Version 3.5c oder
neuer benutzen. Folgender
configure
-Befehl sollte funktionieren:
shell>CFLAGS="-D_XOPEN_XPG4" CXX=gcc CXXFLAGS="-D_XOPEN_XPG4" \
./configure \
--prefix=/usr/local/mysql \
--with-named-thread-libs="-lgThreads -lsocket -lgen -lgThreads" \
--with-named-curses-libs="-lcurses"
Möglicherweise bekommen Sie Probleme mit einigen
Include-Dateien. In diesem Fall finden Sie neue,
SCO-spezifische Include-Dateien auf
http://www.mysql.com/Downloads/SCO/SCO-3.2v4.2-includes.tar.gz.
Entpacken Sie diese Datei ins
include
-Verzeichnis Ihres
MySQL-Source-Trees.
Anmerkungen zur Caldera (SCO) Entwicklung:
MySQL kann FSU-PThreads automatisch erkennen und
mysqld
mit -lgThreads -lsocket
-lgThreads
linken.
Die Caldera (SCO) Entwicklungsbibliotheken sind re-entrant in FSU-PThreads. Caldera behauptet, dass seine Bibliotheken-Funktionen re-entrant sind, daher müssen sie mit FSU-PThreads re-entrant sein. FSU-PThreads auf OpenServer versucht, das SCO-Scheme zu benutzen, um Bibliotheken re-entrant zu machen.
FSU-PThreads (zumindest die Version auf
http://www.mysql.com/)
wird mit gelinktem GNU-malloc
ausgeliefert. Wenn Sie Problemen mit der Speicherbenutzung
begegnen, stellen Sie sicher, dass
gmalloc.o
in
libgThreads.a
und
libgThreads.so
beinhaltet ist.
In FSU-PThreads achten folgende Systemaufrufe auf
pThreads: read()
,
write()
, getmsg()
,
connect()
, accept()
,
select()
und wait()
.
Wenn Sie DBI auf Caldera (SCO) installieren wollen, müssen
Sie Makefile
in DBI-xxx und jedem
Unterverzeichnis editieren.
Beachten Sie, dass folgendes gcc 2.95.2 oder neuer voraussetzt:
ALT: NEU: CC = cc CC = gcc CCCDLFLAGS = -KPIC -W1,-Bexport CCCDLFLAGS = -fpic CCDLFLAGS = -wl,-Bexport CCDLFLAGS = LD = ld LD = gcc -G -fpic LDDLFLAGS = -G -L/usr/local/lib LDDLFLAGS = -L/usr/local/lib LDFLAGS = -belf -L/usr/local/lib LDFLAGS = -L/usr/local/lib LD = ld LD = gcc -G -fpic OPTIMISE = -Od OPTIMISE = -O1 OLD: CCCFLAGS = -belf -dy -w0 -U M_XENIX -DPERL_SCO5 -I/usr/local/include NEW: CCFLAGS = -U M_XENIX -DPERL_SCO5 -I/usr/local/include
Das liegt daran, dass der Perl-dynaloader keine
DBI
-Module lädt, die mit
icc
oder cc
kompiliert
wurden.
Perl funktioniert am besten, wenn es mit cc
kompiliert wird.
Sie benötigen mindestens MySQL-Version 3.22.13, weil diese Version einige Portabilitätsprobleme unter Unixware behebt.
Wir waren in der Lage, MySQL mit folgendem
configure
-Befehl auf Unixware Version 7.0.1
zu kompilieren:
CC=cc CXX=CC ./configure --prefix=/usr/local/mysql
Wenn Sie gcc
benutzen wollen, müssen Sie
gcc
2.95.2 oder neuer benutzen.
MySQL benutzt eine ganze Menge offener Dateien. Deswegen sollten
Sie Ihrer CONFIG.SYS
-Datei folgendes
hinzufügen:
SET EMXOPT=-c -n -h1024
Wenn Sie das nicht tun, erhalten Sie wahrscheinlich folgenden Fehler:
File 'xxxx' not found (Errcode: 24)
Wenn Sie MySQL auf OS/2 Warp 3 einsetzen, wird FixPack 29 oder höher benötigt. Bei OS/2 Warp 4 wird FixPack 4 oder höher benötigt. Das erfordert die PThreads-Bibliothek. MySQL muss auf einer Partition installiert werden, die lange Dateinamen unterstützt, also zum Beispiel HPFS, FAT32 usw.
Das INSTALL.CMD
-Skript muss von OS/2's
eigener CMD.EXE
aus laufen gelassen werden
und funktioniert eventuell nicht mit Ersatz-Shells wie
4OS2.EXE
.
Das scripts/mysql-install-db
-Skript wurde
umbenannt. Es heißt jetzt install.cmd
und
ist ein REXX-Skript, welches die vorgabemäßigen
MySQL-Sicherheitseinstellungen einstellt und die
WorkPlace-Shell-Icons für MySQL erstellt.
Unterstützung für dynamische Module wird einkompiliert, ist aber noch nicht komplett durchgetestet. Dynamische Module sollten unter Benutzung der PThreads-Runtime-Bibliothek kompiliert werden.
gcc -Zdll -Zmt -Zcrtdll=pthrdrtl -I../include -I../regex -I.. \ -o example udf_example.cc -L../lib -lmysqlclient udf_example.def mv example.dll example.udf
Beachten Sie: Aufgrund von
Beschränkungen in OS/2 dürfen UDF-module-name-stems nicht
länger als 8 Zeichen sein. Module werden im
/mysql2/udf
-Verzeichnis gespeichert; das
safe-mysqld.cmd
-Skript trägt dieses
Verzeichnis in die
BEGINLIBPATH
-Umgebungsvariable ein. Wenn Sie
UDF-Module benutzen, werden festgelegte Erweiterungen ignoriert
- es wird nicht angenommen, dass sie .udf
sind. Unter Unix zum Beispiel könnte das gemeinsam genutzte
(shared) Module example.so
benannt sein.
Sie würden daraus eine Funktion wie folgt laden:
mysql> CREATE FUNCTION metaphon RETURNS STRING SONAME "example.so";
Unter OS/2 würde das Modul example.udf
heißen, aber Sie würden nicht die Modul-Erweiterung angeben:
mysql> CREATE FUNCTION metaphon RETURNS STRING SONAME "example";
Wir sind sehr daran interessiert, MySQL auf BeOS ans Laufen zu bringen, aber leider kennen wir niemanden, der sich mit BeOS auskennt oder Zeit hat, eine Portierung durchzuführen.
Wir sind daran interessiert, jemanden für eine Portierung zu finden, und wir werden ihn / sie bei allen technischen Fragen helfen, die bei einer Portierung auftreten können.
Wir haben vor einiger Zeit mit einigen BeOS-Entwicklern gesprochen, die uns sagten, dass MySQL zu 80% auf BeOS portiert ist, aber wir haben schon eine Weile nichts von ihnen gehört.
Wir sind sehr daran interessiert, MySQL auf NetWare ans Laufen zu bringen, aber leider kennen wir niemanden, der sich mit NetWare auskennt oder Zeit hat, eine Portierung durchzuführen.
Wir sind daran interessiert, jemanden für eine Portierung zu finden, und wir werden ihn / sie bei allen technischen Fragen helfen, die bei einer Portierung auftreten können.
DBI
/DBD
-Schnittstelle
Perl-Unterstützung für MySQL wird durch die
DBI
/DBD
-
Client-Schnittstelle zur Verfügung gestellt. See
Abschnitt 9.2, „MySQL-Perl-API“. Der Perl-
DBD
/DBI
-Client-Code
erfordert Perl Version 5.004 oder später. Die Schnittstelle
funktioniert nicht, wenn Sie
eine ältere Version von Perl haben.
MySQL-Perl-Unterstützung erfordert ausserdem, dass Sie MySQL-Client- Programmierunterstützung installiert haben. Wenn Sie MySQL von RPM- Dateien installiert haben, sind Client-Programme im Client-RPM enthalten, aber Client-Programmierunterstützung ist im Entwickler-RPM. Stellen Sie sicher, dass Sie auch das letztgenannte RPM installiert haben.
Ab Version 3.22.8 wird Perl-Unterstützung getrennt von der Haupt-MySQL- Unterstützung ausgeliefert. Wenn Sie Perl-Unterstützung installieren wollen, können Sie die benötigten Dateien von http://www.mysql.com/downloads/api-dbi.html herunter laden.
Die Perl-Distributionen werden als komprimierte
tar
-Archive zur Verfügung gestellt und haben
Namen wie MODULE-VERSION.tar.gz
, wobei
MODULE
der Modulname und
VERSION
die Versionsnummer ist. Sie sollten
die Data-Dumper
-, DBI
- und
Msql- Mysql-modules
-Distributionen laden und
sie in dieser Reihenfolge installieren. Die
Installationsprozedur ist unten dargestellt. Das Beispiel gilt
für das Data-Dumper
-Modul, ist aber für
alle drei Distributionen dieselbe:
Entpacken Sie die Distribution ins aktuelle Verzeichnis.
shell> gunzip < Data-Dumper-VERSION.tar.gz | tar xvf -
Dieser Befehl erzeugt ein Verzeichnis namens
Data-Dumper- VERSION
.
Wechseln Sie ins oberste Verzeichnis der entpackten Distribution:
shell> cd Data-Dumper-VERSION
Bauen Sie die Distribution und kompilieren Sie alles:
shell>perl Makefile.PL
shell>make
shell>make test
shell>make install
Der make test
-Befehl ist wichtig, weil er
sicherstellt, dass die Module funktionieren. Beachten Sie, dass
der MySQL-Server während der Befehlsausführung bei der
Msql-Mysql-modules
-Installation laufen muss,
um den Schnittstellen-Code auszuführen, den ansonsten schlägt
der Test fehl.
Es ist eine gute Idee, die
Msql-Mysql-modules
-Distribution neu zu
kompilieren und zu installieren, wenn Sie ein neues Release von
MySQL installieren, insbesondere, wenn Sie Symptome feststellen
wie dass alle Ihre DBI
-Skripte einen Coredump
liefern, nachdem Sie auf eine höhere Version von MySQL
aktualisiert haben.
Wenn Sie keine Rechte haben, die Perl-Module im Systemverzeichnis zu installieren, oder wenn Sie lokale Perl-Module installieren wollen, könnte Ihnen der folgende Link helfen:
http://www.iserver.com/support/contrib/perl5/modules.html
Suchen Sie nach der Überschrift Installing New Modules
that Require Locally Installed Modules
.
Um das MySQL-DBD
-Modul mit ActiveState-Perl
unter Windows zu installieren, gehen Sie wie folgt vor:
Laden Sie ActiveState-Perl von http://www.activestate.com/Products/ActivePerl/ und installieren Sie es.
Öffnen Sie eine MS-DOS-Eingabeaufforderung.
Setzen Sie - falls erforderlich - die HTTP_proxy-Variable, zum Beispiel wie folgt:
set HTTP_proxy=my.proxy.com:3128
Starten Sie das PPM-Programm:
C:\> c:\perl\bin\ppm.pl
Falls noch nicht geschehen, installieren Sie
DBI
:
ppm> install DBI
Wenn das erfolgreich verlief, führen Sie folgenden Befehl aus:
install ftp://ftp.de.uu.net/pub/CPAN/authors/id/JWIED/DBD-mysql-1.2212.x86.ppd
Das sollte zumindest bei ActiveState-Perl Version 5.6 funktionieren.
Wenn Sie es nicht schaffen, dass oben Genanntes funktioniert, sollten Sie statt dessen den MyODBC-Treiber installieren und sich mit dem MySQL-Server über ODBC verbinden:
use DBI; $dbh= DBI->connect("DBI:ODBC:$dsn","$user","$password") || die "Fehler $DBI::errstr beim Verbinden mit $dsn\n";
Die MySQL-Perl-Distribution enthält DBI
,
DBD:MySQL
und DBD:ODBC
.
Laden Sie die Perl-Distribution für Windows von http://www.mysql.com/download.html.
Entpacken Sie die Distribution in C:
, so
dass Sie ein C:\PERL
-Verzeichnis
erhalten.
Fügen Sie Ihrem Pfad C:\PERL\BIN
hinzu.
Fügen Sie Ihrem Pfad das Verzeichnis
C:\PERL\BIN\MSWIN32-x86- thread
oder
C:\PERL\BIN\MSWIN32-x86
hinzu.
Testen Sie, ob perl
funktioniert, indem
Sie perl -v
in einer
MS-DOS-Eingabeaufforderung ausführen.
Wenn Perl ausgibt, dass es das
../mysql/mysql.so
-Modul nicht finden kann,
liegt das Problem wahrscheinlich darin, dass Perl die gemeinsam
genutzte libmysqlclient.so
nicht findet.
Das können Sie mit einer der folgenden Methoden beheben:
Kompilieren Sie die
Msql-Mysql-modules
-Distribution mit
perl Makefile.PL -static -config
statt
mit perl Makefile.PL
.
Kopieren Sie libmysqlclient.so
in das
Verzeichnis, in dem Ihre anderen gemeinsam genutzten
Bibliotheken liegen (wahrscheinlich
/usr/lib
oder
/lib
).
Unter Linux können Sie der
/etc/ld.so.conf
-Datei den Pfadnamen des
Verzeichnisses hinzufügen, in dem
libmysqlclient.so
liegt.
Fügen Sie der
LD_RUN_PATH
-Umgebungsvariablen den
Pfadnamen des Verzeichnisses hinzu, in dem
libmysqlclient.so
liegt.
Wenn Sie folgende Fehler von DBD-mysql
erhalten, benutzen Sie wahrscheinlich gcc
(oder eine alte Binärdatei, die mit gcc
kompiliert wurde):
/usr/bin/perl: can't resolve symbol '__moddi3' /usr/bin/perl: can't resolve symbol '__divdi3'
Fügen Sie -L/usr/lib/gcc-lib/... -lgcc
zum
Link-Befehl hinzu, wenn die
mysql.so
-Bibliothek gebaut wird
(überprüfen Sie die Ausgabe von make
nach
mysql.so
, wenn Sie den Perl-Client
kompilieren). Die -L
-Option sollte den
Pfadnamen des Verzeichnisses angeben, in dem
libgcc.a
auf Ihrem System liegt.
Ein weiterer Grund für dieses Problem kann sein, dass Perl und
MySQL nicht beide mit gcc
kompiliert wurden.
In diesem Fall können Sie die fehlende Übereinstimmung
(Mismatch) durch Kompilieren von beiden mit
gcc
aufheben.
Wenn Sie folgende Fehler von
Msql-Mysql-modules
erhalten, wenn Sie die
Tests laufen lassen:
t/00base............install_driver(mysql) failed: Can't load '../blib/arch/auto/DBD/mysql/mysql.so' for module DBD::mysql: ../blib/arch/auto/DBD/mysql/mysql.so: undefined symbol: uncompress at /usr/lib/perl5/5.00503/i586-linux/DynaLoader.pm line 169.
Bedeutet das, dass Sie die Kompressionsbibliothek (-lz) in die
Link- Zeile einschließen müssen. Das kann man durch folgende
Änderung in der Datei
lib/DBD/mysql/Install.pm
tun:
$sysliblist .= " -lm"; ändern in $sysliblist .= " -lm -lz";
Danach müssen Sie 'make realclean' laufen lassen und danach mit der Installation von Anfang an beginnen.
Wenn Sie das Perl-Modul auf einem System laufen lassen wollen,
das dynamisches Linken nicht unterstützt (wie Caldera/SCO),
können Sie eine statische Version von Perl erzeugen, die
DBI
und DBD-mysql
enthält. Das bringt man zum Laufen, indem man eine Version von
Perl erzeugt, in der der DBI
-Code eingelinkt
ist, und diese über das aktuelle Perls installiert. Dann
benutzen Sie diese, um eine Version von Perl zu bauen, die
zusätzlich den DBD
-Code eingelinkt hat, und
installieren diese.
Unter Caldera (SCO) müssen folgende Umgebungsvariablen gesetzt sein:
shell>LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/progressive/lib
or shell>LD_LIBRARY_PATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:/usr/progressive/lib:/usr/skunk/lib shell>
LIBPATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:/usr/progressive/lib:/usr/skunk/lib shell>
MANPATH=scohelp:/usr/man:/usr/local1/man:/usr/local/man:/usr/skunk/man:
Erzeugen Sie zuerst ein Perl, das ein statisch gelinktes
DBI
enthält, indem Sie diese Befehle im
Verzeichnis ausführen, in dem Ihre
DBI
-Distribution liegt:
shell>perl Makefile.PL -static -config
shell>make
shell>make install
shell>make perl
Dann müssen Sie das neue Perl installieren. Die Ausgabe von
make perl
zeigt den genauen
make
-Befehl an, den Sie für die Installation
ausführen müssen. Unter Caldera (SCO) ist das make -f
Makefile.aperl inst_perl MAP_TARGET=perl
.
Benutzen Sie als nächstes dieses soeben erzeugte Perl, um ein
weiteres Perl zu erzeugen, dass auch ein statisch gelinktes
DBD::mysql
enthält, indem Sie diese Befehle
im Verzeichnis ausführen, in dem Ihre
Msql-Mysql-modules
-Distribution liegt:
shell>perl Makefile.PL -static -config
shell>make
shell>make install
shell>make perl
Zum Schluss müssen Sie dieses neue Perl installieren. Hierbei
zeigt die Ausgabe von make perl
wiederum,
welcher Befehl benutzt werden muss.
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.