MySQL Forums
Forum List  »  Announcements

MySQL Community Server 5.5.31 has been released
Posted by: Balasubramanian Kandasamy
Date: April 18, 2013 07:59AM

Dear MySQL users,

MySQL 5.5.31 is a new version of the 5.5 production release of the
world's most popular open source database. MySQL 5.5.31 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 Heartbeat
- 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:


Whitepaper: What's New in MySQL 5.5:

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.

For information on installing MySQL 5.5.31 on new servers, please see
the MySQL installation documentation at

For upgrading from previous MySQL releases, please see the important
upgrade considerations at:

MySQL Database 5.5.31 is available in source and binary form for a
number of platforms from our download pages at:

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:


Changes in MySQL 5.5.31 (2013-04-18)
   RPM Notes

     * It was not possible to upgrade a community RPM to a commercial
       RPM using rpm -uvh or yum localupdate. To deal with this, the
       RPM spec file has been updated in MySQL 5.5.31, which has the
       following consequences:

          + For a non-upgrade installation (no existing MySQL version
            installed), it possible to install MySQL using yum.

          + For upgrades, it is necessary to clean up any earlier
            MySQL installations. In effect, the update is performed
            by removing the old installations and installing the new
       Additional details follow.
       For a non-upgrade installation of MySQL 5.5.31, it is possible
       to install using yum:
shell> yum install MySQL-server-NEWVERSION.glibc23.i386.rpm
       For upgrades to MySQL 5.5.31, the upgrade is performed by
       removing the old installation and installing the new one. To
       do this, use the following procedure:

         1. Remove the existing 5.5.X installation. OLDVERSION is the
            version to remove.
shell> rpm -e MySQL-server-OLDVERSION.glibc23.i386.rpm
            Repeat this step for all installed MySQL RPMs.

         2. Install the new version. NEWVERSION is the version to
shell> rpm -ivh MySQL-server-NEWVERSION.glibc23.i386.rpm
       Alternatively, the removal and installation can be done using
shell> yum remove MySQL-server-OLDVERSION.glibc23.i386.rpm
shell> yum install MySQL-server-NEWVERSION.glibc23.i386.rpm
       (Bug #16445097, Bug #16445125)

   Functionality Added or Changed

     * MySQL no longer uses the default OpenSSL compression. (Bug

   Bugs Fixed

     * InnoDB; Performance: Performance was improved for operations
       on tables with many rows that were deleted but not yet purged
       ge). The speedup applies mainly to workloads that perform bulk
       deletes, or updates to the primary key
       mary_key) columns, and where the system is busy enough to
       experience purge lag
       ge_lag). (Bug #16138582, Bug #68069)

     * InnoDB; Performance: The DROP TABLE statement for a table
       using compression
       pression) could be slower than necessary, causing a stall for
       several seconds. MySQL was unnecessarily decompressing pages
       e) in the buffer pool
       fer_pool) related to the table as part of the DROP operation.
       (Bug #16067973)

     * Incompatible Change; Partitioning: Changes in the KEY
       partitioning hashing functions used with numeric, date and
       time, ENUM, and SET columns in MySQL 5.5 makes tables using
       partitioning or subpartitioning by KEY on any of the affected
       column types and created on a MySQL 5.5 or later server
       incompatible with a MySQL 5.1 server. This is because the
       partition IDs as calculated by a MySQL 5.5 or later server
       almost certainly differ from those calculated by a MySQL 5.1
       server for the same table definition and data as a result of
       the changes in these functions.
       The principal changes in the KEY partitioning implementation
       in MySQL 5.5 resulting in this issue were as follows: 1. The
       hash function used for numeric and date and time columns
       changed from binary to character-based. 2. The base used for
       hashing of ENUM and SET columns changed from latin1 ci
       characters to binary.
       The fix involves adding the capability in MySQL 5.5 and later
       to choose which type of hashing to use for KEY partitioning,
       which is implemented with a new ALGORITHM extension to the
       Specifying PARTITION BY KEY ALGORITHM=1 ([columns]) causes the
       server to use the hashing functions as implemented in MySQL
       5.1; using ALGORITHM=2 causes the server to use the hashing
       functions from MySQL 5.5 and later. ALGORITHM=2 is the
       default. Using the appropriate value for ALGORITHM, you can
       perform any of the following tasks:

          + Create KEY partitioned tables in MySQL 5.5 and later that
            are compatible with MySQL 5.1, using CREATE TABLE ...
            PARTITION BY KEY ALGORITHM=1 (...).

          + Downgrade KEY partitioned tables that were created in
            MySQL 5.5 or later to become compatible with MySQL 5.1,
            using ALTER TABLE ... PARTITION BY KEY ALGORITHM=1 (...).

          + Upgrade KEY partitioned tables originally created in
            MySQL 5.1 to use hashing as in MySQL 5.5 and later, using
            Important: After such tables are upgraded, they cannot be
            used any longer with MySQL 5.1 unless they are first
            downgraded again using ALTER TABLE ... PARTITION BY KEY
            ALGORITHM=1 (...) on a MySQL server supporting this
       This syntax is not backward compatible, and causes errors in
       older versions of the MySQL server. When generating CREATE
       TABLE ... PARTITION BY KEY statements, mysqldump brackets any
       occurrence of ALGORITHM=1 or ALGORITHM=2 in conditional
       comments such that it is ignored by a MySQL server whose
       version is not at least 5.5.31. An additional consideration
       for upgrades is that MySQL 5.6 servers prior to MySQL 5.6.11
       do not ignore the ALGORITHM option in such statements when
       generated by a MySQL 5.5 server, due to the that the
       conditional comments refer to version 5.5.31; in this case,
       you must edit the dump manually and remove or comment out the
       option wherever it occurs before attempting to load it into a
       MySQL 5.6.10 or earlier MySQL 5.6 server. This is not an issue
       for dumps generated by MySQL 5.6.11 or later version of
       mysqldump, where the version used in such comments is 5.6.11.
       For more information, see ALTER TABLE Partition Operations
       As part of this fix, a spurious assertion by InnoDB that a
       deleted row had previously been read, causing the server to
       assert on delete of a row that the row was in the wrong
       partition, was also removed. (Bug #14521864, Bug #66462, Bug
       #16093958, Bug #16274455)
       References: See also Bug #11759782.

     * Important Note; Replication: It was possible to replicate from
       a table to a same-named view using statement-based logging,
       while using row-based logging instead led to a failure on the
       slave. Now the target object type is checked prior to
       performing any DML, and an error is given if the target on the
       slave is not actually a table. This is true regardless of the
       binary logging format in use. (Bug #11752707, Bug #43975)

     * InnoDB: For InnoDB tables, if a PRIMARY KEY on a VARCHAR
       column (or prefix) was empty, index page compression could
       fail. (Bug #16400920)

     * InnoDB: For debug builds, InnoDB status exporting was subject
       to a race condition that could cause a server exit. (Bug

     * InnoDB: Internal read operations could be misclassified as
       synchronous when they were actually asynchronous. When the I/O
       requests returned sooner than expected, threads could be
       scheduled inefficiently. This issue mainly affected read-ahead
       d_ahead) requests, and thus had relatively little impact on
       I/O performed by user queries. (Bug #16249505, Bug #68197)

     * InnoDB: An improper call to abort() by InnoDB could result in
       a server exit. (Bug #16263506)

     * InnoDB: If the MySQL server halted at a precise moment when a
       purge operation was being applied from the change buffer
       nge_buffer), the operation could be incorrectly performed
       again during the next restart. A workaround was to set the
       configuration option innodb_change_buffering=changes, to turn
       off change buffering for purge operations. (Bug #16183892, Bug

     * InnoDB: Arithmetic underflow during page compression for
       CREATE TABLE on an InnoDB table could cause a server exit.
       (Bug #16089381)

     * InnoDB: If the server was started with the skip-innodb option,
       or InnoDB otherwise failed to start, query any of these
       Information Schema tables would cause a severe error:



       (Bug #14144290)

     * InnoDB: When printing out long semaphore wait diagnostics,
       sync_array_cell_print() ran into a segmentation violation
       (SEGV) caused by a race condition. This fix addresses the race
       condition by allowing the cell to be freed while it is being
       printed. (Bug #13997024)

     * InnoDB: Killing a query caused an InnoDB assertion failure
       when the same table (cursor) instance was used again. This is
       the result of a regression error introduced by the fix for
       Bug#14704286. The fix introduced a check to handle kill
       signals for long running queries but the cursor was not
       restored to the proper state. (Bug #68051, Bug #16088883)

     * InnoDB: The length of internally generated foreign key names
       was not checked. If internally generated foreign key names
       were over the 64 character limit, this resulted in invalid DDL
       from SHOW CREATE TABLE. This fix checks the length of
       internally generated foreign key names and reports an error
       message if the limit is exceeded. (Bug #44541, Bug #11753153)

     * Partitioning: A query on a table partitioned by range and
       using TO_DAYS() as a partitioing function always included the
       first partition of the table when pruning. This happened
       regardless of the range employed in the BETWEEN clause of such
       a query. (Bug #15843818, Bug #49754)

     * Partitioning: Execution of ALTER TABLE ... DROP PARTITION
       against a view caused the server to crash, rather than fail
       with an error as expected. (Bug #14653504)

     * Replication: A zero-length name for a user variable (such as
       @``) was incorrectly considered to be a sign of data or
       network corruption when reading from the binary log. (Bug
       #16200555, Bug #68135)

     * Replication: Using the --replicate-* options (see Replication
       Slave Options and Variables
       ave.html)) could in some cases lead to a memory leak on the
       slave. (Bug #16056813, Bug #67983)

     * Replication: Backtick (`) characters were not always handled
       correctly in internally generated SQL statements, which could
       sometimes lead to errors on the slave. (Bug #16084594, Bug
       References: This bug is a regression of Bug #14548159, Bug

     * Replication: It was possible immediately after detecting an
       EOF in the dump thread read event loop, and before deciding
       whether to change to a new binary log file, for new events to
       be written to the binary log concurrently with rotating the
       log. If log rotation occurred during this window, any events
       that also occurred at that time were dropped, resulting in
       loss of data. Now in such cases, steps are taken to make sure
       that no more events remain before allowing the log rotation to
       take place. (Bug #13545447, Bug #67929)
       References: See also Bug #16016886.

     * SHOW ENGINE PERFORMANCE_SCHEMA STATUS could report incorrect
       memory-allocation values when the correct values exceeded 4GB.
       (Bug #16414644)

     * A long database name in a GRANT statement could cause the
       server to exit. (Bug #16372927)

     * On Linux, a race condition involving epoll() could cause the
       thread pool plugin to miss events. This was most likely on
       systems with greater than 16 cores. (Bug #16367483)

     * The server could exit if a prepared statement attempted to
       create a table using the name of an existing view while an SQL
       handler was opened. (Bug #16385711)

     * Incorrect results were returned if a query contained a
       subquery in an IN clause which contained an XOR operation in
       the WHERE clause. (Bug #16311231)

     * For upgrade operations, RPM packages produced unnecessary
       errors about being unable to access .err files. (Bug

     * Invocation of the range optimizer for a NULL select caused the
       server to exit. (Bug #16192219)

     * yaSSL did not perform proper padding checks, but instead
       examined only the last byte of plaintext and used it to
       determine how many bytes to remove. (Bug #16218104)

     * With the thread pool plugin enabled, large numbers of
       connections could lead to a Valgrind panic or failure of
       clients to be able to connect. (Bug #16088658, Bug #16196591)

     * The initial test database contained a dummy.bak file that
       prevented DROP DATABASE from working. This file is no longer
       included. Also, a db.opt file is now included that contains
       these lines:
       (Bug #16062056)

     * Setting a system variable to DEFAULT could cause the server to
       exit. (Bug #16044655)

     * Issuing a PREPARE statement using certain combinations of
       stored functions and user variables caused the server to exit.
       (Bug #16056537)

     * Contention in the thread pool during kill processing could
       lead to a Valgrind panic. (Bug #15921866)

     * When a client program loses the connection to the MySQL server
       or if the server begins a shutdown after the client has
       executed mysql_stmt_prepare(), the next mysql_stmt_prepare()
       returns an error (as expected) but subsequent
       mysql_stmt_execute() calls crash the client. (Bug #14553380)

     * SHOW COLUMNS on a view defined as a UNION of Geometry columns
       could cause the server to exit. (Bug #14362617)

     * A LIKE pattern with too many '%' wildcards could cause a
       segmentation fault. (Bug #14303860)

     * SET var_name = VALUES(col_name) could cause the server to
       exit. This syntax is now prohibited because in SET context
       there is no column name and the statement returns
       ER_BAD_FIELD_ERROR. (Bug #14211565)

     * The COM_CHANGE_USER command in the client/server protocol did
       not properly use the character set number in the command
       packet, leading to incorrect character set conversion of other
       values in the packet. (Bug #14163155)

     * Subqueries with OUTER JOIN could return incorrect results if
       the subquery referred to a column from another SELECT. (Bug

     * On Microsoft Windows, the MSI package would now allow a
       license switch (community to or from the commercial edition)
       when the switched MySQL Server versions were identical. (Bug

     * mysql_install_db did not escape '_' in the host name for
       statements written to the grant tables. (Bug #11746817)

     * An out-of-memory condition could occur while handling an
       out-of-memory error, leading to recursion in error handling.
       (Bug #49514, Bug #11757464)

     * The optimizer used loose index scan for some queries for which
       this access method is inapplicable. (Bug #42785, Bug

     * If a dump file contained a view with one character set and
       collation defined on a view with a different character set and
       collation, attempts to restore the dump file failed with an
       "illegal mix of collations" error. (Bug #65382, Bug #14117025)

     * The REPLACE() function produced incorrect results when a user
       variable was supplied as an argument and the operation was
       performed on multiple rows. (Bug #49271, Bug #11757250)

     * UNION ALL on BLOB columns could produce incorrect results.
       (Bug #50136, Bug #11758009)

     * View access in low memory conditions could raise a debugging
       assertion. (Bug #39307, Bug #11749556)

     * Setting max_connections to a value less than the current
       number of open connections caused the server to exit. (Bug
       #44100, Bug #11752803)

     * Incorrect metadata could be produced for columns returned from
       some views. (Bug #65379, Bug #14096619)

     * For debug builds, some queries with SELECT ... FROM DUAL
       nested subqueries raised an assertion. (Bug #60305, Bug

     * If the server was started without a --datadir option, SHOW
       VARIABLES could show an empty value for the datadir system
       variable. (Bug #60995, Bug #12546953)

     * CMake did not check whether the system zlib had certain
       functions required for MySQL, resulting in build errors. Now
       it checks and falls back to the bundled zlib if the functions
       are missing. (Bug #65856, Bug #14300733)

MySQL Release Engineering Team

Edited 1 time(s). Last edit at 04/18/2013 08:01AM by Balasubramanian Kandasamy.

Options: ReplyQuote

Written By
MySQL Community Server 5.5.31 has been released
April 18, 2013 07:59AM

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.