MySQL Forums
Forum List  »  Announcements

MySQL Community Server 5.5.28 has been released
Posted by: Jocelyn Ramilison
Date: September 29, 2012 10:03AM

Dear MySQL users,

MySQL 5.5.28 is a new version of the 5.5 production release of the
world's most popular open source database. MySQL 5.5.28 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 Heart Beat
    - 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/why-mysql/white-papers/mysql-wp-whatsnew-mysql-55.php

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.28 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.28 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/refman/5.5/en/news-5-5-28.html

Enjoy!

Changes in MySQL 5.5.28 (2012-September-28)

Functionality Added or Changed

  * The internal interface of the Thread Pool plugin has changed.
    Old versions of the plugin will work with current versions of
    the server, but versions of the server older than 5.5.28 will
    not work with current versions of the plugin.

Bugs Fixed

  * InnoDB: Certain information_schema tables originally
    introduced in MySQL 5.6 are now also available in MySQL 5.5
    and MySQL 5.1: INNODB_BUFFER_PAGE, INNODB_BUFFER_PAGE_LRU, and
    INNODB_BUFFER_POOL_STATS. (Bug #13113026)

  * InnoDB: When a SELECT ... FOR UPDATE, UPDATE, or other SQL
    statement scanned rows in an InnoDB table using a < or <=
    operator in a WHERE clause, the next row after the affected
    range could also be locked. This issue could cause a lock wait
    timeout for a row that was not expected to be locked. The
    issue occurred under various isolation levels, such as READ
    COMMITTED and REPEATABLE READ. (Bug #11765218)

  * Partitioning: For tables using PARTITION BY HASH or PARTITION
    BY KEY, when the partition pruning mechanism encountered a
    multi-range list or inequality using a column from the
    partitioning key, it continued with the next partitioning
    column and tried to use it for pruning, even if the previous
    column could not be used. This caused partitions which
    possibly matched one or more of the previous partitioning
    columns to be pruned away, leaving partitions that matched
    only the last column of the partitioning key.
    This issue was triggered when both of the following conditions
    were met:

      1. The columns making up the table's partitioning key were
         used in the same order as in the partitioning key
         definition by a SELECT statement's WHERE clause as in the
         column definitions;

      2. The WHERE condition used with the last column of the
         partitioning key was satisfied only by a single value,
         while the condition testing some previous column from the
         partitioning key was satisfied by a range of values.
    An example of a statement creating a partitioned table and a
    query against this for which the issue described above
    occurred is shown here:
      CREATE TABLE t1 (
      c1 INT,
      c2 INT,
      PRIMARY KEY(c2, c1)
      ) PARTITION BY KEY()  # Use primary key as partitioning key
      PARTITIONS 2;

      SELECT * FROM t1 WHERE c2 = 2 AND c1 <> 2;
    This issue is resolved by ensuring that partition pruning
    skips any remaining partitioning key columns once a partition
    key column that cannot be used in pruning is encountered. (Bug
    #14342883)

  * Partitioning: The buffer for the row currently read from each
    partition used for sorted reads was allocated on open and
    freed only when the partitioning handler was closed or
    destroyed. For SELECT statements on tables with many
    partitions and large rows, this could cause the server to use
    excessive amounts of memory.
    This issue has been addressed by allocating buffers for reads
    from partitioned tables only when they are needed and freeing
    them immediately once they are no longer needed. As part of
    this fix, memory is now allocated for reading from rows only
    in partitions that have not been pruned (see Partition Pruning
    (http://dev.mysql.com/doc/refman/5.5/en/partitioning-pruning.h
    tml)). (Bug #13025132)
    References: See also Bug #11764622, Bug #14537277.

  * Replication: On 64-bit Windows platforms, values greater than
    4G for the max_binlog_cache_size and
    max_binlog_stmt_cache_size system variables were truncated to
    4G. This caused LOAD DATA INFILE to fail when trying to load a
    file larger than 4G in size, even when max_binlog_cache_size
    was set to a value greater than this. (Bug #13961678)

  * Replication: In master-master replication with
    --log-slave-updates enabled, setting a user variable and then
    performing inserts using this variable caused the
    Exec_master_log_position column in the output of SHOW SLAVE
    STATUS not to be updated. (Bug #13596613)

  * The RPM spec file now also runs the test suite on the new
    binaries, before packaging them. (Bug #14318456)

  * The libmysqlclient_r client library exported symbols from
    yaSSL that conflict with OpenSSL. If a program linked against
    that library and libcurl, it could crash with a segmentation
    fault. (Bug #14068244)

  * The argument for LIMIT must be an integer, but if the argument
    was given by a placeholder in a prepared statement, the server
    did not reject noninteger values such as '5'. (Bug #13868860)

  * The Thread Pool plugin did not respect the wait_timeout
    timeout for client sessions. (Bug #13699303)

  * CHECK TABLE and REPAIR TABLE could crash if a key definition
    differed in the .frm and .MYI files of a MyISAM table. Now the
    server produces an error. (Bug #13555854)

  * A query for a FEDERATED table could return incorrect results
    when the underlying table had a compound index on two columns
    and the query included an AND condition on the columns. (Bug
    #12876932)

  * mysqlhotcopy failed for databases containing views. (Bug
    #62472, Bug #13006947, Bug #12992993)

  * The argument to the --ssl-key option was not verified to exist
    and be a valid key. The resulting connection used SSL, but the
    key was not used. (Bug #62743, Bug #13115401)

  * Adding a LIMIT clause to a query containing GROUP BY and ORDER
    BY could cause the optimizer to choose an incorrect index for
    processing the query, and return more rows than required. (Bug
    #54599, Bug #11762052)

  * mysqlbinlog did not accept input on the standard input when
    the standard input was a pipe. (Bug #49336, Bug #11757312)


On behalf of the MySQL/ORACLE Build Team

Hery Ramilison


Options: ReplyQuote


Subject
Views
Written By
Posted
MySQL Community Server 5.5.28 has been released
7975
September 29, 2012 10:03AM


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.