新たなFalconトランザクションストレージエンジンおよびクラッシュしても安全なMariaエンジンを持つMySQLデータベースシステムの新バージョンであるMySQL 6.0.8アルファ版がリリースされました。MySQL 6.0に関する主要なページは、http://www.mysql.com/mysql60/にあります。
Falconストレージエンジンが初めてで、より多くの情報が必要な場合、Falcon Evaluation Guide
と、Falcon White Paper
Mariaストレージエンジンは、MyISAMのクラッシュ・セーフなバージョンです。MariaはMyISAMエンジンの主な機能のすべてをサポートします。それだけでなく、システムクラッシュが発生した場合のリカバリサポート、CREATE, DROP, RENAME, TRUNCATEを含む十分なロギング機能、全てのMyISAMテーブルのrow format、Maria固有の新たなrow formatもMariaはサポートしています。Mariaについてはhttp://dev.mysql.com/doc/refman/6.0/en/se-maria.htmlに記述されています。
Functionality added or changed:
* Incompatible Change: The tables for MySQL Backup logging have
been renamed, and the logging capabilities now are more
flexible, similar to the capabilities provided for the general
query log and slow query log.
+ The names of the MySQL Backup log tables in the mysql
database have been changed from ‘online_backup’ and
‘online_backup_progress’ to ‘backup_history’ and
+ Logging now can be enabled or disabled, it is possible to
log to tables or to files, and the names of the log files
can be changed. For details, see Section 126.96.36.199, "MySQL
Backup Log Control."
+ A new statement, FLUSH BACKUP LOGS, closes and reopens
the backup log files. A new option for mysql_refresh(),
REFRESH_BACKUP_LOG, performs the same operation.
* Important Change: The ‘–skip-thread-priority’ option is now
deprecated in MySQL 5.1 and is removed in MySQL 6.0 such that
the server won’t change the thread priorities by default.
Giving threads different priorities might yield marginal
improvements in some platforms (where it actually works), but
it might instead cause significant degradation depending on
the thread count and number of processors. Meddling with the
thread priorities is a not a safe bet as it is very dependent
on the behavior of the CPU scheduler and system where MySQL is
* Important Change: The ‘–log’ option now is deprecated and will
be removed (along with the log system variable) in the future.
Instead, use the ‘–general_log’ option to enable the general
query log and the ‘–general_log_file=file_name’ option to set
the general query log filename. The values of these options
are available in the general_log and ‘general_log_file’ system
variables, which can be changed at runtime.
Similar changes were made for the ‘–log-slow-queries’ option
and ‘log_slow_queries’ system variable. You should use the
‘–slow_query_log’ and ‘–slow_query_log_file=file_name’ options
instead (and the ‘slow_query_log’ and ‘slow_query_log_file’ system
* The "BUILD/compile-solaris-*" scripts now compile MySQL with the
mtmalloc library rather than malloc.
* BACKUP DATABASE now performs an implicit commit, like RESTORE.
* The deprecated ‘–default-table-type’ server option has been
* On WIndows, use of POSIX I/O interfaces in mysys was replaced
with Win32 API calls (CreateFile(), WriteFile(), and so forth)
and the default maximum number of open files has been
increased to 16384. The maximum can be increased further by
using the ‘–max-open-files=N’ option at server startup.
* Most statements that previously caused an implicit commit
before executing now also cause an implicit commit after
executing. Also, the FLUSH statement and mysql_refresh() C API
function now cause an implicit commit. See Section 12.4.3,
"Statements That Cause an Implicit Commit."
* Incompatible Change: Replication: The default binary logging
mode has been changed from MIXED to STATEMENT for
compatibility with MySQL 5.0.
* Incompatible Change: In connection with view creation, the
server created arc directories inside database directories and
maintained useless copies of .frm files there. Creation and
renaming procedures of those copies as well as creation of arc
directories has been discontinued.
This change does cause a problem when downgrading to older
server versions which manifests itself under these circumstances:
1. Create a view ‘v_orig’ in MySQL 6.0.8 or higher.
2. Rename the view to ‘v_new’ and then back to ‘v_orig’.
3. Downgrade to an older 6.0.x server and run "mysql_upgrade".
4. Try to rename ‘v_orig’ to ‘v_new’ again. This operation
As a workaround to avoid this problem, use either of these
+ Dump your data using mysqldump before downgrading and
reload the dump file after downgrading.
+ Instead of renaming a view after the downgrade, drop it
and recreate it.
* Important Change: Replication: The SUPER privilege is now
required to change the session value of ‘binlog_format’ as well
as its global value. For more information about ‘binlog_format’,
see Section 15.1.2, "Replication Formats."
* Partitioning: Replication: Replication to partitioned MyISAM
tables could be slow with row-based binary logging.
* Partitioning: A duplicate key error raised when inserting into
a partitioned table used a different error code from that
returned by such an error raised when inserting into a table
that was not partitioned.
See also Bug#28842:http://bugs.mysql.com/28842
* Partitioning: If an error occurred when evaluating a column of
a partitioned table for the partitioning function, the row
could be inserted anyway.
* Partitioning: Using INSERT … SELECT to insert records into a
partitioned MyISAM table could fail if some partitions were
empty and others are not.
* Replication: Replication of BLACKHOLE tables did not work with
row-based binary logging.
* Replication: In some cases, a replication master sent a
special event to a reconnecting slave to keep the slave’s
temporary tables, but they still had references to the "old"
slave SQL thread and used them to access that thread’s data.
* Replication: Replication filtering rules were inappropiately
applied when executing BINLOG pseudo-queries. One way in which
this problem showed itself was that, when replaying a binary
log with mysqlbinlog, RBR events were sometimes not executed
if the ‘–replicate-do-db’ option was specified. Now replication
rules are applied only to those events executed by the slave
SQL thread. (Bug#36099:http://bugs.mysql.com/36099)
* Replication: For a CREATE TABLE … SELECT statement that
creates a table in a database other than the current one, the
table could be created in the wrong database on replication
slaves if row-based binary logging is used.
* Replication: A statement did not always commit or roll back
correctly when the server was shut down; the error could be
triggered by having a failing UPDATE or INSERT statement on a
transactional table, causing an implicit rollback.
See also Bug#38262:http://bugs.mysql.com/38262
* Windows builds were missing the MySQL Backup log tables.
* Non-ASCII error messages were corrupted.
* The ‘Threads_created’ status variable was not correctly
incremented when the server was started with the
* On Windows Vista, RESTORE did not correctly calculate the
validity point from the backup stream.
* The MySQL Backup ‘backup_history’ log now contains a
‘backup_file_path’ column. ‘backup_file’ contains the basename and
backup_file_path contains the directory of the image file
* Some MySQL Backup-related memory-use warnings detected by
Valgrind were corrected.
* CHECK TABLE … FOR UPGRADE did not check for incompatible
collation changes made in MySQL 5.0.48.
* For a TIMESTAMP column in an InnoDB table, testing the column
with multiple conditions in the WHERE clause caused a server
* For BACKUP DATABASE, the server could add a / character to the
end of the backup path, even when the path ended with a
filename rather than a directory name.
* The server could crash when attempting to insert duplicate
empty strings into a utf8 SET column.
* References to local variables in stored procedures are
replaced with NAME_CONST(name, value) when written to the
binary log. However, an "illegal mix of collation" error might
occur when executing the log contents if the value’s collation
differed from that of the variable. Now information about the
variable collation is written as well.
* BACKUP DATABASE failed on PowerMac platforms due to type
casting problems. (Bug#39127:http://bugs.mysql.com/39127)
* MySQL Backup was not handling several errors.
* Some warnings were being reported as errors.
* Queries of the form SELECT … REGEXP BINARY NULL could lead
to a hung or crashed server.
* Statements of the form INSERT … SELECT .. ON DUPLICATE KEY
UPDATE col_name = DEFAULT could result in a server crash.
* Repeated CREATE TABLE … SELECT statements, where the created
table contained an AUTO_INCREMENT column, could lead to an
assertion failure. (Bug#38821:http://bugs.mysql.com/38821)
* RESTORE crashed if a trigger and an event had the same name.
* For deadlock between two transactions that required a timeout
to resolve, all server tables became inaccessible for the
duration of the deadlock.
* When inserting a string into a duplicate-key error message,
the server could improperly interpret the string, resulting in
a crash. (Bug#38701:http://bugs.mysql.com/38701)
* A race condition between threads sometimes caused unallocated
memory to be addressed.
* A server crash resulted from concurrent execution of a
multiple-table UPDATE that used a NATURAL or USING join
together with FLUSH TABLES WITH READ LOCK or ALTER TABLE for
the table being updated.
* On ActiveState Perl, "mysql-test-run.pl" ‘–start-and-exit’
started but did not exit.
* A server crash resulted from execution of an UPDATE that used
a derived table together with FLUSH TABLES.
* Stored procedures involving substrings could crash the server
on certain platforms due to invalid memory reads.
* The binary log filename stored in the ‘binlog_file’ column of
the ‘mysql.backup_history’ MySQL Backup table now is the file
basename (the final component). Previously, the full pathname
was stored, but this could be too long for the column width.
* Queries containing a subquery with DISTINCT and ORDER BY could
cause a server crash. (Bug#38191:http://bugs.mysql.com/38191)
* Errors during server startup caused destruction of an
uninitialized mutex and assertion failure.
* The handlerton-to-plugin mapping implementation did not free
handler plugin references when the plugin was uninstalled,
resulting in a server crash after several install/uninstall
cycles. Also, on Mac OS X, the server crashed when trying to
access an EXAMPLE table after the EXAMPLE plugin was
* The server crashed if an argument to a stored procedure was a
subquery that returned more than one row.
* When analyzing the possible index use cases, the server was
incorrectly reusing an internal structure, leading to a server
* Access checks were skipped for SHOW PROCEDURE STATUS and SHOW
FUNCTION STATUS, which could lead to a server crash or
insufficient access checks in subsequent statements.
* Comparisons could hang for SET or ENUM columns that used
* SHOW PROCESSLIST displayed "copy to tmp table" when no such
copy was occurring. (Bug#37550:http://bugs.mysql.com/37550)
* The <=> operator could return incorrect results when comparing
NULL to DATE, TIME, or DATETIME values.
* MySQL Backup was not consistently checking for BSTREAM_ERROR
* The combination of a subquery with a GROUP BY, an aggregate
function calculated outside the subquery, and a GROUP BY on
the outer SELECT could cause the server to crash.
* Incorrect BLOB handling by RESTORE could result in a server
* The NO_BACKSLASH_ESCAPES SQL mode was ignored for LOAD DATA
INFILE and SELECT INTO … OUTFILE. The setting is taken into
account now. (Bug#37114:http://bugs.mysql.com/37114)
* If thread-pooling was used and a connection attempt was denied
on the grounds of exceeding the user limits, the number of
active connections for that user was erroneously decreased
twice. The difference between the actual number connections
and the internal count could then cause debug builds of the
server to raise an assertion.
* Long error messages for RESTORE could be truncated.
* In some cases, references to views were confused with
references to anonymous tables and privilege checking was not
* For crash reports on Windows, symbol names in stack traces
were not correctly resolved.
* ALTER EVENT changed the PRESERVE attribute of an event even
when PRESERVE was not specified in the statement.
* "mysql_install_db" failed on machines that had the hostname set
to "localhost". (Bug#35754:http://bugs.mysql.com/35754)
* Dynamic plugins failed to load on i5/OS.
* With the PAD_CHAR_TO_FULL_LENGTH SQL mode enabled, a ucs2 CHAR
column returned additional garbage after trailing space
* RESTORE did not set the ‘validity_point_time’, ‘binlog_pos’, and
‘binlog_file’ fields of the ‘backup_history’ log table row.
* With binary logging enabled, CREATE TABLE … SELECT failed if
the source table was a log table.
* If BACKUP DATABASE and RESTORE were done in a session with
autocommit disabled, a later DROP TABLE or RESTORE in the same
session failed. (Bug#34204:http://bugs.mysql.com/34204)
* The ‘secure_file_priv’ system variable now applies to BACKUP
DATABASE and RESTORE operations: If the value is nonempty,
backup and restore operations can read and write files only in
the given directory. (Bug#34171:http://bugs.mysql.com/34171)
* mysql_real_connect() did not check whether the MYSQL
connection handler was already connected and connected again
even if so. Now an CR_ALREADY_CONNECTED error occurs.
* Shutting down the MySQL Server immediately following the
execution of a BACKUP DATABASE statement caused the server to
crash if the database to be backed up contained any Falcon
* The server crashed for BACKUP DATABASE if the backup progress
tables in the mysql database were missing or created
* CHECKSUM TABLE was not killable with KILL QUERY.
* A trigger for an InnoDB table activating multiple times could
lead to AUTO_INCREMENT gaps.
* mysqldump could fail to dump views containing a large number
of columns. (Bug#31434:http://bugs.mysql.com/31434)
* The server could improperly type user-defined variables used
in the select list of a query.
* For access to the INFORMATION_SCHEMA.VIEWS table, the server
did not check the SHOW VIEW and SELECT provileges, leading to
inconsistency between output from that table and the SHOW
CREATE VIEW statement.
* "mysqld_safe" would sometimes fail to remove the pid file for
the old mysql process after a crash. As a result, the server
would fail to start due to a false A mysqld process already
exists… error. (Bug#11122:http://bugs.mysql.com/11122)