|
Posted
about 12 years
ago
by
hery ramilison
Dear MySQL users,
MySQL 5.5.21 is a new version of the 5.5 production release of the
world's most popular open source database. MySQL 5.5.21 is recommended
for use on production systems.
MySQL 5.5 includes several high-impact enhancements to
... [More]
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.21 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.21 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-21.html
Enjoy!
Changes in MySQL 5.5.21 (17 February 2012)
Functionality Added or Changed
* A new CMake option, MYSQL_PROJECT_NAME, can be set on Windows
or Mac OS X to be used in the project name. (Bug #13551687)
Bugs Fixed
* Performance: InnoDB Storage Engine: Memory allocation for
InnoDB tables was reorganized to reduce the memory overhead
for large numbers of tables or partitions, avoiding situations
where the "resident set size" could grow regardless of FLUSH
TABLES statements. The problem was most evident for tables
with large row size. Some of the memory that was formerly
allocated for every open table is now allocated only when the
table is modified for the first time. (Bug #11764622, Bug
#57480)
* Incompatible Change: An earlier change (in MySQL 5.1.59 and
5.5.16) was found to modify date-handling behavior in General
Availability-status series (MySQL 5.1 and 5.5). This change
has been reverted.
The change was that several functions became more strict when
passed a DATE() function value as their argument, thus they
rejected incomplete dates with a day part of zero. These
functions were affected: CONVERT_TZ(), DATE_ADD(), DATE_SUB(),
DAYOFYEAR(), LAST_DAY(), TIMESTAMPDIFF(), TO_DAYS(),
TO_SECONDS(), WEEK(), WEEKDAY(), WEEKOFYEAR(), YEARWEEK(). The
previous behavior has been restored. (Bug #13458237)
* InnoDB Storage Engine: A Valgrind error was fixed in the
function os_aio_init(). (Bug #13612811)
* InnoDB Storage Engine: The server could crash when creating an
InnoDB temporary table under Linux, if the $TMPDIR setting
points to a tmpfs filesystem and innodb_use_native_aio is
enabled, as it is by default in MySQL 5.5.4 and higher. The
entry in the error log looked like:
101123 2:10:59 InnoDB: Operating system error number
22 in a file operation.
InnoDB: Error number 22 means 'Invalid argument'.
The crash occurred because asynchronous I/O is not supported
on tmpfs in some Linux kernel versions. The workaround was to
turn off the innodb_use_native_aio setting or use a different
temporary directory. The fix causes InnoDB to turn off the
innodb_use_native_aio setting automatically if it detects that
the temporary file directory does not support asynchronous
I/O. (Bug #13593888, Bug #11765450, Bug #58421)
* InnoDB Storage Engine: References to C preprocessor symbols
and macros HAVE_purify, UNIV_INIT_MEM_TO_ZERO, and
UNIV_SET_MEM_TO_ZERO were removed from the InnoDB source code.
They were only used in debug builds instrumented for Valgrind.
They are replaced by calls to the UNIV_MEM_INVALID() macro.
(Bug #13418934)
* InnoDB Storage Engine: The MySQL server could halt with an
assertion error:
InnoDB: Failing assertion: page_get_n_recs(page) > 1
Subsequent restarts could fail with the same error. The error
occurred during a purge
(http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_pur
ge) operation involving the InnoDB change buffer
(http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_cha
nge_buffer). The workaround was to set the configuration
option innodb_change_buffering=inserts. (Bug #13413535, Bug
#61104)
* InnoDB Storage Engine: With 1024 InnoDB transactions running
concurrently and the innodb_file_per_table setting enabled,
a CREATE TABLE operation for an InnoDB table could fail. The
.ibd file from the failed CREATE TABLE was left behind,
preventing the table from being created later, after the load
had dropped.
The fix adds error handling to delete the erroneous .ibd file.
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 needed to trigger the bug,
from 1K to 128K. (Bug #12400341)
* Replication: Executing mysqlbinlog with the --start-position=N
option, where N was equal either to 0 or to a value greater
than the length of the dump file, caused it to crash.
This issue was introduced in MySQL 5.5.18 by the fix for Bug
#32228 and Bug #11747416. (Bug #13593869, Bug #64035)
* Replication: On Windows replication slave hosts, STOP SLAVE
took an excessive length of time to complete when the master
was down. (Bug #11752315, Bug #43460)
* A query that used an index on a CHAR column referenced in a
BETWEEN clause could return invalid results. (Bug #13463488,
Bug #63437)
* Expressions that compared a BIGINT column with any non-integer
constant were performed using integers rather than decimal or
float values, with the result that the constant could be
truncated. This could lead to any such comparison that used <,
>, <=, >=, =, !=/<>, IN, or BETWEEN yielding false positive or
negative results. (Bug #13463415, Bug #11758543, Bug #63502,
Bug #50756)
* When the optimizer performed conversion of DECIMAL values
while evaluating range conditions, it could produce incorrect
results. (Bug #13453382)
* When running mysqldump with both the --single-transaction and
--flush-logs options, the flushing of the log performed an
implicit COMMIT (see Section 12.3.3, "Statements That Cause an
Implicit Commit"), causing more than one transaction to be
used and thus breaking consistency. (Bug #12809202, Bug
#61854)
* It was possible in the event of successive failures for
mysqld_safe to restart quickly enough to consume excessive
amounts of CPU. Now, on systems that support the sleep and
date system utilities, mysqld_safe checks to see whether it
has restarted more than 5 times in the current second, and if
so, waits 1 second before attempting another restart. (Bug
#11761530, Bug #54035)
* When used with the --xml option, mysqldump --routines failed
to dump any stored routines, triggers, or events. (Bug
#11760384, Bug #52792)
* It was possible on replication slaves where FEDERATED tables
were in use to get timeouts on long-running operations, such
as Error 1160 Got an error writing communication packets. The
FEDERATED tables did not need to be replicated for the issue
to occur. (Bug #11758931, Bug #51196)
References: See also Bug #12896628, Bug #61790.
* If an attempt to initiate a statement failed, the issue could
not be reported to the client because it was not prepared to
receive any error messages prior to the execution of any
statement. Since the user could not execute any queries, they
were simply disconnected without providing a clear error.
After the fix for this issue, the client is prepared for an
error as soon as it attempts to initiate a statement, so that
the error can be reported prior to disconnecting the user.
(Bug #11755281, Bug #47032)
* Using myisamchk with the sort recover method to repair a table
having fixed-width row format could cause the row pointer size
to be reduced, effectively resulting in a smaller maximum data
file size. (Bug #48848, Bug #11756869)
* On Windows, the server incorrectly constructed the full path
name of the plugin binary for INSTALL PLUGIN and CREATE
FUNCTION ... SONAME. (Bug #45549, Bug #11754014)
* The stored routine cache was subject to a small memory leak
that over time or with many routines being used could result
in out-of-memory errors. (Bug #44585, Bug #11753187)
On behalf of the MySQL Build Team,
Hery Ramilison
MySQL/ORACLE Release Engineering Team
[Less]
|
