|
MySQL 5.1.53 リリースノート (日本語翻訳)
修正されたバグ:
・ InnoDB ストレージエンジン : Bug#54678 のフォローアップ修正。デバッグバージョンのサーバでは、 TRUNCATETABLE が従来同様にクラッシュ(表明違反)する可能性があった( Bug#57700 )。
・ InnoDB ストレージエンジン :高負荷時のサーバで、InnoDBシステムテーブルスペースが大きくなり続ける可能性があった( Bug#57611 )。
・ InnoDB ストレージエンジン : innodb_stats_on_metadata オプションを使用すると、 ANALYZETABLE ステートメントを実行できない可能性があった( Bug#57252 )。
・ InnoDB ストレージエンジン : InnoDB テーブルに対する ALTERTABLE の実行中にサーバがクラッシュした場合、 SHOWCREATETABLE でテーブルを調査するか、または INFORMATION_SCHEMA テーブルに対してクエリを実行すると、サーバが表明違反を発行して停止する可能性があった( Bug#56982 )。
・ InnoDB ストレージエンジン :カラムに大文字と小文字を区別しないインデックスが存在し、カラムの値の大文字が小文字に変更されるか、小文字が大文字に変更された場合、 InnoDB テーブルに対するクエリ結果に間違った値が返される可能性があった( Bug#56680 )。
・ InnoDB ストレージエンジン :外部キーが大量に宣言されている場合、 SHOWCREATESTATEMENT ステートメントの出力が切り捨てられる可能性があった( Bug#56143 )。
・ InnoDB ストレージエンジン :コンパイルの問題がNetBSD/sparc64上の InnoDB ソースコードに影響を与えていた( Bug#53916 )。
・ レプリケーション :MySQL5.1のマスタとMySQL5.5のスレーブの間の行ベースのレプリケーションが、 SETPASSWORD で失敗していた。
この修正の結果、MySQL5.1.53またはMySQL5.1の最新リリースを動作しているマスタとMySQL5.5.7またはMySQL5.5の最新のリリースを動作しているスレーブの間で、行ベースのレプリケーションを使用して、 SETPASSWORD を正しくレプリケートできるようになった( Bug#57098 )。
・ レプリケーション : ALTERTABLE ステートメントを使用して MyISAM テーブルのカラムにサイズ設定以外の変更を実行すると、バイナリログが破損し、レプリケーション違反が発生した( Bug#56226 )。
・ レプリケーション :トランザクショナルストレージエンジンを使用するテーブルだけを更新するトランザクションの実行中に、 STOPSLAVE が発行されると、スレーブSQLスレッドは現在のトランザクションを後退復帰してすぐに停止する。以前は、 CREATETEMPORARYTABLE ステートメントと DROPTEMPORARYTABLE ステートメントはどちらも後退復帰不可であるにもかかわらず、そのどちらか、または両方を含むトランザクションでも、同じ動作が行われていた。テンポラリテーブルはユーザセッション(この場合はレプリケーションユーザ)が終了するまで存在するので、スレーブが停止またはリセットされるまで残存する。その後 STARTSLAVE ステートメントが実行され、トランザクションが再起動されると、作成しようとするテンポラリテーブルはすでに存在する(または削除しようとするテンポラリテーブルは存在しない)というエラーでSQLスレッドが中断する。
この修正によって、実行中のトランザクションに CREATETEMPORARYTABLE ステートメントと DROPTEMPORARYTABLE ステートメントのどちらか、または両方が含まれる場合、SQLスレッドはトランザクションの終了を待機した後、停止するようになった( Bug#56118 )。
・ レプリケーション :同じ名前のテンポラリテーブルと非テンポラリテーブルがどちらも存在する場合、その名前を指定した更新は、通常はテンポラリテーブルにのみ適用される。ただし、その非テンポラリテーブルが、 CREATETABLE...SELECT ステートメントで既存のテンポラリテーブルと同じ名前を指定して作成されたものである場合は例外である。 MIXED ログ形式を使用してそのようなステートメントが複製され、それが行ベースのログにとってアンセーフな場合、更新がテンポラリテーブルに適用されなかった( Bug#55478 )。
・ レプリケーション :スレーブがその max_binlog_cache_size の値よりも大きなトランザクションを実行しようとすると、クラッシュしていた。これは、ER_TRANS_CACHE_FULLエラーが発生した場合、サーバはトランザクション全体ではなく、そのステートメントだけを後退復帰するべきであるという表明が原因だった。ただし、スレーブSQLスレッドは、エラーのタイプに関係なく、エラーが発生するたびに必ずトランザクション全体を後退復帰していた( Bug#55375 )。
・ レプリケーション : CHANGEMASTERTO を使用してリレーログ設定を変更した場合、I/Oキャッシュがクリアされなかった。そのため、スレーブが無効データをキャッシュから読み取ろうとして、表明を発行して停止した場合、レプリケーションが失敗する可能性があった( Bug#55263 )。
・ レプリケーション :無効なタイプのログイベントを含むバイナリログを読み取ろうとすると、スレーブがクラッシュした( Bug#38718 )。
・ レプリケーション : mysql.tables_priv テーブルを複製しても、 Grantor カラムが複製されず、スレーブでは空のままだった( Bug#27606 )。
・ サーバがトレースファイルのオープンに失敗した場合、 SETGLOBALdebug によってSolarisがクラッシュする可能性があった( Bug#57274 )。
・ SELECT ステートメントによって返される行の数が、同じ行を選択することが予想される CREATETABLE...SELECT によって返される行数と異なる可能性があった( Bug#56423 )。
・ ファイル名の大文字と小文字を区別しないファイルシステムで lower_case_table_names=2 と設定されている場合、テーブル定義キャッシュの不一致によってサーバがクラッシュする可能性があった( Bug#46941 )。