MySQL 6.0.10-alpha リリース
投稿日時 2009-3-28 13:09:44 | トピック： MySQL 6.0
| MySQL 6.0.10-alpha がリリースされました。
これは MySQL 6.0 シリーズの最新バージョンで、6.0シリーズは現在アルファー版です。 安定版がリリースされている最新版は、MySQL 5.1 シリーズです。
注意： このバージョンに含まれる Falcon ストレージエンジンにはバグが含まれています。 このバージョン(MySQL 6.0.10)をビルドした後に発覚した問題があるようですので、Falcon を使用したい人は 6.0.9-alpha のままにするか、 6.0.11のリリースまで待つことが強く勧められています。
MySQL 6.0 についてはこちら：
http://www.mysql.com/mysql60/
ダウンロードはこちら：
http://dev.mysql.com/downloads/mysql/6.0.html
-----------------
以下、チェンジログ(6.0.10-alpha)
■機能の追加と変更(6.0.10-alpha)：
- Important Change: Replication: RESET MASTER and RESET SLAVE
now reset the values shown for Last_IO_Error, Last_IO_Errno,
Last_SQL_Error, and Last_SQL_Errno in the output of SHOW SLAVE
STATUS. (Bug#34654: http://bugs.mysql.com/34654)
- Replication: A new global server variable sync_relay_log is
introduced for use on replication slaves. Setting this
variable to a nonzero integer value N causes the slave to
synchonize the relay log to disk after every N events. It is
analogous to how the sync_binlog variable works for binary
logs on a replication master.
This variable can also be set in my.cnf using the server
option --sync-relay-log.
For more information, see Section 16.1.3.3, "Replication Slave
Options and Variables."
(Bug#31665: http://bugs.mysql.com/31665,
Bug#35542: http://bugs.mysql.com/35542,
Bug#40337: http://bugs.mysql.com/40337)
- Replication: In circular replication, it was sometimes
possible for an event to propagate such that it would be
reapplied on all servers. This could occur when the
originating server was removed from the replication circle and
so could no longer act as the terminator of its own events, as
normally happens in circular replication.
In order to prevent this from occurring, a new
IGNORE_SERVER_IDS option is introduced for the CHANGE MASTER
TO statement. This option takes a list of replication server
IDs; events having a server ID which appears in this list are
ignored and not applied. For more information, see Section
12.6.2.1, "CHANGE MASTER TO Syntax."
(Bug#25998: http://bugs.mysql.com/25998)
See also Bug#27808: http://bugs.mysql.com/27808.
- The libedit library was upgraded to version 2.11.
(Bug#42433: http://bugs.mysql.com/42433)
- A new status variable, Queries, indicates the number of
statements executed by the server. This includes statements
executed within stored programs, unlike the Questions variable
which includes only statements sent to the server by clients.
(Bug#41131: http://bugs.mysql.com/41131)
- Columns that provide a catalog value in INFORMATION_SCHEMA
tables (for example, TABLES.TABLE_CATALOG) now have a value of
def rather than NULL. (Bug#35427: http://bugs.mysql.com/35427)
- mysql-test-run.pl now supports --client-bindir and
--client-libdir options for specifying the directory where
client binaries and libraries are located.
(Bug#34995: http://bugs.mysql.com/34995)
■バグ修正(6.0.10-alpha)：
- Security Fix: Using an XPath expression employing a scalar
expression as a FilterExpr
(http://www.w3.org/TR/xpath#NT-FilterExpr) with ExtractValue()
or UpdateXML() caused the server to crash. Such expressions
now cause an error instead.
(Bug#42495: http://bugs.mysql.com/42495)
- Incompatible Change: The fix for
Bug#33699: http://bugs.mysql.com/33699 introduced a change to
the UPDATE statement such that assigning NULL to a NOT NULL
column caused an error even when strict SQL mode was not
enabled. The original behavior before was that such
assignments caused an error only in strict SQL mode, and
otherwise set the column to the the implicit default value for
the column data type and generated a warning. (For information
about implicit default values, see Section 10.1.4, "Data Type
Default Values.")
The change caused compatibility problems for applications that
relied on the original behavior. It also caused replication
problems between servers that had the original behavior and
those that did not, for applications that assigned NULL to NOT
NULL columns in UPDATE statements without strict SQL mode
enabled. This change has been reverted so that UPDATE again
had the original behavior. Problems can still occur if you
replicate between servers that have the modified UPDATE
behavior and those that do not.
(Bug#39265: http://bugs.mysql.com/39265)
- Important Change: Replication: If a trigger was defined on an
InnoDB table and this trigger updated a non-transactional
table, changes performed on the InnoDB table were replicated
and were visible on the slave before they were committed on
the master, and were not rolled back on the slave after a
successful rollback of those changes on the master.
As a result of the fix for this issue, the semantics of mixing
non-transactional and transactional tables in a transaction in
the first statement of a transaction have changed. Previously,
if the first statement in a transaction contained
non-transactional changes, the statement was written directly
to the binary log. Now, any statement appearing after a BEGIN
(or immediately following a COMMIT if AUTOCOMMIT = 0) is
always considered part of the transaction and cached. This
means that non-transactional changes do not propagate to the
slave until the transaction is committed and thus written to
the binary log.
See Section 16.3.1.25, "Replication and Transactions," for
more information about this change in behavior.
(Bug#40116: http://bugs.mysql.com/40116)
- Important Change: Replication: MyISAM transactions replicated
to a transactional slave left the slave in an unstable
condition. This was due to the fact that, when replicating
from a non-transactional storage engine to a transactional
engine with AUTOCOMMIT turned off, no BEGIN and COMMIT
statements were written to the binary log; thus, on the slave,
a never-ending transaction was started.
The fix for this issue includes enforcing AUTOCOMMIT mode on
the slave by replicating all AUTOCOMMIT=1 statements from the
master. (Bug#29288: http://bugs.mysql.com/29288)
|
|