MySQL Community Server 5.1.51がリリースされました


最も普及しているオープンソースデータベース管理システムの新バージョンMySQL Community Server 5.1.51がリリースされました。MySQL 5.1.50は、プロダクションシステムでの使用をお勧めします。

MySQL 5.1の新機能の概要については、以下を参照してください。


新たなサーバにMySQL 5.1.51をインストール、または以前のMySQLリリースからMySQL 5.1.51にアップグレードする際の情報については、以下を参照してください。







MySQL 5.1に関するオープンな問題の情報については、以下のエラッタリストを参照してください。





    InnoDB Notes:

      * InnoDB Plugin has been upgraded to version 1.0.12. This
        version is considered of General Availability (GA) quality.
        In this release, the InnoDB Plugin is included in source and
        binary distributions, except RHEL3, RHEL4, SuSE 9 (x86,
        x86_64, ia64), generic Linux RPM packages, and any builds
        produced with the icc compiler. It also does not work for
        FreeBSD 6 and HP-UX or for Linux on generic ia64.

    Bugs fixed:

      * Incompatible Change: Replication: As of MySQL 5.5.6, handling
        of CREATE TABLE IF NOT EXISTS ... SELECT statements has been
        changed for the case that the destination table already

           + Previously, for CREATE TABLE IF NOT EXISTS ... SELECT,
             MySQL produced a warning that the table exists, but
             inserted the rows and wrote the statement to the binary
             log anyway. By contrast, CREATE TABLE ... SELECT (without
             IF NOT EXISTS) failed with an error, but MySQL inserted
             no rows and did not write the statement to the binary

           + MySQL now handles both statements the same way when the
             destination table exists, in that neither statement
             inserts rows or is written to the binary log. The
             difference between them is that MySQL produces a warning
             when IF NOT EXISTS is present and an error when it is
        This change in handling of IF NOT EXISTS results in an
        incompatibility for statement-based replication from a MySQL
        5.1 master with the original behavior and a MySQL 5.5 slave
        with the new behavior. Suppose that CREATE TABLE IF NOT EXISTS
        ... SELECT is executed on the master and the destination table
        exists. The result is that rows are inserted on the master but
        not on the slave. (Row-based replication does not have this
        To address this issue, statement-based binary logging for
        CREATE TABLE IF NOT EXISTS ... SELECT is changed in MySQL 5.1
        as of 5.1.51:

           + If the destination table does not exist, there is no
             change: The statement is logged as is.

           + If the destination table does exist, the statement is
             logged as the equivalent pair of CREATE TABLE IF NOT
             EXISTS and INSERT ... SELECT statements. (If the SELECT
             in the original statement is preceded by IGNORE or
             REPLACE, the INSERT becomes INSERT IGNORE or REPLACE,
        This change provides forward compatibility for statement-based
        replication from MySQL 5.1 to 5.5 because when the destination
        table exists, the rows will be inserted on both the master and
        slave. To take advantage of this compatibility measure, the
        5.1 server must be at least 5.1.51 and the 5.5 server must be
        at least 5.5.6.
        To upgrade an existing 5.1-to-5.5 replication scenario,
        upgrade the master first to 5.1.51 or higher. Note that this
        differs from the usual replication upgrade advice of upgrading
        the slave first.
        A workaround for applications that wish to achieve the
        original effect (rows inserted regardless of whether the
        destination table exists) is to use CREATE TABLE IF NOT EXISTS
        and INSERT ... SELECT statements rather than CREATE TABLE IF
        NOT EXISTS ... SELECT statements.
        Along with the change just described, the following related
        change was made: Previously, if an existing view was named as
        the destination table for CREATE TABLE IF NOT EXISTS ...
        SELECT, rows were inserted into the underlying base table and
        the statement was written to the binary log. As of MySQL
        5.1.51 and 5.5.6, nothing is inserted or logged.
        (Bug#47442: http://bugs.mysql.com/bug.php?id=47442,
        Bug#47132: http://bugs.mysql.com/bug.php?id=47132,
        Bug#48814: http://bugs.mysql.com/bug.php?id=48814,
        Bug#49494: http://bugs.mysql.com/bug.php?id=49494)

      * Incompatible Change: Previously, if you flushed the logs using
        FLUSH LOGS or mysqladmin flush-logs and mysqld was writing the
        error log to a file (for example, if it was started with the
        --log-error option), it renamed the current log file with the
        suffix -old, then created a new empty log file. This had the
        problem that a second log-flushing operation thus caused the
        original error log file to be lost unless you saved it under a
        different name. For example, you could use the following
        commands to save the file:
shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory
        To avoid the preceding file-loss problem, renaming no longer
        occurs. The server merely closes and reopens the log file. To
        rename the file, you can do so manually before flushing. Then
        flushing the logs reopens a new file with the original file
        name. For example, you can rename the file and create a new
        one using the following commands:
shell> mv host_name.err host_name.err-old
shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory
        (Bug#29751: http://bugs.mysql.com/bug.php?id=29751)

      * Partitioning: When the storage engine used to create a
        partitioned table was disabled, attempting to drop the table
        caused the server to crash.
        (Bug#46086: http://bugs.mysql.com/bug.php?id=46086)

      * If a view was named as the destination table for CREATE TABLE
        ... SELECT, the server produced a warning whether or not IF
        NOT EXISTS was used. Now it produces a warning only when IF
        NOT EXISTS is used, and an error otherwise.
        (Bug#55777: http://bugs.mysql.com/bug.php?id=55777)

      * The CHECK TABLE command could cause a time-consuming
        verification of the InnoDB adaptive hash index memory
        structure. Now this extra checking is only performed in
        binaries built for debugging.
        (Bug#55716: http://bugs.mysql.com/bug.php?id=55716)

      * After the fix for
        Bug#39653: http://bugs.mysql.com/bug.php?id=39653, the
        shortest available secondary index was used for full table
        scans. The primary clustered key was used only if no secondary
        index could be used. However, when the chosen secondary index
        includes all columns of the table being scanned, it is better
        to use the primary index because the amount of data to scan is
        the same but the primary index is clustered. This is now taken
        into account.
        (Bug#55656: http://bugs.mysql.com/bug.php?id=55656)

      * (Bug#55627: http://bugs.mysql.com/bug.php?id=55627)

      * The server was not checking for errors generated during the
        execution of Item::val_xxx() methods when copying data to a
        group, order, or distinct temp table's row.
        (Bug#55580: http://bugs.mysql.com/bug.php?id=55580)

      * ORDER BY clauses that included user variable expressions could
        cause a debug assertion to be raised.
        (Bug#55565: http://bugs.mysql.com/bug.php?id=55565)

      * Queries involving predicates of the form const NOT BETWEEN
        not_indexed_column AND indexed_column could return incorrect
        data due to incorrect handling by the range optimizer.
        (Bug#54802: http://bugs.mysql.com/bug.php?id=54802)

      * MIN() or MAX() with a subquery argument could raise a debug
        assertion for debug builds or return incorrect data for
        nondebug builds.
        (Bug#54465: http://bugs.mysql.com/bug.php?id=54465)

      * INFORMATION_SCHEMA plugins with no deinit() method resulted in
        a memory leak.
        (Bug#54253: http://bugs.mysql.com/bug.php?id=54253)

      * After ALTER TABLE was used on a temporary transactional table
        locked by LOCK TABLES, any later attempts to execute LOCK
        TABLES or UNLOCK TABLES caused a server crash.
        (Bug#54117: http://bugs.mysql.com/bug.php?id=54117)

      * INSERT IGNORE INTO ... SELECT statements could cause a debug
        assertion to be raised.
        (Bug#54106: http://bugs.mysql.com/bug.php?id=54106)

      * The fix for Bug#30234: http://bugs.mysql.com/bug.php?id=30234
        caused the server to reject the DELETE tbl_name.* ... Access
        compatibility syntax for multiple-table DELETE statements.
        (Bug#53034: http://bugs.mysql.com/bug.php?id=53034)

      * Enumeration plugin variables were subject to a type casting
        error, causing inconsistent results between different
        platforms. (Bug#42144: http://bugs.mysql.com/bug.php?id=42144)

      * A PKG install on Solaris put some files in incorrect
        locations. (Bug#31058: http://bugs.mysql.com/bug.php?id=31058)