|
MySQL 5.1.62 リリースノート (日本語翻訳)
機能の追加と変更
・ バージョン5.1.24以前のMySQLに存在した utf8_general_ci と ucs2_general_ci の動作を維持するため、新しい utf8_general_mysql500_ci と ucs2_general_mysql500_ci の照合が追加された。Bug#27877では元の照合のエラーが修正されたが、ドイツ語におけるラテン小文字のエスツェット '' が含まれるカラムについて非互換性が生じた(修正の結果、この文字を比較すると以前は等しいと評価されなかった文字が、等しいと評価されるようになった)。5.1.24以前のバージョンからMySQL5.1.24以降にアップグレードした後に現れる兆候として、 CHECKTABLE を実行すると次のエラーが生成される。
・Tableupgraderequired.
Pleasedo"REPAIRTABLE`t`"ordump/reloadtofixit!
この問題を REPAIRTABLE で修正することはできなかった。新しい照合を使用すると、MySQL5.1.24以前で作成された古いテーブルを現在のバージョンのMySQLにアップグレードすることが可能。
テーブルファイルを移動しないバイナリアップグレード後に、対象のテーブルを変換するには、新しい照合を使用するようにテーブルを変更する。たとえばテーブル t1 に、問題のある utf8 カラムが1つ以上あると仮定した場合、このテーブルをテーブルレベルで変換するには、次のようなステートメントを使用する。
ALTERTABLEt1
CONVERTTOCHARACTERSETutf8COLLATEutf8_general_mysql500_ci;
カラムごとの基準で変更を適用する場合には、次のようなステートメントを使用する( COLLATE 句を除き、元の指定どおりにカラム定義を繰り返すこと)。
ALTERTABLEt1
MODIFYc1CHAR(N)CHARACTERSETutf8COLLATEutf8_general_mysql500_ci;
ダンプと再ロードの手順でテーブルをアップグレードするには、 mysqldump を使用してテーブルをダンプし、新しい照合が使用されるようにダンプファイルで CREATETABLE ステートメントを変更してから、テーブルを再ロードする。
適切な変更を行うと、 CHECKTABLE でエラーが報告されなくなる。
詳細については、 2.13.3項「CheckingWhetherTablesorIndexesMustBeRebuilt」 と 2.13.4項「RebuildingorRepairingTablesorIndexes」 を参照(Bug#43593、Bug#11752408)。
・ yaSSLは1.7.2から2.2.0にアップグレードされた。
修正されたバグ
・ セキュリティ修正 :Bug#63775が修正された。
・ 矛盾を含む可能性がある変更 :以前の変更(MySQL5.1.59と5.5.16)により、GeneralAvailabilityステータスのシリーズ(MySQL5.1と5.5)における日付処理の動作が変更されたことが判明した。この変更は元に戻された。
この変更は、引数として DATE() 関数を渡されたとき関数の一部がより厳格になるというもので、日にちの部分がゼロの不完全な日付が拒否されていた。 CONVERT_TZ() 、 DATE_ADD() 、 DATE_SUB() 、 DAYOFYEAR() 、 LAST_DAY() 、 TIMESTAMPDIFF() 、 TO_DAYS() 、 TO_SECONDS() 、 WEEK() 、 WEEKDAY() 、 WEEKOFYEAR() 、 YEARWEEK() の各関数が影響を受けた。これ以前の動作が回復された(Bug#13458237)。
・ 重要な変更 : InnoDB : UPDATE 操作が原因で行のサイズが大きくなると、その行に関する情報が引き続き InnoDB ページサイズの制約内に収まるように、他の(更新されていない)カラムがオフページストレージに移動される可能性があった。新しく割り当てられるオフページデータへのポインタは、ページが割り当てられ書き込まれるまで設定されないため、カラムをページ外へ移動中にシステムがクラッシュすると、データが失われる可能性があった。この問題は、Barracudaファイル形式で ROW_FORMAT=DYNAMIC または ROW_FORMAT=COMPRESSED を使用するテーブルにおいて、特に innodb_file_per_table 設定が有効な場合に頻繁に発生した。ページ割り当て操作は、.ibdテーブルスペースファイルを拡張する際に頻繁に発生するためである。この問題は、InnoDBのバージョン、ファイル形式、行形式がどのような組み合わせでも発生する可能性があった。
これに関連する問題として、 UPDATE 操作や、削除されてマークされたレコードを再利用する INSERT 操作の際に、アイソレーションレベルにかかわらず、影響されるカラムのデータが他のトランザクションで無効になる場合があった。
カラムデータを元のページから移動してポインタで置き換える操作の順序が修正され、カラムデータが転送される正確なタイミングでクラッシュが発生しても、クラッシュリカバリ時に転送は再実行されなくなる。
MySQL5.1では、この修正はInnoDBプラグインに適用されるが、組み込みのInnoDBストレージエンジンには適用されない(Bug#13721257、Bug#12612184、Bug#12704861)。
・ InnoDB :ゼロ長の値( '' )を含むカラムにインデックスを作成する際、デバッグビルドでのみ、誤った表明が発生する可能性があった(Bug#13654923)。
・ InnoDB : ALTERTABLE...ADDCOLUMN などのDDL操作が停止し、最終的に fil_rename_tablespace についての Error1005:Can'tcreatetable メッセージでタイムアウトする可能性があった(Bug#13636122、Bug#62100、Bug#63553)。
・ InnoDB :Cプリプロセッサシンボルとマクロ HAVE_purify 、 UNIV_INIT_MEM_TO_ZERO 、 UNIV_SET_MEM_TO_ZERO への参照が、 InnoDB ソースコードから削除された。これらはValgrind用に用意されたデバッグビルドでのみ使用されたもので、 UNIV_MEM_INVALID() マクロの呼び出しに置き換えられている(Bug#13418934)。
・ InnoDB : InnoDB テーブルに対するDDL操作によってMySQLサーバがビジー状態になり、次の表明エラーで停止する可能性があった。
InnoDB:Failingassertion:trx->error_state==DB_SUCCESS
このエラーは、1023個のUNDOスロットがすべて同時トランザクションによって使用されている際にDDL操作を実行すると発生した。 InnoDB のUNDOスロットの数を増やしたことにより同時トランザクションの数(UNDOスロットに対応する)が1Kから128Kに増えたため、MySQL5.5および5.6ではこのエラーが発生しにくくなった(Bug#12739098、Bug#62401)。
・ InnoDB :1024個の同時 InnoDB トランザクションが実行され、 innodb_file_per_table 設定が有効な場合、 InnoDB テーブルに対する CREATETABLE 操作が失敗する可能性があった。 CREATETABLE が失敗した後の .ibd ファイルが放置されていたため、ロードの削除後にもテーブルを作成できなかった。
この修正で、不適切な .ibd ファイルを削除するエラー処理が追加される。 InnoDB のUNDOスロットの数を増やしたことにより同時トランザクションの数が1Kから128Kに増えたため、MySQL5.5および5.6ではこのエラーが発生しにくくなった(Bug#12400341)。
・ InnoDB : InnoDB パーティションドテーブルをLinuxシステムからWindowsシステムにコピーすると、次のエラーが発生する可能性があった。
・10111514:19:53[ERROR]Tabletest\dhasnoprimarykeyinInnoDBdata
dictionary,buthasoneinMySQL!
LinuxからWindowsに InnoDB テーブルをコピーする際の解決策としては通常、Linuxで lower_case_table_names オプションを有効にしてテーブルを作成する。パーティションドテーブルのファイル名に #P# を追加した場合は、この解決方法が適用されなかった(Bug#11765438、Bug#58406)。
・ InnoDB : $TMPDIR 変数のパスが / 文字で終わっている場合、 InnoDB ストレージエンジンを使用するテンポラリテーブルでサーバ起動時にエラーが発生する可能性があった。エラーログは以下のようになる。
・12020219:21:26InnoDB:Operatingsystemerrornumber2inafileoperation.
・InnoDB:Theerrormeansthesystemcannotfindthepathspecified.
・InnoDB:IfyouareinstallingInnoDB,rememberthatyoumustcreate
・InnoDB:directoriesyourself,InnoDBdoesnotcreatethem.
・12020219:21:26InnoDB:Error:tryingtoopenatable,butcouldnot
・InnoDB:openthetablespacefile't/#sql7750_1_0.ibd'!
・InnoDB:HaveyoumovedInnoDB.ibdfilesaroundwithoutusingthe
・InnoDB:commandsDISCARDTABLESPACEandIMPORTTABLESPACE?
・InnoDB:Itisalsopossiblethatthisisatemporarytable#sql...,
InnoDB:andMySQLremovedthe.ibdfileforthis.
この問題の回避策としては、類似のテンポラリテーブルを再作成し、その .frm ファイルを、エラーメッセージで示された名前の下にある tmpdir にコピー( #sql123.frm など)して、 tmpdir を末尾のスラッシュなしで通常の値( /var/tmp など)に設定して mysqld を再起動していた。起動時に、MySQLは .frm ファイルを認識し、孤立したテンポラリテーブルに対して DROPTABLE を発行する(Bug#11754376、Bug#45976)。
・ BETWEEN 句で参照されている CHAR カラムに対するインデックスを使用するクエリが、無効な結果を返す可能性があった(Bug#13463488、Bug#63437)。
・ 範囲条件を評価する際にオプティマイザが DECIMAL 値の変換を実行すると、結果が正しくならない可能性があった(Bug#13453382)。
・ --xml オプションを指定すると、 mysqldump --routines がストアドルーチン、トリガ、イベントのダンプに失敗した(Bug#11760384、Bug#52792)。
・ FEDERATED テーブルを使用するレプリケーションスレーブで、長時間実行する操作がタイムアウトしてエラー1160「Gotanerrorwritingcommunicationpackets」などが発生する可能性があった。 FEDERATED テーブルを複製しなくても、この問題は発生した(Bug#11758931、Bug#51196)。
参考:Bug#12896628、Bug#61790も参照。
・ ステートメントを開始しようとして失敗しても、クライアントはステートメントの実行より前にエラーメッセージを受け取る準備ができていないため、クライアントにその問題が報告されない可能性があった。ユーザはクエリを実行できないため、明確なエラーがないまま切断されるだけだった。
この問題が修正され、クライアントはステートメントの開始と同時にエラーに対応できるようになるので、ユーザが切断される前にエラーが報告されるようになる(Bug#11755281、Bug#47032)。
・ 行形式が固定幅のテーブルを修復するためにソート修復のメソッドを指定して myisamchk を使用すると、行ポインタのサイズが小さくなり、結果的に最大データファイルサイズが小さくなる可能性があった(Bug#48848、Bug#11756869)。
・ ロックが不適切なため、テーブルに対する修正およびチェック操作と同時に ARCHIVE テーブルへの挿入を行うとテーブルが破損した(Bug#37280、Bug#11748748)。
・ ある状況下では、 SUBSTRING_INDEX() の結果の、前の行の内容への依存が正しくなかった(Bug#42404、Bug#11751514)。