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 one.
Additional details follow.
For a non-upgrade installation of MySQL 5.5.31, it is possible to install using yum:
yum install MySQL-server-
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:
Remove the existing 5.5.
OLDVERSION is the
version to remove.
rpm -e MySQL-server-
Repeat this step for all installed MySQL RPMs.
Install the new version.
NEWVERSION is the version to
rpm -ivh MySQL-server-
Alternatively, the removal and installation can be done using yum:
yum remove MySQL-server-shell>
yum install MySQL-server-
(Bug #16445097, Bug #16445125, Bug #16587285)
Functionality Added or Changed
MySQL no longer uses the default OpenSSL compression. (Bug #16235681)
Performance; InnoDB: Performance was improved for operations on tables with many rows that were deleted but not yet purged. The speedup applies mainly to workloads that perform bulk deletes, or updates to the primary key columns, and where the system is busy enough to experience purge lag. (Bug #16138582, Bug #68069)
DROP TABLE statement for a
could be slower than necessary, causing a stall for several
seconds. MySQL was unnecessarily decompressing
pages in the
buffer pool related to
the table as part of the
Incompatible Change; Partitioning:
Changes in the
KEY partitioning hashing
functions used with numeric, date and time,
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
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
SET columns changed from
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
partitioning, which is implemented with a new
ALGORITHM extension to the
BY KEY option for
PARTITION BY KEY ALGORITHM=1
([ causes the
server to use the hashing functions as implemented in MySQL 5.1;
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:
KEY partitioned tables in MySQL
5.5 and later that are compatible with MySQL 5.1, using
CREATE TABLE ... PARTITION BY KEY ALGORITHM=1
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
KEY partitioned tables originally
created in MySQL 5.1 to use hashing as in MySQL 5.5 and
ALTER TABLE ... PARTITION BY KEY
Important: After such tables are
upgraded, they cannot be used any longer with MySQL 5.1
unless they are first downgraded again using
TABLE ... PARTITION BY KEY ALGORITHM=1 (...) on a
MySQL server supporting this option.
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
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
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: Using row-based logging to replicate from a table to a same-named view led to a failure on the slave. Now, when using row-based logging, 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.
It remains possible to replicate from a table to a same-named view using statement-based logging.
(Bug #11752707, Bug #43975)
InnoDB tables, if a
KEY on a
VARCHAR column (or prefix)
was empty, index page compression could fail.
For debug builds,
InnoDB status exporting was
subject to a race condition that could cause a server exit.
RENAME TABLE would result in a hang due to a MySQL mutex
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 requests, and thus had relatively little impact on I/O performed by user queries. (Bug #16249505, Bug #68197)
InnoDB now aborts execution on Windows by calling the
abort() function directly, as it does on
InnoDB: When tables are linked by foreign key constraints, loading one table would open other linked tables recursively. When numerous tables are linked by foreign key constraints, this would sometimes lead to a thread stack overflow causing the server to exit. Tables linked by foreign key constraints are now loaded iteratively. Cascade operations, which were also performed in a recursive manner, are now performed iteratively using an explicit stack. (Bug #16244691)
If the MySQL server halted at a precise moment when a purge
operation was being applied from the
change buffer, the
operation could be incorrectly performed again during the next
restart. A workaround was to set the configuration option
to turn off change buffering for purge operations.
(Bug #16183892, Bug #14636528)
Arithmetic underflow during page compression for
CREATE TABLE on an
InnoDB table could cause a server exit.
If the server was started with the
InnoDB otherwise failed to start,
query any of these Information Schema tables would cause a
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.
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)
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
(Bug #15843818, Bug #49754)
TABLE ... DROP PARTITION against a view caused the
server to crash, rather than fail with an error as expected.
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)
--replicate-* options (see
Replication Slave Options and Variables) could in
some cases lead to a memory leak on the slave.
(Bug #16056813, Bug #67983)
`) characters were not always
handled correctly in internally generated SQL statements, which
could sometimes lead to errors on the slave.
(Bug #16084594, Bug #68045)
References: This bug is a regression of Bug #14548159, Bug #66550.
Replication: It was possible in certain cases—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 before this decision was made. If log rotation occurred at this time, any events that occurred following EOF detection were dropped, resulting in loss of data. Now in such cases, steps are taken to make sure that all events are processed 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.
A long database name in a
statement could cause the server to exit.
On Linux, a race condition involving
could cause the thread pool plugin to miss events. This was most
likely on systems with greater than 16 cores.
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 clause which contained an
XOR operation in the
For upgrade operations, RPM packages produced unnecessary errors
about being unable to access
Invocation of the range optimizer for a
select caused the server to exit.
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)
test database contained a
dummy.bak file that prevented
DATABASE from working. This file is no longer
included. Also, a
db.opt file is now included
that contains these lines:
Setting a system variable to
cause the server to exit.
PREPARE statement using certain
combinations of stored functions and user variables caused the
server to exit.
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
returns an error (as expected) but subsequent
calls crash the client.
LIKE pattern with too many
'%' wildcards could cause a segmentation
cause the server to exit. This syntax is now prohibited because
SET context there is no column name and
the statement returns
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.
OUTER JOIN could return
incorrect results if the subquery referred to a column from
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 #13071597)
mysql_install_db did not escape
'_' in the host name for statements written
to the grant tables.
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 #11751794)
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)
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)
View access in low memory conditions could raise a debugging assertion. (Bug #39307, Bug #11749556)
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 #11827369)
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
(Bug #65856, Bug #14300733)