MySQLニュース

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

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

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

 

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.27をインストールする情報として、以下の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-27.html

Changes in MySQL 5.5.27 (2012-August-02)

Functionality Added or Changed

   * Important Change: The YEAR(2) data type is now deprecated
     because it is problematic. Support for YEAR(2) will be removed
     in a future release of MySQL. For more information, see
     YEAR(2) Limitations and Migrating to YEAR(4)
     (http://dev.mysql.com/doc/refman/5.5/en/migrating-to-year4.html).

Bugs Fixed

   * InnoDB: If a row was deleted from an InnoDB table, then
     another row was re-inserted with the same primary key value,
     an attempt by a concurrent transaction to lock the row could
     succeed when it should have waited. This issue occurred if the
     locking select used a WHERE clause that performed an index
     scan using a secondary index. (Bug #14100254, Bug #65389)

   * InnoDB: An assertion could be raised if an InnoDB table was
     moved to a different database using ALTER TABLE ... RENAME
     while the database was being dropped by DROP DATABASE. (Bug
     #13982017)

   * InnoDB: Using the KILL statement to terminate a query could
     cause an unnecessary message in the error log:
     [ERROR] Got error -1 when reading table table_name
     (Bug #13933132)

   * InnoDB: For an InnoDB table with a trigger, under the setting
     innodb_autoinc_lock_mode=1, sometimes auto-increment values
     could be interleaved when inserting into the table from two
     sessions concurrently. The sequence of auto-increment values
     could vary depending on timing, leading to data inconsistency
     in systems using replication. (Bug #12752572, Bug #61579)

   * Replication: An event whose length exceeded the size of the
     master dump thread's max_allowed_packet caused replication to
     fail. This could occur when updating many large rows and using
     row-based replication.
     As part of this fix, a new server option
     --slave-max-allowed-packet is added, which permits
     max_allowed_packet to be exceeded by the slave SQL and I/O
     threads. Now the size of a packet transmitted from the master
     to the slave is checked only against this value (available as
     the value of the slave_max_allowed_packet server system
     variable), and not against the value of max_allowed_packet.
     (Bug #12400221, Bug #60926)

   * Replication: Statements such as UPDATE ... WHERE
     primary_key_column = constant LIMIT 1 are flagged as unsafe
     for statement-based logging, despite the fact that such
     statements are actually safe. In cases where a great many such
     statements were run, this could lead to disk space becoming
     exhausted do to the number of such false warnings being
     logged. To prevent this from happening, a warning suppression
     mechanism is introduced. This warning suppression acts as
     follows: Whenever the 50 most recent
     ER_BINLOG_UNSAFE_STATEMENT warnings have been generated more
     than 50 times in any 50-second period, warning suppression is
     enabled. When activated, this causes such warnings not to be
     written to the error log; instead, for each 50 warnings of
     this type, a note is written to the error log stating The last
     warning was repeated N times in last S seconds. This continues
     as long as the 50 most recent such warnings were issued in 50
     seconds or less; once the number of warnings has decreased
     below this threshold, the warnings are once again logged
     normally.
     The fix for this issue does not affect how these warnings are
     reported to MySQL clients; a warning is still sent to the
     client for each statement that generates the warning. This fix
     also does not make any changes in how the safety of any
     statement for statement-based logging is determined. (Bug
     #11759333, Bug #51638)
     References: See also Bug #11751521, Bug #42415.

   * Replication: After upgrading a replication slave to MySQL
     5.5.18 or later, enabling the query cache eventually caused
     the slave to fail. (Bug #64624, Bug #14005409)

   * The server did not build with gcc 4.7. (Bug #14238406)

   * Certain arguments to RPAD() could lead to "uninitialized
     variable" warnings. (Bug #14039955)

   * The presence of a file named .empty in the test database
     prevented that database from being dropped. (Bug #12845091)

   * For some subqueries that should be executed using a range scan
     on a non-primary index and required use of filesort, only the
     first execution of the subquery was done as a range scan. All
     following executions were done as full table scans, resulting
     in poor performance. (Bug #12667154)

   * File access by the ARCHIVE storage engine was not instrumented
     and thus not shown in Performance Schema tables. (Bug #63340,
     Bug #13417440)

   * mysqlbinlog exited with no error code if file write errors
     occurred. (Bug #55289, Bug #11762667)

   * Using CONCAT() to construct a pattern for a LIKE pattern match
     could result in memory corrupting and match failure. (Bug
     #59140, Bug #11766101)

   * yaSSL rejected valid SSL certificates that OpenSSL accepts.
     (Bug #54348, Bug #11761822)

   * Sessions could end up deadlocked when executing a combination
     of SELECT, DROP TABLE, KILL, and SHOW ENGINE INNODB STATUS.
     (Bug #60682, Bug #12636001)

   * mysqldump could dump views and the tables on which they depend
     in such an order that errors occurred when the dump file was
     reloaded. (Bug #44939, Bug #11753490)

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

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

ページトップへ