オリジナル版：http://dev.mysql.com/doc/refman/5.5/en/news-5-5-5.html
MySQLデータベース管理システムの新バージョンであるMySQL Server 5.5.5-m3がリリースされました。
修飾子"-m3"は、これが"Celosia"とも呼ばれる"マイルストーン"リリースモデルの3番目のマイルストーンであることを示しています。
リリースモデルと計画済みのマイルストーンについては下記でその詳細を確認できます。
http://forge.mysql.com/wiki/Development_Cycle
このリリースの新機能はベータ品質です。他の試作版と同様に、製品レベルのシステムあるいは、重要なデータを持つシステムにインストールする場合は慎重にしてください。
このリリースからMySQL Server 5.5.2-m2を含む以前のリリースシリーズへの「ダウングレード」はサポートされないことに注意してください。
MySQL 5.1を使用する製品レベルシステムでは、下記のMySQL Enterpriseの製品説明をよく読んでください。
http://mysql.com/products/enterprise/
MySQL 5.5はMySQL 5.4をベースとしており、追加の変更は行われていません。そのためMySQL 5.5は、MySQLサーバのスケーラビリティおよびパフォーマンス問題に対応するための影響の大きな変更をいくつか含んでいます。この変更は、ハードウェアおよびCPU設計における詳細な性能を引き出し、既存のハードウェアをより有効に利用できます。
MySQL 5.5の新機能の概要については、以下の"MySQL 5.5の何が新しくなったのか"を参照してください。
http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html
新しいサーバへMySQL 5.5.5-m3をインストールする情報として、以下のMySQLのインストールドキュメントを参照してください。
http://dev.mysql.com/doc/refman/5.5/en/installing.html
前回のMySQLリリースからアップグレードするには、以下のアップグレードについての注意事項を参照してください。
http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html
MySQL Server 5.5は、http://dev.mysql.com/downloads/とミラーサイトのダウンロード・ページから、ソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。
すべてのミラーサイトが現在、最新であるとは限らないことに注意してください。
あるミラーサイトでこのバージョンを見つけることができない場合は、再度確認を行うか、あるいは別のダウンロード・サイトを選択してください。
バグレポート、バグ修正、パッチ等の情報をお待ちしております。
http://forge.mysql.com/wiki/Contributing
バグフィックスの全リストはオンラインでも閲覧できます。
http://dev.mysql.com/doc/refman/5.5/en/news-5-5-5.html
ソースからビルドする場合の特別な注意点
MySQL 5.5.5-m3では、CMakeが全プラットフォームのビルドフレームワークとしてGNU autotoolsに加わりました。われわれは既にWindows上でCMakeを利用してきました。GNU autotoolsに対する既存のサポートはまだ続けられますが、もしGNU autotoolsをまだお使いなら、下記リンクの指示に従ってCMakeを利用できます。このリリースのオフィシャルパッケージはCMakeを使って作成された最初のパッケージです。いつものようにわれわれはフィードバックを歓迎します。
MySQL 5.5.5の変更点：
|InnoDB is now the default storage engine, rather than MyISAM in||| the
regular versions of MySQL. This change has the following consequences:
* Existing tables are not affected by this change, only new
tables that are created.
* Some of the|InnoDB| option settings also change, so that the
default configuration represents the best practices for|InnoDB|
functionality,reliability, and file management:
|innodb_file_format=Barracuda| rather than|Antelope|,
|innodb_strict_mode=TRUE| rather than|FALSE|, and
|innodb_file_per_table=TRUE| rather than|FALSE|.
* The system tables remain in|MyISAM| format.
*|MyISAM| remains the default storage engine for the embedded version
of MySQL
Bugs Fixed:
* Performance: While looking for the shortest index for a
covering index scan, the optimizer did not consider the full
row length for a clustered primary key, as in InnoDB.
Secondary covering indexes will now be preferred, making full
table scans less likely.
(Bug#39653:http://bugs.mysql.com/bug.php?id=39653)
* Security Fix: The server failed to check the table name
argument of a COM_FIELD_LIST command packet for validity and
compliance to acceptable table name standards. This could be
exploited to bypass almost all forms of checks for privileges
and table-level grants by providing a specially crafted table
name argument to COM_FIELD_LIST.
In MySQL 5.0 and above, this allowed an authenticated user
with SELECT privileges on one table to obtain the field
definitions of any table in all other databases and
potentially of other MySQL instances accessible from the
server's file system.
Additionally, for MySQL version 5.1 and above, an
authenticated user with DELETE or SELECT privileges on one
table could delete or read content from any other table in all
databases on this server, and potentially of other MySQL
instances accessible from the server's file system.
(Bug#53371:http://bugs.mysql.com/bug.php?id=53371,
CVE-2010-1848
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1848))
* Security Fix: The server was susceptible to a buffer-overflow
attack due to a failure to perform bounds checking on the
table name argument of a COM_FIELD_LIST command packet. By
sending long data for the table name, a buffer is overflown,
which could be exploited by an authenticated user to inject
malicious code.
(Bug#53237:http://bugs.mysql.com/bug.php?id=53237,
CVE-2010-1850
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1850))
* Security Fix: Privilege checking for UNINSTALL PLUGIN was
incorrect. (Bug#51770:http://bugs.mysql.com/bug.php?id=51770,
CVE-2010-1621
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1621))
* Security Fix: The server could be tricked into reading packets
indefinitely if it received a packet larger than the maximum
size of one packet.
(Bug#50974:http://bugs.mysql.com/bug.php?id=50974,
CVE-2010-1849
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1849))
* Incompatible Change: TRUNCATE TABLE did not take an exclusive
lock on a table if truncation was done by deleting all rows in
the table. For InnoDB tables, this could break proper
isolation because InnoDB ended up aborting some granted locks
when truncating a table. Now an exclusive metadata lock is
taken before TRUNCATE TABLE can proceed. This guarantees that
no other transaction is using the table.
Incompatible change: Truncation using delete no longer fails
if sql_safe_updates is enabled (this was an undocumented side
effect). (Bug#42643:http://bugs.mysql.com/bug.php?id=42643)
* Important Change: Replication: It was possible to set
sql_log_bin with session scope inside a transaction or
subquery. (Bug#53437:http://bugs.mysql.com/bug.php?id=53437)
* Important Change: Replication: When changing binlog_format or
binlog_direct_non_transactional_updates, permissions were not
checked prior to checking the scope and context of the
variable being changed.
As a result of this fix, an error is no longer reported
when---in the context of a transaction or a stored
function---you try to set a value for a session variable that
is the same as its previous value, or for a variable whose
scope is global only.
(Bug#51277:http://bugs.mysql.com/bug.php?id=51277)
* Important Change: Replication: When invoked, CHANGE MASTER TO
and SET GLOBAL sql_slave_skip_counter now cause information to
be written to the error log about the slave's state prior to
execution of the statement. For CHANGE MASTER TO, this
information includes the previous values for MASTER_HOST,
MASTER_PORT, MASTER_LOG_FILE, and MASTER_LOG_POS. For SET
GLOBAL sql_slave_skip_counter, this information includes the
previous values of sql_slave_skip_counter, the group relay log
name, and the group relay log position.
(Bug#43406:http://bugs.mysql.com/bug.php?id=43406,
Bug#43407:http://bugs.mysql.com/bug.php?id=43407)
* Partitioning: Replication: Attempting to execute LOAD DATA on
a partitioned MyISAM table while using statement-based logging
mode caused the master to hang or crash.
(Bug#51851:http://bugs.mysql.com/bug.php?id=51851)
* Partitioning: Replication: The NO_DIR_IN_CREATE server SQL
mode was not enforced when defining subpartitions. In certain
cases, this could lead to failures on replication slaves.
(Bug#42954:http://bugs.mysql.com/bug.php?id=42954)
* Partitioning: Rows inserted into a table created using a
PARTITION BY LIST COLUMNS option referencing multiple columns
could be inserted into the wrong partition.
(Bug#52815:http://bugs.mysql.com/bug.php?id=52815)
* Partitioning: Partition pruning on RANGE partitioned tables
did not always work correctly; the last partition was not
excluded if the range was beyond it (when not using MAXVALUE).
Now the last partition is not included if the partitioning
function value is not within the range.
(Bug#51830:http://bugs.mysql.com/bug.php?id=51830)
* Partitioning: Attempting to partition a table using a DECIMAL
column caused the server to crash; this not supported and is
now specifically disallowed.
Bug#51347:http://bugs.mysql.com/bug.php?id=51347)
* Partitioning: ALTER TABLE statements that cause table
partitions to be renamed or dropped (such as ALTER TABLE ...
ADD PARTITION, ALTER TABLE ... DROP PARTITION, and ALTER TABLE
... REORGANIZE PARTITION) --- when run concurrently with
queries against the INFORMATION_SCHEMA.PARTITIONS table ---
could fail, cause the affected partitioned tables to become
unusable, or both. This was due to the fact that the
INFORMATION_SCHEMA database ignored the name lock imposed by
the ALTER TABLE statement on the partitions affected. In
particular, this led to problems with InnoDB tables, because
InnoDB would accept the rename operation, but put it in a
background queue, so that subsequent rename operations failed
when InnoDB was unable to find the correct partition. Now,
INFORMATION_SCHEMA honors name locks imposed by ongoing ALTER
TABLE statements that cause partitions to be renamed or
dropped. (Bug#50561:http://bugs.mysql.com/bug.php?id=50561)
See also Bug#47343:http://bugs.mysql.com/bug.php?id=47343,
Bug#45808:http://bugs.mysql.com/bug.php?id=45808.
* Partitioning: The insert_id server system variable was not
reset following an insert that failed on a partitioned MyISAM
table having an AUTO_INCREMENT column.
(Bug#50392:http://bugs.mysql.com/bug.php?id=50392)
* Partitioning: Foreign keys are not supported on partitioned
tables. However, it was possible via an ALTER TABLE statement
to set a foreign key on a partitioned table; it was also
possible to partition a table with a single foreign key.
(Bug#50104:http://bugs.mysql.com/bug.php?id=50104)
* Partitioning: When attempting to perform DDL on a partitioned
table and the table's .par file could not be found, the server
returned the inaccurate error message Out of memory; restart
server and try again (needed 2 bytes). Now in such cases, the
server returns the error Failed to initialize partitions from
.par file. (Bug#49161:http://bugs.mysql.com/bug.php?id=49161)
* Partitioning: GROUP BY queries performed poorly for some
partitioned tables. This was due to the block size not being
set for partitioned tables, thus the keys per block was not
correct, which could cause such queries to be optimized
incorrectly.
(Bug#48229:http://bugs.mysql.com/bug.php?id=48229)
See also Bug#37252:http://bugs.mysql.com/bug.php?id=37252.
* Partitioning: REPAIR TABLE failed for partitioned ARCHIVE
tables. (Bug#46565:http://bugs.mysql.com/bug.php?id=46565)
* Replication: When using unique keys on NULL columns in
row-based replication, the slave sometimes chose the wrong row
when performing an update. This happened because a table
having a unique key on such a column could have multiple rows
containing NULL for the column used by the unique key, and the
slave merely picked the first row containing NULL in that
column. (Bug#53893:http://bugs.mysql.com/bug.php?id=53893)
* Replication: When a CREATE TEMPORARY TABLE ... SELECT
statement was executed within a transaction that updated only
transactional engines and was later rolled back (for example,
due to a deadlock) the changes---including the creation of the
temporary table---were not written to the binary log, which
caused subsequent updates to this table to fail on the slave.
(Bug#53421:http://bugs.mysql.com/bug.php?id=53421)
* Replication: When using the statement-based logging format,
statements that used CONNECTION_ID() were always kept in the
transaction cache; consequently, nontransactional changes that
should have been flushed before the transaction were kept in
the transaction cache.
(Bug#53075:http://bugs.mysql.com/bug.php?id=53075)
This regression was introduced by
Bug#51894:http://bugs.mysql.com/bug.php?id=51894.
* Replication: In some cases, attempting to update a column with
a value of an incompatible type resulted in a mismatch between
master and slave because the column value was set to its
implicit default value on the master (as expected), but the
same column on the slave was set to NULL.
(Bug#52868:http://bugs.mysql.com/bug.php?id=52868)
* Replication: When temporary tables were in use, switching the
binary logging format from STATEMENT to ROW did not take
effect until all temporary tables were dropped. (The existence
of temporary tables should prevent switching the format only
from ROW to STATEMENT from taking effect, not the reverse.)
(Bug#52616:http://bugs.mysql.com/bug.php?id=52616)
* Replication: A buffer overrun in the handling of DATE column
values could cause mysqlbinlog to fail when reading back logs
containing certain combinations of DML on a table having a
DATE column followed by dropping the table.
(Bug#52202:http://bugs.mysql.com/bug.php?id=52202)
* Replication: The failure of a REVOKE statement was logged with
the wrong error code, causing replication slaves to stop even
when the failure was expected on the master.
(Bug#51987:http://bugs.mysql.com/bug.php?id=51987)
* -laio missing from embedded libs
(Bug#55215:_http://bugs.mysql.com/bug.php?id=55215_)
Please see the complete list of changes to MySQL 5.5.5
at_http://dev.mysql.com/doc/refman/5.5/en/news-5-5-5.html_