MySQL 6.0.5-alpha リリース
投稿日時 2008-6-28 20:43:30 | トピック： MySQL 6.0
| MySQL 6.0.5-alpha がリリースされました。 バージョン 6.0シリーズは バージョン5.1シリーズ（現在RC）の次のメジャーバージョンです。
以下のURLからダウンロードできます。
http://dev.mysql.com/downloads/mysql/6.0.html
・ログファイルの出力先のデフォルトが 5.1 で一時、テーブルになりましたが、本バージョンでファイルに戻されました。
・MySQLクラスターがパッケージから外されました。 NDBクラスターは今後別リリースになる予定です。
ほか、多くの重要な変更があります。チェンジログを参照ください。
------
以下チェンジログ
■機能の追加と変更
- Incompatible Change: In MySQL 5.1.6, when log tables were implemented, the default log destination for the general query and slow query log was TABLE. This default has been changed to FILE, which is compatible with MySQL 5.0, but incompatible with earlier releases of MySQL 5.1 from 5.1.6 to 5.1.20. If you are upgrading from MySQL 5.0 to this release, no logging option changes should be necessary. However, if you are upgrading from 5.1.6 through 5.1.20 to this release and were using TABLE logging, use the --log-output=TABLE option explicitly to preserve your server's table-logging behavior. In MySQL 5.1.x, this bug was addressed twice because it turned out that the default was set in two places, only one of which was fixed the first time. (Bug#29993: http://bugs.mysql.com/29993)
- Incompatible Change: The server now includes dtoa, a library for conversion between strings and numbers by David M. Gay. In MySQL, this library provides the basis for improved conversion between string or DECIMAL values and approximate-value (FLOAT/DOUBLE) numbers:
+ Consistent conversion results across platforms, which eliminates, for example, Unix versus Windows conversion differences.
+ Accurate representation of values in cases where results previously did not provide sufficient precision, such as for values close to IEEE limits.
+ Conversion of numbers to string format with the best possible precision. The precision of dtoa is always the same or bettter than that of the standard C library functions. Because the conversions produced by this library differ in some cases from previous results, the potential exists for incompatibilities in applications that rely on previous results. For example, applications that depend on a specific exact result from previous conversions might need adjustment to accommodate additional precision. For additional information about the properties of dtoa conversions, see Section 11.2.2, "Type Conversion in Expression Evaluation." See also Bug#12860: http://bugs.mysql.com/12860, Bug#21497: http://bugs.mysql.com/21497, Bug#26788: http://bugs.mysql.com/26788, Bug#24541: http://bugs.mysql.com/24541, Bug#34015: http://bugs.mysql.com/34015
- Important Change: MySQL Cluster: Packaging: Beginning with this release, standard MySQL 6.0 binaries are no longer built with support for the NDBCLUSTER storage engine, and the NDBCLUSTER code included in 6.0 mainline sources is no longer guaranteed to be maintained or supported. Those using MySQL Cluster in MySQL 6.0.4 and earlier MySQL 6.0 mainline releases should upgrade to MySQL Cluster NDB 6.2.15 should upgrade to MySQL Cluster NDB 6.2.15 or a later MySQL Cluster NDB 6.2 or 6.3 release. (Bug#36193: http://bugs.mysql.com/36193)
- Cluster API: Important Change: Because NDB_LE_MemoryUsage.page_size_kb shows memory page sizes in bytes rather than kilobytes, it has been renamed to page_size_bytes. The name page_size_kb is now deprecated and thus subject to removal in a future release, although it currently remains supported for reasons of backward compatibility. See The Ndb_logevent_type Type (http://dev.mysql.com/doc/ndbapi/en/ndb-logevent-type.html), for more information about NDB_LE_MemoryUsage. (Bug#30271: http://bugs.mysql.com/30271)
- Important Change: Added a ROUTINE_TYPE column to the INFORMATION_SCHEMA.PARAMETERS table, to make it possible to distinguish like-named parameters of stored routines and stored functions having the same names. See Section 25.26, "The INFORMATION_SCHEMA PARAMETERS Table," for more information. (Bug#33106: http://bugs.mysql.com/33106)
■バグ修正
- Important Change: Security Fix: It was possible to circumvent privileges through the creation of MyISAM tables employing the DATA DIRECTORY and INDEX DIRECTORY options to overwrite existing table files in the MySQL data directory. Use of the MySQL data directory in DATA DIRECTORY and INDEX DIRECTORY is now disallowed. This is now also true of these options when used with partitioned tables and individual partitions of such tables.(Bug#32167: http://bugs.mysql.com/32167,CVE-2008-2079 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2079))
- Important Change: Security Enhancement: On Windows Vista and Windows Server 2008, a user without administrative privileges does not have write permissions to the Program Files directory where MySQL and the associated data files are normally installed. Using data files located in the standard Program Files installation directory could therefore cause MySQL to fail, or lead to potential security issues in an installed instance. To address the problem, on Windows XP, Windows Vista and Windows Server 2008, the datafiles and data file configuration are now set to the Microsoft recommended AppData folder. The AppData folder is typically located within the user's home directory.
Important When upgrading an existing 5.1.23 or 6.0.4 installation of MySQL you must take a backup of your data and configuration file (my.ini before installing the new version. To migrate your data, either extract the data and re-import (using mysqldump, then upgrade and re-import using mysql), or back up your data, upgrade to the new version, and copy your existing data files from your old datadir directory to the new directory located within AppData. Failure to back up your data and follow these procedures may lead to data loss. (Bug#34593: http://bugs.mysql.com/34593)
- Important Change: MySQL Cluster: AUTO_INCREMENT columns had the following problems when used in NDB tables:
+ The AUTO_INCREMENT counter was not updated correctly when such a column was updated.
+ AUTO_INCREMENT values were not prefetched beyond statement boundaries.
+ AUTO_INCREMENT values were not handled correctly with INSERT IGNORE statements.
+ After being set, ndb_autoincrement_prefetch_sz showed a value of 1, regardless of the value it had actually been set to. As part of this fix, the behavior of ndb_autoincrement_prefetch_sz has changed. Setting this to less than 32 no longer has any effect on prefetching within statements (where IDs are now always obtained in batches of 32 or more), but only between statements. The default value for this variable has also changed, and is now 1. (Bug#25176: http://bugs.mysql.com/25176, Bug#31956: http://bugs.mysql.com/31956, Bug#32055: http://bugs.mysql.com/32055)
- Important Change: Replication: When the master crashed during an update on a transactional table while in AUTOCOMMIT mode, the slave failed. This fix causes every transaction (including AUTOCOMMIT transactions) to be recorded in the binlog as starting with a BEGIN and ending with a COMMIT or ROLLBACK. (Bug#26395: http://bugs.mysql.com/26395)
- Disk Data: Important Change: It is no longer possible on 32-bit systems to issue statements appearing to create Disk Data log files or data files greater than 4 GB in size. (Trying to create log files or data files larger than 4 GB on 32-bit systems led to unrecoverable data node failures; such statements now fail with NDB error 1515.) (Bug#29186: http://bugs.mysql.com/29186)
- Important Change: It was possible to use FRAC_SECOND as a synonym for MICROSECOND with DATE_ADD(), DATE_SUB(), and INTERVAL; now, using FRAC_SECOND with anything other than TIMESTAMPADD() or TIMESTAMPDIFF() produces a syntax error. It is now possible (and preferable) to use MICROSECOND with TIMESTAMPADD() and TIMESTAMPDIFF(), and FRAC_SECOND is now deprecated. (Bug#33834: http://bugs.mysql.com/33834)
- Important Change: InnoDB free space information is now shown in the Data_free column of SHOW TABLE STATUS and in the DATA_FREE column of the INFORMATION_SCHEMA.TABLES table. (Bug#32440: http://bugs.mysql.com/32440) This regression was introduced by Bug#11379: http://bugs.mysql.com/11379
- Important Change: The server handled truncation of values having excess trailing spaces into CHAR, VARCHAR, and TEXT columns in different ways. This behavior has now been made consistent for columns of all three of these types, and now follows the existing behavior of VARCHAR columns in this regard; that is, a Note is always issued whenever such truncation occurs. This change does not affect columns of these three types when using a binary encoding; BLOB columns are also unaffected by the change, since they always use a binary encoding. (Bug#30059: http://bugs.mysql.com/30059)
- Important Change: An AFTER UPDATE trigger was not invoked when the UPDATE did not make any changes to the table for which the trigger was defined. Now AFTER UPDATE triggers behave the same in this regard as do BEFORE UPDATE triggers, which are invoked whether the UPDATE makes any changes in the table or not. (Bug#23771: http://bugs.mysql.com/23771)
- Replication: Important Note: Network timeouts between the master and the slave could result in corruption of the relay log. This fix rectifies a long-standing replication issue when using unreliable networks, including replication over wide area networks such as the Internet. If you experience reliability issues and see many You have an error in your SQL syntax errors on replication slaves, we strongly recommend that you upgrade to a MySQL version which includes this fix. (Bug#26489: http://bugs.mysql.com/26489)
|
|