Dear MySQL users,
MySQL 5.5.27 is a new version of the 5.5 production release of the
world's most popular open source database. MySQL 5.5.27 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.27 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.27 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.
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-27.html
Enjoy!
Changes in MySQL 5.5.27 (2012-August-02)
Functionality Added or Changed
* Important Change: The YEAR(2) data type is now deprecated
because it is problematic. Support for YEAR(2) will be removed
in a future release of MySQL. For more information, see
YEAR(2) Limitations and Migrating to YEAR(4)
(http://dev.mysql.com/doc/refman/5.5/en/migrating-to-year4.html).
Bugs Fixed
* InnoDB: If a row was deleted from an InnoDB table, then
another row was re-inserted with the same primary key value,
an attempt by a concurrent transaction to lock the row could
succeed when it should have waited. This issue occurred if the
locking select used a WHERE clause that performed an index
scan using a secondary index. (Bug #14100254, Bug #65389)
* InnoDB: An assertion could be raised if an InnoDB table was
moved to a different database using ALTER TABLE ... RENAME
while the database was being dropped by DROP DATABASE. (Bug
#13982017)
* InnoDB: Using the KILL statement to terminate a query could
cause an unnecessary message in the error log:
[ERROR] Got error -1 when reading table table_name
(Bug #13933132)
* InnoDB: For an InnoDB table with a trigger, under the setting
innodb_autoinc_lock_mode=1, sometimes auto-increment values
could be interleaved when inserting into the table from two
sessions concurrently. The sequence of auto-increment values
could vary depending on timing, leading to data inconsistency
in systems using replication. (Bug #12752572, Bug #61579)
* Replication: An event whose length exceeded the size of the
master dump thread's max_allowed_packet caused replication to
fail. This could occur when updating many large rows and using
row-based replication.
As part of this fix, a new server option
--slave-max-allowed-packet is added, which permits
max_allowed_packet to be exceeded by the slave SQL and I/O
threads. Now the size of a packet transmitted from the master
to the slave is checked only against this value (available as
the value of the slave_max_allowed_packet server system
variable), and not against the value of max_allowed_packet.
(Bug #12400221, Bug #60926)
* Replication: Statements such as UPDATE ... WHERE
primary_key_column = co
