|
MySQL 5.1.51 リリースノート (日本語翻訳)
InnoDBに関する注意事項:
・ InnoDBPlugin はバージョン1.0.12にアップグレードされている。本バージョンは、GeneralAvailability(GA)の品質であるとみなされている。
今回のリリースでは、 InnoDBPlugin は、RHEL3、RHEL4、SuSE9(x86、x86_64、ia64)、およびLinuxRPM汎用パッケージを除き、ソースおよびバイナリディストリビューションに含まれている。また、FreeBSD6とHP-UX、およびia64全般のLinuxでは動作しない。
修正されたバグ:
・ セキュリティ修正 :極値関数( LEAST() 、 GREATEST() など)への引数の評価時に、タイプエラーが正しく伝播しなかったために、サーバがクラッシュしていた( Bug#55826 、 CVE-2010-3833 )。
・ セキュリティ修正 :グルーピングのためにテンポラリテーブルを必要とした派生テーブルを実体化した後、サーバがクラッシュする可能性があった( Bug#55568 、 CVE-2010-3834 )。
・ セキュリティ修正 :論理式コンテキストで評価されるユーザ変数への代入式は、 GROUPBY のためのテンポラリテーブルで事前に計算することができる。ただし、テンポラリテーブルの作成後に式の値を使用しようとすると、その値をテンポラリテーブルから読み取るのではなく、式の再評価を実行し、結果的にサーバがクラッシュしていた( Bug#55564 、 CVE-2010-3835 )。
・ セキュリティ修正 :タイムゾーン引数が空の SET カラム値だった場合、 CONVERT_TZ() 関数によってサーバがクラッシュしていた( Bug#55424 )。
・ セキュリティ修正 :ビューのプレパレーション中に LIKE 述語を事前評価すると、サーバがクラッシュする可能性があった( Bug#54568 、 CVE-2010-3836 )。
・ セキュリティ修正 : GROUP_CONCAT() と WITHROLLUP を同時に使用すると、サーバがクラッシュする可能性があった( Bug#54476 、 CVE-2010-3837 )。
・ セキュリティ修正 :クエリで使用している GREATEST() 関数または LEAST() 関数の引数のリストに数値引数と LONGBLOB 引数が混在し、そのような関数を実行した結果が中間テンポラリテーブルを使用して処理された場合、サーバがクラッシュする可能性があった( Bug#54461 、 CVE-2010-3838 )。
・ セキュリティ修正 :ストアドプロシージャまたはプリペアドステートメントで、ネスト化された結合を使用するクエリを実行した場合、サーバで無限ループが発生する可能性があった( Bug#53544 、 CVE-2010-3839 )。
・ セキュリティ修正 : PolyFromWKB() 関数に不正なWKBデータが渡された場合、サーバがクラッシュする可能性があった( Bug#51875 、 CVE-2010-3840 )。
・ 矛盾を含む可能性がある変更 : レプリケーション :MySQL5.5.6の時点で、 CREATETABLEIFNOTEXISTS... SELECT ステートメントで作成するテーブルが既存の場合の処理が変更されている。
・ 以前は、 CREATETABLEIFNOTEXISTS... SELECT で作成するテーブルが既存であることを示す警告がMySQLによって生成されたが、行は挿入され、このステートメントはバイナリログに書き込まれていた。一方、 CREATETABLE... SELECT ( IFNOTEXISTS なし)はエラーを生成して失敗し、行は挿入されず、このステートメントはバイナリログに書き込まれなかった。
・ 現在は、どちらのステートメントも作成するテーブルが既存の場合の処理は同じ(行は挿入されず、ステートメントはバイナリログに書き込まれない)である。ただし、 IFNOTEXISTS がある場合は警告が生成され、ない場合はエラーが生成される点が異なっている。
IFNOTEXISTS の処理の変更によって、変更前の動作を行うMySQL5.1のマスタから変更後の動作を行うMySQL5.5のスレーブへのステートメントベースのレプリケーションで矛盾が発生することになる。たとえば、マスタで CREATETABLEIFNOTEXISTS...SELECT を実行して、作成するテーブルが既存の場合、マスタでは行が挿入されるが、スレーブでは行は挿入されないという結果になる(行ベースのレプリケーションではこの問題は発生しない)。
この問題を解決するために、MySQL5.1では5.1.51の時点で CREATETABLEIFNOTEXISTS... SELECT のステートメントベースのバイナリログについて、以下の変更が行われている。
・作成するテーブルが存在しない場合、これまでどおり、ステートメントはそのままログに記録される。
・ 作成するテーブルが存在する場合、ステートメントはそれと等価な CREATETABLEIFNOTEXISTS ステートメントと INSERT... SELECT ステートメントのペアとしてログに記録される(元のステートメントの SELECT の前に IGNORE または REPLACE が置かれ、 INSERT はそれぞれ INSERTIGNORE または REPLACE に置き換えられる)。
この変更によって、作成するテーブルが既存の場合にマスタとスレーブの両方に行が挿入されるので、MySQL5.1から5.5へのステートメントベースのレプリケーションに前方互換性が提供される。この互換性対策を有効にするには、5.1サーバで5.1.51以降を、5.5サーバで5.5.6以降を使用する必要がある。
既存の5.1から5.5へのレプリケーションシナリオをアップグレードするには、最初にマスタを5.1.51以降にアップグレードする。通常のレプリケーションのアップグレードでは最初にスレーブをアップグレードするように勧告しているが、この場合はそれとは違うので注意すること。
元の動作(作成するテーブルが既存かどうかに関係なく行を挿入する)を使用する必要があるアプリケーションでは、 CREATETABLEIFNOTEXISTS および INSERT...SELECT ステートメントの代わりに CREATETABLEIFNOTEXISTS...SELECT ステートメントを使用することで対応できる。
この変更に関連して、もう1つの変更が同時に行われた。以前は、 CREATETABLEIFNOTEXISTS... SELECT で作成するテーブルと同じ名前のビューが既存だった場合、基礎となるベーステーブルに行が挿入され、このステートメントはバイナリログに書き込まれていた。MySQL5.1.51および5.5.6の時点では、行は挿入されず、ステートメントはログに記録されない( Bug#47442 、 Bug#47132 、 Bug#48814 、 Bug#49494 )。
・ 矛盾を含む可能性がある変更 :以前は、 mysqld がファイルにエラーログを書き込んでいる場合(たとえば --log-error オプション付きで起動されていた場合)、 FLUSHLOGS または mysqladminflush-logs を使用してログをフラッシュすると、現在のログファイルの名前をサフィックス -old 付きの名前に変更して、新しい空のログファイルを作成していた。この場合、もう一度ログフラッシュを実行すると、元のエラーログファイルは、別の名前で保存した場合を除いて失われていた。たとえば、ファイルを保存するには、以下のコマンドを使用する。
・shell> mysqladminflush-logs
・shell> mv host_name .err-old backup-directory
ファイルが失われる問題を回避するために、名前の変更は行わずに、サーバはログファイルのクローズと再オープンだけを行うように変更された。ファイルの名前の変更は、フラッシュの前に手動で実行できる。その後でフラッシュを実行すると、元のファイル名で新しいファイルが再オープンされる。たとえば、ファイルの名前を変更してから新しいファイルを作成するには、以下のコマンドを使用する。
shell> mv host_name .err host_name .err-old
shell> mysqladminflush-logs
shell> mv host_name .err-old backup-directory
( Bug#29751 )
Bug#56821 も参照。
・ InnoDB ストレージエンジン :クラッシュの後にオプションで innodb_force_recovery=6 を指定してMySQLを再起動すると、 InnoDB テーブルに対する一部のクエリが、 WHERE 句または ORDERBY 句によって失敗する可能性があった。
ディザスタリカバリのような状況では、通常はそれらの句を含まないクエリを使用して、テーブル全体をダンプする。高度なトラブルシューティングの実行中は、それらの句を含むクエリを使用して、破損したデータの所在を診断したり、破損した部分に応じてデータをリカバリすることができる( Bug#55832 )。
・ InnoDB ストレージエンジン : CHECKTABLE コマンドによって、長い時間がかかる InnoDB 適応ハッシュインデックスメモリ構造の検証が行われる可能性があった。現在は、このチェックは、デバッグ用にビルドされたバイナリでのみ実行される( Bug#55716 )。
・ InnoDB ストレージエンジン :デバッグバージョンのサーバでは、スレッドが大量に存在して高負荷になると、クラッシュする可能性があった( Bug#55699 )。
・ InnoDB ストレージエンジン : InnoDB テーブルに対する RENAMETABLE 操作中にサーバがクラッシュした場合、その後に行うクラッシュリカバリが失敗する可能性があった。この問題は、内部的に名前変更操作が行われる ALTERTABLE ステートメントにも影響する可能性があった( Bug#55027 )。
・ InnoDB ストレージエンジン :外部キーを経由して子テーブルの長いチェーンにリンクされている InnoDB テーブルをオープンすると、サーバがクラッシュする可能性があった( Bug#54582 )。
・ パーティショニング :パーティションドテーブルの作成に使用したストレージエンジンが無効な場合、そのテーブルを削除しようとすると、サーバがクラッシュした( Bug#46086 )。
・ CREATETABLE... SELECT で作成しようとするテーブルと同じ名前のビューが既存の場合、 IFNOTEXISTS が使用されたかどうかに関係なく、サーバが警告を生成した。現在は、 IFNOTEXISTS が使用された場合だけ警告が生成され、使用されなかった場合はエラーが生成される( Bug#55777 )。
・ Bug#39653 を修正した後は、フルテーブルスキャンに使用されるのは使用可能な最も短いセカンダリインデックスであり、使用できるセカンダリインデックスが存在しない場合にかぎり、クラスタ化プライマリキーが使用された。しかし、選択されたセカンダリインデックスにスキャンするテーブルのすべてのカラムが含まれる場合は、スキャンするデータ量は同じだがプライマリインデックスはクラスタ化されているという理由で、プライマリインデックスを使用するほうが適切である。現在はこのことが考慮されるようになっている( Bug#55656 )。
・ サーバが、GROUPBY、ORDERBY、またはDISTINCTで使用するテンポラリテーブルの行にデータをコピーするときに、 Item::val_xxx() メソッドの実行中に生成されるエラーをチェックしていなかった( Bug#55580 )。
・ ユーザ変数式を含む ORDERBY 句によってデバッグ表明が発生する可能性があった( Bug#55565 )。
・ InnoDB スカラサブクエリの代入によって、 READCOMMITTED トランザクションアイソレーションレベルで予期しない S ロックが発生した( Bug#55382 )。
・ const NOTBETWEEN not_indexed_column AND indexed_column という形式の述語を含むクエリが、範囲オプティマイザによる不正な処理のために正しくない結果を返す可能性があった( Bug#54802 )。
・ MIN() または MAX() にサブクエリ引数を渡すと、デバッグビルドの場合はデバッグ表明が発生する可能性があった。また、非デバッグビルドの場合は正しくないデータを返す可能性があった( Bug#54465 )。
・ INFORMATION_SCHEMA プラグインに deinit() メソッドが存在しない場合、メモリリークが発生する可能性があった( Bug#54253 )。
・ LOCKTABLES によってロックされたテンポラリトランザクショナルテーブルに対して ALTERTABLE を実行した後で、 LOCKTABLES または UNLOCKTABLES を実行しようとすると、サーバがクラッシュした( Bug#54117 )。
・ INSERTIGNOREINTO...SELECT ステートメントによってデバッグ表明が発生する可能性があった( Bug#54106 )。
・ INFORMATION_SCHEMA.COLUMNS が BIGINTUNSIGNED のカラムの精度として正しくない情報をレポートした( Bug#53814 )。
・ Bug#30234 の修正によって、複数テーブルに対する DELETE ステートメントのアクセス互換性構文である DELETEtbl_name.* ... をサーバが拒否するようになった( Bug#53034 )。
・ XASTART に、サーバをクラッシュさせる可能性がある競合状態が存在していた( Bug#51855 )。
・ 列挙プラグイン変数が、型キャストエラーの影響を受けて、異なるプラットフォーム間で一貫性のない結果を生成していた( Bug#42144 )。
・ SolarisのPKGインストールで、いくつかのファイルが正しくない位置に置かれていた( Bug#31058 )。
・ アトミックオペレーションの実装に問題があり、サーバがクラッシュする可能性があった( Bug#22320 、 Bug#52261 )。