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
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql
