List:General Discussion« Previous MessageNext Message »
From:Sunanda Menon Date:February 5 2013 1:10pm
Subject:MySQL Community Server 5.5.30 has been released
View as plain text  
Dear MySQL users,

MySQL 5.5.30 is a new version of the 5.5 production release of the
world's most popular open source database. MySQL 5.5.30 is recommended
for use on production systems.

MySQL 5.5 includes several high-impact enhancements to improve the
performance and scalability of the MySQL Database, taking advantage of
the latest multi-CPU and multi-core hardware and operating systems. In
addition, with release 5.5, InnoDB is now the default storage engine for
the MySQL Database, delivering ACID transactions, referential integrity
and crash recovery by default.

MySQL 5.5 also provides a number of additional enhancements including:

      - Significantly improved performance on Windows, with various
        Windows specific features and improvements
      - Higher availability, with new semi-synchronous replication and
        Replication Heartbeat
      - Improved usability, with Improved index and table partitioning,
        SIGNAL/RESIGNAL support and enhanced diagnostics, including a new
        Performance Schema monitoring capability.

For a more complete look at what's new in MySQL 5.5, please see the
following resources:

MySQL 5.5 is GA, Interview with Tomas Ulin:
http://dev.mysql.com/tech-resources/interviews/thomas-ulin-mysql-55.html

Documentation:
http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html

Whitepaper: What's New in MySQL 5.5:
http://dev.mysql.com/tech-resources/articles/introduction-to-mysql-55.html

If you are running a MySQL production level system, we would like to
direct your attention to MySQL Enterprise Edition, which includes the
most comprehensive set of MySQL production, backup, monitoring,
modeling, development, and administration tools so businesses can
achieve the highest levels of MySQL performance, security and uptime.
http://mysql.com/products/enterprise/

For information on installing MySQL 5.5.30 on new servers, please see
the MySQL installation documentation at
http://dev.mysql.com/doc/refman/5.5/en/installing.html

For upgrading from previous MySQL releases, please see the important
upgrade considerations at:
http://dev.mysql.com/doc/refman/5.5/en/upgrading.html

MySQL Database 5.5.30 is available in source and binary form for a
number of platforms from our download pages at:
http://dev.mysql.com/downloads/mysql/

The following section lists the changes in the MySQL source code since
the previous released version of MySQL 5.5. It may also be viewed
online at:
http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-30.html

Enjoy!

Changes in MySQL 5.5.30 (5 Feb, 2013)

    Known limitations of this release:

    On Microsoft Windows, when using the MySQL Installer to install
    MySQL Server 5.5.30 on a host with an existing MySQL Server of a
    different version (such as 5.6.10), that also has a different
    license (community versus commercial), you must first update the
    license type of the existing MySQL Server. Otherwise, MySQL
    Installer will remove MySQL Server(s) with different licenses from
    the one you chose with MySQL Server 5.5.30.

    On Microsoft Windows 8, updating a community release to a
    commercial release requires you to manually restart the MySQL
    service after the update.

    Functionality Added or Changed

       * InnoDB: The innodb_print_all_deadlocks configuration option
        from MySQL 5.6 was backported to MySQL 5.5. This option
        records each deadlock
        (http://dev.mysql.com/doc/refman/5.5/en/glos_deadlock.html)
        condition in the MySQL error log, allowing easier
        troubleshooting if frequent deadlocks point to application
        coding issues. (Bug #14515889)

      * In RPM packages built for Unbreakable Linux Network,
        libmysqld.so now has a version number. (Bug #15972480)

    Bugs Fixed

      * InnoDB; Performance: Some data structures related to undo
        logging could be initialized unnecessarily during a query,
        although they were only needed under specific conditions. (Bug
        #14676084)

      * InnoDB; Performance: Optimized read operations for compressed
        (http://dev.mysql.com/doc/refman/5.5/en/glos_compression.html)
        tables by skipping redundant tests. The check for whether any
        related changes needed to be merged from the insert buffer
        (http://dev.mysql.com/doc/refman/5.5/en/glos_insert_buffer.htm
        l) was being called more often than necessary. (Bug #14329288,
        Bug #65886)

      * InnoDB; Performance: Immediately after a table was created,
        queries against it would not use loose index scans
        (http://dev.mysql.com/doc/refman/5.5/en/loose-index-scan.html)
        . The issue went away following an ALTER TABLE on the table.
        The fix improves the accuracy of the index statistics
        (http://dev.mysql.com/doc/refman/5.5/en/glos_index_statistics.
        html) gathered when the table is first created, and prevents
        the query plan from being changed by the ALTER TABLE
        statement. (Bug #14200010)

      * InnoDB; Partitioning: Previously, when attempting to optimize
        one or more partitions of a partitioned table that used a
        storage engine that does not support partition-level OPTIMIZE,
        such as InnoDB, MySQL reported Table does not support
        optimize, doing recreate + analyze instead, then re-created
        the entire table, but did not actually analyze it. Now in such
        cases, the warning message is, Table does not support optimize
        on partitions. All partitions will be rebuilt and analyzed. In
        addition, the entire table is analyzed after first being
        rebuilt. (Bug #11751825)

      * InnoDB: On systems that cannot handle unaligned memory access,
        depending on the stack frame alignment, a SIGBUS error could
        occur during startup. This issue was observed on Solaris
        64-bit systems. (Bug #16021177)

      * InnoDB: The status variable
        Innodb_buffer_pool_read_ahead_evicted could show an inaccurate
        value, higher than expected, because some pages in the buffer
        pool
        (http://dev.mysql.com/doc/refman/5.5/en/glos_buffer_pool.html)
        were incorrectly considered as being brought in by read-ahead
        (http://dev.mysql.com/doc/refman/5.5/en/glos_read_ahead.html)
        requests. (Bug #15859402, Bug #67476)

      * InnoDB: Creating an index on a CHAR column could fail for a
        table with a character set with varying length, such as UTF-8,
        if the table was created with the ROW_FORMAT=REDUNDANT clause.
        (Bug #15874001)

      * InnoDB: The server could halt with an assertion error while
        creating an index:
        InnoDB: Assertion failure in thread thread_num in file row0merge.cc
        line 465
        This issue affected tables with a combination of
        ROW_FORMAT=REDUNDANT off-page columns
        (http://dev.mysql.com/doc/refman/5.5/en/glos_off_page_column.h
        tml), and an index on a column prefix
        (http://dev.mysql.com/doc/refman/5.5/en/glos_column_prefix.htm
        l). (Bug #14753402)

      * InnoDB: If the server crashed at a precise moment during an
        ALTER TABLE operation that rebuilt the clustered index
        (http://dev.mysql.com/doc/refman/5.5/en/glos_clustered_index.h
        tml) for an InnoDB table, the original table could be
        inaccessible afterward. An example of such an operation is
        ALTER TABLE ... ADD PRIMARY KEY The fix preserves the original
        table if the server halts during this operation. You might
        still need to rename the .ibd file manually to restore the
        original table contents: in MySQL 5.6 and higher, rename from
        #sql-ib$new_table_id.ibd to table_name.ibd within the database
        directory; prior to MySQL 5.6, the temporary file to rename is
        table_name#1 or #2. (Bug #14669848)

      * InnoDB: An error at the filesystem level, such as too many
        open files, could cause an unhandled error during an ALTER
        TABLE operation. The error could be accompanied by Valgrind
        warnings, and by this assertion message:
        Assertion `! is_set()' failed.
        mysqld got signal 6 ;
        (Bug #14628410, Bug #16000909)

      * InnoDB: A RENAME TABLE statement could stall for several
        minutes before timing out. This issue could occurred for a
        table using compression
        (http://dev.mysql.com/doc/refman/5.5/en/glos_compression.html)
        , with change buffering
        (http://dev.mysql.com/doc/refman/5.5/en/glos_change_buffering.
        html) enabled. (Bug #14556349)

      * InnoDB: During shutdown, with the innodb_purge_threads
        configuration option set greater than 1, the server could halt
        prematurely with this error:
        mysqld got signal 11
        A workaround was to increase innodb_log_file_size and set
        innodb_purge_threads=1. The fix was backported to MySQL 5.5
        and 5.1, although those versions do not have the
        innodb_purge_threads configuration option so the error was
        unlikely to occur. (Bug #14234028)

      * InnoDB: If the value of innodb_force_recovery was less than 6,
        opening a corrupted table might loop forever if a corrupted
        page was read when calculating statistics for the table.
        Information about the corrupted page was written repeatedly to
        the error log, possibly causing a disk space issue. The fix
        causes the server to halt after a fixed number of failed
        attempts to read the page. To troubleshoot such a corruption
        issue, set innodb_force_recovery=6 and restart. (Bug
        #14147491, Bug #65469)

      * InnoDB: The value of the innodb_version variable was not
        updated consistently for all server releases for the InnoDB
        Plugin in MySQL 5.1, and the integrated InnoDB component in
        MySQL 5.5, 5.6, and higher. Since InnoDB and MySQL Server
        development cycles are fully integrated and synchronized, now
        the value returned by the innodb_version variable is the same
        as for the version variable. (Bug #13463493, Bug #63435)

      * Partitioning: Concurrent ALTER TABLE ... REBUILD PARTITION
        operations could interfere with one another, even when not
        running against the same table, because they both used global
        memory for storage. Now each partition rebuild operation
        stores intermediate data in memory that is local to that
        process. (Bug #14589559, Bug #66645)

      * Partitioning: Inserting any number of rows into an ARCHIVE
        table that used more than 1000 partitions and then attempting
         to drop the table caused the MySQL Server to fail. (Bug
        #13819630, Bug #64580)

      * Replication: After dropping a column from the slave's version
        of a table, then altering the same column of this table on the
        master (so that a type conversion would have been required had
        the column not been droppped on the slave), inserts into this
        table caused replication to fail. (Bug #15888454)

      * Replication: When a binary log is replayed on a server (for
        example, by executing a command like mysqlbinlog binlog.000001
        | mysql), it sets a pseudo-slave mode on the client connection
        used, so that the server can read binlog and apply binary log
        events correctly. However, the pseudo-slave mode was not
        disabled after the binary log dump was read, which caused
        unexpected filtering rules to be applied to SQL statements
        subsequently executed on the same connection. (Bug #15891524)

      * Replication: When using statement-based replication, and where
        the master and the slave used table schemas having different
        AUTO_INCREMENT columns, inserts generating AUTO_INCREMENT
        values logged for a given table on the master could be applied
        to the wrong table on the slave. (Bug #12669186)

      * Replication: Repeated execution of CHANGE MASTER TO statements
        using invalid MASTER_LOG_POS values could lead to errors and
        possibly a crash on the slave. Now in such cases, the
        statement fails with a clear error message. (Bug #11764602,
        Bug #57454)

      * Replication: If the disk becomes full while writing to the
        binary log, the server hangs until space is freed up manually.
        It was possible after this was done for the MySQL server to
        fail, due to an internal status value being set when not
        needed. Now in such cases, rather than trying to set this
        status, a warning is written in the error log instead. (Bug
        #11753923, Bug #45449)

       * Microsoft Windows: Dynamic file names (with colons) are no
        longer allowed. Static file names using the Alternate Data
        Stream (ADS) NTFS functionality of Microsoft Windows may
        continue to be used. (Bug #11761752)

      * Directory name manipulation could result in stack overflow on
        Mac OS X and Windows. (Bug #16066243)

      * Joins of exactly 32 tables and containing a HAVING clause
        returned an empty result. (Bug #15972635)

      * A buffer-handling problem in yaSSL was fixed. (Bug #15965288)

      * A mysys library string-formatting routine could mishandle
        width specifiers. (Bug #15960005)

      * In certain cases, UpdateXML() could return NULL incorrectly.
        (Bug #15948580)
        References: See also Bug #13007062.

      * Metadata locking and table definition cache routines did not
        always check length of names passed to them. (Bug #15954872)

      * XA START had a race condition that could cause a server crash.
        (Bug #14729757)

      * Enabling the query cache during high client contention could
        cause the server to exit. (Bug #14727815)

      * There was a performance regression for queries using SELECT
        ... INTO user variables and a WHERE condition on one or more
        of the variables in the INTO list. (Bug #14664077)
        References: This bug was introduced by Bug #12408412.

      * The server sometimes failed to respect
        MAX_CONNECTIONS_PER_HOUR limits on user connections. (Bug
        #14627287)

      * Output generated with mysqldump --routines could produce
        syntax errors when reloaded. (Bug #14463669)

      * With the thread pool plugin installed, a workload consisting
        of concurrent KILL statements and ping queries caused the
        server to exit. (Bug #14458232, Bug #14458002)

      * CHECK TABLE and REPAIR TABLE could crash if a MyISAM table had
        a corrupt key (.MYI) file. Now the server produces an error.
        (Bug #13556107, Bug #13556000)

      * Passing an unknown time zone specification to CONVERT_TZ()
        resulted in a memory leak. (Bug #12347040)

      * For dumps of the mysql database, mysqldump skipped the event
        table unless the --events option was given. To skip this table
        if that is desired, use the --ignore-table option instead (Bug
        #55587, Bug #11762933)

      * For MEMORY tables with HASH indexes, DELETE sometimes failed
        to delete all applicable rows. (Bug #51763, Bug #11759445)

      * The mysql client could mishandle the delimiter command if it
        occurred on a line during which mysql was looking for the end
        of a quoted string. (Bug #64135, Bug #13639125)

      * mysqld_safe used the nonportable -e test construct. (Bug
        #67976, Bug #16046140)

      * Configuring the server with
        performance_schema_events_waits_history_size=0 and
        performance_schema_events_waits_history_long_size=0 could
        cause a Performance Schema segmentation fault. (Bug #68008,
        Bug #16060864)

       * DECIMAL multiplication operations could produce significant
        inaccuracy. (Bug #45860, Bug #11754279)

      * For subqueries executing using a filesort, the optimizer could
        produce an incorrect result containing wrong rows. (Bug
        #66845, Bug #14636211)
        References: See also Bug #12667154.

      * UNION type conversion could incorrectly turn unsigned values
        into signed values. (Bug #49003, Bug #11757005)

      * During the startup process, mysqld could incorrectly remove
        the PID file of an already running mysqld. (Bug #23790, Bug
        #11746142)
        References: See also Bug #14726272.

On behalf of the MySQL/ORACLE Build Team,

Sunanda Menon




Thread
MySQL Community Server 5.5.30 has been releasedSunanda Menon5 Feb