2010年9月28日

[installer 2523] mysql-5.1.51

mysql-5.1.51 出ています。

☆ mysql-5.1.51
http://www.mysql.com/
http://dev.mysql.com/downloads/mysql/5.1.html

C.1.1. Changes in MySQL 5.1.51 (10 September 2010)
--------------------------------------------------


InnoDB Notes:

* InnoDB Plugin has been upgraded to version 1.0.12. This version
is considered of General Availability (GA) quality.

In this release, the InnoDB Plugin is included in source and
binary distributions, except RHEL3, RHEL4, SuSE 9 (x86, x86_64,
ia64), generic Linux RPM packages, and any builds produced with
the icc compiler. It also does not work for FreeBSD 6 and HP-UX
or for Linux on generic ia64.

Bugs fixed:

* Incompatible Change: Replication: As of MySQL 5.5.6, handling of
CREATE TABLE IF NOT EXISTS ... SELECT statements has been changed
for the case that the destination table already exists:

- Previously, for CREATE TABLE IF NOT EXISTS ... SELECT, MySQL
produced a warning that the table exists, but inserted the rows
and wrote the statement to the binary log anyway. By contrast,
CREATE TABLE ... SELECT (without IF NOT EXISTS) failed with an
error, but MySQL inserted no rows and did not write the
statement to the binary log.

- MySQL now handles both statements the same way when the
destination table exists, in that neither statement inserts
rows or is written to the binary log. The difference between
them is that MySQL produces a warning when IF NOT EXISTS is
present and an error when it is not.

This change in handling of IF NOT EXISTS results in an
incompatibility for statement-based replication from a MySQL 5.1
master with the original behavior and a MySQL 5.5 slave with the
new behavior. Suppose that CREATE TABLE IF NOT EXISTS ... SELECT
is executed on the master and the destination table exists. The
result is that rows are inserted on the master but not on the
slave. (Row-based replication does not have this problem.)

To address this issue, statement-based binary logging for CREATE
TABLE IF NOT EXISTS ... SELECT is changed in MySQL 5.1 as of
5.1.51:

- If the destination table does not exist, there is no change:
The statement is logged as is.

- If the destination table does exist, the statement is logged as
the equivalent pair of CREATE TABLE IF NOT EXISTS and INSERT
... SELECT statements. (If the SELECT in the original statement
is preceded by IGNORE or REPLACE, the INSERT becomes INSERT
IGNORE or REPLACE, respectively.)

This change provides forward compatibility for statement-based
replication from MySQL 5.1 to 5.5 because when the destination
table exists, the rows will be inserted on both the master and
slave. To take advantage of this compatibility measure, the 5.1
server must be at least 5.1.51 and the 5.5 server must be at
least 5.5.6.

To upgrade an existing 5.1-to-5.5 replication scenario, upgrade
the master first to 5.1.51 or higher. Note that this differs from
the usual replication upgrade advice of upgrading the slave
first.

A workaround for applications that wish to achieve the original
effect (rows inserted regardless of whether the destination table
exists) is to use CREATE TABLE IF NOT EXISTS and INSERT
... SELECT statements rather than CREATE TABLE IF NOT EXISTS
... SELECT statements.

Along with the change just described, the following related
change was made: Previously, if an existing view was named as the
destination table for CREATE TABLE IF NOT EXISTS ... SELECT, rows
were inserted into the underlying base table and the statement
was written to the binary log. As of MySQL 5.1.51 and 5.5.6,
nothing is inserted or logged. (Bug#47442, Bug#47132, Bug#48814,
Bug#49494)

* Incompatible Change: 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 -old, 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:

shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory
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:

shell> mv host_name.err host_name.err-old
shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory
(Bug#29751)

* Partitioning: When the storage engine used to create a
partitioned table was disabled, attempting to drop the table
caused the server to crash. (Bug#46086)

* If a view was named as the destination table for CREATE 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. (Bug#55777)

* The CHECK TABLE command could cause a time-consuming verification
of the InnoDB adaptive hash index memory structure. Now this
extra checking is only performed in binaries built for
debugging. (Bug#55716)

* 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)

* (Bug#55627)

* The server was not checking for errors generated during the
execution of Item::val_xxx() methods when copying data to a
group, order, or distinct temp table's row. (Bug#55580)

* ORDER BY clauses that included user variable expressions could
cause a debug assertion to be raised. (Bug#55565)

* Queries involving predicates of the form const NOT BETWEEN
not_indexed_column AND indexed_column could return incorrect data
due to incorrect handling by the range optimizer. (Bug#54802)

* MIN() or MAX() with a subquery argument could raise a debug
assertion for debug builds or return incorrect data for nondebug
builds. (Bug#54465)

* INFORMATION_SCHEMA plugins with no deinit() method resulted in a
memory leak. (Bug#54253)

* After ALTER TABLE was used on a temporary transactional table
locked by LOCK TABLES, any later attempts to execute LOCK TABLES
or UNLOCK TABLES caused a server crash. (Bug#54117)

* INSERT IGNORE INTO ... SELECT statements could cause a debug
assertion to be raised. (Bug#54106)

The fix for Bug#30234 caused the server to reject the DELETE
tbl_name.* ... Access compatibility syntax for multiple-table
DELETE statements. (Bug#53034)

* Enumeration plugin variables were subject to a type casting
error, causing inconsistent results between different
platforms. (Bug#42144)

* A PKG install on Solaris put some files in incorrect
locations. (Bug#31058)

----
こがよういちろう


投稿者 xml-rpc : 2010年9月28日 13:14
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/98681
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。