START-INFO-DIR-ENTRY * mysql: (mysql). *MySQL* documentation. END-INFO-DIR-ENTRY This is a manual for *MySQL*. This version is about the 3.22.14-gamma version of *MySQL*. For a *3.20* version see the relevant distribution. General Information about *MySQL* ********************************* This is the *MySQL* reference manual; it documents *MySQL* version 3.22.14-gamma. *MySQL* is a very fast, multi-threaded, multi-user and robust SQL database server. For Unix/OS2 platforms *MySQL* is basically free, for Microsoft platforms you must get a *MySQL* license after a trial time of 30 days. *Note Licensing and Support::. The *MySQL* home page (http://www.tcx.se/) provides the latest information about *MySQL*. For a discussion of *MySQL*'s capabilities, see *Note Features::. For installation instructions, see *Note Installing::. For tips on porting *MySQL* to new machines or operating systems, see *Note Porting::. *Note Upgrading-from-3.21::, for information about upgrading from a 3.21 release. For examples of SQL and benchmarking information, see the `bench' directory. For a history of new features and bug fixes, see *Note News::. For a list of currently known bugs and misfeatures, see *Note Bugs::. For future plans, see *Note TODO::. For a list of all the contributors to this product, see *Note Credits::. *IMPORTANT:* Send bug (error) reports, questions and comments to the mailing list at . *Note Bug reports:: For source distributions, the `mysqlbug' script can be found in the `scripts' directory. For binary distributions, `mysqlbug' can be found in the `bin' directory. If you have any suggestions concerning additions or corrections to this manual, please send them to the *MySQL* mailing list () with the following subject line: `documentation suggestion: [Insert Topic Here]'. *Note Mailing-list::. What is *MySQL*? ================ *MySQL* is a true multi-user, multi-threaded SQL (Structured Query Language) database server. SQL is the most popular database language in the world. *MySQL* is a client/server implementation that consists of a server daemon `mysqld' and many different client programs and libraries. The main goals of *MySQL* are speed, robustness and ease of use. *MySQL* was originally developed because we at TcX needed a SQL server that could handle very large databases an order of magnitude faster than what any database vendor could offer to us. We have now been using *MySQL* since 1996 in an environment with more than 40 databases containing 10,000 tables, of which more than 500 have more than 7 million rows. This is about 100 gigabytes of mission-critical data. The base upon which *MySQL* is built is a set of routines that have been used in a highly demanding production environment for many years. While *MySQL* is still in development, it already offers a rich and highly useful function set. The official way to pronounce *MySQL* is "My Ess Que Ell" (Not MY-SEQUEL). About this manual ================= This manual is currently available in TeXInfo, plain text, Info and HTML versions. Because of their size, PostScript and PDF versions are available for separate download. The primary document is the TeXInfo file. The HTML version is produced automatically with a modified version of `texi2html'. The plain text and Info versions are produced with `makeinfo'. The Postscript version is produced using `texi2dvi' and `dvips'. The PDF version is produced with the Ghostscript utility `ps2pdf'. This manual is written and maintained by David Axmark, Michael (Monty) Widenius, Paul DuBois and Kim Aldale. For other contributors, see *Note Credits::. Conventions used in this manual ------------------------------- This manual uses certain typographical conventions: `constant' Constant-width font is used for command names and options; SQL statements; database, table and column names; C and Perl code; and environment variables. Example: "to see how `mysqladmin' works, invoke it with the `--help' option." `filename' Constant-width font with surrounding quotes is used for filenames and pathnames. Example: "the distribution might be installed under the `/usr/local/' directory." `c' Constant-width font with surrounding quotes is also used to indicate character sequences. Example: "to specify a wildcard, use the `%' character." *italic* Italic font is used for emphasis, *like this*. *boldface* Boldface font is used for access privilege names (e.g., "do not grant the *process* privilege lightly") and occasionally to convey *especially strong emphasis*. When commands are shown that are meant to be executed by a particular program, the prompt for the command indicates the program. For example, `shell>' indicates a command that you execute from your login shell, and `mysql>' indicates a command that you execute from the `mysql' client: shell> type a shell command here mysql> type a mysql command here Shell commands are given using Bourne shell syntax. If you are using a `csh'-style shell, you may need to issue commands slightly differently. For example, the sequence to set an environment variable and run a command looks like this in Bourne shell syntax: shell> VARNAME=value some_command For `csh', you would execute the sequence like this: shell> setenv VARNAME value shell> some_command Database, table and column names often must be substituted into commands. To indicate that such substitution is necessary, this manual uses `db_name', `tbl_name' and `col_name'. For example, if you see this: mysql> SELECT col_name FROM db_name.tbl_name; It means that were you to enter a similar statement, you would supply your own database, table and column names, perhaps like this: mysql> SELECT author_name FROM biblio_db.author_list; SQL statements may be entered in uppercase or lowercase. When this manual shows a SQL statement, uppercase is used for particular keywords if those keywords are under discussion (to emphasize them) and lowercase for the rest of the statement. So you might see the following in a discussion of the `SELECT' statement: mysql> SELECT count(*) FROM tbl_name; On the other hand, in a discussion of the `COUNT()' function, the statement would be written like this: mysql> select COUNT(*) from tbl_name; If no particular emphasis is intended, all keywords are written in uppercase. In syntax descriptions, square brackets (`[' and `]') are used to indicate optional words or clauses: DROP TABLE [IF EXISTS] tbl_name When a syntax element consists of a number of alternatives, the alternatives are separated by vertical bars (`|'). When one member from a set of choices may be chosen, the alternatives are listed within square brackets. When one member from a set of choices must be chosen, the alternatives are listed within braces (`{' and `}'): TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str) {DESCRIBE | DESC} tbl_name {col_name | wild} History of *MySQL* ================== We once started off with the intention to use `mSQL' to connect to our own fast low-level (ISAM) tables. However, after some testing we came to the conclusion that `mSQL' was not fast enough or flexible enough for our needs. This resulted in a new SQL interface to our database but with almost the same API interface as `mSQL'. This API was chosen to ease porting of third-party code. The derivation of the name *MySQL* is not perfectly clear. Our base directory and a large number of our libraries and tools have had the prefix "my" for well over 10 years. However, Monty's daughter (some years younger) is also named My. So which of the two gave its name to *MySQL* is still a mystery, even for us. The main features of *MySQL* ============================ * Fully multi-threaded using kernel threads. That means it easily can use multiple CPUs if available. * C, C++, Java, Perl, Python and TCL API's. *Note Clients::. * Works on many different platforms. *Note Which OS::. * Many column types: signed/unsigned integers 1, 2, 3, 4 and 8 bytes long, `FLOAT', `DOUBLE', `CHAR', `VARCHAR', `TEXT', `BLOB', `DATE', `DATETIME', `TIMESTAMP', `YEAR', `SET' and `ENUM' types. *Note Column types::. * Very fast joins using an optimized one-sweep multi-join. * Full operator and function support in the `SELECT' and `WHERE' parts of queries. Example: mysql> SELECT CONCAT (first_name, " ", last_name) from tbl_name WHERE income/dependents > 10000 AND age > 30; * SQL functions are implemented through a highly-optimized class library and should be as fast as they can get! Usually there shouldn't be any memory allocation at all after the query initialization. * Full support for SQL `GROUP BY' and `ORDER BY' clauses. Support for group functions (`COUNT()', `AVG()', `STD()', `SUM()', `MAX()' and `MIN()'). * Support for `LEFT OUTER JOIN' with ANSI SQL and ODBC syntax. * You can mix tables from different databases in the same query (as of version 3.22). * A privilege and password system which is very flexible and secure, and which allows host-based verification. Passwords are secure since all password traffic when connecting to a server is encrypted. * ODBC (Open-DataBase-Connectivity) for Windows95 (with source). All ODBC 2.5 functions and many others. You can, for example, use Access to connect to your *MySQL* server. *Note ODBC::. * Very fast B-tree disk tables with index compression. * 16 indexes per table are allowed. Each index may consist of 1 to 15 columns or parts of columns. The maximum index length is 256 bytes (this may be changed when compiling *MySQL*). An index may use a prefix of a `CHAR' or `VARCHAR' field. * Fixed-length and variable-length records. * In-memory hash tables which are used as temporary tables. * Handles large databases. We are using *MySQL* with some databases that contain 50,000,000 records. * All columns have default values; you can use `INSERT' to insert a subset of a table's columns and columns that were not explicitly given values will be set to their default values. * Uses GNU Automake, Autoconf, and `libtool' for portability. * Written in C and C++. Tested with a broad range of different compilers. * A very fast thread-based memory allocation system. * No memory leaks. Tested with a commercial memory leakage detector (`purify'). * Includes `isamchk', a very fast table check, optimize and repair utility. *Note Maintenance::. * All data are saved in ISO-8859-1 Latin1 format. All comparisons for normal string columns are case insensitive. * Full support for the ISO-8859-1 Latin1 character set. For example, the Scandinavian characters *a, "a and "o are allowed in table and column names. * Sorts according to the ISO-8859-1 Latin1 character set (the Swedish way at the moment). It is possible to change this in the source by adding new sort order arrays. To see an example of very advanced sorting, look at the Czech sorting code. *MySQL* supports many different character sets that can be specified at compile time. * Aliases on tables and columns as in the SQL92 standard. * `DELETE', `INSERT', `REPLACE', and `UPDATE' return how many rows were affected. * Function names do not clash with table or column names. For example, `ABS' is a valid column name. The only restriction is that for a function call, no spaces are allowed between the function name and the `(' that follows it. *Note Reserved words::. * All *MySQL* programs can be invoked with the `--help' or `-?' options to obtain online assistance. * The server can provide error messages to clients in many languages. *Note Languages::. * Clients connect to the *MySQL* server using a TCP/IP connection or Unix socket. * The *MySQL*-specific `SHOW' command can be used to retrieve information about databases, tables and indexes. The `EXPLAIN' command can be used to check how the optimizer resolves a query. How stable is *MySQL*? ====================== This section addresses the questions, "how stable is *MySQL*?" and, "can I depend on *MySQL* in this project?" At TcX, *MySQL* has worked without any problems in our projects since mid-1996. When *MySQL* was released to a wider public, we noticed that there were some pieces of "untested code" that were quickly found by the new users who made queries in a different manner. Each new release has had fewer portability problems than the previous one, even though each has had many new features, and we hope that it will be possible to label one of the next releases "stable". Each release of *MySQL* has been usable and there have been problems only when users start to use code from "the gray zones". Naturally, outside users can't know what the gray zones are; this section attempts to indicate those that are currently known. Here we will try to clarify some issues and to answer some of the more important questions that seem to concern many people. This section has been put together from information gathered from the mailing list (which is very active in reporting bugs). The descriptions deal with the 3.21.x version of *MySQL*. All known and reported bugs are fixed in the latest version, with the exception of the bugs listed in the BUGS file which are things that are "design"-related. *MySQL* is written in multiple layers and different independent modules. Here is a list of the different modules and how well-tested each of them is: *The ISAM table handler -- Stable* This is how all the data are stored. In all *MySQL* releases there hasn't been a single (reported) bug in this code. The only known way to get a corrupted table is to kill the server in the middle of an update. Even that is unlikely to destroy any data beyond rescue, because all data are flushed to disk between each query. There hasn't been a single bug report about lost data because of bugs in *MySQL*, either. *The parser and lexical analyser -- Stable* There hasn't been a single reported bug in this system for a long time. *The C client code -- Stable* No known problems. In early 3.20 releases, there were some limitations in the send/receive buffer size. In 3.21.x, the send/receive buffer is now dynamic up to a default of 512K. *`mysql', `mysqladmin' and `mysqlshow', `mysqldump',* and `mysqlimport' -- Stable *Basic SQL -- Stable* The basic SQL function system and string classes and dynamic memory handling. Not a single reported bug on this system. *Query optimizer -- Gamma* *Range optimizer -- Stable* *Join optimizer -- Stable* *Locking -- Gamma* This is very system-dependent. On some systems there are big problems using standard OS locking (`fcntl()'). In these cases, you should run the *MySQL* daemon with the `--skip-locking' flag. Problems are known to occur on some Linux systems and on SunOS when using NFS-mounted file systems. *Linux threads -- Gamma* The only problem found has been with the `fcntl()' call, which is fixed by using the `--skip-locking' option to `mysqld'. Some people have reported lockup problems with the 0.5 release. *Solaris 2.5+ pthreads -- Stable* We use this for all our production work. *MIT-pthreads (Other systems) -- Gamma* There have been no reported bugs since 3.20.15 and no known bugs since 3.20.16. On some systems, there is a "misfeature" where some operations are quite slow (a 1/20 second sleep is done between each query). Of course, MIT-pthreads may slow down everything a bit, but index-based `SELECT' statements are usually done in one time frame so there shouldn't be a mutex locking/thread juggling. *Other thread implementions -- Alpha - Beta* The ports to other systems are still very new and may have bugs, possibly in *MySQL*, but most often in the thread implementation itself. *`LOAD DATA ...', `INSERT ... SELECT' -- Stable* Some people have thought they have found bugs here, but these have turned out to be misunderstandings. So check the manual before reporting bugs! *`ALTER TABLE' -- Gamma* Small changes in 3.22.12 *DBD -- Gamma* Now maintained by Jochen Wiedmann . Thanks! *`mysqlaccess' -- Gamma* Written and maintained by Yves Carlier . Thanks! *`GRANT' - Alpha* Big changes done in *MySQL* 3.22.12. **MyODBC* (uses ODBC SDK 2.5) -- Beta* It seems to work well with some programs. TcX provides email support for paying customers, but the *MySQL* mailing list usually provides answers to common questions. Bugs are usually fixed right away with a patch; for serious bugs, there is almost always a new release. Year 2000 compliance ==================== *MySQL* itself has no problems with Year 2000 compliance: * *MySQL* uses Unix time functions and has no problems with dates until `2069'; all 2-digit years are regarded to be in the range `1970' to `2069', which means that if you store `01' in a `year' column, *MySQL* treats it as `2001'. * All *MySQL* date functions are stored in one file `sql/time.cc' and coded very carefully to be year 2000-safe. * In *MySQL* 3.22 and later versions, the new `YEAR' column type can store years `0' and `1901' to `2155' in 1 byte and display them using 2 or 4 digits. You may run into problems with applications that use *MySQL* in a way that is not Year 2000-safe. For example, many old applications store or manipulate years using 2-digit values (which are ambiguous) rather than 4-digit values. This problem may be compounded by applications that use values such as `00' or `99' as "missing" value indicators. Unfortunately, these problems may be difficult to fix, since different applications may be written by different programmers, each of whom may use a different set of conventions and date-handling functions. Here is a simple test that shows that MySQL doesn't have any problems with dates until 2030 ! mysql> DROP TABLE IF EXISTS y2k; mysql> CREATE TABLE y2k (date date, date_time datetime, time_stamp timestamp); mysql> INSERT INTO y2k VALUES ("1998-12-31","1998-12-31 23:59:59",19981231235959); mysql> INSERT INTO y2k VALUES ("1999-01-01","1999-01-01 00:00:00",19990101000000); mysql> INSERT INTO y2k VALUES ("1999-09-09","1999-09-09 23:59:59",19990909235959); mysql> INSERT INTO y2k VALUES ("2000-01-01","2000-01-01 00:00:00",20000101000000); mysql> INSERT INTO y2k VALUES ("2000-02-28","2000-02-28 00:00:00",20000228000000); mysql> INSERT INTO y2k VALUES ("2000-02-29","2000-02-29 00:00:00",20000229000000); mysql> INSERT INTO y2k VALUES ("2000-03-01","2000-03-01 00:00:00",20000301000000); mysql> INSERT INTO y2k VALUES ("2000-12-31","2000-12-31 23:59:59",20001231235959); mysql> INSERT INTO y2k VALUES ("2001-01-01","2001-01-01 00:00:00",20010101000000); mysql> INSERT INTO y2k VALUES ("2004-12-31","2004-12-31 23:59:59",20041231235959); mysql> INSERT INTO y2k VALUES ("2005-01-01","2005-01-01 00:00:00",20050101000000); mysql> INSERT INTO y2k VALUES ("2030-01-01","2030-01-01 00:00:00",20300101000000); mysql> INSERT INTO y2k VALUES ("2050-01-01","2050-01-01 00:00:00",20500101000000); mysql> SELECT * FROM y2k; +------------+---------------------+----------------+ | date | date_time | time_stamp | +------------+---------------------+----------------+ | 1998-12-31 | 1998-12-31 23:59:59 | 19981231235959 | | 1999-01-01 | 1999-01-01 00:00:00 | 19981231000000 | | 1999-09-09 | 1999-09-09 23:59:59 | 19990909235959 | | 2000-01-01 | 2000-01-01 00:00:00 | 20000101000000 | | 2000-02-28 | 2000-02-28 00:00:00 | 20000228000000 | | 2000-02-29 | 2000-02-29 00:00:00 | 20000229000000 | | 2000-03-01 | 2000-03-01 00:00:00 | 20000301000000 | | 2000-12-31 | 2000-12-31 23:59:59 | 20001231235959 | | 2001-01-01 | 2001-01-01 00:00:00 | 20010101000000 | | 2004-12-31 | 2004-12-31 23:59:59 | 20041231235959 | | 2005-01-01 | 2005-01-01 00:00:00 | 20050101000000 | | 2030-01-01 | 2030-01-01 00:00:00 | 20300101000000 | | 2050-01-01 | 2050-01-01 00:00:00 | 00000000000000 | +------------+---------------------+----------------+ 13 rows in set (0.00 sec) mysql> DROP TABLE y2k; This shows that the `DATE' and `DATETIME' types are *Date Data* compliant, while the `TIMESTAMP' type, that is used to store the current time, only has a range up to `2030-01-01'. `TIMESTAMP' has a range of `1970' to `2030' on 32-bit machines. General SQL information and tutorials ===================================== This book has been recommended by a several people on the *MySQL* mailing list: Judith S. Bowman, Sandra L. Emerson and Marcy Darnovsky The Practical SQL Handbook: Using Structured Query Language Second Edition Addison-Wesley ISBN 0-201-62623-3 http://www.awl.com This book has also received some recommendations on the mailing list: Martin Gruber Understanding SQL ISBN 0-89588-644-8 Publisher Sybex 510 523 8233 Alameda, CA USA A SQL tutorial is available on the net at `http://w3.one.net/~jhoffman/sqltut.htm'. Useful *MySQL*-related links ============================ Web development tools that support *MySQL* ------------------------------------------ * PHP: A server-side HTML-embedded scripting language (http://www.php.net/) * A JDBC driver for *MySQL* (http://www.voicenet.com/~zellert/tjFM) * *MySQL* + PHP demos (http://www.wernhart.priv.at/php/) * WWW-SQL: Display database information (http://www.daa.com.au/~james/www-sql/) * Minivend: A Web shopping cart (http://www.minivend.com/minivend/) * HeiTML: A server-side extension of HTML and a 4GL language at the same time (http://www.heitml.com/) * Metahtml: A Dynamic Programming Language for WWW Applications (http://www.metahtml.com/) * VelocityGen for Perl and TCL (http://www.binevolve.com/) * Hawkeye Internet Server Suite (http://hawkeye.net/) * Network Database Connection For Linux (http://www.fastflow.com/) * WDB: Web browser as a universal front end to databases (http://www.lava.net/beowulf/programming/wdb/) * WebGroove Script: HTML compiler and server-side scripting language (http://www.webgroove.com/) * A server-side web site scripting language (http://www.ihtml.com/) * Visual Basic class generator for Active X (http://www.pbc.ottawa.on.ca) * How to use *MySQL* with Coldfusion on Solaris (ftp://ftp.igc.org/pub/myodbc/README) Web servers with *MySQL* tools ------------------------------ * An Apache authentication module (http://bourbon.netvision.net.il/mysql/mod_auth_mysql/) * The Roxen Challenger Web server (http://www.roxen.com/) Examples and source ------------------- * Examples using *MySQL* (http://php.netvision.net.il/examples), * A Contact Database using *MySQL* and PHP (http://www.webtechniques.com/features/1998/01/note/note.shtml) * Web based interface and Community Calender with PHP (http://modems.rosenet.net/mysql/) * Perl package to generate html from a SQL table structure and for generating SQL statements from an html form. (http://www.odbsoft.com/cook/sources.htm) * Basic telephone database using `DBI'/`DBD' (http://www.gus.ml.org/proj/telsql/). * *TmySQL*; A library to use *MySQL* with Delphi (http://www.productivity.org/projects/mysql/) Other *MySQL*-related links --------------------------- * Links about using *MySQL* in Japan/Asia (http://www.softagency.co.jp/mysql/index.en.phtml) * Commercial Web defect tracking system (http://www.open.com.au/products.html) * PTS: Project Tracking System (http://www.stonekeep.com/pts/) * Job and software tracking system (http://tomato.nvgc.vt.edu/~hroberts/mot) * Support for BIND (The Internet Domain Name Server) (http://www.seawood.org/msql_bind/) * Registry of Web providers who support *MySQL* (http://www.wix.com/mysql-hosting) * Full-text search engine using *MySQL* (http://home.wxs.nl/cgi-bin/planeteers/pgidszoek.cgi) * ExportSQL: A script to export data from Access95+ (http://www.cynergi.net/non-secure/exportsql/) * SAL (Scientific Applications on Linux) *MySQL* entry (http://SAL.KachinaTech.COM/H/1/MYSQL.html) * *MySQL* Apps and Utilities Listing (http://www.cgishop.com/bin/mysqllist) * A consulting company which mentions *MySQL* in the right company (http://www.infotech-nj.com/itech/index.shtml) * PMP Computer Solutions. Database developers using *MySQL* and `mSQL' (http://www.pmpcs.com/) * Airborne Early Warning Association (http://www.aewa.org) * *MySQL* UDF Registry (http://abattoir.cc.ndsu.nodak.edu/~nem/mysql/udf/) SQL and database interfaces --------------------------- * The JDBC database access API (http://java.sun.com/products/jdbc/) * *MySQL* binding to Free Pascal (http://tfdec1.fys.kuleuven.ac.be/~michael/fpc-linux/mysql) * Patch for `mSQL' TCL (http://www.gagme.com/mysql) * EasySQL: An ODBC-like driver manager (http://www.amsoft.ru/easysql/) * A REXX interface to SQL databases (http://www.lightlink.com/hessling/rexxsql.html) * TCL interface (http://www.binevolve.com/~tdarugar/tcl-sql) * Example of storing/retrieving images with *MySQL* and CGI (http://tim.desert.net/~tim/imger/) General database links ---------------------- * Database Jump Site (http://www.pcslink.com/~ej/dbweb.html) * Homepage of the webdb-l (Web Databases) mailing list. (http://black.hole-in-the.net/guy/webdb/) * Perl `DBI'/`DBD' modules homepage (http://www.hermetica.com/technologia/DBI/) * Cygwin tools (MySQL +Apache + PHP under Win32 (http://www-public.rz.uni-duesseldorf.de/~tolj) There are also many web pages that use *MySQL*. *Note Users::. Send any additions to this list to . *MySQL* mailing lists and how to ask questions or report errors (bugs) ********************************************************************** The *MySQL* mailing lists ========================= Requests to be added to or dropped from the main *MySQL* mailing list should be sent to the electronic mail address . Sending a one-line message saying either `subscribe mysql' or `unsubscribe mysql' suffices. If your reply address is not valid, you may specify your address explicitly using `subscribe mysql your-name@your.domain' or `unsubscribe mysql your-name@your.domain'. Please *do not* send mail about subscribing or unsubscribing to , since any mail sent to that address is forwarded automatically to hundreds of other users. Your local site may have many subscribers to . If so, it may have a local mailing list, so that a single message from `tcx.se' is sent to the site and propagated to the local list. In such cases, please contact your system administrator to be added to or dropped from the local *MySQL* list. Mail to is handled automatically by the Majordomo mailing list processor. The following *MySQL* mailing lists exist: `mysql-announce' This is for announcement of new versions of *MySQL* and related programs. This is a low volume list that we think all *MySQL* users should be on. `mysql' The main list for general *MySQL* discussion. Please note that some things should go to the more-specialized lists. It you post to the wrong list, you may not get an answer! `mysql-digest' The `mysql' list in digest form. That means you get all individual messages, sent as one large mail message once a day. `mysql-Java' Discussion about *MySQL* and Java. Mostly about the JDBC drivers. `mysql-win32' All things concerning *MySQL* on Microsoft operating systems like Windows/NT. `myodbc' All things concerning connecting to *MySQL* with ODBC. `msql-mysql-modules' A list about the Perl support in *MySQL*. `msql-mysql-modules-digest' A digest version of the `msql-mysql-modules' list. `mysql-developer' A list for people who work on the *MySQL* code. You subscribe or unsubscribe to all lists in the same way as described above. In your subscribe or unsubscribe request, just put the appropriate mailing list name rather than `mysql'. Asking questions or reporting bugs ================================== Before you ask a question on the mailing list, it is a good idea to check this manual. If you can't find an answer here, check with your local *MySQL* expert. If you still can't find an answer to your question, go ahead and read the next section about how to send mail to . How to report bugs / problems ============================= Before posting a bug report / question, please start by searching the *MySQL* online manual `http://www.tcx.se/Manual_chapter/manual_toc.html' and in the `MySQL' mail archives. We try to keep the manual up to date and we constantly update this with solutions to new found problems! You can find the some search able mail archives at `http://www.tcx.se/doc.html'. You can also use `http://www.tcx.se/search.html' to search all the web pages (including the manual) at `http://www.tcx.se'. Writing a good bug report takes patience, but doing it right at once saves time from us and from you. This section will help you writing your report right and prevents consuming your time doing things that may not help us much or at all. We encourage everyone to use script `mysqlbug' to generate a bug report, or a report about any problem, if possible. The `mysqlbug' can be found from the `scripts' in the distribution or in the `bin' directory, where you have installed *MySQL*. If you are unable to use it, you should still include all the necessary information from this section. The `mysqlbug' will help you making the report by automatically finding a lot of the following information, but if something important is missing, please include it with your message! Please read carefully this section and make sure you have all the information described here included in your report. Remember that it is possible to answer a letter with too much information, but not the one with too little. Often people omit facts, because they think they know what is the reason for the problem and assume that some details don't matter. A good principle is: if you are in doubt to state something, state it! It is a thousand times faster and less troublesome to read a couple of lines more than to be forced to ask again and wait for the answer. Most common errors are that people don't tell the *MySQL* version number they are using, or don't tell on what platform they have *MySQL* installed on, including the version number of the platform. This is very relevant information and in 99 cases out of 100 the bug report is useless without this information! Very often we get questions like 'Why doesn't this work for me?' and then we found that the quested feature wasn't yet implemented to that *MySQL* version, or there was a bug which was already fixed in the newer *MySQL* versions. Sometimes the error is platform depended and it is next to impossible to fix anything without knowing the operating system and the version number of the platform. Remember also to give information about your compiler, if it is related to the problem. Often people found bugs in compilers and think the problem is *MySQL* related. Most compilers are under development all the time and become better version by version too. To verify, if the problem depends on compiler, we need to know what compiler is used. Note that every compiling problem should be regarded as a bug report and reported according to it. Most helpful is when a good description of the problem is given. That is, a good example of all the things one did that leaded to the problem and the problem itself exactly described. The best bug reports are those that includes a full example how to reproduce the bug or problem. If a program gives an error message, please include it. If we try to search something from the archives using programs, it is better that the error message is exactly the one that the program gave. (Even the case sensitivity should be observed!) This is the reason why >>cut'n'paste>> is the only right principle here! * Version number of the *MySQL* you are using (for example, *MySQL* 3.22.12). You can find out which version you are running by executing `mysqladmin version'. `mysqladmin' can be found from the `bin' directory where *MySQL* is installed. * The manufacturer and model of the machine you are working on. * The operating system name and version. For most operating systems, you can get this by executing a Unix command `uname -a'. * Sometimes the amount of memory is relevant. (real and virtual) If in doubt, include them. * If one has the source distribution of *MySQL*, the information about the compiler used is needed. The name and the version number. If one has a binary distribution, the distribution name is needed. * If the problem occurs during a compilation, include the exact error message(s) and also a few lines around the offending code in the file where the error occurred. * Include the output from `mysqldump --no-data database table1 table2...', if any table is related to the problem. This is very easy and a powerful way to get information about any table in a database and we will be able to create a situation that matches the one you have. * In speed related bugs/problems with selects, one should always include the output of 'explain select ...' and at least the number of rows that the 'select ...' gives. * If a problem / bug occurs while running *MySQL*, an input script, which will reproduce the bug, is needed. This script should include all the necessary source files, if any. The closer to the real situation the script will make, the better. * If you think that *MySQL* gives a strange result from a query, include not only the result, but also your opinion what the result should be and some account for why. * When giving an example of the problem, it's better to use same variable names, table names, etc. those exist in the real situation than come up with new names. The problem could be even a variable, table etc. name related! Rare case perhaps, but better safe than sorry. After all it should be easier for you to use the same situation in your example that you really had and it is by all means better for us. In case you have some data you don't want to show to others, you can use `ftp' to transfer the data to `ftp://www.tcx.se/pub/mysql/secret'. If the data is really top secret and you don't want to show it even to us, then go ahead and make an example using other variable names, etc., but please regard it as the last choice. * If a program gives an error message, it is very important to state it! One should never try to remember what the error message was, but copy and paste the whole error message into the mail! * Include all the options given to the relevant programs, if possible. For example, the options to the mysqld daemon and to any *MySQL* client programs. The options to `mysqld' ,`mysql' or to `configure' script are often keys to answers and very relevant! It is never a bad idea to include them anyway! If you use any modules, like Perl or PHP, please include the version number(s) of these. * If you can't produce a test case in a few rows, or if the test table is too big to be mailed to everyone (more than 10 rows), you should dump your tables using `mysqldump' and create a `README' file that describes your problem. Use `tar' and `gzip' or `zip' on the files and use `ftp' to transfer the archive to `ftp://www.tcx.se/pub/mysql/secret'. Then send a short description of the problem to . * If your question is related to the privilege system, please include the output of `mysqlaccess' (can be found from the scripts directory), the output of `mysqladmin reload' and all the error messages you get when trying to connect! You should do all the tests in the order above! * If you have a patch for a bug, it's good. If the patch is good, then very good. Still, don't expect that we will use the patch anyway and omit some necessary information, like a test case, thinking that the patch is all we need. We might found problems with your patch or don't understand it at all and if so, we don't use the patch. If we can't verify what the patch is exactly meant for, we don't use it. A test case will help us here. Show that the patch will handle all the situations that may happen. If we found, even a rare borderline case, there the patch won't work, the patch may be useless. * A guess about what the bug is, why it occurs, or what it depends on, is usually wrong. Even we can't guess such things without first using a debugger to find out where the bug really comes from. * Indicate in your mail message that you have checked the reference manual and mail archive so others know that you have tried to solve your problem yourself. * If you get a `parse error' please check your syntax closely! If you can't find something wrong with it, it's extremely likely that your current version of *MySQL* doesn't support the query you are using! In this case you should check the *MySQL* change history for when the syntax was implemented! *Note News:: If the manual at `http://www.tcx.se/doc.html' doesn't cover the query syntax you are using, this means that *MySQL* doesn't yet support this! In this case your only options are to implement this yourself or email and ask for an offer to implement this! * If possible download the newest *MySQL* version and test if your problem is solved in this! All *MySQL* versions are throughly tested and should work without problems! We believe in making everything as backward compatible as possible and you should be able to switch *MySQL* version in minutes! *Note Which version::. If you are a support customer, please cross post the bug report to for higher priority treatment, as well as to the appropriate mailing list to see if someone else has experienced (and perhaps solved) the problem. For information on reporting bugs in *MyODBC*, see *Note ODBC Problems::. When answers are sent to you individually and not to the mailing list, it is considered good etiquette to summarize the answers and send the summary to the mailing list to that others may have the benefit of the responses you received that helped you solve your problem!. What to do if *MySQL* keeps crashing ------------------------------------ Since it is very hard to know why something is crashing, first try to check whether or not things that work for others crash for you. Please try the following things: * Have you tried the benchmarks? This should test *MySQL* rather well. You can also add code that simulates your application! * Try `fork_test.pl' and `fork2_test.pl'. * If you configure *MySQL* for debugging, it will be much easier to find out possible errors if something goes wrong. *Note Debugging::. * Reconfigure *MySQL* with the `--with-debug' option to `configure' and then recompile. This causes a safe memory allocator to be included that can find some errors. It also provides a lot of output about what is happening. * Use `mysqld --log' and try to determine from the information in the log whether or not some specific query kills the server. 95% of all bugs are related to some specific query! * Have you applied the latest patches for your operating system? * Use the `--skip-locking' option to `mysqld'. On some systems, the `lockd' lock manager does not work properly; the `--skip-locking' option tells `mysqld' not to use external locking. (This means that you cannot run 2 `mysqld' servers on the same data and you must be careful when using `isamchk', but it may be instructive to try the option as a test.) * Have you tried `mysqladmin -u root processlist' when `mysqld' appears to be dead? Sometimes `mysqld' is not dead even though you might think so. The problem may be that all connections are in use, or there may be some internal lock problem. `mysqladmin processlist' will usually be able to make a connection even in these cases, and can provide useful information about the current number of connections and their status. * Run the command `mysqladmin -i 5 status' in a separate window to output statistics. * Try the following: 1. Start `mysqld' from `gdb' (or another debugger). 2. Run your test scripts. 3. Do `back' (or the backtrace command in your debugger) when `mysqld' core dumps. * Try to simulate your application with a Perl script to force *MySQL* to crash or misbehave. * Or send a normal bug report. *Note Bug reports::. But be even more detailed than usual. Since *MySQL* works for many people it may be that the crash results from something that exists only on your computer (for example, an error that is related to your particular system libraries). Guidelines for answering questions on the mailing list ====================================================== If you consider your answer to have broad interest, you may want to post it to the mailing list instead of replying directly to the individual who asked. Try to make your answer general enough that people other than the original poster may benefit from it. When you post to the list, please make sure that your answer is not a duplication of a previous answer. Try to summarize the essential part of the question in your reply, but don't feel obliged to quote the whole question. Please don't post mails from your browser with HTML mode turned on! Many users doesn't read mails with a browser! Licensing or When do I have/want to pay for *MySQL*? **************************************************** The basic licensing issues are: * The easiest way to pay for *MySQL* is to use the license form at TcX's secure server at `https://www.tcx.se/license.htmy'. * We hope everybody understands that you only have to pay if you are selling *MySQL* directly, selling a product which includes the *MySQL* server or installing and maintaining a *MySQL* server at some client site. You may not include *MySQL* in a distribution if you charge for some part of the distribution. For internal use, you do not have to pay us if you do not want to. * There is no restriction in the number of clients that connects to a *MySQL* server or the number of *MySQL* servers that runs on one machine! * You do not need a license to include client code in commercial programs. The client access part of *MySQL* is in the public domain. The command line client (`mysql') includes parts that are under the GNU Public License (`readline'). * We may add some additional functionality in the commercial version. The likely test candidate for this is the ability to create fast compressed read-only databases. The current server includes support to read such databases but not the packing tool used to create them. If we get enough revenue from support, we will probably release this under the same license as the other stuff. * But if you like *MySQL* and want to encourage further development you are welcome to purchase a license or support. *Note Public license::. How much *MySQL* costs ====================== For normal use on Unix or OS/2, *MySQL* costs nothing. When you sell *MySQL*, directly or as a part of another product, you have to pay for it. *Note Public license::. For use on Win95/Win98/NT you will need a *MySQL* license after a trial time of 30 days. You can of course first try the shareware version before buying! `http://www.tcx.se/mysql_w32.htmy,*MySQL* -Win32' Some examples about when you need a `MySQL' license on Unix / OS/2. * If you use *MySQL* to store data for www server you don't have to pay for a license. * If a customer sets and administrates a *MySQL* server on your machine for himself, neither you or he needs a *MySQL* license. * If you set up a *MySQL* server for a paying client you will need a license for the machine that runs the mysqld server. This is because you are in this case selling a system with `MySQL'. Note that the single *MySQL* license will cover any number of users/customers on this machine! * If you on install *MySQL* on a clients machine and any money changes hands (directly or indirectly) then you must buy a *MySQL* license! * If you sell a product, that will be installed at the customers machine, that REQUIRES *MySQL* to work, you will need a license. *Note User adding MySQL::. If your use of *MySQL* requires a license (*note Licensing and Support::.), you only need to get a license for each machine that runs the `mysqld' server. A multi-CPU machine counts as one machine. There is no restriction on the number of concurrent users connected to a machine running a `mysqld' server. Our current license prices are shown below. All prices are in US Dollars. If you pay by credit card, the currency is EURO (European Union Euro) so the prices will differ slightly. *Number of *Price per *Total* licenses* copy* 1 US $200 US $200 10 pack US $150 US $1500 50 pack US $120 US $6000 For high volume (OEM) purchases, the following prices apply: *Number of *Price per *Minimum at one time* *Minimum payment* licenses* copy* 100-1000 $40 100 $4000 1000-2500 $25 200 $5000 2500-5000 $20 400 $8000 For OEM purchases, you must act as a middle-man for eventual problems or extension requests from users. We also require OEM customers to have a support contract. If you have a low-margin high-volume product, you can always talk to us about other terms (for example, a percent of the sale price). If you do, please be informative about your product, pricing, market and any other information that may be relevant. How to get commercial support ============================= A full-price license includes really basic support. This means that we try to answer any relevant question. If the answer is in the documentation, we will direct you to the appropriate section. If you do not have a license or support, we probably will not answer at all. If you discover what we consider a real bug, we are likely to fix it in any case. But if you pay for support we will notify you about the fix status instead of just fixing it in a later release. More comprehensive support is sold separately. Costs for the various types of commercial support are shown below, and the following sections describe what each level of support includes. You are entitled to upgrade from any lower level of support to a higher level of support for the difference between the prices of the two support levels. Support level prices are in EURO (European Union Euro). One EURO is about 1.17 USD. *Type of support* *Cost per year* Basic email support EURO 170 Extended email EURO 1000 support Login support EURO 2000 Extended login EURO 5000 support Basic email support ------------------- Basic email support includes the following types of service: * For *MySQL*-specific questions that don't belong on the *MySQL* mailing list (), you can contact . Remember to always include your registration number and expiration date to ensure a quick response from . You can also crosspost your questions to any of the standard *MySQL* mailing lists, as someone else may already have experienced and solved the problem/question you have. * If your question is already answered in the manual, we will inform you of the correct section in which you can find the answer. If the answer is not in the manual, we will point you in the right direction to solve your problem. * We guarantee a timely answer for your email messages. We can't guarantee that we can solve any problem, but at least you will receive an answer if we can contact you by email. * We will help with unexpected problems when you install *MySQL* from a binary distribution on supported platforms. This level of support does not cover installing *MySQL* from a source distribution. * We will help you with bugs and missing features. Any bugs that are found are fixed for the next *MySQL* release. If the bug is critical for you, we will mail you a patch for it as soon the bug is fixed. Critical bugs always have the highest priority for us, to ensure that they are fixed as soon as possible. * Your suggestions for the further development of *MySQL* will be taken into consideration. By taking email support you have already helped the further development of *MySQL*. If you want to have more input, upgrade to a higher level of support. * If you want us to help optimize your system, you have to upgrade to a higher level of support. Basic email support is a very inexpensive support option and should be thought of more as a way to support our development of *MySQL* than as a real support option. Extended email support ---------------------- Extended basic support includes everything in basic email support with these additions: * Your email will be dealt with before mail from basic email support users and non-registered users. * Your suggestions for the further development of *MySQL* will receive strong consideration. Simple extensions that suit the basic goals of *MySQL* are implemented in a matter of days. By taking extended email support you have already helped the further development of *MySQL*. * We include a binary version of the `pack_isam' tool that supports fast compressed read-only databases (no `BLOB' or `TEXT' types yet). The current server includes support to read such databases but not the packing tool. * Typical questions that are covered by extended email support are: - We will answer and (within reason) solve questions that relate to possible bugs in *MySQL*. As soon as the bug is found and corrected, we will mail a patch for it. - We will help with unexpected problems when you install *MySQL* from a source or binary distribution on supported platforms. - We will answer questions about missing features and offer hints how to work around them. - We will provide hints on optimizing `mysqld' for your situation. * You are allowed to influence the priority of items on the *MySQL* TODO. This will ensure that the features you really need will be implemented sooner than they might be otherwise. Login support ------------- Login support includes everything in extended basic email support with these additions: * Your email will be dealt with even before mail from extended support users. * Your suggestions for the further development of *MySQL* will be taken into very high consideration. Realistic extensions that can be implemented in a couple of hours and that suit the basic goals of *MySQL* will be implemented as soon as possible. * If you have a very specific problem, we can try to log in on your system to solve the problem "in place". * Like any database vendor, we can't guarantee that we can rescue any data from crashed tables, but if the worst happens we will help you rescue as much as possible. *MySQL* has proven itself very reliable, but anything is possible due to circumstances beyond our control (for example, if your system crashes or someone kills the server with `kill -9'). * We will provide hints on optimizing your system and your queries. * You are allowed to call a *MySQL* developer (in moderation) and discuss your *MySQL*-related problems. Extended login support ---------------------- Extended login support includes everything in login support with these additions: * Your email has the highest possible priority. * We will actively examine your system and help you optimize it and your queries. We may also optimize and/or extend *MySQL* to better suit your needs. * You may also request special extensions just for you. For example: mysql> select MY_CALCULATION(col_name1,col_name2) from tbl_name; * We will provide a binary distribution of all important *MySQL* releases for your system, as long as we can get an account on a similar system. In the worst case, we may require access to your system to be able to create a binary distribution. * If you can provide accommodations and pay for traveler fares, you can even get a *MySQL* developer to visit you and offer you help with your troubles. Extended login support entitles you to one personal encounter per year, but we are as always very flexible towards our customers! How to pay for licenses or support ================================== Currently we can take SWIFT payments, cheques or credit cards. Payment should be made to: Postgirot Bank AB 105 06 STOCKHOLM, SWEDEN T.C.X DataKonsult AB BOX 6434 11382 STOCKHOLM, SWEDEN SWIFT address: PGSI SESS Account number: 96 77 06 - 3 Specify: license and/or support and your name and email address. In Europe and Japan you can use EuroGiro (that should be less expensive) to the same account. If you want to pay by cheque, make it payable to "Monty Program KB" and mail it to the address below: T.C.X DataKonsult AB BOX 6434 11382 STOCKHOLM, SWEDEN If you want to pay with credit card over the Internet, you can use TcX's secure license form (https://www.tcx.se/license.htmy). You can also print a copy of the above page, fill it in and send it by fax to: +46-8-729 69 05 If you want us to bill you, you can use the license form and write "bill us" in the comment field. You can also mail a message to with your company information and ask us to bill you. Who to contact for more information about licensing or support ============================================================== For commercial licensing, or if you have any questions about any of the information in this section, please contact: David Axmark Detron HB Kungsgatan 65 B 753 21 UPPSALA SWEDEN Voice Phone +46-18-10 22 80 (Swedish and English spoken) Fax +46-8-729 69 05 (Email *much* preferred) E-Mail: mysql-licensing@tcx.se What copyrights *MySQL* uses ============================ There are several different copyrights on the *MySQL* distribution: 1. The *MySQL*-specific source needed to build the `mysqlclient' library and programs in the `client' directory is in the public domain. Each file that is in the public domain has a header which clearly states so. This includes everything in the `client' directory and some parts of the `mysys', `mystring' and `dbug' libraries. 2. Some small parts of the source (GNU `getopt') are covered by the "GNU LIBRARY LIBRARY GENERAL PUBLIC LICENSE". See the `mysys/COPYING.LIB' file. 3. Some small parts of the source (GNU `readline') are covered by the "GNU GENERAL PUBLIC LICENSE". See the `readline/COPYING' file. 4. Some parts of the source (the `regexp' library) are covered by a Berkeley style copyright. 5. The other source needed for the *MySQL* server on Unix platforms is covered by the "MySQL FREE PUBLIC LICENSE", which is based on the "Aladdin FREE PUBLIC LICENSE." *Note Public license::. When running *MySQL* on any Microsoft operating system, other licensing applies. *Note Win license:: The following points set forth the philosophy behind our copyright policy: * The SQL client library should be totally free so that it can be included in commercial products without limitations. * People who want free access to the software we have put a lot of work into can have it, so long as they do not try to make money directly by distributing it for profit. * People who want the right to keep their own software proprietary, but also want the value from our work, can pay for the privilege. * That means normal in-house use is FREE. But if you use it for something important to you, you may want to support further development of *MySQL* by purchasing a support contract. When you may distribute *MySQL* commercially without a fee ========================================================== This is a clarification of the information in the "*MySQL* FREE PUBLIC LICENSE" (FPL). *Note Public license::. *MySQL* may be *used* freely, including by commercial entities for evaluation or unsupported internal use. However, *distribution* for commercial purposes of *MySQL*, or anything containing or derived from *MySQL* in whole or in part, requires a written commercial license from TcX AB, the sole entity authorized to grant such licenses. You may not include *MySQL* "free" in a package containing anything for which a charge is being made, except as noted below. The intent of the exception provided in the second clause of the license is to allow commercial organizations operating an FTP server or a bulletin board to distribute *MySQL* freely from it, provided that: 1. The organization complies with the other provisions of the FPL, which include among other things a requirement to distribute the full source code of *MySQL* and of any derived work, and to distribute the FPL itself along with *MySQL*; 2. The only charge for downloading *MySQL* is a charge based on the distribution service and not one based on the content of the information being retrieved (i.e., the charge would be the same for retrieving a random collection of bits of the same size); 3. The server or BBS is accessible to the general public, i.e., the phone number or IP address is not kept secret, and anyone may obtain access to the information (possibly by paying a subscription or access fee that is not dependent on or related to purchasing anything else). If you want to distribute software in a commercial context that incorporates *MySQL* and you do *not* want to meet these conditions, you should contact TcX AB to find out about commercial licensing. Commercial licenses involve a payment, and include support and other benefits. These are the only ways you legally can distribute *MySQL* or anything containing *MySQL*: either by distributing *MySQL* under the requirements of the FPL, or by getting a commercial license from TcX AB. Selling a product that can be configured to use *MySQL* ======================================================= If you want to sell a product that can be configured to use *MySQL* although your customer is responsible for obtaining/installing *MySQL* (or some other supported alternative), does one of you owe us money if your customer chooses to use *MySQL*? If your product REQUIRES *MySQL* to work, you would have to buy a license. If *MySQL* just added some new features, it should fall inside normal use. For example, if using *MySQL* added logging to a database rather than to a text file, it would not require a license. This would, of course, mean that the user bears the responsibility of obtaining and installing *MySQL*. If the program is (almost) useless without *MySQL* you would have to get a *MySQL* license to sell your product. Running a commercial web server using *MySQL* ============================================= If you run a commercial web server that uses *MySQL*, you are not selling *MySQL* itself and need not purchase a license. However, in this case we would like you to purchase *MySQL* support. That is either your support of *MySQL* or our support of you (the latter is more expensive since our time is limited). Selling commercial Perl/Tcl/PHP/etc. applications ================================================= These are the questions you should ask to determine whether or not you need a *MySQL* license when selling your application: Is your application designed for *MySQL* alone? Does it require *MySQL* to function at all? Or is it designed more generally for "a database" and can run under *MySQL*, PostgreSQL, or something else? If you've designed it strictly around *MySQL* then you've really made a commercial product that requires the engine, so you need to buy a license. If, however, you can support any database with a base level of functionality (and you don't rely on anything that only *MySQL* supports) you probably DO NOT have to pay. It also depends on what you're doing for the client. Are you tying into a database you expect to already exist by the time your software is purchased? Then you probably don't have to pay. Or do you plan to distribute *MySQL* or give them detailed instructions on installing it with your software? Then you probably do. One thing I'd like to suggest, folks. Look, development won't last forever if nobody pays. I agree that buying a copy for every software user is prohibitive compared to other products available, but would it not be courtesy for commercial developers to register their OWN copy that they develop with? Possible future changes in the licensing ======================================== We may choose to distribute older versions of *MySQL* with the GPL in the future. However, these versions will be identified as *GNU MySQL*. Also, all copyright notices in the relevant files will be changed to the GPL. Installing *MySQL* ****************** How to get *MySQL* ================== Check the *MySQL* home page (http://www.tcx.se/) for information about the current version and for downloading instructions. However, the Internet connection at TcX is not so fast; we would *prefer* that you do the actual downloading from one of the mirror sites listed below. Please report bad or out of date mirrors to . Europe: * Austria [Univ. of Technology/Vienna] WWW (http://gd.tuwien.ac.at/db/mysql/) FTP (ftp://gd.tuwien.ac.at/db/mysql/) * Bulgaria [Naturella] FTP (ftp://ftp.ntrl.net/pub/mirror/mysql) * Czech Republic [CESNET] WWW (http://mirror.opf.slu.cz/mysql/) * Denmark [Ake] WWW (http://mysql.ake.dk) * Denmark [SunSITE] WWW (http://SunSITE.auc.dk/mysql/) FTP (ftp://SunSITE.auc.dk/pub/databases/mysql/) * Estonia [Tradenet] WWW (http://mysql.tradenet.ee) * Germany [Bonn University, Bonn] WWW (http://www.wipol.uni-bonn.de/MySQL//) FTP (ftp://ftp.wipol.uni-bonn.de/pub/mirror/MySQL/) * Germany [Wolfenbuettel] WWW (http://www.fh-wolfenbuettel.de/ftp/pub/database/mysql/) FTP (ftp://ftp.fh-wolfenbuettel.de/pub/database/mysql/) * Germany [Staufen] WWW (http://mysql.staufen.de/) * Greece [NTUA, Athens] WWW (http://www.ntua.gr/mysql/) FTP (ftp://ftp.ntua.gr/pub/databases/mysql/) * Hungary [Xenia] WWW (http://xenia.sote.hu/ftp/mirrors/www.tcx.se-mysql/) * Israel [Netvision] WWW (http://mysql.netvision.net.il/) * Italy [Matrice] WWW (http://www.matrice.it/risorse/mysql/) * Poland [Sunsite] WWW (http://sunsite.icm.edu.pl/mysql/) FTP (ftp://sunsite.icm.edu.pl/pub/unix/mysql/) * Russia [DirectNet] WWW (http://mysql.directnet.ru) * Russia [Cityline] FTP (ftp://mysql.cityline.ru/pub/mysql) WWW (http://mysql.cityline.ru) * Romania [Timisoara] WWW (http://www.dnttm.ro/mysql) FTP (ftp://ftp.dnttm.ro/pub/mysql) * Romania [Bucharest] WWW (http://www.lbi.ro/MySQL) FTP (ftp://ftp.lbi.ro/mirrors/ftp.tcx.se) * Sweden [Sunet] WWW (http://ftp.sunet.se/pub/unix/databases/relational/mysql/) FTP (ftp://ftp.sunet.se/pub/unix/databases/relational/mysql/) * UK [Omnipotent/UK] WWW (http://mysql.omnipotent.net/) FTP (ftp://mysql.omnipotent.net/) * UK [PLiG/UK] WWW (http://ftp.plig.org/pub/mysql/) FTP (ftp://ftp.plig.org/pub/mysql/) * UK [SunSITE] WWW (http://sunsite.org.uk/packages/mysql/) FTP (ftp://sunsite.org.uk/packages/mysql/) * Ukraine [PACO] WWW (http://mysql.paco.net.ua) FTP (ftp://mysql.paco.net.ua/) North America: * Canada [Polaris Computing] WWW (http://mysql.polaris.ca/) * Canada [Tryc] WWW (http://web.tryc.on.ca/mysql/) * Canada [Cyberus] WWW (http://mysql.cyberus.ca/) FTP (ftp://mysql.cyberus.ca/) * USA [Hurricane Electric/San Jose] WWW (http://mysql.he.net) * USA [Buoy/New York] WWW (http://www.buoy.com/mysql/) * USA [Netcasting/West Coast] FTP (ftp://ftp.netcasting.net/pub/mysql/) * USA [Circle Net/North Carolina] WWW (http://www.mysql.net) * USA [Gina net/Florida] WWW (http://www.gina.net/mysql/) * USA [DIGEX] FTP (ftp://ftp.digex.net/pub/database/mysql/index.html) South America: * Chile [Amerikanclaris] WWW (http://www.labs.amerikanclaris.cl/mysql) FTP (ftp://ftp.amerikanclaris.cl/pub/mysql) Asia: * Korea [KREONet] WWW (http://linux.kreonet.re.kr/mysql/) * Japan [Soft Agency] WWW (http://www.softagency.co.jp/MySQL) * Japan [Nagoya Syouka University] WWW (http://www.happysize.co.jp/mysql/) FTP (ftp://ftp.happysize.co.jp/pub/mysql/) * Japan [HappySize] WWW (http://mirror.nucba.ac.jp/mirror/mysql) FTP (ftp://mirror.nucba.ac.jp/mirror/mysql) * Singapore [Com5 Productions] WWW (http://mysql.com5.net) FTP (ftp://ftp.com5.net/pub/mysql) * Taiwan [NCTU] WWW (http://mysql.taconet.com.tw) Australia: * Australia [AARNet/Queensland] WWW (http://mirror.aarnet.edu.au/mysql) FTP (ftp://mirror.aarnet.edu.au/pub/mysql) * Australia [Tas] WWW (http://ftp.tas.gov.au/mysql) FTP (ftp://ftp.tas.gov.au/pub/mysql) * Australia [Blue Planet/Melbourne] WWW (http://mysql.bluep.com/) FTP (ftp://mysql.bluep.com/pub/mirror1/mysql/) Africa: * South-Africa [The Internet Solution/Johannesburg] FTP (ftp://ftp.is.co.za/linux/mysql/) Operating systems supported by *MySQL* ====================================== 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 and develop the software ourselves primarily on Sun Solaris (versions 2.5 & 2.6) and to a lesser extent on RedHat Linux 5.0. *MySQL* has been reported to compile sucessfully on the following operating system/thread package combinations. Note that for many operating systems, the native thread support works only in the latest versions. * Solaris 2.5, 2.6 and 2.7 with native threads on sparc and x86 * SunOS 4.x with the included MIT-pthreads package * BSDI 2.x with the included MIT-pthreads package * BSDI 3.0 and 3.1 with native threads * SGI IRIX 6.x with native threads * AIX 4.x with native threads * DEC UNIX 4.x with native threads * Linux 2.0+ with LinuxThreads 0.7.1 or `glibc' 2.0.7 * FreeBSD 2.x with the included MIT-pthreads package * FreeBSD 3.x with native threads * SCO OpenServer with a recent port of the FSU-threads package * SCO UnixWare 7.0.1 * NetBSD 1.3 Intel and NetBSD 1.3 Alpha * OpenBSD 2.x with the included MIT-pthreads package * HP-UX 10.20 with the included MIT-pthreads package * Win95 and NT (The newest version is currently available only for users with a *MySQL* license or *MySQL* email support). We have released an older `http://www.tcx.se/mysql_w32.htmy,*MySQL* version (3.21.29) as shareware' for those who like to test before they buy. * OS/2 Which *MySQL* version to use ============================ The first decision to make is whether you want to use the latest development release or the last stable release. Normally if you are beginning to use *MySQL* for the first time or trying to port it to some system for which there is no binary distribution, 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. *Note Benchmarks::. Otherwise, if you are running an old system and want to upgrade, but don't want to take chances with 3.22, you should upgrade to 3.21.33. We have tried to fix only fatal bugs and make small, relatively safe changes in this version. The second decision to make is whether you want to use a source distribution or a binary distribution: * If you want to run *MySQL* on a platform for which a current binary distribution exists, use that. It generally will be easier to install than a source distribution. * If you want to read (and/or modify) the C and C++ code that makes up *MySQL*, you should get a source distribution. The source code is always the ultimate manual. Source distributions also contain more tests and examples than binary distributions. In the *MySQL* naming scheme, release numbers consist of three numbers and a suffix. For example, a release name like `mysql-3.21.17-beta' is interpreted like this: * The first number (`3') describes the file format. All version 3 releases have the same file format. When a version 4 appears, every table will have to be converted to the new format (nice tools for this will be included, of course). * The second number (`21') is the release level. Normally there are two to choose from. One is the release/stable branch and the other is the development branch. Normally both are stable but the development version may have quirks, missing documentation or may fail to compile on some systems. * The third number (`17') is the version number within the release level. This is incremented for each new distribution. Usually you want the latest version for the release level you have choosen. * The suffix (`beta') indicates the stability level of the release: - `alpha' means that some new large code section exists which hasn't been 100% tested. Known bugs should be documented in the News section (usually there are none). *Note News::. There are also new commands and extensions in most alpha releases. - `beta' means that all new code has been tested. No major new things are added. There should be no known bugs. - `gamma' is a beta that has been around a while and seems to work fine. This is what many other companies call a release. - If there is no suffix, it means that the version has been run for a while at many different sites with no reports of bugs other than platform-specific bugs. All versions of *MySQL* are run through our standard tests and benchmarks to ensure that they are relatively safe to use. Since the standard tests are extended over time to check for all previously found bugs, the test suite keeps getting better. Note that all releases have been tested at least with: An internal test suite This is part of a production system for a customer. It has many tables with hundreds of megabytes of data. The *MySQL* benchmark suite This runs a range of common queries. It is also a test to see whether the latest batch of optimizations actually made the code faster. *Note Benchmarks::. The `crash-me' test This tries to determine what features the database supports and what its capabilities and limitations are. *Note Benchmarks::. Another test is that we use the newest *MySQL* version in our internal production environment, on at least one machine. We have more than 100 gigabytes of data to work with. How and when updates are released ================================= Well, *MySQL* is evolving quite rapidly here at TcX and we want to share this with other *MySQL* users. We try to make a release when we have a very useful feature that others seem to have a need for. We also try to help out users who request features that are easy to implement. We also take note on what our licensed users want to have and we especially take notes of what our extended email supported customers want and try to help them out. No one has to download a new release. The News section will tell you if the new release has something you really want. *Note News::. We use the following policy when updating *MySQL*: * For each minor update, the last number in the version string is incremented. When there are major new features or minor incompatibilities with previous versions, the second number in the version string is incremented. When the file format changes, the first number is increased. * Stable tested releases are meant to appear about 1-2 times a year, but if small bugs are found, a release with only bug-fixes will be released. * Working releases are meant to appear about every 1-8 weeks. * Binary distributions for some platforms will be made by us for major releases. Other people may make binary distributions for other systems but probably less frequently. * We usually make patches available as soon as we have located and fixed small bugs. * For non-critical but annoying bugs, we will make patches available if they are sent to us. Otherwise we will combine many of them into a bigger patch. * If there is, by any chance, a fatal bug in a release we will make a new release as soon as possible. We would like other companies to do this, too. :) The 3.21.x version incorporates major portability changes for many different systems. When the 3.21 release is stable, we will remove the alpha/beta suffix and move active development to 3.22. Bugs will still be fixed in the stable version. We don't believe in a complete freeze, as this also leaves out bug fixes and 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". Installation layouts ==================== This section describes the default layout of the directories created by installing binary and source distributions. A binary distribution is installed by unpacking it at the installation location you choose and creates the following directories in the location you choose (typically `/usr/local/mysql'): *Directory* *Contents of directory* `bin' Client programs, the `mysqld' server `data' Log files, databases `scripts' `mysql_install_db' `share' Error message files `sql-bench' Benchmarks A source distribution is installed after you configure and compile it. By default, the installation step installs files under `/usr/local', in the following subdirectories: *Directory* *Contents of directory* `bin' Client programs and scripts `libexec' The `mysqld' server `share' Error message files `sql-bench' Benchmarks `var' Log files, databases The layout of a source installation differs from that of a binary installation in the following ways: * The `mysqld' server is installed in the `/usr/local/libexec' directory rather than in `/usr/local/mysql/bin'. * The data directory is `/usr/local/var' rather than `/usr/local/mysql/data'. * `mysql_install_db' is installed in the `/usr/local/bin' directory rather than in `/usr/local/mysql/scripts'. Installing a *MySQL* binary distribution ======================================== The basic commands you have to do to use a *MySQL* binary distribution are: shell> bin/mysql_install_db shell> bin/safe_mysqld & Here follows a more detailed description: You need the following tools to install a *MySQL* binary distribution: * GNU `gunzip' to uncompress the distribution. * A reasonable `tar' to unpack the distribution. GNU `tar' is known to work. If you run into problems, *PLEASE ALWAYS USE* `mysqlbug' when posting questions to . Even if the problem isn't a bug, `mysqlbug' gathers system information that will help others solve your problem. By not using `mysqlbug', you lessen the likelihood of getting a solution to your problem! You will find `mysqlbug' in the `bin' directory after you unpack the distribution. *Note Bug reports::. To install a binary distribution, follow the steps below, then proceed to *Note Post-installation::, for post-installation setup and testing. 1. Pick the directory under which you want to unpack the distribution, and move into it. In the example below, we unpack the distribution under `/usr/local' and create a directory `/usr/local/mysql' into which *MySQL* is installed. (The following instructions therefore assume you have permission to create files in `/usr/local'. If that directory is protected, you will need to perform the installation as `root'.) 2. Obtain a distribution file from one of the sites listed in *Note Getting MySQL::. *MySQL* binary distributions are provided as compressed `tar' archives and have names like `mysql-VERSION-OS.tar.gz', where `VERSION' is a number (e.g., `3.21.15'), and `OS' indicates the type of operating system for which the distribution is intended (e.g., `pc-linux-gnu-i586'). 3. Unpack the distribution and create the installation directory: shell> gunzip < mysql-VERSION-OS.tar.gz | tar xvf - shell> ln -s mysql-VERSION-OS mysql The first command creates a directory named `mysql-VERSION-OS'. The second command makes a symbolic link to that directory. This lets you refer more easily to the installation directory as `/usr/local/mysql'. 4. Change into the installation directory: shell> cd mysql You will find several files and subdirectories in the `mysql' directory. The most important for installation purposes are the `bin' and `scripts' subdirectories. `bin' This directory contains client programs and the server You should add the full pathname of this directory to your `PATH' environment variable so that your shell finds the *MySQL* programs properly. `scripts' This directory contains the `mysql_install_db' script used to initialize the server access permissions 5. If you would like to use `mysqlaccess' and have the *MySQL* distribution in some nonstandard place, you must change the location where `mysqlaccess' expects to find the `mysql' client. Edit the `bin/mysqlaccess' script at approximately line 18. Search for a line that looks like this: $MYSQL = '/usr/local/bin/mysql'; # path to mysql executable Change the path to reflect the location where `mysql' actually is stored on your system. If you do not do this, you will get a `broken pipe' error when you run `mysqlaccess'. 6. If you want to install support for the Perl `DBI'/`DBD' interface, see *Note Perl-installation::. 7. If you would like *MySQL* to start automatically when you boot your machine, you can copy `bin/mysql.server' to where your system has its startup files. More information can be found in the `bin/mysql.server' script itself, and in *Note Automatic start::. After everything has been unpacked and installed, you should initialize and test your distribution. *Note Post-installation::. Building client programs ------------------------ If you compile *MySQL* clients that you've written yourself or that you obtain from a third party, they must be linked using the `-lmysqlclient' option on the link command. You may also need to specify a `-L' option to tell the linker where to find the library. For example, if the library is installed in `/usr/local/mysql/lib', use `-L/usr/local/mysql/lib -lmysqlclient' on the link command. For clients that use *MySQL* header files, you may need to specify a `-I' option (for example, `-I/usr/local/mysql/include') when you compile them, so the compiler can find the header files. System-specific notes --------------------- The following sections indicate some of the issues that have been observed to occur on particular systems. Linux notes ........... * *MySQL* needs at least Linux 2.0. * The binary release is linked with `-static', which means you need not worry about which version of the system libraries you have. You need not install LinuxThreads, either. A program linked with `-static' is slightly bigger than a dynamically-linked program but also slightly faster (3-5%). The only problem is that you can't use user definable functions (UDFs) with a statically-linked program. If you are going to write or use UDF functions (this is only something for C or C++ programmers) you must compile *MySQL* yourself, using dynamic linking. * The Linux-Intel binary release of *MySQL* is configured for the highest possible speed. We are even using the Pentium compiler, `pgcc'. This compiler is installed under the name `gcc' and the distribution is configured as follows: shell> CC=gcc \ CFLAGS="-O6 -mpentium -mstack-align-double -fomit-frame-pointer" \ CXX=gcc \ CXXFLAGS="-O6 -mpentium -mstack-align-double -fomit-frame-pointer -felide-constructors" \ ./configure \ --prefix=/usr/local/mysql \ --enable-assembler \ --with-mysqld-ldflags=-all-static * *MySQL* Perl support requires Perl 5.004_03 or newer. HP-UX notes ........... 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. The HP 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: * HP 9000/7xx running HP-UX 10.20+ * HP 9000/8xx running HP-UX 10.30 (does not use HP native threads) The following configurations almost definitely won't work: * HP 9000/7xx or 8xx running HP-UX 10.x where x < 2 * HP 9000/7xx or 8xx running HP-UX 9.x To install the distribution, use one of the commands below, where `/path/to/depot' is the full path to the depot file: * To install everything, including the server, client and development tools: /usr/sbin/swinstall -s /path/to/depot mysql.full * To install only the server: /usr/sbin/swinstall -s /path/to/depot mysql.server * To install only the client package: /usr/sbin/swinstall -s /path/to/depot mysql.client * To install only the development tools: /usr/sbin/swinstall -s /path/to/depot mysql.developer The depot places binaries and libraries in `/opt/mysql' and data in `/var/opt/mysql'. The depot also creates the appropriate entries in `/sbin/init.d' and `/sbin/rc2.d' to start the server automatically at boot time. Obviously, this entails being `root' to install. Installing a *MySQL* source distribution ======================================== You need the following tools to build and install *MySQL* from source: * GNU `gunzip' to uncompress the distribution. * A reasonable `tar' to unpack the distribution. GNU `tar' is known to work. * A working ANSI C++ compiler. `gcc' >= 2.8.1, `egcs' >= 1.0.2, SGI C++ and SunPro C++ are some of the compilers that are known to work. `libg++' is not needed when using `gcc'. `gcc' 2.7.x has a bug that makes it impossible to compile some perfectly legal C++ files, such as `sql/sql_base.cc'. If you only have `gcc' 2.7.x, you must upgrade your `gcc' to be able to compile *MySQL*. * A good `make' program. GNU `make' is always recommended and is sometimes required. If you have problems, we recommend trying GNU `make' 3.75 or newer. If you run into problems, *PLEASE ALWAYS USE `mysqlbug'* when posting questions to . Even if the problem isn't a bug, `mysqlbug' gathers system information that will help others solve your problem. By not using `mysqlbug', you lessen the likelihood of getting a solution to your problem! You will find `mysqlbug' in the `scripts' directory after you unpack the distribution. *Note Bug reports::. Quick installation overview --------------------------- The basic commands you have to do to install *MySQL* from source are: shell> configure --prefix=/usr/local/mysql shell> make shell> make install shell> scripts/mysql_install_db shell> /usr/local/mysql/bin/safe_mysqld & Here follows a more detailed description: To install a source distribution, follow the steps below, then proceed to *Note Post-installation::, for post-installation initialization and testing. 1. Pick the directory under which you want to unpack the distribution, and move into it. 2. Obtain a distribution file from one of the sites listed in *Note Getting MySQL::. *MySQL* source distributions are provided as compressed `tar' archives and have names like `mysql-VERSION.tar.gz', where `VERSION' is a number like 3.22.14-gamma. 3. Unpack the distribution into the current directory: shell> gunzip < mysql-VERSION.tar.gz | tar xvf - This command creates a directory named `mysql-VERSION'. 4. Change into the top-level directory of the unpacked distribution: shell> cd mysql-VERSION 5. Configure the release and compile everything: shell> ./configure shell> make When you run `configure', you might want to specify some options. Run `./configure --help' for a list of options. *Note `configure' options: configure options, discusses some of the more useful options. If `configure' fails, and you are going to send mail to to ask for assistance, please include any lines from `config.log' that you think can help solve the problem. Also include the last couple of lines of output from `configure' if `configure' aborts. Post the bug report using the `mysqlbug' script. *Note Bug reports::. If the compile fails, see *Note Compilation problems::, for help with a number of common problems. 6. Install everything: shell> make install You might need to run this command as `root'. 7. Create the *MySQL* grant tables shell> scripts/mysql_install_db 8. If you want to install support for the Perl `DBI'/`DBD' interface, see *Note Perl-installation::. 9. If you would like *MySQL* to start automatically when you boot your machine, you can copy `support-files/mysql.server' to where your system has its startup files. More information can be found in the `support-files/mysql.server' script itself, and in *Note Automatic start::. After everything has been installed, you should initialize and test your distribution. You can start the *MySQL* server with: shell> cd mysql-install-directory shell> bin/safe_mysqld & Note that *MySQL* versions before 3.22.10 started the *MySQL* server when you run `mysql_install_db'. This is no longer true! *Note Post-installation::. Applying patches ---------------- Sometimes patches appear on the mailing list. To apply a patch, change into the top-level directory of your *MySQL* source tree and run these commands: shell> gunzip < patch-file-name.gz | patch -p1 shell> rm config.cache shell> make clean Then follow the instructions for a normal source install, beginning with the `./configure' step. After running the `make install' step, restart your *MySQL* server. You may need to bring down any currently running server before you run `make install'. Some systems do not allow you to install a new version of a program if it replaces the version that is currently executing. Typical `configure' options --------------------------- The `configure' script gives you a great deal of control over how you configure your *MySQL* distribution. Typically you do this using options on the `configure' command line. You can also affect `configure' using certain environment variables. For a list of options supported by `configure', run this command: shell> ./configure --help Some of the more commonly-used `configure' options are described below: * To compile just the *MySQL* client libraries and client programs, use the `--without-server' option: shell> ./configure --without-server If you don't have a C++ compiler, `mysql' will not compile (it is the one client program that requires C++). In this case, you can remove the code in `configure' that tests for the C++ compiler and then run `./configure' with the `--without-server' option. The compile step will still try to build `mysql', but you can ignore any warnings about `mysql.cc'. (If `make' stops, try `make -k' to tell it to continue with the rest of the build even if errors occur.) * If you don't want your log files and database directories located under `/usr/local/var', use a `configure' command something like one of these: shell> ./configure --prefix=/usr/local/mysql shell> ./configure --prefix=/usr/local \ --localstatedir=/usr/local/mysql/data The first command changes the installation prefix so that everything is installed under `/usr/local/mysql' rather than the default of `/usr/local'. The second command preserves the default installation prefix, but overrides the default location for database directories (normally `/usr/local/var') and changes it to `/usr/local/mysql/data'. * If you want your sockets located somewhere other than the default location (normally `/tmp' or `/var/run'), use a `configure' command like this: shell> ./configure --with-unix-socket-path=/path/to/socket/dir `/path/to/socket/dir' must be an absolute pathname. * If you want to compile statically-linked programs (e.g., to make a binary distribution, to get more speed or to work around problems with some RedHat distributions), run `configure' like this: shell> ./configure --with-client-ldflags=-all-static \ --with-mysqld-ldflags=-all-static * If you are using `gcc' and don't have `libg++' or `libstdc++' installed, you can tell `configure' to use `gcc' as your C++ compiler: shell> CC=gcc CXX=gcc ./configure When you use `gcc' as your C++ compiler, it will not attempt to link in `libg++' or `libstdc++'. If you get errors that your compiler or linker can't create the shared library `libmysqlclient.so.#' you can work around this problem by giving the `--disable-shared' option to `configure'. In this case, `configure' will not build a shared `libmysqlclient.so.#' library. * You can configure *MySQL* not to use `DEFAULT' column values for non-`NULL' columns (i.e., columns that are not allowed to be `NULL'). This causes `INSERT' statements to generate an error unless you explicitly specify values for all columns that require a non-`NULL' value. To suppress use of default values, run `configure' like this: shell> CXXFLAGS=-DDONT_USE_DEFAULT_FIELDS ./configure * By default, *MySQL* uses the ISO-8859-1 (Latin1) character set. To change the default set, use the `--with-charset' option: shell> ./configure --with-charset=CHARSET `CHARSET' may be one of `big5', `czech', `danish', `dec8', `dos', `german1', `hebrew', `hp8', `hungarian', `koi8_ru', `ru', `latin1', `latin2', `sjis', `swe7', `tis620', `ujis', `usa7' or `win1251'. *Note Character sets::. Note that if you want to change the character set, you must do a `make distclean' between configurations ! If you want to convert characters between the server and the client, you should take a look at the `SET OPTION CHARACTER SET' command. *Note Set option::. *Warning:* If you change character sets after having created any tables, you will have to run `isamchk -r -q' on every table. Your indexes may be sorted incorrectly otherwise. (This can happen if you install *MySQL*, create some tables, the reconfigure *MySQL* using a different character set and reinstall it.) * To configure *MySQL* with debugging code, use the `--with-debug' option: shell> ./configure --with-debug This causes a safe memory allocator to be included that can find some errors and that provides output about what is happening. * Options that pertain to particular systems can be found in the system-specific sections later in this chapter. *Note System-specifics::. Problems compiling? =================== All *MySQL* programs compile cleanly for us with no warnings on Solaris using `gcc'. On other systems, warnings may occur due to differences in system include files. See *Note MIT-pthreads::, for warnings that may occur when using MIT-pthreads. For other problems, check the list below. The solution to many problems involves reconfiguring. If you do need to reconfigure, take note of the following: * If `configure' is run after it already has been run, it may use information that was gathered during its previous invocation. This information is stored in `config.cache'; when `configure' starts up, it looks for that file and reads its contents if it exists, on the assumption that the information is still correct. That assumption is invalid when you reconfigure. * Each time you run `configure', you must run `make' again to recompile. However, you may want to remove old object files from previous builds first, since they were compiled using different configuration options. To prevent old configuration information or object files from being used, run these commands before rerunning `configure': shell> rm config.cache shell> make clean Alternatively, you can run `make distclean'. The list below describes some of the problems compiling *MySQL* that have been found to occur most often: * If you get errors when compiling `sql_yacc.cc' such as the ones shown below, you have probably run out of memory or swap space: Internal compiler error: program cc1plus got fatal signal 11 or Out of virtual memory or Virtual memory exhausted The problem is that `gcc' requires huge amounts of memory to compile `sql_yacc.cc' with inline functions. Try running `configure' with the `--with-low-memory' option: shell> ./configure --with-low-memory This option causes `-fno-inline' to be added to the compile line if you are using `gcc' and `-O0' if you are using something else. You should try the `--with-low-memory' option even if you have so much memory and swap space that you think you can't possibly have run out. This problem has been known to occur even on systems with generous hardware configurations, and the `--with-low-memory' option usually fixes it. * By default, `configure' picks `c++' as the compiler name and GNU `c++' links with `-lg++'. If you are using `gcc', this can cause problems during configuration such as this: configure: error: installation or configuration problem: C++ compiler cannot create executables. You might also observe problems during compilation related to `g++', `libg++' or `libstdc++'. One cause of these problems is that you may not have `g++', or you may have `g++' but not `libg++' or `libstdc++'. The `config.log' contains the exact reason why your c++ compiler didn't work! To work around these problems, you can use `gcc' as your C++ compiler. Try setting the environment variable `CXX' to `"gcc -O3"'. For example: shell> CXX="gcc -O3" ./configure This works because `gcc' compiles C++ sources as well as `g++' does, but does not link in `libg++' or `libstdc++' by default. Another way to fix these problems, of course, is to install `g++', `libg++' and `libstdc++'. * If your compile fails with either of the following errors, you have to upgrade your version of `make' to GNU `make': making all in mit-pthreads make: Fatal error in reader: Makefile, line 18: Badly formed macro assignment or make: file `Makefile' line 18: Must be a separator (: * If your `make' stops with this error, you should try using GNU `make': Can't find Makefile.PL Solaris and FreeBSD are known to have troublesome `make' programs. * If you get error messages from `make' or error messages like this, you have to upgrade your `make' to GNU `make': pthread.h: No such file or directory GNU `make' version 3.75 is known to work. * If you want to define flags to be used by your C or C++ compilers, do so by adding the flags to the `CFLAGS' and `CXXFLAGS' environment variables. You can also specify the compiler names this way using `CC' and `CXX'. For example: shell> CC=gcc shell> CFLAGS=-O6 shell> CXX=gcc shell> CXXFLAGS=-O6 shell> export CC CFLAGS CXX CXXFLAGS See *Note TcX binaries::, for a list of flag definitions that have been found to be useful on various systems. * If you get an error message like this, you need to upgrade your `gcc' compiler: client/libmysql.c:273: parse error before `__attribute__' `gcc' 2.8.1 is known to work, but we recommend using `egcs' 1.0.3a or newer instead. * If you get errors when compiling `mysqld' that look like this, `configure' didn't correctly detect the type of the last argument to `accept()', `getsockname()' or `getpeername()': 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); To fix this, edit the `config.h' file (which is generated by `configure'). Look for these lines: /* Define as the base type of the last arg to accept */ #define SOCKET_SIZE_TYPE XXX Change `XXX' to `size_t' or `int', depending on your operating system. (Note that you will have to do this each time you run `configure', since `configure' regenerates `config.h'.) * The `sql_yacc.cc' file is generated from `sql_yacc.yy'. Normally you don't need to generate `sql_yacc.cc' yourself, since *MySQL* comes with an already-generated copy. However, if you do need to recreate it, you might encounter this error: "sql_yacc.yy", line xxx fatal: default action causes potential... This is a sign that your version of `yacc' is deficient. You probably need to install `bison' (the GNU version of `yacc') and use that instead. * If you need to debug `mysqld' or a *MySQL* client, run `configure' with the `--with-debug' option, then recompile and link your clients with the new client library. Before running a client, you should set the `MYSQL_DEBUG' environment variable: shell> MYSQL_DEBUG=d:t:O,/tmp/client.trace shell> export MYSQL_DEBUG This causes clients to generate a trace file in `/tmp/client.trace'. * If you have problems with your own client code, you should attempt to connect to the server and run your query using a client that is known to work. Do this by running `mysql' in debugging mode: shell> mysql --debug=d:t:O,/tmp/client.trace This will provide useful information in case you mail a bug report. *Note Bug reports::. MIT-pthreads notes ================== This section describes some of the issues involved in using MIT-pthreads. If your system does not provide native thread support, you will need to build *MySQL* using the MIT-pthreads package. This includes most FreeBSD systems, SunOS 4.x, Solaris 2.4 and earlier, and some others. *Note Which OS::. * On most systems, you can force MIT-pthreads to be used by running `configure' with the `--with-mit-threads' option: shell> ./configure --with-mit-threads Building in a non-source directory is not supported when using MIT-pthreads, because we want to minimize our changes to this code. * MIT-pthreads doesn't support the `AF_UNIX' protocol used to implement Unix sockets. This means that if you compile using MIT-pthreads, all connections must be made using TCP/IP (which is a little slower). If you find after building *MySQL* that you cannot connect to the local server, it may be that your client is attempting to connect to `localhost' using a Unix socket as the default. Try making a TCP/IP connection by using `mysql' with a host option (`-h' or `--host') to specify the local host name explicitly. * The checks that determine whether or not to use MIT-pthreads occur only during the part of the configuration process that deals with the server code. If you have configured the distribution using `--without-server' to build only the client code, clients will not know whether or not MIT-pthreads is being used and will use Unix socket connections by default. Since Unix sockets do not work under MIT-pthreads, you will also need to use `-h' or `--host' in such instances. * When *MySQL* is compiled using MIT-pthreads, system locking is disabled by default for performance reasons. You can tell the server to use system locking with the `--use-locking' option. * Sometimes (at least on Solaris) the pthread `bind()' command fails to bind to a socket without any error message. The result is that all connections to the server fail. For example: shell> mysqladmin version 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' server and restart it. This has only happened to us when we have forced the server down and done a restart immediately. * With MIT-pthreads, the `sleep()' system call isn't interruptible with `SIGINT' (break). This is only noticeable when you run `mysqladmin --sleep'. You must wait for the `sleep()' call to terminate before the interrupt is served and the process stops. * When linking (at least on Solaris) you will receive warning messages like these; they can be ignored: 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 also can be ignored: implicit declaration of function `int strtoll(...)' implicit declaration of function `int strtoul(...)' * We haven't gotten `readline' to work with MIT-pthreads. (This isn't needed, but may be interesting for someone.) Perl installation comments ========================== *MySQL* support for the Perl `DBI'/`DBD' interface is distributed separately from the main *MySQL* distribution, as of release 3.22.8. If you want to install Perl support, check `http://www.tcx.se/Contrib' for the files you will need. The Perl client code for the `DBD'/`DBI' interface requires Perl 5.004 or later. The interface *will not work* if you have an older version of Perl. The Perl distributions are provided as compressed `tar' archives and have names like `MODULE-VERSION.tar.gz', where `MODULE' is the module name and `VERSION' is the version number. You should get the `Data-Dumper', `DBI', and `Msql-Mysql-modules' archives. Once you have them, install them using the procedure shown below. The example shown below is for the `Data-Dumper' module, but the procedure is the same for all three modules. 1. Unpack the distribution into the current directory: shell> gunzip < Data-Dumper-VERSION.tar.gz | tar xvf - This command creates a directory named `Data-Dumper-VERSION'. 2. Change into the top-level directory of the unpacked distribution: shell> cd Data-Dumper-VERSION 3. Build the distribution and compile everything: shell> perl Makefile.PL shell> make shell> make test shell> make install After you've installed the three modules, run `make test' in the `Msql-Mysql-modules' directory to exercise the interface code. (The server must be running for this to work.) Problems using the Perl `DBI'/`DBD' interface --------------------------------------------- If perl reports that it can't find the `../mysql/mysql.so' module, then the problem is probably that perl can't locate the shared library `libmysqlclient.so'. You can fix this by any of the following methods: bullet Compile the Msql-MySQL modules with: `perl Makefile.PL -static' instead of `perl Makefile.PL' bullet Copy `libmysqlclient.so' to the library where your other shared libraries are (probably `/usr/lib' or `/lib'). bullet On `Linux' you can add the path to the directory, where you have `libmysqlclient.so', to `/etc/ld.so.conf'. bullet Add the path to `libmysqlclient.so' to the `LD_RUN_PATH' environment variable. If you get the following errors from `DBD-mysql', you are probably using `gcc' (or using an old binary compiled with `gcc'): /usr/bin/perl: can't resolve symbol '__moddi3' /usr/bin/perl: can't resolve symbol '__divdi3' Add `-L/usr/lib/gcc-lib/... -lgcc' to the link command when the `mysql.so' library gets built (check the output from `make' for `mysql.so' when you compile the Perl client). The `-L' option should specify the path to the directory where `libgcc.a' is located on your system. Another cause of this problem may be that Perl and *MySQL* aren't both compiled with `gcc'. In this case, you can solve the mismatch by compiling both with `gcc'. If you want to use the Perl module on a system that doesn't support dynamic linking (like SCO) you can generate a static version of Perl that includes `DBI' and `DBD-mysql'. The way this works is that you generate a version of Perl with the `DBI' code linked in and install it on top of your current Perl. Then you use that to build a version of Perl that additionally has the `DBD' code linked in, and install that. On SCO, you must have the following environment variables set: 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: First, you create a Perl that includes a statically-linked `DBI' by running these commands in the `perl/DBI' directory: shell> perl Makefile.PL LINKTYPE=static shell> make shell> make install shell> make perl After this you must install the new Perl. The output of `make perl' will indicate the exact `make' command you will need to execute to perform the installation. On SCO, this is `make -f Makefile.aperl inst_perl MAP_TARGET=perl'. Next you create Perl that includes a statically-linked `DBD::mysql' by running these commands in the `perl/Mysql-modules' directory: shell> perl Makefile.PL LINKTYPE=static shell> make shell> make install shell> make perl You should also install this new Perl. Again, the output of `make perl' indicates the command to use. System-specific notes ===================== The following sections indicate some of the issues that have been observed to occur on particular systems. Solaris notes ------------- On Solaris, you may run into trouble even before you get the *MySQL* distribution unpacked! Solaris `tar' can't handle long file names, so you may see an error like this when you unpack *MySQL*: 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 In this case, you must use GNU `tar' (`gtar') to unpack the distribution. You can find a precompiled copy for Solaris at `http://www.tcx.se/Downloads/'. Sun native threads work only on Solaris 2.5 and higher. For 2.4 and earlier versions, *MySQL* will automaticly use MIT-pthreads. *Note MIT-pthreads::. If you have the Sun Workshop 4.2 compiler, you can run `configure' like this: shell> CC=cc CFLAGS="-Xa -fast -xstrconst -mt" \ CXX=CC CXXFLAGS="-xsb -noex -fast -mt" \ ./configure You may also have to edit the `configure' script to change this line: #if !defined(__STDC__) || __STDC__ != 1 to this: #if !defined(__STDC__) If you turn on `__STDC__' with the `-Xc' option, the Sun compiler can't compile with the Solaris `pthread.h' header file. This is a Sun bug (broken compiler or broken include file). If `mysqld' issues the error message shown below when you run it, you have tried to compile *MySQL* with the Sun compiler without enabling the multi-thread option `-mt': libc internal error: _rmutex_unlock: rmutex not held Add `-mt' to `CFLAGS' and `CXXFLAGS' and try again. If you get the following error when compiling *MySQL* with `gcc', it means that your `gcc' is not configured for your version of Solaris! 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' The proper thing to do in this case is to get the newest version of `egcs' or `gcc' and compile it with your current `gcc' compiler! At least for Solaris 2.5, almost all binary versions of `gcc' have old, unusable include files that will break all programs that use threads (and possibly other programs)! Note that `gcc' 2.8.1 has a couple on bugs on Sparc platforms! On Sparc, we recommend you use `egcs' 1.0.3a. If you are using `egcs' 1.1 or `egcs' 1.1.1 you MUST compile *MySQL* with `-O1' as higher optimization levels produces wrong code. The recommended `configure' line when using `egcs' 1.1 or `egcs' 1.1.1 is: shell> CC=gcc CFLAGS="-O1" \ CXX=gcc CXXFLAGS="-O1 -felide-constructors -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql --with-low-memory As Solaris doesn't provide static versions of all system libraries (`libpthreads' and `libdl'), you can't compile *MySQL* with `--static'. If you try to do this, you will get the error: ld: fatal: library -ldl: not found Solaris 2.7 has some bugs in the include files. If you get the following error when you use `gcc': /usr/include/widec.h:42: warning: `getwc' redefined /usr/include/wchar.h:326: warning: this is the location of the previous definition You can do the following to avoid this: `copy /usr/include/widec.h to .../lib/gcc-lib/os/gcc-version/include' and change row 41 from: #if !defined(lint) && !defined(__lint) to #if !defined(lint) && !defined(__lint) && !defined(getwc) You can of course edit `/usr/include/widec.h' directly. After this you should remove `config.cache' and run `configure' again! If too many processes try to connect very rapidly to `mysqld', you will see this error in the *MySQL* log: Error in accept: Protocol error You might try starting the server with the `--set-variable back_log=50' option as a workaround for this. If you are linking your own *MySQL* client and get the error: ld.so.1: ./my: fatal: libmysqlclient.so.#: open failed: No such file or directory when executing them, the problem can be avoided by one of the following methods: * Link the client with the following flag (instead of `-Lpath'): `-Wl,r/path-libmysqlclient.so' * Copy `libmysqclient.so' to `/usr/lib' * Set the `LD_RUN_PATH' environment to the path to `libmysqlclient.so' before running your client. Solarix x86 notes ----------------- If you are using `gcc' or `egcs' on Solaris x86 and you experience problems with core dumps under load, you should use the following `configure' command: shell> CC=gcc CFLAGS="-O6 -fomit-frame-pointer" \ CXX=gcc \ CXXFLAGS="-O6 -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql This will avoid problems with the `libstdc++' library and with C++ exceptions. If this doesn't help, you should compile a debug version and run this with a trace file or under `gdb'. *Note Debugging::. SunOS 4 notes ------------- On SunOS 4, MIT-pthreads is needed. This in turn means you will need GNU `make' to compile *MySQL*. Some SunOS 4 systems have problems with dynamic libraries and `libtool'. You can use the following `configure' line to avoid this problem. ./configure --disable-shared --with-mysqld-ldflags=-all-static When compiling `readline', you may get warnings about duplicate defines. These may be ignored. When compiling `mysqld', there will be some `implicit declaration of function' warnings. These may be ignored. Linux notes (all Linux versions) -------------------------------- If you can't start `mysqld' or if `mysql_install_db' doesn't work, please continue reading! This only happens on Linux system with problems in the LinuxThreads or `libc'/`glibc' libraries. There are a lot of simple workarounds to get *MySQL* to work! The simplest is to use the binary version of *MySQL* (not the RPM) for Linux x86; One nice aspect of this version is that it's probably 10% faster than any version you would compile yourself! *Note Compile and link options::. `isamchk' hangs with `libc.so.5.3.12'. Upgrading to the newest `libc' fixes this problem. When using LinuxThreads you will see a minimum of three processes running. These are in fact threads. There will be one thread for the LinuxThreads manager, one thread to handle connections, and one thread to handle alarms and signals. If you are using LinuxThreads and `mysqladmin shutdown' doesn't work, you have to upgrade to LinuxThreads 0.7.1 or newer. If you are using RedHat, you might get errors like this: /usr/bin/perl is needed... /usr/sh is needed... /usr/sh is needed... If so, you should upgrade your version of `rpm' to `rpm-2.4.11-1.i386.rpm' and `rpm-devel-2.4.11-1.i386.rpm' (or later). You can get the upgrades of libraries to RedHat 4.2 from `ftp://ftp.redhat.com/updates/4.2/i386'. Or `http://www.sunsite.unc.edu/pub/Linux/distributions/redhat/code/rpm/' for other distributions. If you are linking an own *MySQL* client and get the error: ld.so.1: ./my: fatal: libmysqlclient.so.4: open failed: No such file or directory when executing them, the problem can be avoided by one of the following methods: * Link the client with the following flag (instead of `-Lpath'): `-Wl,r/path-libmysqlclient.so' * Copy `libmysqclient.so' to `/usr/lib' * Set the `LD_RUN_PATH' environment to the path to `libmysqlclient.so' before running your client. Linux-x86 notes ............... LinuxThreads should be installed before configuring *MySQL*! *MySQL* requires `libc' version 5.4.12 or newer. It's known to work with `libc' 5.4.46. `glibc' version 2.0.6 and later should also work. There have been some problems with the `glibc' RPMs from RedHat so if you have problems, check whether or not there are any updates! The `glibc' 2.0.7-19 RPM is known to work. On some older Linux distributions, `configure' may produce an error like this: 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 message says and add an extra underscore to the `_P' macro that has only one underscore, then try again. You may get some warnings when compiling; those shown below 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' In Debian GNU/Linux, if you want *MySQL* to start automatically when the system boots, do the following: shell> cp mysql.server /etc/init.d/mysql.server shell> /usr/sbin/update-rc.d mysql.server defaults 99 `mysql.server' can be found in the `share/mysql' directory under the *MySQL* installation directory, or in the `support-files' directory of the *MySQL* source tree. If `mysqld' always core dumps when it starts up, the problem may be that you have an old `/lib/libc.a'. Try renaming it, then remove `sql/mysqld' and do a new `make install' and try again. This problem has been reported on some Slackware installations. RedHat 5.0 has also a similar problem with some new `glibc' versions. *Note Linux-RedHat50::. If you get the following error when linking `mysqld', it means that your `libg++.a' is not installed correctly: /usr/lib/libc.a(putc.o): In function `_IO_putc': putc.o(.text+0x0): multiple definition of `_IO_putc' You can avoid using `libg++.a' by running `configure' like this: shell> CXX=gcc ./configure RedHat 5.0 notes ................ If you have any problems with *MySQL* on RedHat, you should start by upgrading `glibc' to the newest possible version! If you install all the official RedHat patches (including `glibc-2.0.7-19' and `glibc-devel-2.0.7-19'), both the binary and source distributions of *MySQL* should work without any trouble! 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 a statically-linked *MySQL* binary distribution. If you want to compile from source, you must install the corrected version of LinuxThreads from `http://www.tcx.se/Downloads/Linux' or upgrade your `glibc'. If you have an incorrect version of `glibc' or LinuxThreads, the symptom is that `mysqld' crashes after each connection. For example, `mysqladmin version' will crash `mysqld' when it finishes! Another symptom of incorrect libraries is that `mysqld' crashes at once when it starts. On some Linux systems, this can be fixed by configuring like this: shell> ./configure --with-mysqld-ldflags=-all-static On Redhat 5.0, the easy way out is to install the `glibc' 2.0.7-19 RPM and run `configure' *without* the `--with-mysqld-ldflags=-all-static' option. For the source distribution of `glibc' 2.0.7, a patch that is easy to apply and is tested with *MySQL* may be found at `http://www.tcx.se/Download/Linux/glibc-2.0.7-total-patch.tar.gz'. If you experience crashes like these when you build *MySQL*, you can always download the newest binary version of *MySQL*. This is statically-linked to avoid library conflicts and should work on all Linux systems! *MySQL* comes with an internal debugger that can generate trace files with a lot of information that can be used to find and solve a wide range of different problems. *Note Debugging::. RedHat 5.1 notes ................ The `glibc' of RedHat 5.1 (`glibc' 2.0.7-13) has a memory leak, so to get a stable *MySQL* version, you must upgrade `glibc' to 2.0.7-19, downgrade `glibc' or use a binary version of `mysqld'. If you don't do this, you will encounter memory problems (out of memory, etc., etc.). The most common error in this case is: Can't create a new thread (errno 11). If you are not out of available memory, you can consult the manual for any possible OS dependent bug After you have upgraded to `glibc' 2.0.7-19, you can configure *MySQL* with dynamic linking (the default), but you *cannot* run `configure' with the `--with-mysqld-ldflags=-all-static' option until you have installed `glibc' 2.0.7-19 from source! You can check which version of `glibc' you have with `rpm -q glibc'. Linux-Sparc notes ................. In some implementations, `readdir_r()' is broken. The symptom is that `SHOW DATABASES' always returns an empty set. This can be fixed by removing `HAVE_READDIR_R' from `config.h' after configuring and before compiling. 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' (a version of Linux that was never merged with the official 2.0.30). You must also install LinuxThreads 0.6 or newer. Thanks to for this information. Linux-Alpha notes ................. The first problem is LinuxThreads. The RedHat distribution uses an old (broken) LinuxThreads version, so you must patch LinuxThreads for Alpha. Use the following procedure: 1. Obtain the `glibc2.5c' source from any GNU FTP site. 2. Get the file `ftp://www.tcx.se/pub/mysql/linux/patched-glibc-linuxthreads-0.6.tar.gz'. This includes a fixed `.c' file. Copy this to the `glibc' `./linuxthreads' directory. 3. Configure and compile `glibc' (You have to read the manual how to do this together with LinuxThreads), but don't install it! 4. In the `/usr/lib' directory, rename your old version of `libpthread.a' to `libpthread.a-old'. 5. Copy the file `glibc.../linuxthreads/libpthread.a' to `/usr/lib'. 6. Configure *MySQL* with the following command: shell> CC=gcc CCFLAGS="-Dalpha_linux_port" \ CXX=gcc CXXFLAGS="-O3 -Dalpha_linux_port" \ ./configure --prefix=/usr/local/mysql 7. Try to compile `mysys/thr_lock' and `mysys/thr_alarm'. Test that these programs work! (Invoke each one with no arguments. Each should end with `test_succeeded' if everything was okay.) 8. Recompile `mysqld'. Note that Linux-Alpha is still an alpha-quality platform for *MySQL*. With RedHat 5.0 and the patched LinuxThreads, you have a very good chance of it working. If you have problems with signals (*MySQL* dies unexpectedly under high load) you may have found an OS bug with threads and signals. In this case you can tell *MySQL* not to use signals by configuring with: shell> CFLAGS=-DDONT_USE_THR_ALARM CXXFLAGS=-DDONT_USE_THR_ALARM ./configure ... This doesn't affect the performance of *MySQL*, but has the side effect that you can't kill clients that are "sleeping" on a connection with `mysqladmin kill' or `mysqladmin shutdown'. The client will instead die when it issues its next command. MkLinux notes ............. *MySQL* should work on MkLinux with the newest `glibc' package (tested with `glibc' 2.0.7). Linux RPM notes --------------- The recommended way to install *MySQL* on linux is by a RPM. The *MySQL* RPMS is currently being build on a RedHat 5.1 system but should work on other versions of Linux that supports RPM as well. * MySQL-VERSION.i386.rpm The *MySQL* server. Unless you only want to connect to another *MySQL* server running on another machice yo will need this. * MySQL-client-VERSION.i386.rpm