MySQL Forums
Forum List  »  Announcements

MySQL 6.0.4 Alpha has been released!
Posted by: Daniel Fischer
Date: March 07, 2008 05:41PM

Dear MySQL users,

MySQL 6.0.4-alpha, a new version of the MySQL database system including
the Falcon transactional storage engine (now at beta stage), has been released. The main page for MySQL 6.0 is at:

http://www.mysql.com/mysql60/

If you are new to the Falcon storage engine and need more information,
please read the Falcon Evaluation Guide at:

http://www.mysql.com/why-mysql/white-papers/falcon-getting-started.php

and the Falcon White Paper at:

http://www.mysql.com/why-mysql/white-papers/storage-engines-falcon.php

MySQL 6.0.4-alpha is available in source and binary form for a number
of platforms from our download pages at

http://dev.mysql.com/downloads/mysql/6.0.html

and mirror sites. Note that not all mirror sites may be up to date at
this point in time, so if you can't find this version on some mirror,
please try again later or choose another download site.

We welcome and appreciate your feedback, bug reports, bug fixes,
patches etc.:

http://forge.mysql.com/wiki/Contributing

The following section lists the changes since the last released version
of MySQL 6.0. It can also be viewed online at

http://dev.mysql.com/doc/refman/6.0/en/news-6-0-4.html

Changes since the last release:

Functionality added or changed:
* Important Change: Partitioning: Security Fix: It was possible,
by creating a partitioned table using the DATA DIRECTORY and
INDEX DIRECTORY options to gain privileges on other tables
having the same name as the partitioned table. As a result of
this fix, any table-level DATA DIRECTORY or INDEX DIRECTORY
options are now ignored for partitioned tables.
(Bug#32091: http://bugs.mysql.com/32091, CVE-2007-5970
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5970))
See also Bug#29325: http://bugs.mysql.com/29325,
Bug#32111: http://bugs.mysql.com/32111
* Incompatible Change: The Unicode implementation has been
extended to provide support for supplementary characters that
lie outside the Basic Multilingual Plane (BMP). Noteworthy
features:
+ utf16 and utf32 character sets have been added. These
correspond to the UTF-16 and UTF-32 encodings of the
Unicode character set, and they both support
supplementary characters.
+ The utf8 character set from previous versions of MySQL
has been renamed to utf8mb3, to reflect that its encoding
uses a maximum of three bytes for multi-byte characters.
(Old tables that previously used utf8 will be reported as
using utf8mb3 after an in-place upgrade to MySQL 6.0, but
otherwise work as before.)
+ The new utf8 character set in MySQL 6.0 is similar to
utf8mb3, but its encoding allows up to four bytes per
character to enable support for supplementary characters.
+ The ucs2 character set is essentially unchanged except
for the inclusion of some newer BMP characters.
In most respects, upgrading from MySQL 5.1 to 6.0 should
present few problems with regard to Unicode usage, although
there are some potential areas of incompatibility. Some
examples:
+ For the variable-length character data types (VARCHAR and
the TEXT types), the maximum length in characters for
utf8 columns is less in MySQL 6.0 than previously.
+ For all character data types (CHAR, VARCHAR, and the TEXT
types), the maximum number of characters for utf8 columns
that can be indexed is less in MySQL 6.0 than previously.
Consequently, if you want to upgrade tables from the old utf8
(now utf8mb3) to the current utf8, it may be necessary to
change some column or index definitions.
For additional details about the new Unicode character sets
and potential incompatibilities, see Section 9.1.8, "Unicode
Support," and Section 9.1.9, "Upgrading from Previous to
Current Unicode Support."
If you use events, a known issue is that if you upgrade from
MySQL 5.1 to 6.0.4, the event scheduler will not work, even
after you run mysql_upgrade. (This is an issue only for an
upgrade, not for a new installation of MySQL 6.0.4.) To work
around this upgrading problem, use these instructions:
1. In MySQL 5.1, before upgrading, create a dump file
containing your mysql.event table:
shell> mysqldump -uroot -p mysql event > event.sql
2. Stop the server, upgrade to MySQL 6.0, and start the
server.
3. Recreate the mysql.event table using the dump file:
shell> mysql -uroot -p mysql < event.sql
4. Run mysql_upgrade to upgrade the other system tables in
the mysql database:
shell> mysql_upgrade -uroot -p
5. Restart the server. The event scheduler should run
normally.
* Incompatible Change: Because of a change in the format of the
Falcon pages stored within Falcon database files, Falcon
databases created in MySQL 6.0.4 (or later) are not compatible
with previous releases, and existing Falcon databases are
incompatible with MySQL 6.0.4 (and later versions. You should
dump Falcon databases using mysqldump before upgrading, and
then reload them after the upgrade. For more information, see
Section 4.5.4, "mysqldump --- A Database Backup Program."
* Partitioning: Error messages for partitioning syntax errors
have been made more descriptive.
(Bug#29368: http://bugs.mysql.com/29368)
* Replication: Replication of the following now switches to
row-based logging in MIXED mode, and generates a warning in
STATEMENT mode:
+ USER()
+ CURRENT_USER()
+ CURRENT_USER
+ FOUND_ROWS()
+ ROW_COUNT()
See Section 5.2.4.3, "Mixed Binary Logging (MBL) Format," for
more information. (Bug#12092: http://bugs.mysql.com/12092,
Bug#28086: http://bugs.mysql.com/28086,
Bug#30244: http://bugs.mysql.com/30244)
* Cluster Replication: A replication heartbeat mechanism has
been added to facilitate monitoring. This provides an
alternative to checking log files, making it possible to
detect in real time when a slave has failed.
Configuration of heartbeats is done via a new
MASTER_HEARTBEAT_PERIOD = interval clause for the CHANGE
MASTER TO statement (see Section 12.6.2.1, "CHANGE MASTER TO
Syntax"); monitoring can be done by checking the values of the
status variables Slave_heartbeat_period and
Slave_received_heartbeats (see Section 5.1.5, "Status
Variables").
The addition of replication heartbeats addresses a number of
issues:
+ Relay logs were rotated every slave_net_timeout seconds
even if no statements were being replicated.
+ SHOW SLAVE STATUS displayed an incorrect value for
seconds_behind_master following a FLUSH LOGS statement.
+ Replication master-slave connections used
slave_net_timeout for connection timeouts.
(Bug#20435: http://bugs.mysql.com/20435,
Bug#29309: http://bugs.mysql.com/29309,
Bug#30932: http://bugs.mysql.com/30932)
* The --event-scheduler option without a value disabled the
event scheduler. Now it enables the event scheduler.
(Bug#31332: http://bugs.mysql.com/31332)
* mysqldump produces a -- Dump completed on DATE comment at the
end of the dump if --comments is given. The date causes dump
files for identical data take at different times to appear to
be different. The new options --dump-date and --skip-dump-date
control whether the date is added to the comment.
--skip-dump-date suppresses date printing. The default is
--dump-date (include the date in the comment).
(Bug#31077: http://bugs.mysql.com/31077)
* MySQL now can be compiled with gcc 4.2.x. There was a problem
involving a conflict with the min() and max() macros in
my_global.h. (Bug#28184: http://bugs.mysql.com/28184)
* It is now possible to set long_query_time in microseconds or
to 0. Setting this value to 0 causes all queries to be
recorded in the slow query log.
Currently, fractional values can be used only when logging to
files. We plan to provide this functionality for logging to
tables when time-related data types are enhanced to support
microsecond resolution.
(Bug#25412: http://bugs.mysql.com/25412)
* INFORMATION_SCHEMA implementation changes were made that
optimize certain types of queries for INFORMATION_SCHEMA
tables so that they execute more quickly. Section 7.2.17,
"INFORMATION_SCHEMA Optimization," provides guidelines on how
to take advantage of these optimizations by writing queries
that minimize the need for the server to access the filesystem
to obtain the information contained in INFORMATION_SCHEMA
tables. By writing queries that enable the server to avoid
directory scans or opening table files, you will obtain better
performance. (Bug#19588: http://bugs.mysql.com/19588)
* Three options were added to mysqldump make it easier to
generate a dump from a slave server. --dump-slave is similar
to --master-data, but the CHANGE MASTER statement contains
binary log coordinates for the slave's master host, not the
slave itself. --apply-slave-statements causes STOP SLAVE and
START SLAVE statements to be added before the CHANGE MASTER
statement and at the end of the output, respectively.
--include-master-host-port causes the CHANGE MASTER statement
to include MASTER_PORT and MASTER_HOST options for the slave's
master. (Bug#8368: http://bugs.mysql.com/8368)
* An alternative thread model is available for dealing with the
issues that occur with the original one-thread-per-client
model when scaling to large numbers of simultaneous
connections. This model uses thread pooling:
+ Connection manager threads do not dedicate a thread to
each client connection. Instead, the connection is added
to the set of existing connection sockets. The server
collects input from these sockets and when a complete
request has been received from a given client, it is
queued for service.
+ The server maintains a pool of service threads to process
requests. When a queued request is waiting and there is
an available (not busy) service thread in the pool, the
request is given to the thread to be handled. After
processing the request, the service thread becomes
available to process other requests.
Service threads are created at server startup and exist
until the server terminates. A given service thread is
not tied to a specific client connection and the requests
that it processes over time may originate from different
client connections.
+ The pool of service threads has a fixed size, so the
amount of memory required for it does not increase as the
number of client connections increases.
For information about choosing one thread model over the other
and tuning the parameters that control thread resources, see
Section 7.5.7, "How MySQL Uses Threads for Client
Connections."
* When the server detects MyISAM table corruption, it now writes
additional information to the error log, such as the name and
line number of the source file, and the list of threads
accessing the table. Example: Got an error from thread_id=1,
mi_dynrec.c:368. This is useful information to include in bug
reports.
* Two options relating to slow query logging have been added for
mysqld. --log-slow-slave-statements causes slow statements
executed by a replication slave to be written to the slow
query log; min_examined_row_limit can be used to cause queries
which examine fewer than the stated number of rows not to be
logged.

Bugs fixed:
* Security Fix: Replication: It was possible for any connected
user to issue a BINLOG statement, which could be used to
escalate privileges.
Use of the BINLOG statement now requires the SUPER privilege.
(Bug#31611: http://bugs.mysql.com/31611, CVE-2007-6313
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6313))
* Security Fix: Three vulnerabilities in yaSSL versions 1.7.5
and earlier were discovered that could lead to a server crash
or execution of unauthorized code. The exploit requires a
server with yaSSL enabled and TCP/IP connections enabled, but
does not require valid MySQL account credentials. The exploit
does not apply to OpenSSL.
Note:
The proof-of-concept exploit is freely available on the
Internet. Everyone with a vulnerable MySQL configuration is
advised to upgrade immediately.
(Bug#33814: http://bugs.mysql.com/33814, CVE-2008-0226
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0226),
CVE-2008-0227
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0227))
* Security Fix: Using RENAME TABLE against a table with explicit
DATA DIRECTORY and INDEX DIRECTORY options can be used to
overwrite system table information by replacing the symbolic
link points. the file to which the symlink points.
MySQL will now return an error when the file to which the
symlink points already exists.
(Bug#32111: http://bugs.mysql.com/32111, CVE-2007-5969
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5969))
* Security Fix: ALTER VIEW retained the original DEFINER value,
even when altered by another user, which could allow that user
to gain the access rights of the view. Now ALTER VIEW is
allowed only to the original definer or users with the SUPER
privilege. (Bug#29908: http://bugs.mysql.com/29908)
* Security Fix: When using a FEDERATED table, the local server
could be forced to crash if the remote server returned a
result with fewer columns than expected.
(Bug#29801: http://bugs.mysql.com/29801)
* Important Change: Incompatible Change: A number of problems
existed in the implementation of MERGE tables that could cause
problems. The problems are summarized below:
+ Bug#26379: http://bugs.mysql.com/26379 - Combination of
FLUSH TABLE and REPAIR TABLE corrupts a MERGE table. This
was caused in a number of situations:
1. A thread trying to lock a MERGE table performs busy
waiting while REPAIR TABLE or a similar table
administration task is ongoing on one or more of its
MyISAM tables.
2. A thread trying to lock a MERGE table performs busy
waiting until all threads that did REPAIR TABLE or
similar table administration tasks on one or more of
its MyISAM tables in LOCK TABLES segments do UNLOCK
TABLES. The difference against problem #1 is that
the busy waiting takes place after the
administration task. It is terminated by UNLOCK
TABLES only.
3. Two FLUSH TABLES within a LOCK TABLES segment can
invalidate the lock. This does not require a MERGE
table. The first FLUSH TABLES can be replaced by any
statement that requires other threads to reopen the
table. In 5.0 and 5.1 a single FLUSH TABLES can
provoke the problem.
+ Bug#26867: http://bugs.mysql.com/26867-Simultaneously
executing LOCK TABLES and REPAIR TABLE on a MERGE table
would result in memory/cpu hogging.
Trying DML on a MERGE table, which has a child locked and
repaired by another thread, made an infinite loop in the
server.
+ Bug#26377: http://bugs.mysql.com/26377 - Deadlock with
MERGE and FLUSH TABLE
Locking a MERGE table and its children in parent-child
order and flushing the child deadlocked the server.
+ Bug#25038: http://bugs.mysql.com/25038-WaitingTRUNCATE
Truncating a MERGE child, while the MERGE table was in
use, let the truncate fail instead of waiting for the
table to become free.
+ Bug#25700: http://bugs.mysql.com/25700 - MERGE base
tables get corrupted by OPTIMIZE/ANALYZE/REPAIR TABLE
Repairing a child of an open MERGE table corrupted the
child. It was necessary to FLUSH the child first.
+ Bug#30275: http://bugs.mysql.com/30275 - MERGE tables:
FLUSH TABLES or UNLOCK TABLES causes server to crash.
Flushing and optimizing locked MERGE children crashed the
server.
+ Bug#19627: http://bugs.mysql.com/19627 - temporary merge
table locking
Use of a temporary MERGE table with non-temporary
children could corrupt the children.
Temporary tables are never locked. Creation of tables
with non-temporary children of a temporary MERGE table is
now prohibited.
+ Bug#27660: http://bugs.mysql.com/27660 - Falcon: MERGE
table possible
It was possible to create a MERGE table with non-MyISAM
children.
+ Bug#30273: http://bugs.mysql.com/30273 - MERGE tables:
Can't lock file (errno: 155)
This was a Windows-only bug. Table administration
statements sometimes failed with "Can't lock file (errno:
155)".
The fix introduces the following changes in behavior:
+ This patch changes the behavior of temporary MERGE
tables. Temporary MERGE must have temporary children. The
old behavior was wrong. A temporary table is not locked.
Hence even non-temporary children were not locked. See
Bug#19627: http://bugs.mysql.com/19627.
+ You cannot change the union list of a non-temporary MERGE
table when LOCK TABLES is in effect. The following does
not work:
CREATE TABLE m1 ... ENGINE=MRG_MYISAM ...;
LOCK TABLES t1 WRITE, t2 WRITE, m1 WRITE;
ALTER TABLE m1 ... UNION=(t1,t2) ...;
However, you can do this with a temporary MERGE table.
+ You cannot create a MERGE table with CREATE ... SELECT,
neither as a temporary MERGE table, nor as a
non-temporary MERGE table. For example:
CREATE TABLE m1 ... ENGINE=MRG_MYISAM ... SELECT ...;
gives error message: table is not BASE TABLE.
(Bug#19627: http://bugs.mysql.com/19627,
Bug#25038: http://bugs.mysql.com/25038,
Bug#25700: http://bugs.mysql.com/25700,
Bug#26377: http://bugs.mysql.com/26377,
Bug#26379: http://bugs.mysql.com/26379,
Bug#26867: http://bugs.mysql.com/26867,
Bug#27660: http://bugs.mysql.com/27660,
Bug#30275: http://bugs.mysql.com/30275,
Bug#30491: http://bugs.mysql.com/30491)
* Incompatible Change: SET PASSWORD statements now cause an
implicit commit, and thus are prohibited within stored
functions and triggers.
(Bug#30904: http://bugs.mysql.com/30904)
* Incompatible Change: The mysql_install_db script could fail to
locate some components (including resolveip) during execution
if the --basedir option was specified on the command-line or
within the my.cnf file. This was due to a conflict when
comparing the compiled-in values and the supplied values.
The --source-install command-line option to the script has
been removed and replaced with the --srcdir option.
mysql_install_db now locates components either using the
compiled-in options, the --basedir option or --srcdir option.
(Bug#30759: http://bugs.mysql.com/30759)
* Incompatible Change: It was possible for option files to be
read twice at program startup, if some of the standard option
file locations turned out to be the same directory. Now
duplicates are removed from the list of files to be read.
Also, users could not override system-wide settings using
~/.my.cnf because SYSCONFDIR/my.cnf was read last. The latter
file now is read earlier so that ~/.my.cnf can override
system-wide settings. (Bug#20748: http://bugs.mysql.com/20748)
* Partitioning: Important Note: An apostrophe or single quote
character (') used in the DATA DIRECTORY, INDEX DIRECTORY, or
COMMENT for a PARTITION clause caused the server to crash.
When used as part of a CREATE TABLE statement, the crash was
immediate. When used in an ALTER TABLE statement, the crash
did not occur until trying to perform a SELECT or DML
statement on the table. In either case, the server could not
be completely restarted until the .FRM file corresponding to
the newly created or altered table was deleted.
Note:
Upgrading to the current (or later) release solves this
problem only for tables that are newly created or altered.
Tables created or altered in previous versions of the server
to include ' characters in PARTITION options must still be
removed by deleting the corresponding .FRM files and
re-creating them afterwards.
(Bug#30695: http://bugs.mysql.com/30695)
* Partitioning: MySQL Cluster: EXPLAIN PARTITIONS reported
partition usage by queries on NDB tables according to the
standard MySQL hash function than the hash function used in
the NDB storage engine.
(Bug#29550: http://bugs.mysql.com/29550)
* Replication: MySQL Cluster: Row-based replication from or to a
big-endian machine where the table used the NDB storage engine
failed, if the same table on the other machine was either
non-NDB or the other machine was little-endian.
(Bug#29549: http://bugs.mysql.com/29549,
Bug#30790: http://bugs.mysql.com/30790)
See also Bug#24231: http://bugs.mysql.com/24231,
Bug#30024: http://bugs.mysql.com/30024,
Bug#30133: http://bugs.mysql.com/30133,
Bug#30134: http://bugs.mysql.com/30134
* MySQL Cluster: An insert or update with combined range and
equality constraints failed when run against an NDB table with
the error Got unknown error from NDB. An example of such a
statement would be UPDATE t1 SET b = 5 WHERE a IN (7,8) OR a
>= 10;. (Bug#31874: http://bugs.mysql.com/31874)
* MySQL Cluster: An error with an if statement in
sql/ha_ndbcluster.cc could potentially lead to an infinite
loop in case of failure when working with AUTO_INCREMENT
columns in NDB tables.
(Bug#31810: http://bugs.mysql.com/31810)
* MySQL Cluster: The NDB storage engine code was not safe for
strict-alias optimization in gcc 4.2.1.
(Bug#31761: http://bugs.mysql.com/31761)
* MySQL Cluster: Following an upgrade, ndb_mgmd would fail with
an ArbitrationError. (Bug#31690: http://bugs.mysql.com/31690)
* MySQL Cluster: It was possible in some cases for a node group
to be "lost" due to missed local checkpoints following a
system restart. (Bug#31525: http://bugs.mysql.com/31525)
* MySQL Cluster: A query against a table with TEXT or BLOB
columns that would return more than a certain amount of data
failed with Got error 4350 'Transaction already aborted' from
NDBCLUSTER. (Bug#31482: http://bugs.mysql.com/31482)
This regression was introduced by
Bug#29102: http://bugs.mysql.com/29102
* MySQL Cluster: NDB tables having names containing
non-alphanumeric characters (such as " $ ") were not
discovered correctly. (Bug#31470: http://bugs.mysql.com/31470)
* MySQL Cluster: A node failure during a local checkpoint could
lead to a subsequent failure of the cluster during a system
restart. (Bug#31257: http://bugs.mysql.com/31257)
* MySQL Cluster: In some cases, the cluster managment server
logged entries multiple times following a restart of mgmd.
(Bug#29565: http://bugs.mysql.com/29565)
* MySQL Cluster: ndb_mgm --help did not display any information
about the -a option. (Bug#29509: http://bugs.mysql.com/29509)
* MySQL Cluster: An interpreted program of sufficient size and
complexity could cause all cluster data nodes to shut down due
to buffer overruns. (Bug#29390: http://bugs.mysql.com/29390)
* MySQL Cluster: Performing DELETE operations after a data node
had been shut down could lead to inconsistent data following a
restart of the node. (Bug#26450: http://bugs.mysql.com/26450)
* MySQL Cluster: UPDATE IGNORE could sometimes fail on NDB
tables due to the use of unitialized data when checking for
duplicate keys to be ignored.
(Bug#25817: http://bugs.mysql.com/25817)
* MySQL Cluster: The cluster log was formatted inconsistently
and contained extraneous newline characters.
(Bug#25064: http://bugs.mysql.com/25064)
* MySQL Cluster: (Replication): Inconsistencies could occur
between the master and the slave when replicating Disk Data
tables. (Bug#19259: http://bugs.mysql.com/19259,
Bug#19227: http://bugs.mysql.com/19227)
* Partitioning: Repeated updates of a table that was partitioned
by KEY on a TIMESTAMP column eventually crashed the server.
(Bug#32067: http://bugs.mysql.com/32067)
* Partitioning: Selecting from a table partitioned by KEY on a
VARCHAR column whose size was greater than 65530 caused the
server to crash. (Bug#31705: http://bugs.mysql.com/31705)
* Partitioning: INSERT DELAYED into a partitioned table crashed
the server. (Bug#31201: http://bugs.mysql.com/31201)
* Partitioning: Using ALTER TABLE to partition an existing table
having an AUTO_INCREMENT column could crash the server.
(Bug#30878: http://bugs.mysql.com/30878)
This regression was introduced by
Bug#27405: http://bugs.mysql.com/27405
* Partitioning: Falcon cannot drop a table for which there is a
pending transaction, but the error message for such attempts
was misleading. (Bug#22972: http://bugs.mysql.com/22972)


(to be continued)

--
Daniel Fischer, Staff Engineer, MySQL Release Engineering
Oracle Corporation, http://oss.oracle.com/

Options: ReplyQuote


Subject
Views
Written By
Posted
MySQL 6.0.4 Alpha has been released!
13604
March 07, 2008 05:41PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.