You can always check MySQL's home page to read the latest news.
But since the Internet connection at TcX is not very fast we would prefer if you do the actual downloading from one of the mirrors below.
Europe:
North America:
Asia:
Australia:
The first decision is if you want to use the latest development release or the last stable release.
Normally if you are starting with development we recommend going with the development release. This is because there are usually no really bad bugs in the development release and you can easily test it on your machine with the crash-me and benchmark tests. See section MySQL benchmark suite.
The second decision is if you want a source or a binary release.
If you want to run MySQL on a platform that has a current binary release, use that. A binary version of MySQL is easier to install.
If you want to read (and/or modify) the C and C++ code that makes up MySQL you should always get a source distribution. The code is always the ultimate manual. The source distribution also contains more tests and examples than the binary distribution.
To clarify our naming schema:
All MySQL versions are run through our standard tests and benchmarks to ensure that they are relatively safe to use. The standard tests are also extended the whole time to test for all previously found bugs, so it's gets better the whole time.
The MySQL release numbers consist of 3 numbers and a suffix.
So a release name like mysql-3.21.17-beta means.
Note that all releases have at least been tested with:
Another test is our internal production. We usually use the latest version for this (at least on one machine) and we have more than 100 gigabytes of data to work with.
We use the following policy when updating MySQL:
Each minor version will increment the last number in the version string. When there are major new features or minor incompatibilities with previous versions, the second number in the version string will be incremented. When the file format changes the first number will be increased.
We use GNU autoconf so it is possible to port MySQL to all modern systems with working Posix threads and a C++ compiler. The client code requires C++ but not threads. We use/develop the software ourselves primarily on Sun Solaris (versions 2.5 & 2.6) and some on RedHat Linux 5.0.
The following OS/thread packages have been reported to compile MySQL successfully. Note that for many OSes the native thread support only works in the latest versions.
What you need:
gzip to uncompress the distribution.
tar to unpack the distribution. GNU tar is
known to work.
C++ compiler. gcc >= 2.7, SGI C++, SunPro C++ are
some of the compilers that are known to work. libg++ is not
needed when using gcc.
make program. If you have problems we recommend trying GNU
make.
Unpack tar archive in a directory. The tar file should be named like mysql-VERSION.tar.gz (VERSION is a number like ). A directory named mysql-VERSION should be created.
zcat mysql-VERSION.tar.gz | tar xvf -
cd mysql-VERSION
./configure
make
make install
./scripts/mysql_install_db
'installation_directory'/bin/mysqladmin version
mysqladmin Ver 6.3 Distrib 3.21.17, for pc-linux-gnu on i686 TCX Datakonsult AB, by Monty Server version 3.21.17-alpha Protocol version 10 Connection Localhost via UNIX socket TCP port 3306 UNIX socket /tmp/mysql.sock Uptime: 16 sec Running threads: 1 Questions: 20 Reloads: 2 Open tables: 3
Usual configure switches:
--without-server
--prefix=/usr/local or --prefix=/usr/local
--localstatedir=/usr/local/data/mysql
--with-unix-socket-path=absolute_file_name
--with-charset=charset.
Where [charset] may be one of: big5, czech, dec8,
dos, german1, hp8, koi8_ru, latin1,
latin2, swe7 or usa7.
If you want to add another character set to MySQL you must:
mysql_source_directory/strings/ctype-$CHARSET_NAME.c.
CHARSETS_AVAILABLE list in
configure.in
SET OPTION CHARACTER SET.
See section SET OPTION syntax.
Warning: If you change character sets after having created a
table you will have to run isamchk -r -q on every
table. Otherwise things will be sorted incorecctly in some cases (but
not all!).
GNU make is always recommended and is sometimes required.
About creating the grants database `mysql_install_db':
The default priviliges is that anybody may create/use the databases
named test or starting with test_. root can do
anyting. See section How does the privilege system work?.
To change the defaults edit the script before running it. If this is
the first time you install MySQL you must run this command. If
you don't do it you will get the error: Can't find file:
'./mysql/host.frm'. This script also starts the mysqld daemon the first
time.
If you want to change things in the grant tables after installing you
should use mysql -u root mysql to connect to the grant tables
as the 'root' user.
Normal start of the MySQL server daemon (not needed the first
time): 'installation_directory'/bin/safe_mysqld --log
Some times patches appear on the mailing list. To apply them, do something like this:
cd 'old-mysql-source-distribution-path' gunzip < patch-file-name.gz | patch -p1 rm config.cache make clean
And then follow the instructions for a normal source install from the
./configure step.
And then restart your MySQL server.
If your compile fails with something like:
configure: error: installation or configuration problem: C++ compiler cannot create executables.
Try setting the environment variable CXX to "gcc -O3" (If
you are using gcc). For example CXX="gcc -O3"
./configure. If you use this you don't nead to have libg++ installed!
You can also install libg++. By default `configure' picks
c++ as a compiler name and GNU c++ links with
-lg++.
making all in mit-pthreads make: Fatal error in reader: Makefile, line 18: Badly formed macro assignmentThis means you have to upgrade your make to GNU
make.
CC="gcc -O4" CXX="gcc -O4" export CC CXX
make stops with Can't find Makefile.PL when making
mysqlperl you should try using GNU make. Solaris and FreeBSD
are known to have troublesome make programs.
pthread.h: No such file or directory
This means you have to upgrade your make to GNU make
(GNU make version 3.75 is known to work).
client/libmysql.c:273: parse
error before `__attribute__'
This means you need to upgrade your gcc compiler (2.7.2 is known to work).
mysqlbug
when posting questions to mysql@tcx.se. See section I think I have found a bug. What information do you need to help me?.
Even if the problem isn't a bug, mysqlbug gathers some system
information that will help others solve your problem!
configure --with-debug=yes
Before running a client you should do:
MYSQL_DEBUG=d:t:o,/tmp/client.trace export MYSQL_DEBUGYou will now get a trace file in `/tmp/client.trace'.
mysql --debug=d:t:o,/tmp/client.trace before mailing a bug
report. See section I think I have found a bug. What information do you need to help me?.
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);
Then configure didn't detect the type of the last argument to
accept(), getsockname() and getpeername(). Search
after the line:
/* Define as the base type of the last arg to accept */ #define SOCKET_SIZE_TYPE ###and change ### to size_t or int depending on your operating system.
All MySQL programs compile clean (no warnings) for us (on Solaris using gcc). But warning may appear because of different system include files. Se below for warnings that may occur when using mit-pthreads.
When compiling sql_yacc.yy you should probably get:
conflicts: 4 reduce/reduce
You probably have to use bison to compile sql_yacc.yy. If you get an error like:
"sql_yacc.yy", line xxx fatal: default action causes potential...
you have to install bison (the GNU yacc).
If you want to have static linked code, use (with gcc):
LDFLAGS="-static" ./configure ...
Building in a non source directory is not supported when using MIT-threads. This is because we want to keep our changes to this code minimal.
MIT-pthreads doesn't support the AF_UNIX protocol so we must use
the TCP/IP protocol for all connections (which is a little slower). If
you can't connect to a table, try using the host (-h or
--host) switch to mysql. This must be done if you have
compiled the client code --without-server because the default
connection is to use Unix sockets.
MySQL compiled with MIT threads has system locking disabled by
default for performance reasons. One can start the server with system
locking with the --use-locking switch.
Sometimes (at least on Solaris) the pthread bind() command fails
to bind to a socket without any error message. The result of this is
that all connections to server fails.
> mysqladmin ver mysqladmin: connect to server at " failed;
error: 'Can't connect to mysql server on localhost (146)'
The solution to this is to kill the mysqld daemon and restart it.
This has only happened to us when we have forced the daemon down and done
a restart immediately.
sleep() isn't interruptible with SIGINT (break) with
MIT-threads. This is only notable in mysqladmin --sleep. One must
wait for the end of the sleep() before the interrupt is served
and the process stops.
We haven't got readline to work with MIT threads. (This isn't needed, but may be interesting for someone)
When linking (at least on Solaris) you will receive warning messages like:
ld: warning: symbol `_iob' has 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' has 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
Some other warnings which also can be ignored:
implicit declaration of function `int strtoll(...)' implicit declaration of function `int strtoul(...)'
The included perl client code requires perl5.004 or later.
If you got a the following error (from mysqlperl or DBD-mysql):
/usr/bin/perl: can't resolve symbol '__moddi3' /usr/bin/perl: can't resolve symbol '__divdi3'
You are probably using gcc (or using an old binary compiled with
gcc). Add -L/usr/lib/gcc-lib/... -lgcc to the link command where
-L/... is the path to the directory where libgcc.a
exists.
Sun native threads only work on Solaris 2.5 and higher. For 2.4 and earlier versions, you can use MIT-pthreads. See section MIT-pthreads notes. (FreeBSD).
If there are too many processes that try to connect very rapidly to the
mysqld one will get Error in accept : Protocol error in
the mysql log.
If you have the Sun Workshop 4.2 compiler you can configure with:
CC="cc -Xa -fast -xstrconst" CXX="CC -xsb -noex -fast"
./configure
You may also have to change the row in configure:
#if !defined(__STDC__) || __STDC__ != 1 to #if
!defined(__STDC__) because if you turn on __STDC__ with the
-Xc switch, the Sun compiler can't compile with the Solaris
`pthread.h' header files anymore. This is a Sun bug (Broken
compiler or broken include file).
The tar in Solaris can't handle long file names; You may get the following error (or something similar) when unpacking the MySQL distribution:
x mysql-3.21.21a-beta-sun-solaris2.6-sparc/perl/Mysql-modules/blib/lib/auto/Msql-Mysql-modules, 0 bytes, 0 tape blocks tar: directory checksum error
You have to use gnu tar to unpack the distribution. You can find copy of precompiled gnu tar (gtar) for Solaris at http://www.mysql.com/Downloads/
On SunOS 4, MIT-pthreads is needed. You must have GNU make to compile
(because of MIT-pthreads).
In readline you may get warnings about duplicate defines. These may be ignored.
When compiling mysqld there will be some warnings about implicit
declaration of function. These may be ignored.
On Linux you should use the --skip-locking flag to mysqld
(it is added automatically by safe_mysqld). This is because a bug
in Linux file locking calls. This bug is known to exist as recently as
Linux version 2.0.32.
When using LinuxThreads you will see a minimum of three processes running. These are in fact threads. There will be one thread for the Linux Threads manager, one thread to handle connections, and one thread to handle alarms and signals.
if you are using RedHat you might get errors like:
/usr/bin/perl is needed... /usr/sh is needed... /usr/sh is needed...
If so upgrade rpm itself to rpm-2.4.11-1.i386.rpm & rpm-devel-2.4.11-1.i386.rpm (or later versions).
You can get the 4.2 updates from ftp://ftp.redhat.com/updates/4.2/i386. Or http://www.sunsite.unc.edu/pub/Linux/distributions/redhat/code/rpm/ for other distributions.
LinuxThreads should be installed before configuring MySQL!
MySQL requires libc version 5.4.12 or newer. glibc version 2.0.6 and later should also work.
On some older Linux distributions configure may give a error
about: Syntax error in sched.h. Change _P to __P in the
/usr/include/sched.h file.\
See the Installation chapter in the Reference Manual. Just do what the
error says and add a extra underscore to the _P macro that only
has one underscore. Then try again.
You will get some warnings when compiling: (these can be ignored)
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'
When using glibc 2 you must also execute the configure with
CXX=gcc ./configure ... because if you compile with g++, you
will link with libg++ which dosen't work with LinuxThreads.
If you want in Debian GNU/Linux to get MySQL to auto start when system boots, do the following:
> cp scripts/mysql.server /etc/init.d/mysql.server > /usr/sbin/update-rc.d mysql.server defaults 99
If mysqld always core dumps when starting, the problem may be that you have an old `/lib/libc.a'. Try renaming this, remove sql/mysqld and do a new make install and try again. This problem has been reported on some Slackware installations.
If you install all the official redhat patches (including glibc-2.0.6-8 and glibc-devel-2.0.6-8) it should work out of the box (se above for how to configure).
The updates are needed since there is a bug in glibc 2.0.5 in how pthread_key_create variables are freed. With glibc 2.0.5 you must use the static-linked MySQL binary distribution. If you want to compile from source you must install the corrected version of linuxthreads from
In some implementations readdir_r is broken. This will be
noticed when SHOW DATABASES always returns an empty set. This
can be fixed by removing HAVE_READDIR_R from `config.h'.
Some problems will require patching your Linux installation. The patch can be found at http://www.tcx.se/patches/Linux-sparc-2.0.30.diff. This patch is against the linux distribution `sparclinux-2.0.30.tar.gz', that is available at vger.rutgers.edu. This is a version of linux which was never merged with the official 2.0.30. You must also install linuxthreads 0.6 or newer.
Thanks to jacques@solucorp.qc.ca for the above information.
The first problem is linuxthreads. You must patch linuxthreads for alpha because the RedHat distribution uses an old (broken) linuxthreads version.
Note that Alpha-Linux is still an alpha platform for MySQL. With RedHat 5.0 and the patched linuxthreads you have a very good chance of it working.
When compiling threaded programs under Digital UNIX using CC / CXX the
documentation recommends the switch to cc and cxx and the libraries
-lmach -lexc (in addition to -lpthread).
So you have to configure with something like this:
CC="cc -pthread" CXX="cxx -pthread -O" ./configure
-with-named-thread-libs="-lpthread -lmach -lexc -lc"
When compiling mysqld you will may this warning for mysqld for a couple of lines:
mysqld.cc: In function void handle_connections()': mysqld.cc:626: passing long unsigned int *' as argument 3 of accept(int,sockad ddr *, int *)'
You can safely ignore these. This is because configure can't detect warnings, only errors.
You may get problems with the server exiting directly. If so, try
starting it with nohup safe_mysqld [options]
nohup is a command that ignores any SIGHUP sent from the
terminal.
In some versions of OSF1, the alloca() functions is broken. Fix
this by removing 'HAVE_ALLOCA' from config.h.
When using the Digital C++ you could try
-with-named-thread-libs="-lpthread -lmach -lexc -lc"
You may have to undefine some things in `config.h' (generated by `./configure').
In some Irix implementations the alloca() function is broken. If
the mysqld server dies on some selects, remove HAVE_ALLOC &
HAVE_ALLOCA_H from `config.h'. If mysqladmin create doesn't
work, remove HAVE_READDIR_R from config.h. Also you may have to
remove HAVE_TERM_H.
Irix 6.2 doesn't support POSIX threads out of of the box. You have install these patches, available from SGI if you have support:
1403, 1404, 1644, 1717, 1918, 2000, 2044
If you get the something like the following error when compiling mysql.cc:
"/usr/include/curses.h", line 82: error(1084): invalid combination of type
Type the following in the mysql installation directory:
> extra/replace bool curses_bool < /usr/include/curses.h > include/curses.h > make
There have also been reports about scheduling problems. This is because if only one thread is running, things go slow. Avoid this by starting another client. This may lead to a 2-10 fold increase in execution speed thereafter for the other thread.
This is a poorly-understood problem with IRIS threads, so you may have to improvise to find solutions until it can be fixed.
If you get link errors when compiling mysqlperl (Type
ient.a(my_getwd.o): RRS text relocation at 0x9a9f for
"__db_pargs_")
You must recompile the Perl code with -DPIC -fpic.
Do the following:
CFLAGS = -g -O2 to
CFLAGS = -O2 -DPIC -fpic
cd client
rm *.o
make libmysqlclient.a
cd ../perl/mysqlperl
make
This shall hopefully be handled automatically in the future.
The FreeBSD make behaviour is slightly different from GNU
make. If you have a problem that `mysqlperl/Makefile.PL'
doesn't get generated, you should install GNU make.
Other (temporary) solution:
> cd perl > make mysqlperl/Makefile.PL > make mysqlperl/mysql_test
If mysql or mysqladmin takes a long time to respond, a user said the following:
Are you running the ppp user process? On ine FreeBSD box (2.2.5) MySQL clients takes a couple of seconds to connect to mysqld if the ppp process is running.
FreeBSD is also known to have a very low default file handle limit. See section File not found
You have to configure with:
--with-named-thread-libs=-lc_r
The pthreads library for FreeBSD doesn't contain the sigwait
function and there is some bugs in it. To fix this, get the
`FreeBSD-3.0-libc_r-1.0.diff' file and apply this in the
`/usr/src/lib/libc_r/uthread' directory. Follow after this the
instructions that can be found with man pthread about how to
recompile the libc_r library.
You can test if you have a 'modern' libpthread.a with:
> nm /usr/lib/libc_r.a | grep sigwait.
If the above doesn't find sigwait you have to use the above patch
and recompile libc_r.
From Jan Legenhausen jleg@csl-gmbh.net.
I finally got mysqlperl working on BSDI2.1.
What i did was almost nothing:
GCC="shlicc2" per default;
perl5 automagically uses shlicc2 - you should use _one_ version (either
gcc or shlicc2) for both Mysql.c and
libmysqlclient.a!)
rm *.o
gmake libmysqlclient.a
cd ../perl/mysqlperl
make clean
$sysliblist=" -L$tmp -lgcc -lcompat"; to Makefile.PL line 45
(just to be sure - i didn't check if one could leave out this one)
perl Makefile.PL
libmysqlclient.a's in /usr/lib and
/usr/contrib/lib
make install
If you can't run the mysql_install_db script because the script
can't connect to the server you should check that you have an entry in
/etc/hosts like:
127.0.0.1 localhost
If you get the following error when compiling MySQL:
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
Then your ulimit for virtual memory is too low. Try using: ulimit
-v 30000 and do make again.
env CXX=shlicc++ CC=shlicc2 ./configure --prefix=/usr/local --localstatedir=/var/mysql --without-perl --with-unix-socket-path=/var/mysql/mysql.sock
You can change the directory locations if you wish, or just use their defaults by not specifying them.
The current port is only tested on a 'sco3.2v5.0.4' system.
as.
make when making MySQL.
SCO development notes:
-lgthreads -lsocket -lgthreads
When using the IBM compiler, something like this is needed:
CC="xlc_r -ma -O3 -qstrict" CXX="xlC_r -ma -O3 -qstrict" ./configure
Automatic detection of xlC is missing from autoconf.
Please always use the mysqlbug script when posting questions to the mailinglist (mysql@tcx.se). Even if the problem isn't a bug, mysqlbug gathers some system information that will help other solve your problem! See section I think I have found a bug. What information do you need to help me?.
> cd /usr/local > zcat /<where ever you put it>/mysql-3.20.0-SunOS5.tgz | tar xvf - > ln -s mysql-VERSION mysql
> scripts/mysql_install_dbIf you want to change things in the grant tables after installing you should use
mysql -u root mysql to connect to the grant tables
as the 'root' user.
The mysql_install_db script also starts the mysqld daemon.
> bin/safe_mysqld --log &
> bin/mysqladmin verThat should print something like this. The exact output depends on you platfrom and use.
bin/mysqladmin Ver 6.3 Distrib 3.21.15-alpha, for SOLARIS 2.5 on SPARCstation TCX Datakonsult AB, by Monty Server version 3.21.15-alpha Protocol version 9 Connection Localhost via UNIX socket TCP port 3306 UNIX socket /tmp/mysql.sock Uptime: 2 days 1 hour 42 min 3 sec Running threads: 2 Questions: 450378 Reloads: 17 Open tables: 64
> cd mysqlperl > perl Makefile.PL > make > make install
You should use the safe_mysqld script to the server.
safe_mysqld expects one of two conditions to be true:
/usr/local/mysql)
/my/. To get it to run correctly,
you should cd to /usr/local/mysql and then execute
safe_mysqld or modify the script so that it expects the base
mysql directory to be `/usr/local/mysql' rather than the default
`/my/'.
When you execute this:
> bin/mysqld --help
You will get the options for mysqld (and safe_mysqld) and the current
paths. Normally you only should need to change the
--basedir=path. You can test the path switches by executing:
> bin/mysqld --basedir=/usr/local --help
If you would like to use mysqlaccess and have the mysql distribution in
some nonstandard place, you must change the path to mysql in
mysqlaccess. bin/mysqlaccess about line 308:
$MYSQL = '/usr/local/bin/mysql --batch --unbuffered';
If you don't change the path, you will get a 'broken pipe' error when using mysqlaccess.
If you would like MySQL to start when you boot your machine,
you can copy bin/mysql.server to where your system has it startup
files. More information can be bound in the bin/mysql.server script
itself.
The binary distribution of MySQL for HP/UX is distributed as an HP depot file. This means that you must be running at least HP/UX 10.x to have access to HP's software depot tools.
This version of MySQL was compiled on an HP 9000/8xx server under HP/UX 10.20, and uses MIT Pthreads. It is known to work well under this configuration. This version does not use HP's native thread package. It is highly unlikely that MySQL will use HP native threads on anything but HP/UX 10.30 or later.
Other configurations that may work:
9000/7xx - HP/UX 10.20+ 9000/8xx - HP/UX 10.30 (does not use HP native threads)
The following configurations almost definitely won't work:
9000/7xx or 8xx - HP/UX 10.x where x < 2 9000/7xx or 8xx - HP/UX 9.x
To install (everything, including server, client and development tools):
/usr/sbin/swinstall -s <full path to the depot file> mysql.full
To install server only:
/usr/sbin/swinstall -s <full path to the depot file> mysql.server
To install client pack only:
/usr/sbin/swinstall -s <full path to the depot file> mysql.client
To install development tools only:
/usr/sbin/swinstall -s <full path to the depot file> mysql.developer
The depot will place binaries/libraries in /opt/mysql and data in /var/opt/mysql. The depot will also create the appropriate entries in /sbin/init.d and /sbin/rc2.d to automatically start the server on boot. This obviously entails being root to install.
Clients have to be linked with: -lmysqlclient
Check the log file to see if mysqld started up correctly.
mysqld daemon starts with a cd to 'mysql-data-dir'. After this,
mysqld-data-dir is changed to './' (current dir). All paths (databases,
pid file, and log file) have this directory as base path './'. If you
have any problems with wrong paths, try mysqld --help to see
your current paths. Every path can be changed by a startup option to
safe_mysqld or mysqld
cd <localstatedir default /usr/local/var> tail <your host name>.log
To verify that MySQL is working run the following tests:
> cd /usr/local/bin > ./mysqlshow +-----------+ | Databases | +-----------+ | mysql | +-----------+ > ./mysqlshow mysql Database: mysql +--------+ | Tables | +--------+ | db | | host | | user | +--------+ > ./mysql -e "select host,db,user from db" mysql +------+--------+------+ | host | db | user | +------+--------+------+ | % | test | | | % | test_% | | +------+--------+------+
There is also a benchmark suite so you can compare how MySQL performs on different platforms. In the near future this will also be used to compare MySQL to other SQL databases.
> cd bench > run-auto-increment-test
You can also run the tests in the test subdirectory. To run `auto_increment.tst':
./mysql -vf test < ./tests/auto_increment.tst
Expected results are shown in the file `./tests/auto_increment.res'.
To start or stop MySQL use the following commands:
scripts/mysql.server stop scripts/mysql.server start
You might want to add these start and stop commands in the appropriate places in your `/etc/rc*' files when you start using MySQL for production applications.
Go to the first, previous, next, last section, table of contents.