|
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
)。
・
パーティショニング
:
パーティションドテンポラリテーブルが許可されていなくても、
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の「高速インデックス作成」メカニズムを使用してインデックスを作成しているときにクラッシュが発生した場合、データベース再起動時のクラッシュリカバリ処理では、部分的に作成されたインデックスが削除される。