オープンソース サポート サービス(OSS サポート サービス)| オープンソースまるごと OpenStandia™(オープンスタンディア)
野村総合研究所


MySQL 5.1.48 リリースノート (日本語翻訳)

 

InnoDBに関する注意事項:

・ InnoDBPlugin はバージョン1.0.9にアップグレードされている。本バージョンは、GeneralAvailability(GA)の品質であるとみなされている。 InnoDBPluginChangeHistory には、ここで報告した変更点に加えて情報が含まれている場合がある。

今回のリリースでは、 InnoDBPlugin は、RHEL3、RHEL4、SuSE9(x86、x86_64、ia64)、およびLinuxRPM汎用パッケージを除き、ソースおよびバイナリディストリビューションに含まれている。また、FreeBSD6とHP-UX、およびia64全般のLinuxでは動作しない。

機能の追加と変更:

・行を変更する UPDATE および DELETE ステートメントの場合、スロークエリログ行の Rows_examined 値はゼロ以外の値になる( Bug#49756 )。

修正されたバグ:

・ 重要な変更 : レプリケーション : トランザクショナルスレーブに複製された MyISAM トランザクションは、スレーブを不安定な状態にしていた。これは、 autocommit をオフにして非トランザクショナルストレージエンジンからトランザクショナルエンジンに複製すると BEGIN および COMMIT ステートメントがバイナリログに書き込まれないことが原因だった。したがって、スレーブでは、終わりのないトランザクションが開始された。

この問題の修正には、マスタからすべての autocommit=1 ステートメントを複製することによってスレーブに autocommit モードを強制する処理が含まれている( Bug#29288 )。

・ パーティショニング : テーブルパーティションの名前変更または削除を引き起こす ALTERTABLE ステートメント( ALTERTABLE...ADDPARTITION 、 ALTERTABLE...DROPPARTITION 、 ALTERTABLE...REORGANIZEPARTITION など )は、 INFORMATION_SCHEMA.PARTITIONS テーブルに対するクエリと同時に実行すると、失敗したり、影響を受けるパーティションドテーブルを使用不可能にしたり、その両方の問題を発生する可能性があった。これは、影響を受けるパーティションの ALTERTABLE ステートメントによって強要された名前ロックを INFORMATION_SCHEMA データベースが無視していたことが原因だった。 InnoDB は名前変更操作を受け入れたが、それをバックグラウンドキューに入れたため、 InnoDB が正しいパーティションを検出できない場合は後続の名前変更操作が失敗した。そのため、これは特に InnoDB テーブルの問題につながった。 INFORMATION_SCHEMA は、パーティションの名前変更または削除を引き起こす進行中の ALTERTABLE ステートメントによって強要された名前ロックに従うようになっている( Bug#50561 )。

Bug#47343 、 Bug#45808 も参照。

・ パーティショニング : パーティションドテンポラリテーブルが許可されていなくても、 CREATETEMPORARYTABLEtmpLIKEpt ステートメント(ptはパーティションドテーブル)を実行することが可能だった。これにより、サーバがクラッシュした。現在は、そのようなステートメントの実行を防止するためのチェックが行われるようになっている( Bug#49477 )。

・ パーティショニング : パーティションドテーブルで DDL を実行し、そのテーブルの .par ファイルが見つからない場合、サーバは Outofmemory;restartserverandtryagain(needed2bytes) という不正確なエラーメッセージを返した。このような場合、サーバは Failedtoinitializepartitionsfrom.parfile というエラーを返すようになった( Bug#49161 )。

・ レプリケーション : 互換性のないタイプの値でカラムを更新しようとすると、マスタでは(予期したとおりに)カラム値が暗黙的なデフォルト値に設定されたが、スレーブ上の同じカラムは NULL に設定されたため、マスタとスレーブの間で不一致が生じることがあった( Bug#52868 )。

・ レプリケーション : autocommitを無効にして 非トランザクショナルテーブルをマスタで使用すると、バイナリログでは、このテーブルに影響を及ぼすステートメントの後に COMMIT が記録されなかった。スレーブでこのテーブルのコピーがトランザクショナルストレージエンジンを使用した場合、トランザクションは開始されたが、決して完了しないようだった( Bug#49522 )。

Bug#29288 も参照。

・ レプリケーション : 自己ログストレージエンジンを使用するテーブルからの読み取りおよびトランザクショナルエンジン( InnoDB など )を使用するテーブルの更新では、スレーブを分化させる可能性のあるステートメント形式を使用して、バイナリログに書き込まれる変更が生成された。ただし、混合ログ形式を使用している場合、そのような変更は行形式を使用してバイナリログに書き込まれる必要がある(自己ログエンジンを使用しているテーブルからの読み取り時および MyISAM テーブルの更新時には、 非トランザクショナルエンジンとトランザクショナルエンジンの組み合わせのチェックによってすでに対処されていたため、この問題は発生しなかった)。そのようなステートメントはアンセーフとして分類され、混合モードでは行ベースのログへの切り替えを引き起こすようになった( Bug#49019 )。

・ 一般に Windows システムのシャットダウン中には、 InnoDB:Assertionfailureinthread nnnn というメッセージを表示してサーバがクラッシュすることがあった( Bug#53947 )。

・不完全な DATETIME 値を TIMESTAMP() 関数に渡すことによって発生するValgrind警告は修正された( Bug#53942 )。

・ InnoDB テーブルの UPDATE が、 WHERE 条件を満たすために使用される同じインデックスを変更すると、環境によってはデバッグ表明がトリガされる可能性があった( Bug#53830 )。

・ ALTERDATABASE`#mysql50#< special >`UPGRADEDATADIRECTORYNAME の< special >が「.」、「..」、または「 」あるいは「 」で始まるシーケンスの場合、MySQLはこのステートメントを正しく処理しなかった。MySQLはサーバデータディレクトリ(他の通常のデータベースが含まれている)をデータベースディレクトリとして使用していた( Bug#53804 、 CVE-2010-2008 )。

・InnoDBは、 /*/ というシーケンスを誤ってコメントの開始 / 終了シーケンスとみなした( Bug#53644 )。

・ 高速 ALTERTABLE がユニークインデックスを追加した後に、テーブルで複製を置換すると、 InnoDB がクラッシュした( Bug#53592 )。

・ InnoDB テーブルの場合、高速 CREATEINDEX のエラーハンドラは失敗した操作の取り消しを試みる前にトランザクションのエラー状態をリセットしなかったため、クラッシュが発生した( Bug#53591 )。

・単一テーブルの場合、クイックセレクトとインデックススキャンを同時に使用する DELETE ステートメントは、サーバのクラッシュまたは表明違反を引き起こした( Bug#53450 )。

・不可能なWHERE条件を持つ InnoDB テーブルの LEFTJOIN では 、不正な結果が返される可能性があった( Bug#53334 )。

・ユニークキーを複数のカラムに追加し、そのいずれかのカラムがnullである場合、重複キーエラーが誤ってレポートされる可能性があった( Bug#53290 )。

・ --innodb_checksums オプションが有効な場合に 圧縮テーブルについてレポートされるチェックサムエラーを修正した( Bug#53248 )。

・ innodb_change_buffering=default 設定の処理を修正した(MySQL5.1と5.5の間では、適切なデフォルト値が異なる)( Bug#53165 )。

・ mysqldump と SELECT...INTOOUTFILE は、長い BLOB および TEXT 値を766バイトに切り詰めていた( Bug#53088 )。

・デバッグバージョンのサーバでは、環境によっては FreeState() 関数が2回呼び出され、表明違反が発生する可能性があった( Bug#52884 )。

・外部結合クエリでは、集計関数が誤ってNULLを返す可能性があった( Bug#52051 )。

・外部結合の場合、オプティマイザはテーブル依存関係を正しく計算できなかった( Bug#52005 )。

・LooseIndexScan最適化メソッドは、あたかもストレージエンジンであるかのように、パーティショニングエンジンに依存して間隔エンドポイント情報を維持できることを前提としていた( Bug#50939 )。

・EventSchedulerイベントの間隔の計算は移植可能でなかった( Bug#50087 )。

・ INFORMATION_SCHEMA.ROUTINES または INFORMATION_SCHEMA.PARAMETERS から選択を行うと、メモリリークが発生した( Bug#48729 )。

・複数ステートメントの実行は、外部キー制約に関するエラーを発生して失敗することがあった。この問題は、 mysql_query() と mysql_real_query() の呼び出し 、およびストアドプロシージャを呼び出す CALL ステートメントに影響する可能性があった( Bug#48024 )。

・トランザクションのアイソレーションレベルが REPEATABLEREAD で、バイナリログがステートメントまたは混合形式を使用した場合、 InnoDB テーブル を参照する サブクエリがあるSELECTステートメントは、これらのテーブルの行で共有ロックを不必要に取得していた( Bug#46947 )。

・複数の結果セットを生成する初期コマンド(ストアドプロシージャや複数ステートメントコマンドなど)を mysql_options(...,MYSQL_INIT_COMMAND,...) で使用すると、接続が使用不可能になった( Bug#42373 )。

・InnoDBの「高速インデックス作成」メカニズムを使用してインデックスを作成しているときにクラッシュが発生した場合、データベース再起動時のクラッシュリカバリ処理では、部分的に作成されたインデックスが削除される。

  • 免責条項
  • |  サイト利用規定
  • |  個人情報保護方針
  • |  個人情報の取り扱いについて
  • |  情報セキュリティ対策についての宣言文
  • |  
  • |  アクセスマップ
© Copyright Nomura Research Institute, Ltd. All rights reserved. オープンソースはOpenStandia