Functionality added or changed:
Incompatible Change:
If you upgrade to MySQL 5.4.3 from an earlier 5.4 release, the
server may fail to start due to changes in the default values of
innodb_log_files_in_group
and
innodb_log_file_size
, which
differ from those in earlier 5.4 releases. You should discard
the old InnoDB
log files and let
MySQL 5.4.3 create new ones. It is necessary to shut down your
current server cleanly so that no outstanding transaction
information remains in the log. The procedure to use depends on
the value of
innodb_fast_shutdown
used in
your current server:
If innodb_fast_shutdown
is
not set to 2: Stop your current MySQL server and make sure
that it shuts down without errors (to ensure that there is
no information for outstanding transactions in the log).
Copy the old log files into a safe place in case something
went wrong during the shutdown and you need them to recover
the tablespace. Delete the old log files and edit
my.cnf
if necessary to specify the
desired log file configuration. Then upgrade to MySQL 5.4.3
and start the new server. mysqld sees
that no InnoDB
log files exist
at startup and creates new ones.
If innodb_fast_shutdown
is
set to 2: Shut down your current server, set
innodb_fast_shutdown
to 1,
and restart the server. The server should be allowed to
recover. Then you should shut down the server again and
follow the procedure described in the preceding item to
change InnoDB
log file size.
Set innodb_fast_shutdown
back to 2 and start the MySQL 5.4.3 server.
Incompatible Change:
The following list indicates InnoDB
configuration changes in MySQL 5.4.3, compared to previous
versions of MySQL 5.4. For a description of cumulative changes
in MySQL 5.4 compared to MySQL 5.1, see
Section 1.5, “What Is New in MySQL 5.4”.
The default value of these system variables was changed:
Variable | Change in default value |
---|---|
innodb_autoextend_increment
|
From 64MB to 8MB |
innodb_buffer_pool_size
|
From 1GB to 128MB |
innodb_log_buffer_size
|
From 16MB to 8MB |
innodb_log_file_size
|
From 128MB to 5MB |
innodb_log_files_in_group
|
From 3 to 2 |
innodb_read_io_threads
|
From 8 to 4 |
innodb_write_io_threads
|
From 8 to 4 |
These default value changes in most cases revert changes made in earlier MySQL 5.4 releases. The result is that the defaults are more similar to those in MySQL 5.1.
On Linux (and perhaps other systems), the performance of MySQL
Server can be improved by using a different
malloc()
implementation, developed by Google
and called tcmalloc
. The gain is noticeable
with a higher number of simultaneous users. MySQL 5.4.1 was
linked against this library, which improved performance but
imposed some restrictions. As a result of these restrictions,
MySQL 5.4.3 uses a different approach:
The server is linked against the default
malloc()
provided by the respective
platform.
Binary distributions for Linux include
libtcmalloc_minimal.so
(a shared
library that can be linked against at runtime) in
pkglibdir
(that is, the same directory
within the package where server plugins and similar object
files are located). The version of
tcmalloc
included with MySQL 5.4.3 comes
from google-perftools
1.4.
If you want to try tcmalloc
but are using
a binary distribution for a non-Linux platform or a source
distribution, you can install Google's
tcmalloc
. Some distributions provide it
in a google-perftools
package or with a
similar name, or you can download it from Google at
http://code.google.com/p/google-perftools/
and compile it yourself.
mysqld_safe now supports a
--malloc-lib
option that
enables administrators to specify that
mysqld should use
tcmalloc
.
The --malloc-lib
option
works by modifying the LD_PRELOAD
environment
value to affect dynamic linking to enable the loader to find the
memory-allocation library when mysqld runs:
If the option is not given, or is given without a value
(--malloc-lib=
),
LD_PRELOAD
is not modified and no attempt
is made to use tcmalloc
.
If the option is given as
--malloc-lib=tcmalloc
,
mysqld_safe looks for a
tcmalloc
library in
/usr/lib
and then in the MySQL
pkglibdir
location (for example,
/usr/local/mysql/lib
or whatever is
appropriate). If tmalloc
is found, its
path name is added to the beginning of the
LD_PRELOAD
value for
mysqld. If tcmalloc
is
not found, mysqld_safe aborts with an
error.
If the option is given as
--malloc-lib=
,
that full path is added to the beginning of the
/path/to/some/library
LD_PRELOAD
value. If the full path points
to a nonexistent or unreadable file,
mysqld_safe aborts with an error.
For cases where mysqld_safe adds a path
name to LD_PRELOAD
, it adds the path to
the beginning of any existing value the variable already
has.
As a result of the preceding changes, Linux users can use the
libtcmalloc_minimal.so
now included in
binary packages by adding these lines to the
my.cnf
file:
[mysqld_safe] malloc-lib=tcmalloc
Those lines also suffice for users on any platform who have
installed a tcmalloc
package in
/usr/lib
. To use a specific
tcmalloc
library, specify its full path name.
Example:
[mysqld_safe] malloc-lib=/opt/lib/libtcmalloc_minimal.so
Bugs fixed:
Performance:
For MyISAM
tables with
bulk_insert_buffer_size
values
larger than 256KB, the performance of bulk insert operations
such as multiple-row INSERT
and
INSERT ...
SELECT
operations has been improved greatly when up to
a hundred rows are inserted at the same time.
(Bug#44723)
Partitioning: Replication:
Attempting to replicate an
INSERT ...
SELECT
statement on a partitioned table using
row-based replication caused the slave to crash.
(Bug#44108)
Partitioning: When reorganizing partitions, not all affected subpartitions were removed prior to renaming. One way in which the issue was visible was that attempting to reorganize two partitions into a single partition having the same name as one of the original partitions could lead to a crash of the server. (Bug#47029)
Partitioning:
An INSERT ...
SELECT
statement on an empty partition of a
partitioned table failed with ERROR 1030 (HY000): Got
error 124 from storage engine. This issue also
caused queries run against a partitioned table while a
LOAD DATA CONCURRENT
INFILE
statement was in progress to fail with the same
error.
(Bug#46639)
Partitioning:
An online or fast ALTER TABLE
of
a partitioned table could leave behind temporary files in the
database directory.
(Bug#46483)
Partitioning:
A partitioned table having a
TIMESTAMP
column with a default
value of CURRENT_TIMESTAMP
and this column
was not defined using an ON UPDATE
option, an
ALTER TABLE ...
REORGANIZE PARTITION
statement on the table caused the
TIMESTAMP
column value to be set
to CURRENT_TIMESTAMP
regardless.
(Bug#46478)
Partitioning:
Partition pruning did not always work correctly when the
table's partitioning key used the
TO_DAYS()
function.
(Bug#46362)
Partitioning:
Inserting negative values into an
AUTO_INCREMENT
column of a partitioned table
could lead to apparently unrelated errors or a crash of the
server.
(Bug#45823)
Partitioning: Attempting to access a partitioned table when partitioning support was disabled in a MySQL server binary that had been compiled with partitioning support caused the server to crash. (Bug#39893)
Partitioning: Unnecessary calls were made in the server code for performing bulk inserts on partitions for which no inserts needed to be made. (Bug#35845)
See also Bug#35843.
Partitioning:
The use of TO_DAYS()
in the
partitioning expression led to selection failures when the
column having the date value contained invalid dates. This
occurred because the function returns NULL
in
such cases, and the partition containing NULL values was pruned
away. For example, this problem occurred if
'2001-02-00'
was inserted into a
DATE
column of such a table, and
a subsequent query on this table used WHERE
— while date_col
< '2001-02-00''2001-01-01'
is less than
'2001-02-00'
,
TO_DAYS('2001-02-00')
evaluates as
NULL
, and so the row containing
'2001-01-01'
was not returned. Now, for
tables using RANGE
or LIST
partitioning and having TO_DAYS()
in the partitioning expression, the NULL
partition is also scanned instead of being ignored.
The fix for this issue also corrects misbehavior such that a
query of the form SELECT * FROM
on a table
partitioned by table
WHERE
date_col
<
date_val
RANGE
or
LIST
was handled as though the server SQL
mode included
ALLOW_INVALID_DATES
even if
this was not actually part of the server SQL mode at the time
the query was issued.
(Bug#20577)
Replication:
Performing a multi-row update of the
AUTO_INCREMENT
column of a transactional
table could result in an inconsistency between master and slave
when there was a trigger on the transactional table that updated
a nontransactional table. When such an update failed on the
master, no rows were updated on the master, but some rows could
(erroneously) be updated on the slave.
(Bug#46864)
Replication:
When using the
--replicate-rewrite-db
option and
the database referenced by this option on the master was the
current database when the connection to the slave was closed,
any temporary tables existing in this database were not properly
dropped.
(Bug#46861)
Replication: When a statement that changed both transactional and nontransactional tables failed, the transactional changes were automatically rolled back on the master but the slave ignored the error and did not roll them back, thus leading to inconsistencies between master and slave.
This issue is fixed by automatically rolling back a statement
that fails on the slave; however, the transaction is not rolled
back unless a corresponding
ROLLBACK
statement is found in the relay log file.
(Bug#46130)
See also Bug#33864.
Replication:
When using row-based replication, importing a dump made with
mysqldump and replicating a row with an
AUTO_INCREMENT
column set to 0, with
NO_AUTO_VALUE_ON_ZERO
active
on the master, the row was inserted successfully on the master;
however any setting for
NO_AUTO_VALUE_ON_ZERO
was
ignored on the slave. When the AUTO_INCREMENT
column was incremented, this caused replication to fail on the
slave due to a duplicate key error. In some cases it could also
cause the slave to crash.
(Bug#45999)
Replication:
When slave_transaction_retries
is set, a statement that replicates, but is then rolled back due
to a deadlock on the slave, should be retried. However, in
certain cases, replication was stopped with error 1213
(Deadlock found when trying to get lock; try
restarting transaction) instead, even when this
variable was set.
(Bug#45694)
Replication:
The binary logging behavior (and thus, the replication behavior)
of CREATE
DATABASE IF NOT EXISTS
,
CREATE TABLE IF
NOT EXISTS
, and
CREATE EVENT IF
NOT EXISTS
was not consistent among these statements,
nor with that of
DROP DATABASE IF
EXISTS
,
DROP TABLE IF
EXISTS
, and
DROP EVENT IF
EXISTS
: A DROP ... IF EXISTS
statement is always logged even if the database object named in
the statement does not exist. However, of the CREATE
... IF NOT EXISTS
statements, only the
CREATE EVENT IF
NOT EXISTS
statement was logged when the database
object named in the statement already existed.
Now, every CREATE ... IF NOT EXISTS
statement
is written to the binary log (and thus replicated), whether the
database object named in the statement exists or not. For more
information, see
Section 16.4.1.3, “Replication of CREATE ... IF NOT EXISTS
Statements”.
Exception.
Replication and logging of
CREATE TABLE IF
NOT EXISTS ... SELECT
continues to be handled
according to existing rules. See
Section 16.4.1.4, “Replication of CREATE
TABLE ... SELECT
Statements”, for more
information.
Replication:
When using statement-based replication, database-level character
sets were not always honored by the replication SQL thread. This
could cause data inserted on the master using
LOAD DATA
to be replicated using
the wrong character set.
This was not an issue when using row-based replication.
Replication:
In some cases, a STOP SLAVE
statement could cause the replication slave to crash. This issue
was specific to MySQL on Windows or Macintosh platforms.
(Bug#45238, Bug#45242, Bug#45243, Bug#46013, Bug#46014, Bug#46030)
See also Bug#40796.
Replication:
Creating a scheduled event whose DEFINER
clause was either set to
CURRENT_USER
or not set
explicitly caused the master and the slave to become
inconsistent. This issue stems from the fact that, in both
cases, the DEFINER
is set to the
CURRENT_USER
of the current
thread. (On the master, the
CURRENT_USER
is the
mysqld user; on the slave, the
CURRENT_USER
is empty.)
This behavior has been modified as follows:
If CURRENT_USER
is used as
the DEFINER
, it is replaced with the
value of
CURRENT_USER
before the
CREATE EVENT
statement is
written to the binary log.
If the definer is not set explicitly, a
DEFINER
clause using the value of
CURRENT_USER
is added to the
CREATE EVENT
statement before
it is written to the binary log.
See also Bug#42217.
Replication:
When using the statement-based logging format, the only possible
safe combination of transactional and nontransactional
statements within the same transaction is to perform any updates
on nontransactional tables (such as
MyISAM
tables) first, before
updating any transactional tables (such as those using the
InnoDB
storage engine). This is due
to the fact that, although a modification made to a
nontransactional table is immediately visible to other
connections, the update is not immediately written to the binary
log, which can lead to inconsistencies between master and slave.
(Other combinations may hide a causal dependency, thus making it
impossible to write statements updating nontransactional tables
to the binary log in the correct order.)
However, in some cases, this situation was not handled properly, and the determination whether a given statement was safe or not under these conditions was not always correct. In particular, a multi-table update that affected both transactional and nontransactional tables or a statement modifying data in a nontransactional table having a trigger that operated on a transactional table (or the reverse) was not determined to be unsafe when it should have been.
With this fix, the following determinations regarding replication safety are made when combining updates to transactional and nontransactional tables within the same transaction in statement-based logging mode:
Any statement modifying data in a nontransactional table within a given transaction is considered safe if it is issued prior to any data modification statement accessing a transactional table within the same transaction.
A statement that updates transactional tables only is always considered safe.
A statement affecting both transactional and
nontransactional tables within a transaction is always
considered unsafe. It is not necessary that both tables be
modified for this to be true; for example, a statement such
as INSERT INTO
is also
considered unsafe.
innodb_table
SELECT * FROM
myisam_table
The current fix is valid only when using statement-based
logging mode; we plan to address similar issues occurring when
using the MIXED
or ROW
format in a future MySQL release.
The ARCHIVE
storage engine lost
records during a bulk insert.
(Bug#46961)
CONCAT_WS()
could return
incorrect results due to an argument buffer also being used as a
result buffer.
(Bug#46815)
Stack overflow checking did not account for the size of the structure stored in the heap. (Bug#46807)
The server crashed when re-using outer column references in correlated subqueries when the enclosing query used a temp table. (Bug#46791)
The server could crash for queries with the following elements:
1. An “impossible where” in the outermost
SELECT
; 2. An aggregate in the outermost
SELECT
; 3. A correlated subquery with a
WHERE
clause that includes an outer field
reference as a top-level WHERE
sargable
predicate;
(Bug#46749)
Assertion failure could result from repeated execution of a stored procedure containing an incorrect query with a subselect. (Bug#46629)
CREATE TABLE ...
SELECT
could cause assertion failure if a table
already existed with the same name and contained an
AUTO_INCREMENT
column.
(Bug#46616)
SHOW CREATE TRIGGER
for a
MERGE
table trigger caused an
assertion failure.
(Bug#46614)
In queries for which the loose index scan access method was
chosen, using a condition of the form
col_name
rather than the equivalent
caused an assertion failure.
(Bug#46607)col_name
<>
0
The server ignored the setting of
sync_frm
for
CREATE TABLE ...
LIKE
.
(Bug#46591)
TRUNCATE TABLE
for a table that
was opened with HANDLER
did not
close the handler and left it in an inconsistent state that
could lead to a server crash. Now TRUNCATE
TABLE
for a table closes all open handlers for the
table.
(Bug#46456)
An attempt to create a table with the same name as an existing view could cause a server crash. (Bug#46384)
A parser problem prevented properly stripping backquotes from an
argument to a user-defined function (UDF). If the UDF was in an
ORDER BY
clause, its name would not be
properly resolved against an alias with the same name in the
select list.
(Bug#46259)
A query containing a subquery in the FROM
clause and PROCEDURE ANALYSE()
caused a
server crash.
(Bug#46184)
See also Bug#48293.
Certain SELECT
statements
containing DISTINCT
, GROUP
BY
, and HAVING
clauses could hang
in an infinite loop.
(Bug#46159)
Killing a query that was performing a sort could result in a memory leak. (Bug#45962)
A Valgrind error when opening the
init_file
file was corrected.
(Bug#45894)
CREATE TEMPORARY TABLE
failed for
InnoDB
tables on systems with
case-insensitive file systems when
lower_case_table_names
= 2
and the pathname of the temporary file
directory contained uppercase characters.
(Bug#45638)
Truncation of DECIMAL
values
could lead to assertion failures; for example, when deducing the
type of a table column from a literal
DECIMAL
value.
(Bug#45261)
See also Bug#48370.
When re-installing MySQL on Windows on a server that has a data
directory from a previous MySQL installation, the installer
would fail to identify the existence of the installation and the
password configured for the root
user.
(Bug#45200)
Debug builds of the server on Windows crashed in debugging code. (Bug#45118)
The default value of
innodb_buffer_pool_size
was set
to 1GB in MySQL 5.4.0. This was too large for many
installations, so the default has been lowered to 128MB.
(Bug#44408)
SHOW ERRORS
returned an empty
result set after an attempt to drop a nonexistent table.
(Bug#42364)
A test for stack growth failed on some platforms, leading to server crashes. (Bug#42213)
A buffer overflow could occur during handling of IS
NULL
ranges.
(Bug#37044)
mysqladmin --wait ping crashed on Windows systems. (Bug#35132)
myisamchk performed parameter value casting at startup that generated unnecessary warning messages. (Bug#33785)
When using the ARCHIVE
storage
engine, SHOW TABLE STATUS
displayed incorrect
information for Max_data_length
,
Data_length
and
Avg_row_length
.
(Bug#29203)
User Comments
Add your own comment.