MySQL 6.0.8アルファ版がリリースされました。


新たな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に記述されています。

MySQL 6.0.8アルファ版は、http://dev.mysql.com/downloads/mysql/6.0.htmlとミラーサイトのダウンロード・ページから、ソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。



MySQL 6.0の以前のバージョン以来の重要な変更、互換性のない変更、およびセキュリティ変更を以下のセクションに記載します。より多くの修正を含む全ての変更ログはhttp://dev.mysql.com/doc/refman/6.0/en/news-6-0-8.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, "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
    being run.

  * 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
    removed. (Bug#34818:http://bugs.mysql.com/34818)

  * 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."

Bugs fixed:

  * 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.

    See also Bug#40021:http://bugs.mysql.com/40021

  * 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
    '--thread-handling=pool-of-threads' option.

  * 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
    pathname. (Bug#39690:http://bugs.mysql.com/39690)

  * 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
    crash. (Bug#39353:http://bugs.mysql.com/39353)

  * 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
    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
    installed. (Bug#37958:http://bugs.mysql.com/37958)

  * 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
    crash. (Bug#37943:http://bugs.mysql.com/37943)

  * 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
    'latin2_czech_cs' collation.

  * 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
    errors. (Bug#37522:http://bugs.mysql.com/37522)

  * 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
    crash. (Bug#37212:http://bugs.mysql.com/37212)

  * 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
    performed. (Bug#36086:http://bugs.mysql.com/36086)

  * 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.

  * Hostname values in SQL statements were not being checked for
   '@', which is illegal according to RFC952.

  * "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
    characters. (Bug#35720:http://bugs.mysql.com/35720)

  * 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
    tables. (Bug#33575:http://bugs.mysql.com/33575)

  * The server crashed for BACKUP DATABASE if the backup progress
    tables in the mysql database were missing or created
    incorrectly. (Bug#33352:http://bugs.mysql.com/33352)

  * 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)