List:Packagers« Previous MessageNext Message »
From:Hery Ramilison Date:March 22 2012 11:40pm
Subject:MySQL Community Server 5.5.22 has been released
View as plain text  
Dear MySQL users,

MySQL 5.5.22 is a new version of the 5.5 production release of the
world's most popular open source database. MySQL 5.5.22 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.22 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.22 is available in source and binary form for a
number of platforms from our download pages at:
     http://dev.mysql.com/downloads/mysql/

Not all mirror sites may be up to date at this point in time, so if you
can't find this version on some mirror, please try again later or choose
another download site.

We welcome and appreciate your feedback, bug reports, bug fixes,
patches, etc.:
     http://forge.mysql.com/wiki/Contributing

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-22.html

Enjoy!


Changes in MySQL 5.5.22 (21 March 2012)

  Functionality Added or Changed

    * InnoDB Storage Engine: A deprecation warning is now issued
      when --ignore-builtin-innodb is used. (Bug #13586262)

    * yaSSL was upgraded from version 1.7.2 to 2.2.0.

  Bugs Fixed

    * Important Change: InnoDB Storage Engine: When a row grew in
      size due to an UPDATE operation, other (non-updated) columns
      could be moved to off-page storage so that information about
      the row still fit within the constraints of the InnoDB page
      size. The pointer to the new allocated off-page data was not
      set up until the pages were allocated and written, potentially
      leading to lost data if the system crashed while the column
      was being moved out of the page. The problem was more common
      with tables using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED
      along with the Barracuda file format, particularly with the
      innodb_file_per_table setting enabled, because page allocation
      operations are more common as the .ibd tablespace files are
      extended. Still, the problem could occur with any combination
      of InnoDB version, file format, and row format.
      A related issue was that during such an UPDATE operation, or
      an INSERT operation that reused a delete-marked record, other
      transactions could see invalid data for the affected column,
      regardless of isolation level.
      The fix corrects the order of operations for moving the column
      data off the original page and replacing it with a pointer.
      Now if a crash occurs at the precise moment when the column
      data is being transferred, the transfer will not be re-run
      during crash recovery.
      In MySQL 5.1, this fix applies to the InnoDB Plugin, but not
      the built-in InnoDB storage engine. (Bug #13721257, Bug
      #12612184, Bug #12704861)

    * InnoDB Storage Engine: An erroneous assertion could occur, in
      debug builds only, when creating an index on a column
      containing zero-length values (that is, ''). (Bug #13654923)

    * InnoDB Storage Engine: A DDL operation such as ALTER TABLE ...
      ADD COLUMN could stall, eventually timing out with an Error
      1005: Can't create table message referring to
      fil_rename_tablespace. (Bug #13636122, Bug #62100, Bug #63553)

    * InnoDB Storage Engine: A DDL operation for an InnoDB table
      could cause a busy MySQL server to halt with an assertion
      error:
       InnoDB: Failing assertion: trx->error_state == DB_SUCCESS
      The error occurred if the DDL operation was run while all 1023
      undo slots were in use by concurrent transactions. This error
      was less likely to occur in MySQL 5.5 and 5.6, because raising
      the number of InnoDB undo slots increased the number of
      simultaneous transactions (corresponding to the number of undo
      slots) from 1K to 128K. (Bug #12739098, Bug #62401)

    * InnoDB Storage Engine: Server startup could produce an error
      for temporary tables using the InnoDB storage engine, if the
      path in the $TMPDIR variable ended with a / character. The
      error log would look like:
       120202 19:21:26  InnoDB: Operating system error number 2 in
        InnoDB: a file operation.
        InnoDB: The error means the system cannot find the path
        InnoDB: specified.
        InnoDB: If you are installing InnoDB, remember that you
        InnoDB: must create directories yourself, InnoDB does not
        InnoDB: create them.
        120202 19:21:26  InnoDB: Error: trying to open a table, but
        InnoDB: could not open the tablespace file
        InnoDB: './t/#sql7750_1_0.ibd'!
        InnoDB: Have you moved InnoDB .ibd files around without
        InnoDB: using the commands DISCARD TABLESPACE and IMPORT
        InnoDB: TABLESPACE?
        InnoDB: It is also possible that this is a temporary
        InnoDB: table #sql...,
        InnoDB: and MySQL removed the .ibd file for this.
      The workaround for the problem was to create a similar
      temporary table again, copy its .frm file to tmpdir under the
      name mentioned in the error message (for example, #sql123.frm)
      and restart mysqld with tmpdir set to its normal value without
      a trailing slash, for example /var/tmp. On startup, MySQL
      would see the .frm file and issue DROP TABLE for the orphaned
      temporary table. (Bug #11754376, Bug #45976)

    * Replication: Statements that wrote to tables with
      AUTO_INCREMENT columns based on an unordered SELECT from
      another table could lead to the master and the slave going out
      of sync, as the order in which the rows are retrieved from the
      table may differ between them. Such statements include any
      INSERT ... SELECT, REPLACE ... SELECT, or CREATE TABLE ...
      SELECT statement. Such statements are now marked as unsafe for
      statement-based replication, which causes the execution of one
      to throw a warning, and forces the statement to be logged
      using the row-based format if the logging format is MIXED.
      (Bug #11758263, Bug #50440)

    * myisam_sort_buffer_size could not be set larger than 4GB on
      64-bit systems. (Bug #45702, Bug #11754145)

    * Due to improper locking, concurrent inserts into an ARCHIVE
      table at the same time as repair and check operations on the
      table resulted in table corruption. (Bug #37280, Bug
      #11748748)

On behalf of the MySQL Build Team,

Hery Ramilison
MySQL/ORACLE Release Engineering Team

Thread
MySQL Community Server 5.5.22 has been releasedHery Ramilison22 Mar