MySQL now supports pluggable authentication, such that the server uses plugins to authenticate incoming client connections. Client programs load an authentication plugin that interacts properly with the corresponding server plugin.
Pluggable authentication enables two important capabilities, external authentication and proxy users:
Pluggable authentication makes it possible for clients to
connect to the MySQL server with credentials that are
appropriate for authentication methods other than native
authentication based on passwords stored in the
mysql.user table. For example, plugins
can be created to use external authentication methods such
as PAM, Windows login IDs, LDAP, or Kerberos.
If a user is permitted to connect, an authentication plugin can return to the server a user name different from the name of the connecting user, to indicate that the connecting user is a proxy for another user. While the connection lasts, the proxy user is treated, for purposes of access control, as having the privileges of a different user. In effect, one user impersonates another.
Pluggable authentication entails these changes:
mysql.user table, there are new
columns that specify plugin information. The
plugin column, if nonempty, indicates
which plugin authenticates connections for an account. The
authentication_string column is a string
that the server passes to the plugin for connections by
clients that authenticate using the plugin.
API function, there are new
MYSQL_PLUGIN_DIR options that enable
client programs to load authentication plugins.
For the mysql client, there are new
--plugin-dir options for
specifying which authentication plugin and plugin directory
to use. These options will be added to other clients in
For the mysqltest client, there is a new
--plugin-dir option for
specifying which plugin directory to use, and a new
connect() command argument to specify an
For the server plugin API, there is a new
MYSQL_AUTHENTICATION_PLUGIN plugin type.
A new client plugin API enables client programs to manage plugins.
The native authentication methods previously supported in
MySQL have been reimplemented as plugins. These methods
provide against the current password format and pre-MySQL
4.1.1 format that uses shorter password hash values. This
change reimplements the native methods as plugins that
cannot be unloaded. Existing clients authenticate as before
with no changes needed. In particular, starting the server
still prevents clients that have pre-4.1.1 password hashes
from connecting, and
disables all password checking.
Proxy user capability entails these changes:
Due to these changes, the server requires that a new grant
proxies_priv, be present in the
mysql database. If you are upgrading to MySQL
5.5.7 from a previous MySQL release rather than performing a new
installation, the server will find that this table is missing
and exit during startup with the following message:
Table 'mysql.proxies_priv' doesn't exist
To create the
proxies_priv table, start the
server with the
--skip-grant-tables option to
cause it to skip the normal grant table checks, then run
mysql_upgrade. For example:
mysqld --skip-grant-tables &shell>
Then stop the server and restart it normally.
You can specify other options on the mysqld
command line if necessary. Alternatively, if your installation
is configured so that the server normally reads options from an
option file, use the
--defaults-file option to
specify the file (enter each command on a single line):
option, the server does no password or privilege checking, so
any client can connect and effectively have all privileges. For
additional security, use the
--skip-networking option as well
to prevent remote clients from connecting.
The upgrade problem just described is fixed in MySQL 5.5.8.
The server treats a missing
table as equivalent to an empty table.
For additional information, consult these references:
Information about pluggable authentication, including installation and usage instructions: Pluggable Authentication.
Information about proxy users: Proxy Users.
Information about the server and client plugin API: Writing Plugins.
Information about the C API functions for managing client plugins: See C API Client Plugin Functions.
Information about current restrictions on the use of pluggable authentication, including which connectors support which plugins: See Restrictions on Pluggable Authentication. Third-party connector developers should read that section to determine the extent to which a connector can take advantage of pluggable authentication capabilities and what steps to take to become more compliant.
MySQL releases now are built using CMake rather than the GNU autotools. Accordingly, the instructions for installing MySQL from source have been updated to discuss how to build MySQL using CMake. See Installing MySQL from Source. If you are familiar with autotools but not CMake, you might find these transition instructions helpful: Autotools to CMake Transition Guide
The build process is now similar enough on all platforms, including Windows, that there are no longer sections dedicated to notes for specific platforms.
The default installation layout when compiling from source now matches that used for binary distributions. You will notice these differences for installations from source distributions:
mysqld is installed in
mysql_install_db is installed in
The data directory is
The make_binary_distribution and
make_win_bin_dist scripts are now obsolete.
To create a binary distribution, use make
Functionality Added or Changed
Previously, if you flushed the logs using
FLUSH LOGS or
mysqladmin flush-logs and
mysqld was writing the error log to a file
(for example, if it was started with the
--log-error option), it renamed
the current log file with the suffix
then created a new empty log file. This had the problem that a
second log-flushing operation thus caused the original error log
file to be lost unless you saved it under a different name. For
example, you could use the following commands to save the file:
To avoid the preceding file-loss problem, renaming no longer occurs. The server merely closes and reopens the log file. To rename the file, you can do so manually before flushing. Then flushing the logs reopens a new file with the original file name. For example, you can rename the file and create a new one using the following commands:
References: See also Bug #56821.
A new status variable,
the number of requests to read the last key in an index. With
ORDER BY, the server issues a first-key
request followed by several next-key requests, whereas with
ORDER BY DESC, the server issues a last-key
request followed by several previous-key requests.
The unused and undocumented
system variable was removed.
Added a new
Waiting for query cache lock. This
indicates that a session is waiting to take the query cache lock
while it performs some query cache operation.
pstack library was nonfunctional and has
been removed, along with the
option for configure and the
--enable-pstack option for
Previously, the server supported values of
FORCE for the
option format for controlling plugin loading using an option
named after the plugin. Such options now support a
FORCE_PLUS_PERMANENT value. This value is
FORCE, but in addition prevents the
plugin from being unloaded at runtime. If a user attempts to do
UNINSTALL PLUGIN, an
error occurs. See Installing and Uninstalling Plugins.
In addition, the
now has a
LOAD_OPTION column that indicates
the plugin loading value (
INFORMATION_SCHEMA PLUGINS Table.
Security Fix; Incompatible Change; InnoDB:
TRUNCATE TABLE and
examining the same table's information in the
INFORMATION_SCHEMA database at the same time
could cause a crash in the debug version of the server.
As a result of this change,
uses the fast truncation technique, equivalent to
DROP TABLE and
CREATE TABLE. It no longer
performs a row-by-row delete for tables with parent-child
foreign key relationships.
TABLE returns an error for such tables. Modify your
SQL to issue
for such tables
PolyFromWKB() function could
crash the server when improper WKB data was passed to the
(Bug #51875, Bug #11759554, CVE-2010-3840)
EXPLAIN EXTENDED caused a server
crash with some prepared statements.
The server crashed for assignment of values of types other than
Geometry to items of type
MultiSurface). Now the server checks the
value type and fails with
bad geometry value
if it detects incorrect parameters.
InnoDB background thread could
sometimes cause transient performance drops due to excessive
flushing of modified pages.
Incompatible Change; Replication:
The behavior of
statements when using statement-based replication has changed as
INSERT DELAYED continues to be
INSERT (without the
DELAYED option). The behavior of
INSERT DELAYED remains unchanged
INSERT DELAYED generates no
warnings, is executed as
DELAYED, and is logged using the row-based format.
This change also affects
INSERT DELAYED is no longer
considered unsafe. Now, when the logging format is
MIXED, no switch to row-based logging occurs.
This means that the statement is logged as a simple
INSERT (that is, without the
DELAYED option), using the statement-based
(Bug #54579, Bug #11762035)
References: See also Bug #56678, Bug #11763907, Bug #57666. This bug was introduced by Bug #39934, Bug #11749859.
READ statements that invoke stored functions can cause
replication errors. Such statements are now disallowed and
result in an
Important Change; InnoDB:
The server could crash with an assertion, possibly leading to
data corruption, while updating the primary key of an
InnoDB table containing
BLOB or other columns requiring
off-page storage. This fix applies to the
InnoDB Plugin in MySQL 5.1, and to
InnoDB 1.1 in MySQL 5.5.
If the master had
or both, certain
options, such as
ignored. This could permit the master to avoid raising
However, the ignored
options were still written into the binary log, so that, if the
it could encounter an
ER_TOO_BIG_ROWSIZE error while
executing the record from the log, causing the slave SQL thread
to abort and replication to fail.
In the case where the master was running MySQL 5.1 and the slave
was MySQL 5.5 (or later), the failure occurred when both master
and slave were running with default values for
innodb_file_format. This could
cause problems during upgrades.
To address this issue, the default values for
innodb_file_format are reverted
to the MySQL 5.1 default values—that is,
(Bug #56318, Bug #11763590)
If the server crashed during a
operation on an
InnoDB table, subsequent
crash recovery could fail. This problem could also affect an
ALTER TABLE statement that caused a rename
The output from the
SHOW ENGINE INNODB
STATUS command can now be up to 1MB. Formerly, it was
truncated at 64KB. Monitoring applications that parse that
output can check whether it exceeds this new, larger limit by
Changed the locking mechanism for the
data dictionary during
to improve concurrency for
Improved the performance of
InnoDB tables, when only non-indexed
columns are changed.
The server could crash on shutdown, if started with
InnoDB: A heavy workload with a large number of threads could cause a crash in the debug version of the server. (Bug #55699)
When MySQL was restarted after a crash with the option
innodb_force_recovery=6, certain queries
InnoDB tables could fail, depending
Usually in such a disaster recovery situation, you dump the entire table using a query without these clauses. During advanced troubleshooting, you might use queries with these clauses to diagnose the position of the corrupted data, or to recover data following the corrupted part. (Bug #55832)
For debug builds, a
SELECT ... FOR UPDATE
statement affecting a range of rows in an
InnoDB table could cause a server crash.
If the server crashed during an
TABLE operation on an
examining the table through
SHOW CREATE TABLE
or querying the
could cause the server to stop with an assertion error.
InnoDB incorrectly reported an error when a
cascading foreign key constraint deleted more than 250 rows.
InnoDB startup messages now include the start
and end times for buffer pool initialization, and the total
buffer pool size.
With multiple buffer pools enabled,
could flush more data from the buffer pool than necessary,
causing extra I/O overhead.
CHECK TABLE command could cause a
time-consuming verification of the
adaptive hash index memory structure. Now this extra checking is
only performed in binaries built for debugging.
InnoDB transactions could be incorrectly
committed during recovery, rather than rolled back, if the
server crashed and was restarted after performing
TABLE ... ADD PRIMARY KEY on an
InnoDB table, or some other operation that
involves copying the entire table.
PACK_KEYS=0 table option for an
InnoDB table prevented new indexes
from being added to the table.
The server could crash when opening an
InnoDB table linked through foreign
keys to a long chain of child tables.
TABLE statement acting on table partitions that failed
while the affected table was locked could cause the server to
involving a partitioned
table could cause this table to become corrupted. Not all tables
affected by the
UPDATE needed to
be partitioned for this issue to be observed.
PARTITIONS returned bad estimates for range queries on
MyISAM tables. In
addition, values in the
rows column of
PARTITIONS output did not take partition pruning into
(Bug #53806, Bug #46754)
SET PASSWORD caused failure of
row-based replication between a MySQL 5.1 master and a MySQL 5.5
This fix makes it possible to replicate
PASSWORD correctly, using row-based replication
between a master running MySQL 5.1.53 or a later MySQL 5.1
release to a slave running MySQL 5.5.7 or a later MySQL 5.5
References: See also Bug #55452, Bug #57357.
When a slave tried to execute a transaction larger than the
slave's value for
crashed. This was caused by an assertion that the server should
roll back only the statement but not the entire transaction when
occurred. However, the slave SQL thread always rolled back the
entire transaction whenever any error occurred, regardless of
the type of error.
The error message for
was hard coded in English in
so that it could not be translated in
errmsg.txt for other languages.
Additionally, this same error message was used for three separate error conditions:
When the heartbeat period exceeded the value of
When the heartbeat period was nonnegative but shorter than 1 millisecond.
When the value for the heartbeat period was either negative or greater than the maximum permitted.
These issues have been addressed as follows:
By using three distinct error messages for each of the conditions listed previously.
By moving the sources for these error messages into the
errmsg-utf8.txt file to facilitate
translations into languages other than English.
Replication: Backticks used to enclose identifiers for savepoints were not preserved in the binary log, which could lead to replication failure when the identifier, stripped of backticks, could be misinterpreted, causing a syntax or other error.
This could cause problems with MySQL application programs making
use of generated savepoint IDs. If, for instance,
java.sql.Connection.setSavepoint() is called
without any parameters, Connector/J automatically generates a
savepoint identifier consisting of a string of hexadecimal
F encased in
`) characters. If such an ID took
N represents a string of the
e is a literal uppercase or lowercase
“E” character). Removing the backticks when writing
the identifier into the binary log left behind a substring which
the slave MySQL server tried to interpret as a floating point
number, rather than as an identifier. The resulting syntax error
caused loss of replication.
References: See also Bug #55962.
DELAYED statements were written to the binary log
(Bug #56678, Bug #11763907)
References: This bug is a regression of Bug #54579, Bug #11762035.
Multiple-statement execution could fail. (Bug #40877)
The server entered an infinite loop with high CPU utilization after an error occurred during flushing of the I/O cache. (Bug #55629)
Performance for certain read-only queries, in particular
point_select, had deteriorated compared to
REPAIR TABLE on a
MERGE table caused the
server to crash.
INFILE, using a
SET clause to set a
column equal to itself caused a server crash.
For the Performance Schema, the default number of rwlock classes
was increased to 30, and the default number of rwlock and mutex
instances was increased to 1 million. These changes were made to
account for the volume of data instrumented when the
InnoDB storage engine is used
(because of the
Trailing space removal for
utf32 strings was
done with non-multi-byte-safe code, leading to incorrect result
length and assertion failure.
plugin_audit.h include files are part of
the public API/ABI, but were not tested by the ABI check.
The fix for Bug #30234 caused the server to reject the
DELETE Access compatibility syntax for multiple-table
INFORMATION_SCHEMA plugins with no
deinit() method resulted in a memory leak.
If a view was named as the destination table for
TABLE ... SELECT, the server produced a warning
whether or not
IF NOT EXISTS was used. Now it
produces a warning only when
IF NOT EXISTS is
used, and an error otherwise.
SETUP_INSTRUMENTS.TIMER = 'NO' caused
TIMER_WAIT values for aggregations to be
NULL rather than 0.
Short (single-letter) command-line options did not work. (Bug #55873)
Queries involving predicates of the form
incorrect data due to incorrect handling by the range optimizer.
const NOT BETWEEN
After the fix for Bug #39653, the shortest available secondary index was used for full table scans. The primary clustered key was used only if no secondary index could be used. However, when the chosen secondary index includes all columns of the table being scanned, it is better to use the primary index because the amount of data to scan is the same but the primary index is clustered. This is now taken into account. (Bug #55656)
If one session attempted to drop a database containing a table
which another session had opened with
HANDLER, any instance of
CREATE DATABASE, or
DROP DATABASE issued by the
latter session produced a deadlock.
In debug builds, the server raised an assertion for
DROP DATABASE in installations
that had an outdated or corrupted
table. For example, this affected
mysql_upgrade when run as part of a MySQL 5.1
to 5.5 upgrade.
The ordering for supplementary characters in the
utf32_bin collations was incorrect.
It was possible to compile mysqld with Performance Schema support but with a dummy atomic-operations implementation, which caused a server crash. This problem does not affect binary distributions. It is helpful as a safety measure for users who build MySQL from source. (Bug #56521)
An atomic “compare and swap” operation using x86 assembly code (32 bit) could access incorrect data, which would make it work incorrectly and lose the intended atomicity. This in turn caused the MySQL server to work on inconsistent data structures and return incorrect data. That code affected only 32-bit builds; the effect has been observed when icc was used to build binaries. With gcc, no incorrect results have been observed during tests, so this fix is a proactive one. Other compilers do not use this assembly code. (Bug #52419)
Row subqueries producing no rows were not handled as
UNKNOWN values in row-comparison expressions.
In some cases, when the left part of a
subquery predicate was a row and contained
NULL values, the query result was incorrect.
EXPLAIN produced an incorrect
rows value for queries evaluated using an
index scan and that included
GROUP BY, and
ORDER BY on
a computed column.
A malformed packet sent by the server when the query cache was in use resulted in lost-connection errors. (Bug #42503)
For some queries, the optimizer produced incorrect results using
the Index Merge access method with
IGNORE statement including a subquery that was
evaluated using a temporary table, an error transferring the
data from the temporary was ignored, causing an assertion to be
CREATE TABLE failed if a column
referred to in an index definition and foreign key definition
had different lettercases in the two definitions.
If a query specified a
DATETIME value in a format
'YYYY-MM-DD HH:MM:SS', a
matched only greater-than values in an indexed
(Bug #55779, Bug #50774, Bug #11758558)
If there was an active
statement, an error arising during trigger execution could cause
a server crash.
mysql_use_result() are not for
use with prepared statements and are not intended to be called
but failed to return an error when invoked that way.
A buffer overrun could occur when formatting
tcmalloc library was missing from binary
MySQL packages for Linux.
If an application using the embedded server called
mysql_library_init() a second
time after calling
mysql_library_end() to start and
stop the server, the application crashed when reading option
max_length metadata value of
MEDIUMBLOB types was reported as
1 byte greater than the correct value.
The server could crash during shutdown due to a race condition relating to Performance Schema cleanup. (Bug #55105, Bug #56324)
The server could crash inside
reading certain Performance Schema tables.
(Bug #56761, Bug #58003)
CHECKSUM TABLE for Performance
Schema tables could cause a server crash due to uninitialized
Memory leaks detected by Valgrind were corrected. (Bug #56709)
If the global and session
system variables had the same value, the debug trace file could
be closed twice, leading to freeing already freed memory and a
INSERT DELAYED statement for a
MERGE table could cause deadlock if
it occurred as part of a transaction or under
LOCK TABLES, and there was a
concurrent DDL or
LOCK TABLES ...
WRITE statement that tried to lock one of its
The server crashed if a table maintenance statement such as
ANALYZE TABLE or
REPAIR TABLE was executed on a
MERGE table and opening and locking
a child table failed. For example, this could happen if a child
table did not exist or if a lock timeout happened while waiting
for a conflicting metadata lock to disappear.
As a consequence of this bug fix, it is now possible to use
CHECK TABLE for log tables
without producing an error.
(Bug #56422, Bug #56494)
Deadlock could occur for heavily concurrent workloads consisting
of a mix of DML, DDL, and
statements affecting the same set of tables.
(Bug #56715, Bug #56404, Bug #56405)
DBUG_PRINT statement in
fill_schema_schemata() caused server crashes
after an XA transaction was already ended raised an assertion.
Comparison of one
result with another could return incorrect results.
On Solaris with gcc 3.4.6,
ha_example.so was built with DTrace support
even if the server was not, causing plugin loading problems.
When mysqld was started as a service on
Windows and mysqld was writing the error log
to a file (for example, if it was started with the
--log-error option), the server
reassigned the file descriptors of the
stderr streams to the file descriptor of
the log file. On Windows, if
stderr is not associated with an output
stream, the file descriptor returns a negative value.
Previously, this caused the file descriptor reassignment to fail
and the server to abort. To avoid this problem on Windows, the
server now first assigns the
stderr streams to the log file stream by
opening this file. This causes the
stderr file descriptors to be nonzero and the
server can successfully reassign them to the file descriptor of
the log file.
References: This bug is a regression of Bug #29751.
mysqlcheck behaved differently depending on the order in which options were given on the command line. (Bug #35269)
CASE expressions with a mix of
operands in different character sets sometimes returned
could return incorrect results.
An assertion could be raised by
DELETE on a view that referenced
another view which in turn (directly or indirectly) referenced
more than one table.
COALESCE() in MySQL 5.5 could
return a result different from MySQL 5.1 for some arguments.
References: This bug is a regression of Bug #38999.
When invoked to display a help message, mysqld also displayed spurious warning or error messages. (Bug #30025)