MySQLニュース

MySQL 5.5.21 がリリースされました

オリジナル版:http://dev.mysql.com/doc/refman/5.5/en/news-5-5-21.html

MySQL 5.5.21は世界でもっともポピュラーなオープンソースデータベースの5.5のプロダクトリリースの新しいバージョンです。MySQL 5.5.21はプロダクションシステムでの使用をお勧めします。

MySQL 5.5は最新のマルチCPUやマルチコアハードウェアやオペレーティングシステムの利点を生かし、MySQLデータベースのパフォーマンスとスケーラビリ ティを改善するための影響の大きい変更をいくつか含んでいます。現在ではInnoDBがMySQLデータベースのデフォルトのストレージエンジンであり、 ACIDトランザクション、参照整合性、クラッシュリカバリをデフォルトで提供しています。

MySQL 5.5は以下の多くの新しい強化も含んでいます:

   - Windowsにおける特有の機能と改善を利用した著しいパフォーマンス向上
   - 新しい準同期レプリケーションとレプリケーションハートビートによるより高いレベルの可用性
   - 改善されたインデックスとテーブルパーティショニング、SIGNAL/RESIGNALサポート、そして新しいPERFORMANCE_SCHEMAに含まれる強化された診断法による改善されたユーザビリティ

MySQL 5.5の新機能のより完全な概観については、以下のリソースを参照下さい。

MySQL 5.5 GA、Tomas Ulinのインタビュー:

http://dev.mysql.com/tech-resources/interviews/thomas-ulin-mysql-55.html

ドキュメント:

http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html

ホワイトペーパー: MySQL 5.5の新機能

http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html

製品レベルのシステムでMySQLを稼動させているならば、MySQL製品、バックアップ、モニタリング、モデリング、開発、管理ツールの包括的なセット を含むMySQLパフォーマンス、セキュリティ、アップタイムの高いレベルを実現するMySQL Enterprise Editionの製品詳細に注目してください。

http://mysql.com/products/enterprise/

新しいサーバへMySQL 5.5.21をインストールする情報として、以下の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

 

次の節では、MySQL 5.5の以前のバージョンからのMySQLソースコードの変更を記載しています。これはオンラインでも閲覧できます。
http://dev.mysql.com/doc/refman/5.5/en/news-5-5-21.html

Changes in MySQL 5.5.21 (17 February 2012)

Functionality Added or Changed

   * A new CMake option, MYSQL_PROJECT_NAME, can be set on Windows
     or Mac OS X to be used in the project name. (Bug #13551687)

Bugs Fixed

   * Performance: InnoDB Storage Engine: Memory allocation for
     InnoDB tables was reorganized to reduce the memory overhead
     for large numbers of tables or partitions, avoiding situations
     where the "resident set size" could grow regardless of FLUSH
     TABLES statements. The problem was most evident for tables
     with large row size. Some of the memory that was formerly
     allocated for every open table is now allocated only when the
     table is modified for the first time. (Bug #11764622, Bug
     #57480)

   * Incompatible Change: An earlier change (in MySQL 5.1.59 and
     5.5.16) was found to modify date-handling behavior in General
     Availability-status series (MySQL 5.1 and 5.5). This change
     has been reverted.
     The change was that several functions became more strict when
     passed a DATE() function value as their argument, thus they
     rejected incomplete dates with a day part of zero. These
     functions were affected: CONVERT_TZ(), DATE_ADD(), DATE_SUB(),
     DAYOFYEAR(), LAST_DAY(), TIMESTAMPDIFF(), TO_DAYS(),
     TO_SECONDS(), WEEK(), WEEKDAY(), WEEKOFYEAR(), YEARWEEK(). The
     previous behavior has been restored. (Bug #13458237)

   * InnoDB Storage Engine: A Valgrind error was fixed in the
     function os_aio_init(). (Bug #13612811)

   * InnoDB Storage Engine: The server could crash when creating an
     InnoDB temporary table under Linux, if the $TMPDIR setting
     points to a tmpfs filesystem and innodb_use_native_aio is
     enabled, as it is by default in MySQL 5.5.4 and higher. The
     entry in the error log looked like:
       101123  2:10:59  InnoDB: Operating system error number
                                22 in a file operation.
       InnoDB: Error number 22 means 'Invalid argument'.
     The crash occurred because asynchronous I/O is not supported
     on tmpfs in some Linux kernel versions. The workaround was to
     turn off the innodb_use_native_aio setting or use a different
     temporary directory. The fix causes InnoDB to turn off the
     innodb_use_native_aio setting automatically if it detects that
     the temporary file directory does not support asynchronous
     I/O. (Bug #13593888, Bug #11765450, Bug #58421)

   * InnoDB Storage Engine: References to C preprocessor symbols
     and macros HAVE_purify, UNIV_INIT_MEM_TO_ZERO, and
     UNIV_SET_MEM_TO_ZERO were removed from the InnoDB source code.
     They were only used in debug builds instrumented for Valgrind.
     They are replaced by calls to the UNIV_MEM_INVALID() macro.
     (Bug #13418934)

   * InnoDB Storage Engine: The MySQL server could halt with an
     assertion error:
       InnoDB: Failing assertion: page_get_n_recs(page) > 1
     Subsequent restarts could fail with the same error. The error
     occurred during a purge
     (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_pur
     ge) operation involving the InnoDB change buffer
     (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_cha
     nge_buffer). The workaround was to set the configuration
     option innodb_change_buffering=inserts. (Bug #13413535, Bug
     #61104)

   * InnoDB Storage Engine: With 1024 InnoDB transactions running
     concurrently and the innodb_file_per_table setting enabled,
     a CREATE TABLE operation for an InnoDB table could fail. The
     .ibd file from the failed CREATE TABLE was left behind,
     preventing the table from being created later, after the load
     had dropped.
     The fix adds error handling to delete the erroneous .ibd file.
     This error was less likely to occur in MySQL 5.5 and 5.6,
     because raising the number of InnoDB undo slots increased the
     number of simultaneous transactions needed to trigger the bug,
     from 1K to 128K. (Bug #12400341)

   * Replication: Executing mysqlbinlog with the --start-position=N
     option, where N was equal either to 0 or to a value greater
     than the length of the dump file, caused it to crash.
     This issue was introduced in MySQL 5.5.18 by the fix for Bug
     #32228 and Bug #11747416. (Bug #13593869, Bug #64035)

   * Replication: On Windows replication slave hosts, STOP SLAVE
     took an excessive length of time to complete when the master
     was down. (Bug #11752315, Bug #43460)

   * A query that used an index on a CHAR column referenced in a
     BETWEEN clause could return invalid results. (Bug #13463488,
     Bug #63437)

   * Expressions that compared a BIGINT column with any non-integer
     constant were performed using integers rather than decimal or
     float values, with the result that the constant could be
     truncated. This could lead to any such comparison that used <,
     >, <=, >=, =, !=/<>, IN, or BETWEEN yielding false positive or
     negative results. (Bug #13463415, Bug #11758543, Bug #63502,
     Bug #50756)

   * When the optimizer performed conversion of DECIMAL values
     while evaluating range conditions, it could produce incorrect
     results. (Bug #13453382)

   * When running mysqldump with both the --single-transaction and
     --flush-logs options, the flushing of the log performed an
     implicit COMMIT (see Section 12.3.3, "Statements That Cause an
     Implicit Commit"), causing more than one transaction to be
     used and thus breaking consistency. (Bug #12809202, Bug
     #61854)

   * It was possible in the event of successive failures for
     mysqld_safe to restart quickly enough to consume excessive
     amounts of CPU. Now, on systems that support the sleep and
     date system utilities, mysqld_safe checks to see whether it
     has restarted more than 5 times in the current second, and if
     so, waits 1 second before attempting another restart. (Bug
     #11761530, Bug #54035)

   * When used with the --xml option, mysqldump --routines failed
     to dump any stored routines, triggers, or events. (Bug
     #11760384, Bug #52792)

   * It was possible on replication slaves where FEDERATED tables
     were in use to get timeouts on long-running operations, such
     as Error 1160 Got an error writing communication packets. The
     FEDERATED tables did not need to be replicated for the issue
     to occur. (Bug #11758931, Bug #51196)
     References: See also Bug #12896628, Bug #61790.

   * If an attempt to initiate a statement failed, the issue could
     not be reported to the client because it was not prepared to
     receive any error messages prior to the execution of any
     statement. Since the user could not execute any queries, they
     were simply disconnected without providing a clear error.
     After the fix for this issue, the client is prepared for an
     error as soon as it attempts to initiate a statement, so that
     the error can be reported prior to disconnecting the user.
     (Bug #11755281, Bug #47032)

   * Using myisamchk with the sort recover method to repair a table
     having fixed-width row format could cause the row pointer size
     to be reduced, effectively resulting in a smaller maximum data
     file size. (Bug #48848, Bug #11756869)

   * On Windows, the server incorrectly constructed the full path
     name of the plugin binary for INSTALL PLUGIN and CREATE
     FUNCTION ... SONAME. (Bug #45549, Bug #11754014)

   * The stored routine cache was subject to a small memory leak
     that over time or with many routines being used could result
     in out-of-memory errors. (Bug #44585, Bug #11753187)

MySQLや関連ソリューションに関するお問い合わせ、お見積などがございましたら、ご連絡ください。

お問い合わせ各MySQL保守サービス見積依頼スマートスタイルOSSストア

ページトップへ