MySQLニュース

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

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

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

 

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.29をインストールする情報として、以下の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.29は、http://dev.mysql.com/downloads/とミラーサイトのダウンロード・ページから、ソースコード及び多くのプラットフォームのためのバイナリで現在利用可能です。

 

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

Changes in MySQL 5.5.29 (21-December-2012)

  Functionality Added or Changed

    * The SHOW AUTHORS and SHOW CONTRIBUTORS statements are now
      deprecated in MySQL 5.5 and have been removed in MySQL 5.6.

  Bugs Fixed

    * Performance: InnoDB: The timing values for low-level InnoDB
      read operations were adjusted for better performance with fast
      storage devices, such as SSD
      (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_ssd
      ). This enhancement primarily affects read operations for BLOB
      columns in compressed
      (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_com
      pression) tables. (Bug #13702112, Bug #64258)

    * Important Change: InnoDB: A DML
      (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_dml
      ) statement using the index merge access method could lock
      many rows from the table, even when those rows were not part
      of the final result set. This fix reduces the excessive
      locking
      (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_loc
      king) by releasing the locks of unmatched rows. This
      optimization affects only transactions with isolation level
      equal to or less strict than READ COMMITTED; it does not apply
      to transactions using REPEATABLE READ or SERIALIZABLE
      isolation level. (Bug #14226171)

    * InnoDB: An online DDL operation for an InnoDB table
      incorrectly reported an empty value ('') instead of the
      correct key value when it reported a duplicate key error for a
      unique index using an index prefix. (Bug #14729221)

    * InnoDB: If a CREATE TABLE statement failed due to a disk full
      error, some memory allocated during the operation was not
      freed properly. (Bug #14708715)

    * InnoDB: With the innodb_file_per_table setting enabled, a DROP
      TABLE operation could cause a crash, due to a race condition
      that depended on the timing of pending I/O requests. (Bug
      #14594600, Bug #66718)

    * InnoDB: If the server crashed at the specific point when a
      change buffer
      (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_cha
      nge_buffer) entry was being merged into a buffer pool page,
      the transaction log and the change buffer were left in an
      inconsistent state. After a restart, MySQL could crash after
      reading the corresponding secondary index page. The problem
      was more likely to occur in MySQL 5.5 or later, where the
      original insert buffering
      (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_ins
      ert_buffering) mechanism was generalized to cover other
      operations. (Bug #14636528, Bug #66819, Bug #58571, Bug
      #61104, Bug #65443)

    * InnoDB: Inserting data of varying record lengths into an
      InnoDB table that used compression
      (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_com
      pression) could cause the server to halt with an error. (Bug
      #14554000, Bug #13523839, Bug #63815, Bug #12845774, Bug
      #61456, Bug #12595091, Bug #61208)

    * InnoDB: If a table was defined with an index key length very
      close to the upper length limit of 3072, a query against that
      table could cause a serious error. (Bug #14500557, Bug #66413)

    * InnoDB: When an auto-increment column used a FLOAT or DOUBLE
      data type, if the auto-increment value became very large
      (larger than the maximum unsigned long long value), subsequent
      inserts could fail or cause the server to halt. (Bug
      #14145950, Bug #55071)

    * InnoDB: If a transaction was started with a consistent
      snapshot, then new indexes were added to the table while the
      transaction was in progress, a subsequent UPDATE statement
      could incorrectly encounter the error:
      HA_ERR_TABLE_DEF_CHANGED: insufficient history for index
      This issue could cause an assertion error in debug builds.
      (Bug #14036214)

    * InnoDB: The error message was improved for the case where an
      UPDATE failed because the row included several BLOB values
      greater than 768 bytes each, causing the size of a row to
      exceed half the page size
      (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_pag
      e_size). The old message, was misleading; it suggested using
      BLOBs, when the 768-byte prefix for each BLOB column was the
      cause of the limit error:
      Error Code 1118: Row size too large. The maximum row size for
      the used table type, not counting BLOBs, is 8126. You have to
      change some columns to TEXT or BLOBs
      A workaround for the problem was to create the table with the
      ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED clause, which is
      now suggested in the message. (Bug #13453036, Bug #63507)

    * InnoDB: In rare circumstances, MySQL could apply InnoDB undo
      (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_und
      o) records out of order during a ROLLBACK
      (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_rol
      lback) of an operation that modified a BLOB column. This issue
      could cause an assertion error in debug builds:
      !bpage->file_page_was_freed
      (Bug #13249921)

    * Replication: Updates writing user variables whose values were
      never set on a slave while using --replicate-ignore-table
      could cause the slave to fail. (Bug #14597605)
      References: This bug was introduced by Bug #14275000.

    * Replication: Backtick (`) characters were not always handled
      correctly in internally generated SQL statements, which could
      sometimes lead to errors on the slave. (Bug #14548159)

    * Replication: Following an insert into a nontransactional table
      that failed due to insufficient disk space, the server did not
      properly clean up all pending events, leading to an assert or
      possibly to other errors. (Bug #11750014)

    * Very long database names in queries could cause the server to
      exit. (Bug #15912213)

    * Within a stored procedure, executing a multiple-table DELETE
      statement that used a very long table alias could cause the
      server to exit. (Bug #15954896)

    * Very long table aliases in queries could cause the server to
      exit. (Bug #15948123)

    * Attempting to create an auto-increment
      (http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_aut
      o_increment) column in an InnoDB table with a NULL type
      attribute could cause a serious error. (Bug #14758479)

    * A DELETE statement for an InnoDB table could write incorrect
      transaction metadata into a record, causing the server to halt
      with an error. To work around this issue, reduce the specified
      length of the primary key to less than 1K bytes. (Bug
      #14731482)

    * Repeated execution of a query containing a subquery that used
      MAX() could result in increasing memory consumption. (Bug
      #14683676)

    * USE dbname could fail with Unknown database when dbname
      contained multiple backtick (`) characters. (Bug #14645196)

    * The configure.pl script that converts GNU configure options to
      CMake equivalents generated erroneous output for the
      --with-client-ldflags and --with-mysqld-ldflags options. It
      now ignores those options. (Bug #14593123)

    * SHOW PROFILE could be used to cause excessive server memory
      consumption. (Bug #14629232)

    * The thread cache implementation worked in LIFO rather than
      FIFO fashion and could result in a thread being denied service
      (although this was a remote possibility). (Bug #14621627)

    * Within a stored program, memory allocated to hold condition
      information was not released until program exit, leading to
      excessive memory use. (Bug #14640599)

    * Improper memory cleanup could cause the server to exit. (Bug
      #14536113)

    * Granting or revoking the PROXY privilege caused the server to
      exit if the server was started with --skip-name-resolve. (Bug
      #14211140)

    * CREATE USER and DROP USER could fail to flush the privileges,
      requiring FLUSH PRIVILEGES to be used explicitly. (Bug
      #13864642)

    * Access to INFORMATION_SCHEMA tables through a view could leak
      memory. (Bug #13734987)

    * A memory leak could occur for queries containing a subquery
      that used GROUP BY on an outer column. (Bug #13724099)

    * On Microsoft Windows with CMake 2.6, the build process would
      not stop if the create_initial_db step failed. (Bug #13713525)

    * The test in mysqld_safe for the presence of the --plugin_dir
      option and assignment of a default value to it were performed
      before the actual argument parsing took place. (Bug #13548161)

    * CHECK TABLE and REPAIR TABLE could crash if a MyISAM table had
      a corrupt key (.MYI) file. Now the server produces an error.
      (Bug #13556441)

    * Improper memory cleanup could cause the server to exit. (Bug
      #13340270)

    * A memory leak occurred due to failure to clean up after
      QUICK_INDEX_MERGE_SELECT/Unique. (Bug #12694872, Bug
      #14542543)

    * The number of connection errors from a given host as counted
      by the server was periodically reset, with the result that
      max_connect_errors was never reached and invalid hosts were
      never blocked from trying to connect. (Bug #11753779)
      References: See also Bug #38247, Bug #43006, Bug #45584, Bug
      #45606.

    * During optimization, ZEROFILL values may be converted to
      string constants. However, CASE expressions did not handle
      switching data types after the planning stage, leading to CASE
      finding a null pointer instead of its argument. (Bug #57135,
      Bug #11764313)

    * In debug builds, an InnoDB assertion was overly aggressive
      about prohibiting an open range. (Bug #66513, Bug #14547952)

    * On Windows, the Perl version of mysql_install_db created
      system tables in the mysql database that were not populated
      properly. (Bug #65584, Bug #14181049)

    * mysqld_safe ignored the value of the UMASK environment
      variable, leading to behavior different from mysqld with
      respect to the access mode of created files. Now mysqld_safe
      (and mysqld_multi) attempt to approximate the same behavior as
      mysqld. (Bug #57406, Bug #11764559)

    * LAST_INSERT_ID(expr) did not work for expr values greater than
      the largest signed BIGINT value. (Bug #20964, Bug #11745891)

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

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

ページトップへ