-
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 is 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:
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:
-
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.
-
Install the new version.
NEWVERSION
is the version to install.shell> rpm -ivh MySQL-server-NEWVERSION.glibc23.i386.rpm
Alternatively, the removal and installation can be done using yum:
shell> yum remove MySQL-server-OLDVERSION.glibc23.i386.rpm shell> yum install MySQL-server-NEWVERSION.glibc23.i386.rpm
(Bug #16445097, Bug #16445125, Bug #16587285)
MySQL no longer uses the default OpenSSL compression. (Bug #16235681)
-
Incompatible Change; Partitioning: Changes in the
KEY
partitioning hashing functions used with numeric, date and time,ENUM
, andSET
columns in MySQL 5.5 makes tables using partitioning or subpartitioning byKEY
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 ofENUM
andSET
columns changed fromlatin1 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 newALGORITHM
extension to thePARTITION BY KEY
option forCREATE TABLE
andALTER TABLE
. SpecifyingPARTITION BY KEY ALGORITHM=1 ([
causes the server to use the hashing functions as implemented in MySQL 5.1; usingcolumns
])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 forALGORITHM
, 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, usingCREATE 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, usingALTER 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, usingALTER TABLE ... PARTITION BY KEY ALGORITHM=2 (...)
.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 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 ofALGORITHM=1
orALGORITHM=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 theALGORITHM
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.
NoteIt remains possible to replicate from a table to a same-named view using statement-based logging.
(Bug #11752707, Bug #43975)
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)
Performance; InnoDB: The
DROP TABLE
statement for a table using compression 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 theDROP
operation. (Bug #16067973)InnoDB: Crash recovery failed with a
!recv_no_log_write
assertion when reading a page. (Bug #16405422)InnoDB: For
InnoDB
tables, if aPRIMARY KEY
on aVARCHAR
column (or prefix) was empty, index page compression could fail. (Bug #16400920)InnoDB:
RENAME TABLE
would result in a hang due to a MySQL mutex acquisition deadlock. (Bug #16305265)InnoDB: For debug builds,
InnoDB
status exporting was subject to a race condition that could cause a server exit. (Bug #16292043)InnoDB: InnoDB now aborts execution on Windows by calling the
abort()
function directly, as it does on other platforms. (Bug #16263506)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: 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
innodb_change_buffering=changes
, to turn off change buffering for purge operations. (Bug #16183892, Bug #14636528)InnoDB: Arithmetic underflow during page compression for
CREATE TABLE
on anInnoDB
table could cause a server exit. (Bug #16089381)-
InnoDB: If the server was started with the
skip-innodb
option, orInnoDB
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 theBETWEEN
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: Backtick (
`
) 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 issue is a regression of: Bug #14548159, Bug #66550.
Replication: Using the
--replicate-*
options (see Replication Slave Options and Variables) could in some cases lead to a memory leak on the slave. (Bug #16056813, Bug #67983)-
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.
Microsoft Windows: 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)
SHOW ENGINE PERFORMANCE_SCHEMA STATUS
could report incorrect memory-allocation values when the correct values exceeded 4GB. (Bug #16414644)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)
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)Incorrect results were returned if a query contained a subquery in an
IN
clause which contained anXOR
operation in theWHERE
clause. (Bug #16311231)For upgrade operations, RPM packages produced unnecessary errors about being unable to access
.err
files. (Bug #16235828)yaSSL did not perform proper padding checks, but instead examined only the last byte of cleartext and used it to determine how many bytes to remove. (Bug #16218104)
Invocation of the range optimizer for a
NULL
select caused the server to exit. (Bug #16192219)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 adummy.bak
file that preventedDROP DATABASE
from working. This file is no longer included. Also, adb.opt
file is now included that contains these lines:default-character-set=latin1 default-collation=latin1_swedish_ci
(Bug #16062056)
Issuing a
PREPARE
statement using certain combinations of stored functions and user variables caused the server to exit. (Bug #16056537)Setting a system variable to
DEFAULT
could cause the server to exit. (Bug #16044655)When a partition is missing, code in
ha_innodb.cc
would retry 10 times and sleep for a microsecond each time while holdingLOCK_open
. The retry logic for partitioned tables was introduced as a fix for Bug#33349 but did not include a test case to validate it. This fix removes the retry logic for partitioned tables. If the problem reported in Bug#33349 reappears, a different solution will be explored. (Bug #15973904)Contention in the thread pool during kill processing could lead to a Valgrind panic. (Bug #15921866)
The MSI Installer installed MySQL in “per-user” mode, which could result in conflicts or failure to detect an existing installation if two users installed MySQL on the same machine. Now the MSI Installer uses “per-machine” installation mode. (Bug #14711808)
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 nextmysql_stmt_prepare()
returns an error (as expected) but subsequentmysql_stmt_execute()
calls crash the client. (Bug #14553380)SHOW COLUMNS
on a view defined as aUNION
ofGeometry
columns could cause the server to exit. (Bug #14362617)A
LIKE
pattern with too many'%'
wildcards could cause a segmentation fault. (Bug #14303860)SET
could cause the server to exit. This syntax is now prohibited because invar_name
= VALUES(col_name
)SET
context there is no column name and the statement returnsER_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 anotherSELECT
. (Bug #13068506)mysql_install_db did not escape
'_'
in the host name for statements written to the grant tables. (Bug #11746817)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 bundledzlib
if the functions are missing. (Bug #65856, Bug #14300733)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)
Incorrect metadata could be produced for columns returned from some views. (Bug #65379, Bug #14096619)
If the server was started without a
--datadir
option,SHOW VARIABLES
could show an empty value for thedatadir
system variable. (Bug #60995, Bug #12546953)For debug builds, some queries with
SELECT ... FROM DUAL
nested subqueries raised an assertion. (Bug #60305, Bug #11827369)UNION ALL
onBLOB
columns could produce incorrect results. (Bug #50136, Bug #11758009)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
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)Setting
max_connections
to a value less than the current number of open connections caused the server to exit. (Bug #44100, Bug #11752803)The optimizer used loose index scan for some queries for which this access method is inapplicable. (Bug #42785, Bug #11751794)
View access in low memory conditions could raise a debugging assertion. (Bug #39307, Bug #11749556)