 |
|
MySQL 5.5.21 リリースノート （日本語翻訳）
機能の追加と変更
・ WindowsまたはMacOSXで、 CMake の新しいオプションとして、プロジェクト名に使用する MYSQL_PROJECT_NAME を設定できるようになる（Bug#13551687）。
・ バージョン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 を実行すると次のエラーが生成される。
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.11.3項「CheckingWhetherTablesorIndexesMustBeRebuilt」 と 2.11.4項「RebuildingorRepairingTablesorIndexes」 を参照（Bug#43593、Bug#11752408）。
修正されたバグ
・ パフォーマンス : InnoDB :テーブルまたはパーティションの数が大きい場合のメモリオーバーヘッドを緩和し、"residentsetsize"が FLUSHTABLES ステートメントとは無関係に拡大する状況を回避するため、 InnoDB テーブルに対するメモリ割り当てが再編成された。この問題が最も顕著なのは、行サイズが大きいテーブルの場合だった。以前は開いているテーブルのすべてにメモリが割り当てられていたが、その一部が現在はテーブルを初めて変更する際にのみ割り当てられるようになっている（Bug#11764622、Bug#57480）。
・ 矛盾を含む可能性がある変更 :以前の変更（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 :関数 os_aio_init() で、Valgrindエラーが修正された（Bug#13612811）。
・ InnoDB :MySQL5.5.4以降のデフォルト設定のように、 $TMPDIR 設定で tmpfs ファイルシステムが指定され、 innodb_use_native_aio が有効な場合、Linuxで InnoDB テンポラリテーブルを作成する際にサーバがクラッシュする可能性があった。エラーログのエントリは以下のようになる。
・1011232:10:59InnoDB:Operatingsystemerrornumber22inafileoperation.
InnoDB:Errornumber22means'Invalidargument'.
クラッシュの原因は、一部のバージョンのLinuxカーネルでtmpfsが非同期I/Oに対応していないことだった。回避策としては、 innodb_use_native_aio 設定を無効にするか、別のテンポラリディレクトリを使用していた。今回の修正で InnoDB は、テンポラリファイルディレクトリが非同期I/Oに対応していない場合に innodb_use_native_aio 設定を自動的に無効にするようになる（Bug#13593888、Bug#11765450、Bug#58421）。
・ InnoDB :Cプリプロセッサシンボルとマクロ HAVE_purify 、 UNIV_INIT_MEM_TO_ZERO 、 UNIV_SET_MEM_TO_ZERO への参照が、 InnoDB ソースコードから削除された。これらはValgrind用に用意されたデバッグビルドでのみ使用されたもので、 UNIV_MEM_INVALID() マクロの呼び出しに置き換えられている（Bug#13418934）。
・ InnoDB :MySQLサーバが次の表明エラーで停止する可能性があった。
InnoDB:Failingassertion:page_get_n_recs(page)>1
この後で再起動しても同じエラーで失敗することがあった。このエラーは、 InnoDB の バッファ変更 を伴う パージ 操作の際に発生した。回避策として、構成オプション innodb_change_buffering=inserts を設定していた（Bug#13413535、Bug#61104）。
・ 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）。
・ レプリケーション : --start-position= N オプションを指定して mysqlbinlog を実行すると、 N が0に等しいか、ダンプファイルの長さを超える値に等しい場合、クラッシュする可能性があった。
この問題は、Bug#32228およびBug#11747416に対する修正によってMySQL5.5.18で導入された退化であった（Bug#13593869、Bug#64035）。
・ レプリケーション :Windowsのレプリケーションスレーブホストで、マスタが停止していると STOPSLAVE が完了するまでに極端に長い時間がかかった（Bug#11752315、Bug#43460）。
・ 共有バージョンの libmysqlclient は、クライアントプログラムによってリンクされる関数 get_tty_password() 、 handle_options() 、 my_print_help() をエクスポートしなかった（Bug#13604121）。
・ BETWEEN 句で参照されている CHAR カラムに対するインデックスを使用するクエリが、無効な結果を返す可能性があった（Bug#13463488、Bug#63437）。
・ BIGINT カラムを非整数定数と比較する式が、小数値または浮動小数値ではなく整数を使用して実行され、定数が切り捨てられている可能性があった。そのため、 < 、 > 、 <= 、 >= 、 = 、 != 、 <> 、 IN 、 BETWEEN を使用するこの種の比較で、擬陽性または否定の結果になる可能性があった（Bug#13463415、Bug#11758543、Bug#63502、Bug#50756）。
・ 範囲条件を評価する際にオプティマイザが DECIMAL 値の変換を実行すると、結果が正しくならない可能性があった（Bug#13453382）。
・ --single-transaction と --flush-logs の両方のオプションを指定して mysqldump を実行すると、ログのフラッシュによって暗黙的な COMMIT （ 13.3.3項「StatementsThatCauseanImplicitCommit」 を参照）が実行され、複数のトランザクションが使用されて整合性が損なわれる可能性があった（Bug#12809202、Bug#61854）。
・ --xml オプションを指定すると、 mysqldump --routines がストアドルーチン、トリガ、イベントのダンプに失敗した（Bug#11760384、Bug#52792）。
・ mysqld_safe が連続して失敗すると急激な再起動が発生し、極端にCPUが消費されることがあった。現在、システムユーティリティ sleep と date をサポートするシステムでは、 mysqld_safe が現時点で6回以上再起動したかどうかをチェックし、そうであれば次の再起動を試行するまで1秒待つようになる（Bug#11761530、Bug#54035）。
・ FEDERATED テーブルを使用するレプリケーションスレーブで、長時間実行する操作がタイムアウトしてエラー1160「Gotanerrorwritingcommunicationpackets」などが発生する可能性があった。 FEDERATED テーブルを複製しなくても、この問題は発生した（Bug#11758931、Bug#51196）。
参考:Bug#12896628、Bug#61790も参照。
・ ステートメントを開始しようとして失敗しても、クライアントはステートメントの実行より前にエラーメッセージを受け取る準備ができていないため、クライアントにその問題が報告されない可能性があった。ユーザはクエリを実行できないため、明確なエラーがないまま切断されるだけだった。
この問題が修正され、クライアントはステートメントの開始と同時にエラーに対応できるようになるので、ユーザが切断される前にエラーが報告されるようになる（Bug#11755281、Bug#47032）。
・ Windowsのサーバで、 INSTALLPLUGIN と CREATEFUNCTION...SONAME に対するプラグインバイナリのフルパス名が正しく作成されなかった（Bug#45549、Bug#11754014）。
・ 行形式が固定幅のテーブルを修復するためにソート修復のメソッドを指定して myisamchk を使用すると、行ポインタのサイズが小さくなり、結果的に最大データファイルサイズが小さくなる可能性があった（Bug#48848、Bug#11756869）。
・ ストアドルーチンキャッシュで小さいメモリリークが起きる危険性があり、長期間またはルーチン数が多い場合にはメモリ不足のエラーになる可能性があった。
この問題の修正では stored_program_cache という新しいグローバルサーバシステム変数も導入され、この変数を使用するとストアドルーチンキャッシュのサイズを制御できるようになる（Bug#44585、Bug#11753187）。
・ ある状況下では、 SUBSTRING_INDEX() の結果の、前の行の内容への依存が正しくなかった（Bug#42404、Bug#11751514）。