|
MySQL 5.5.9 リリースノート (日本語翻訳)
機能の追加または変更:
・ mysqladmin および mysqldump クライアントに、使用する認証プラグインおよびプラグインディレクトリを指定するための--default-authおよび--plugin-dirオプションが追加された(Bug#58139)。
・ sql_priv.hに、MySQLClusterの transaction_allow_batching 機能用の OPTION_ALLOW_BATCH フラグが新たに含まれるようになった(Bug#57604)。
・ boolean型のシステム変数は、ランタイムを ON か OFF に設定することで有効になるが、以前はサーバの起動時にこれがうまくいかなかった。現在では、起動時にboolean型のシステム変数を ON または TRUE に設定することで有効化できる。変数がその他の非数の場合は、 OFF と解釈される(Bug#46393によって、 ON 、 TRUE 、 OFF および FALSE のみ認識され、その他の値は無効になるようになった)(Bug#51631)。
修正されたバグ:
・ パフォーマンス : InnoDB ストレージエンジン : InnoDB は、 PAUSE 指示が使用可能なすべてのプラットフォーム上で PAUSE 指示を使用するようになった。以前は、Windowsシステム上でのみ使用していた(Bug#58666)。
・ パフォーマンス :特に多くの外部キーが存在している場合に、必要な回数以上に統計が再チェックされていたため、 TABLE_CONSTRAINTS 、 KEY_COLUMN_USAGE 、および REFERENTIAL_CONSTRAINTS の INFORMATON_SCHEMA テーブル内の InnoDB テーブルを含むクエリが必要以上に遅かった。今回の改善は、多数のサーバや何万ものテーブルをMySQLEnterpriseMonitorで監視しているユーザに特に有用となるだろう(Bug#43818、Bug#11752585)。
・ 互換性のない変更 : auto_increment_increment が1よりも大きい場合、バルク挿入によって生成される値がカラムの最大値に達した場合、オーバーフローエラーを生じてラップアラウンドされる可能性があった。
この修正により、自動生成値が BIGINTUNSIGNED の最大値と等しくなることはなくなった。カラムによって受け入れられる場合は、その値を手動で保存することは可能である(Bug#39828)。
・ 重要な変更 : パーティショニング :パーティショニング関数として使用される日付と時刻関数のオペランドのタイプがチェックされるようになり、間違ったタイプの値は許可されなくなった。また、 col が DATE または DATETIME カラムの場合、戻り値が default_week_format システム変数の値に依存するため、 EXTRACT(WEEKFROMcol) も許可されなくなった(Bug#54483)。
Bug#57071も参照。
・ パーティショニング : InnoDB ストレージエンジン :パーティショニングハンドラがロック情報をテーブルのストレージエンジンハンドラに渡さなかったため、 InnoDB パーティションドテーブルで作業する際に競合が多くなり、パフォーマンスの低下を招いていた(Bug#59013)。
・ InnoDB ストレージエンジン :複数の InnoDB バッファプールが有効化された場合、 SHOWENGINEINNODB コマンドを実行すると、各バッファプールの情報は表示されたが、バッファプールのサブシステム全体の統計を組み合わせたサマリ情報は表示されなかった。現在では、 BUFFERPOOLANDMEMORY セクションに集計された情報が表示され、各バッファプールインスタンスに関する情報は新たな INDIVIDUALBUFFERPOOLINFO セクションに表示される(Bug#58461)。
・ InnoDB ストレージエンジン :デバッグビルドを作成するコマンド( cmake-DWITH_DEBUG... )を実行すると、 InnoDB のデバッグフラグ UNIV_DEBUG がすべてのプラットフォーム上で自動的に設定されるようになった。以前は、 UNIV_DEBUG フラグはXcodeがインストールされたOSXでは設定されず、VisualStudioがインストールされたWindowsプラットフォームでは設定されない可能性があった(Bug#58279)。
・ InnoDB ストレージエンジン : InnoDB ステータスの出力において、 I/Osum[] の値が間違って非常に大きな数字として表示される可能性があった(Bug#57600)。
・ InnoDB ストレージエンジン :ストアドプロシージャ、ストアドファンクションまたはトリガが、 auto-increment カラムを含む1つの InnoDB テーブルを修正し、自動インクリメントカラムを含む別の InnoDB テーブルを削除した場合に、サーバが表明エラーでクラッシュする可能性があった(Bug#56228)。
・ InnoDB ストレージエンジン :他の接続がBLOB型を含むクエリを実行している間は、 information_schema.innodb_trx テーブルをクエリすることができなかった(Bug#55397)。
・ InnoDB ストレージエンジン : lower_case_table_names 変数が2に設定された場合、 InnoDB が、大文字と小文字を区別する名前を含む外部キー制約のあるテーブルの mysqldump ダンプの復元に失敗する可能性があった(Bug#55222)。
・ InnoDB ストレージエンジン : OPTIMIZETABLE ステートメントを実行すると、 InnoDB テーブルの自動インクリメントカウンタがリセットされていた。現在では、このステートメントを実行しても、自動インクリメント値は保持される(Bug#18274)。
・ パーティショニング : ALTERTABLE...TRUNCATEPARTITION ステートメントが失敗した場合も、バイナリログに書き込まれていた(Bug#58147)。
・ パーティショニング : ALTERTABLE...PARTITION ステートメントが失敗すると、メモリリークが発生する可能性があった(Bug#56380)。
Bug#46949、Bug#56996も参照。
・ レプリケーション : INSERTDELAYED ステートメントに1つの値が挿入された場合、警告は返されないにも関わらず、警告がエラーログに書き込まれる可能性があった(Bug#57666)。
Bug#49567も参照。
・ レプリケーション :テンポラリテーブルを使用するセッションを閉じる時に、FailedtowritetheDROPstatementfortemporarytablestobinarylogという誤ったエラーによってバイナリロギングが失敗する場合があった(Bug#57288)。
・ レプリケーション :MySQL5.5.3で行われた変更により、 binlog_cache_size および max_binlog_cache_size サーバシステム変数の設定がバイナリログのステートメントキャッシュ(同バージョンから導入)とバイナリログのトランザクショナルキャッシュ(以前は単にバイナリログキャッシュと呼ばれていた)の両方に影響を与えるようになった。つまり、これらの変数のいずれかまたは両方を設定することによって、予測より2倍のリソースが使用されていた。この問題を解決するために、これらの変数はトランザクショナルキャッシュにのみ影響を与えるようになった。また、この修正によって、新たに binlog_stmt_cache_size と max_binlog_stmt_cache_size という、バイナリログのステートメントキャッシュのみに影響を与えるシステム変数2つが導入された。
さらに、いずれかのキャッシュが使用されるたびに Binlog_cache_use ステータス変数が、そしていずれかのキャッシュのディスク容量が使用されるたびに Binlog_cache_disk_use ステータス変数が増分されており、過度のディスクシークやそれに関連した問題のトラブルシューティングの際に、どちらのキャッシュの容量を超えたのかを判断することができないという、ステートメントのパフォーマンス調整およびトランザクショナルキャッシュの問題が発生していた。したがって、バイナリログのトランザクショナルキャッシュが使用された場合のみ、これら2つのステータス変数を増分するようにし、さらにバイナリログのステートメントキャッシュが使用された場合のみ増分される Binlog_stmt_cache_use と Binlog_stmt_cache_disk_use という2つの新たなステータス変数を導入したことで、この問題は解決した。
詳細については、「 Systemvariablesusedwiththebinarylog 」および セクション 5.1.6 「 ServerStatusVariables 」 を参照のこと(Bug#57275)。
・ レプリケーション :デフォルトでは、 AUTO_INCREMENT カラムの値は NULL または0をカラムに挿入することで生成される。 NO_AUTO_VALUE_ON_ZERO をサーバSQLモードに設定すると、0の動作が抑制されるため、 NULL がカラムに挿入された場合のみ生成される。
この動作は、レプリケーションスレーブがステートメントベースのフォーマットでマスタに記録されたイベントを適用する際にも(スレーブのSQLスレッドによって)引き継がれる。しかし、行ベースのフォーマットで記録されたイベントを適用する場合には、 NO_AUTO_VALUE_ON_ZERO が無視され、表明が発行される可能性があった。
この問題を修正するために、 AUTO_INCREMENT カラムの値は、スレーブ上で適用された変更に既に含まれているため、行ベースの行フォーマットで記録されたイベントを適用する場合には生成されなくなった(Bug#56662)。
・ レプリケーション :トランザクショナルストレージエンジンを使用するテーブルに変更を加えると、 Binlog_cache_use および Binlog_cache_disk_usestatus 変数が2回増分されていた(Bug#56343)。
・ レプリケーション : BINLOG ステートメントがセッション変数の値を修正していたため、point-in-timeリカバリなどの操作において問題が発生する可能性があった。たとえば、外部キー制約を持つ InnoDB テーブルのセットを作成し、データを投入するために、セッションレベルで foreign_key_checks=OFF を設定することに依存する行ベースのバイナリログを再実行する際に、問題が発生していた(Bug#54903)。
・ レプリケーション : mysqlbinlog は、デフォルトのデータベースがイベント間に変更した場合のみ、 USE ステートメントを出力していた。これはたとえば、ユーザが次のステートメントシーケンスを発行した場合に問題を引き起こす可能性があった。
CREATEDATABASEmydb;
USEmydb;
CREATETABLEmytable( column_definitions );
DROPDATABASEmydb;
CREATEDATABASEmydb;
USEmydb;
CREATETABLEmytable( column_definitions );
2つ目の CREATETABLE ステートメントを mysqlbinlog によって再生しようとすると、Error:NoDatabaseSelectedというエラーが出て失敗していた。これは、 mydb 以外のデータベースが選択されていないため、2つ目の USE ステートメントが再生されていないからである。
この修正により、 mysqlbinlog は、バイナリログから USE ステートメントを読み取るたびに、 USE ステートメントを出力するようになった(Bug#50914)。
・ レプリケーション :以前は、ステートメントがスレーブ上でマスタ上とは異なるエラーで失敗した場合、スレーブのSQLスレッドが以下を含むメッセージを表示していた。
・マスタのエラーコードに対するエラーメッセージ
・マスタのエラーコード
・スレーブのエラーコードに対するエラーメッセージ
・スレーブのエラーコード
ところが、スレーブにはマスタのメッセージの出力フォーマット指定子を記述するための情報がないため、メッセージ形式の文字列をそのまま表示していた。マスタに表示されるのと同じメッセージが表示されていないことをより明確にするために、スレーブは出力されるマスタの部分をメッセージそのものではなく、メッセージ形式で表示するようになった。例えば以前は、スレーブは次のような情報を表示していた。
Error:"Querycauseddifferenterrorsonmasterandslave.Erroronmaster:
'Duplicateentry'%-.192s'forkey%d'(1062),Erroronslave:
'noerror'(0).Defaultdatabase:'test'.Query:
'insertintot1values(1),(2)'"(expecteddifferenterrorcodesonmasterandslave)
現在では、スレーブは次のメッセージを表示する。
Error:"Querycauseddifferenterrorsonmasterandslave.Erroronmaster:
messageformat='Duplicateentry'%-.192s'forkey%d'errorcode=1062;
Erroronslave:actualmessage='noerror',errorcode=0.Defaultdatabase:
'test'.Query:'insertintot1values(1),(2)'"
(expecteddifferenterrorcodesonmasterandslave)(Bug#46697)
・ レプリケーション :新しいバイナリログファイルの名前の生成時にエラーが発生した場合、エラーは記録されたがユーザには表示されなかった(Bug#46166)。
Bug#37148、Bug#40611、Bug#43929、Bug#51019も参照。
・ 集計値と TIMESTAMP 値の比較が不正確だった(Bug#59330)。
・ DIV 式の結果を複数の変数に割り当てると、サーバがクラッシュする可能性があった(Bug#59241)。
Bug#8457も参照。
・ MIN( year_col ) が間違った結果を返す場合があった(Bug#59211)。
・ mysql_store_result() が NULL を返したかどうかのチェックに mysqlslap が失敗し、結果セットを処理しようとしてクラッシュしていた(Bug#59109)。
・ サブクエリにおいて、参照テーブルのない(もしくはバーチャルテーブル dual のみを参照している) UNION が、 ORDERBY 句を許可しなかった(Bug#58970)。
・ -DWITHOUT_PERFSCHEMA_STORAGE_ENGINE=1でMySQLを構成すると、ビルドが失敗した(Bug#58953)。
・ いくつかのValgrind警告が修正された(Bug#58948、Bug#59021)。
・ InnoDB テーブルで OPTIMIZETABLE を実行し、その操作が強制終了によって失敗した場合、表明が発行される可能性があった(Bug#58933)。
・ max_allowed_packet が16MBより上に設定された場合、サーバが“Packettoolarge”エラーによって大きすぎるパケットを拒否できなかった(Bug#58887)。
・ HAVING 句を含むサブクエリを引数に取る NOTIN 述語が取得する行が、サブクエリ自体が NULL を返した場合に多すぎる可能性があった(Bug#58818)。
・ 2つの派生テーブルにアクセスするクエリにおいて、 EXPLAIN がクラッシュする可能性があった(Bug#58730)。
・ Solarisで、デバッグが有効になっている状態でMySQLを構成した場合に、ビルドが失敗した(Bug#58699)。
・ 条件のプッシュダウンを使用するクエリにおいて EXPLAINEXTENDED を発行すると、 mysqld がクラッシュする可能性があった(Bug#58553)。
・ オプティマイザがIndexMergeレンジアクセスまたはconstrefアクセスメソッドのいずれかを選択できるクエリについて、表明が発行される可能性があった(Bug#58456)。
・ VisualStudioExpressでMySQLをビルドした場合、プロジェクトwixcaがビルドされなかった(Bug#58411)。
・ GROUP_CONCAT() を使用するクエリにおいて、 EXPLAIN がクラッシュする可能性があった(Bug#58396)。
・ CMake が、インストールに関連するテンポラリファイルをソースツリーに無駄に書き込んでいた(Bug#58372)。
・ DTraceとの互換性向上のために、sp_head.ccのセキュリティコンテキストの参照先が書き換えられた(Bug#58350)。
・ ucs2 文字セットは、BMP(BasicMultilingualPlane:基本多言語面)以外の文字をサポートしていないが、そのような文字を含む文字列を変換しても、変換に失敗したという警告が生成されなかった(Bug#58321)。
・ archive_discover から fn_format を呼び出す時にValgrindエラーが発生した(Bug#58205)。
・ CMake によって、 MYSQL_ADD_PLUGIN の LINK_LIBRARIES が libmysqld に追加されなかった(Bug#58158)。
・ サーバが、別のスレッドによって強制終了されたセッションを同時に閉じた場合、表明が発行される可能性があった(Bug#58136)。
・ 条件のプッシュダウンの最適化を実行すると、間違ったカラムを参照した条件をプッシュダウンする可能性があった(Bug#58134)。
・ icc でコンパイルする際に、保守用モードで構成を有効にするとエラーが発生した(Bug#57991、Bug#58871)。
・ ORDERBY 句を UNION コンテキストで使用した場合、間違ったサブステートメントに結合されていた(Bug#57986)。
・ 結合によって一致する行が返されない場合、 BIT_AND() 関数が間違った結果を返す可能性があった(Bug#57954)
・ AVG(DISTINCT) と一緒に集計された値セットに NULL 値が含まれている場合、関数の結果が不正確な可能性があった(Bug#57932)。
・ 短縮形を含む照合順序を使用するインデックス付きコラムについて、 LIKE 式が失敗する場合がまれにあった(Bug#57737)。
・ コンテキスト内でステートメント準備やビュー作成などの不必要なサブクエリ評価を実行すると、サーバがクラッシュする可能性があった(Bug#57703)。
・ ビューの作成によって、Valgrind警告が発生する可能性があった(Bug#57352)。
・ NULL ジオメトリ値によって、 Item_func_spatial_collection::fix_length_and_dec がクラッシュする可能性があった(Bug#57321)。
・ PerformanceSchemaのサポートがあれば mysqld をコンパイルすることは可能だったが、ダミーの不可分操作を実装する必要があり、その結果サーバがクラッシュしていた。この問題はバイナリディストリビューションには影響を及ぼさないが、ソースからMySQLをビルドするユーザにとって、安全策として有効である(Bug#56769)。
・ cp1251 文字セットがユーロ記号( 0x88 )を正しくサポートしていなかった。例えば、 cp1251 の文字を含む文字列を utf8 に変換すると、 utf8 のユーロ記号ではなく '?' となっていた(Bug#56639)。
・ 符号なしシステム変数が負の値として表示される可能性があった(Bug#55794)。
・ CREATEDATABASE および DROPDATABASE によって、 mysql--one-database がステートメントをフィルタリングするコンテキストを管理できなくなった(Bug#54899)。
・ DROPDATABASE と REPAIRTABLE が同時に実行され、 DROPDATABASE がテーブルの.TMDファイルを削除すると同時に、 REPAIRTABLE がその削除されたファイルの詳細を読み込もうとした場合に表明が発行される可能性があった。
また、 REPAIRTABLE がテーブルの.TMDファイルを削除すると同時に、 DROPTABLE がそのテーブルに属する全ファイルを削除しようとした場合にも問題が発生する可能性があった(Bug#54486)。
・ ソースからのコンパイル後、インストールのincludeディレクトリのサブディレクトリにインストールされるべきものも含め、すべてのヘッダファイルが同じディレクトリにインストールされていた(Bug#51925)。
・ mysqld がクラッシュダンプ情報を出力する際に、いくつかの有効なポインタが間違って無効と示されていた(Bug#51817)。
・ MacOSXで、構成エラーが発生するとpreferencepaneが失敗した(Bug#51264)。
・ FreeBSDで、 SIGHUP シグナルによって mysqld が強制終了された場合、 InnoDB の.ibdファイルが破損する可能性があった(Bug#51023)。
・ 2つ以上の行に書き込みを行うステートメントによって、 AUTO_INCREMENT カラムに1が挿入された場合、表明が発行される可能性があった(Bug#50619)。
・ MySQLの権限テーブルに保管されるユーザ名には最大16文字まで使用できるが、クライアントがそれよりも長いユーザ名を提供した場合、すべての文字が考慮されていた。それを従来どおり、最初の16文字で一致を確認する動作に戻した(Bug#49752)。
・ my_seek() および my_tell() 関数が、エラーを返す時に MY_WME フラグを無視していたため、クライアントプログラムがハングする可能性があった(Bug#48451)。
・ システム変数への値の割り当て時に、値の範囲の妥当性チェックを実行するタイミングが遅いため、適切なエラーチェックが行われなかった(Bug#43233)。
・ Solarisで、 NOW() や SYSDATE() などの時刻関数が、一定値を返す可能性があった(Bug#42054)。
・ FEDERATED テーブルのあるリモートサーバにアクセスできない場合、 INFORMATION_SCHEMA.TABLES テーブルに対するクエリが失敗した(Bug#35333)。