|
MySQL 5.5.8 リリースノート (日本語翻訳)
構成に関する注意事項:
・ 現在、MySQLリリースはすべてのプラットフォーム上においてGNUオートツールではなく Cmake を利用して 構築されているため、オートツールのサポートは削除されている。 Cmake を利用したMySQLの構築については セクション 2.9 「 InstallingMySQLfromSource 」 を参照のこと。以前はconfigure.inに含まれていたMySQLのバージョン番号を抽出する必要のあるサードパーティツールの場合はVERSIONファイルを利用できる。詳細については セクション 2.9.6 「 MySQLConfigurationandThird-PartyTools 」 を参照のこと。
機能の追加または変更:
・ IBMDB2I ストレージエンジンのサポートが削除された(Bug#58079)。
・ 以前のMySQL5.5リリースで予約語だった SLOW 、 GENERAL 、 IGNORE_SERVER_IDS 、 MASTER_HEARTBEAT_PERIOD の各語が予約語ではなくなった(Bug#57899)。
・ autocommit システム変数は、すべてのユーザ接続においてデフォルトで有効にされ、また init_connect システム変数を SETautocommit=0 に設定することで、新たな接続毎にセッション値を設定することができる。ただし、これは SUPER 権限を有するユーザには影響がない。
現在は、 autocommit のグローバル値をサーバ起動時に設定できるようになった。この値は、 SUPER 権限を有するユーザを含むすべてのユーザの新規接続のセッション値を初期化するために使用される。変数はブール値として扱われるため、 --autocommit 、 --autocommit=1 または --enable-autocommit で有効化することができる。無効化するには、 --autocommit=0 、 --skip-autocommit または --disable-autocommit を使用する(Bug#57316)。
・ クライアント/サーバプロトコルに、クエリが遅いこと、つまりクエリ実行が long_query_time システム変数の値を超えていることを示す SERVER_QUERY_WAS_SLOW フラグが含まれるようになった(Bug#57058)。
・ http://dev.mysql.com/downloads/timezones.html に掲載されているタイムゾーン表が更新された。これらの表は、zoneinfoファイルを含まないWindowsやHP-UXなどのシステム上で利用できる(Bug#40230)。
・ MySQL5.6のレプリケーション機能の変更により、 --base64-output=ALWAYS オプションによって生成される mysqlbinlog アウトプットが利用できなかったため、 ALWAYS は無効なオプション値としてMySQL5.6で廃止された。 AUTO 以外の --base64-output 値は本来、デバッグ目的でのみ使用するものであり、プロダクション環境で使用するものではないため、特に問題にはならないはずである。
Bug#28760も参照。
・ mysql 、 mysqldump 、 mysqladmin 、 mysqlbinlog 、 mysqlcheck 、 mysqlimport および mysqlshow の各MySQLクライアントプログラムに --bind-address オプションが追加された。これによって、複数のネットワークインタフェースを有するコンピュータにおいて、MySQLサーバに接続するためのインタフェースを選択することができる。
修正されたバグ:
・ パフォーマンス : InnoDB ストレージエンジン : InnoDB テーブルに対して複数の ANALYZETABLE または SHOWTABLESTATUS ステートメントが同時に実行された場合の同時並行性が改善された(Bug#53046)。
・ InnoDB ストレージエンジン : セキュリティ修正 : InnoDB テーブルに対して失敗した CREATETABLE ステートメントによって、解放されていないメモリが割り当てられる可能性があった(Bug#56947)。
・ 互換性のない変更 :以前は、 performance_schema データベース内のテーブルの名前が大文字だったため、 lower_case_table_names システム変数と互換性がなく、インストールまたはアップグレード 後に システム変数を変更した場合に問題が発生していた。
現在、 performance_schema テーブルのテーブル名は小文字になっているため、 lower_case_table_names 設定にかかわらず、小文字に統一される。SQLステートメントでこれらのテーブルを参照する場合は、テーブル名を小文字で記述すべきである。本変更は互換性がないが、 lower_case_table_names のあらゆる値について互換性のある動作を提供する。
MySQL5.5の以前のバージョンからMySQL5.5.8にアップグレードする場合は、必ず mysql_upgrade を実行し(およびサーバを再起動し)、既存の performance_schema テーブル名を大文字から小文字に変更すること。 mysql_upgrade がうまくいかない場合は、以下の手順を実行する。
a. mysqld を停止する。
・ データディレクトリからperformance_schema/*.frmファイルを削除する。
・ ダミーのMySQL5.5.8インストールを別に作成する。
・ ダミーのインストールからperformance_schema/*.frmファイルをアップグレードしているインストールにコピーする。
・ mysqld を再起動してから mysqld_upgrade--force を実行し、エラーが発生しないことを確認する。
・ダミーのインストールを削除する。
(Bug#57609)
・ 互換性のない変更 :MySQL5.6の実装と適合させるために、 performance_schema.threads テーブルが以下のように変更された。
・ ID カラム:カラム名が PROCESSLIST_ID に変更され、定義から NOTNULL が削除された。
・ NAME カラム: VARCHAR(64) から VARCHAR(128) へ変更された。
(Bug#57154)
・ 互換性のない変更 :2つ以上の接続においてDMLステートメントが常に同時実行されている場合に、 FLUSHTABLESWITHREADLOCK ステートメントのスタベーションが生じていた。 HANDLER ステートメントによっていくつかのテーブルがオープンになった1つの接続が、DMLステートメントによってデータの更新を試み、同時に別の接続が FLUSHTABLESWITHREADLOCK を実行しようとした場合にデッドロックが生じていた。
これらの問題は、グローバル読み取りロックの実装によるものであり、再実装することによって以下の効果があった。
・ 本パッチによって引き起こされたイベント処理コードのデッドロックを解消するために、イベントの LOCK_event_metadata ミューテックスをメタデータロックで置き換えた。その結果、イベントのDDL操作は LOCKTABLES で禁止されるようになった。これは互換性のない変更である。
・ グローバル読み取りロック( FLUSHTABLESWITHREADLOCK )によって、テンポラリテーブルのDMLおよびDDLがブロックされないようになった。本パッチ以前には、サーバ動作に一貫性がなく、テンポラリテーブルのDML/DDLがブロックされる場合とされない場合があった。 FLUSHTABLESWITHREADLOCK は主にバックアップ時に使用され、テンポラリテーブルはバックアップ中には保存されないため、サーバはグローバル読み取りロックを使用している場合にテンポラリテーブルのDMLおよびDDLを常に許可するようになった。
・スレッド状態のセットが以下のように変更された。
・ Waitingforglobalmetadatalock が Waitingforglobalreadlock で置き換えられた。
・ 以前は、 Waitingforreleaseofreadlock がDML/DDLステートメントが読み取りロックの解放を待機していることを示すために使用され、 FLUSHTABLESWITHREADLOCK がグローバル読み取りロックの獲得を待機していることを示すためには Waitingtogetreadlock が使用されていた。現在は、どちらの場合にも Waitingforglobalreadlock が使用される。
・ 以前は、 Waitingforreleaseofreadlock が明示的および暗黙的コミットを発生させるすべてのステートメントが読み取りロックの解放を待機していることを示すために使用され、 Waitingforallrunningcommitstofinish は FLUSHTABLESWITHREADLOCK によって使用されていた。現在は、どちらの場合にも Waitingforcommitlock が使用される。
・ Waitingfortriggermetadatalock と Waitingforeventmetadatalock という2つの新しい状態が加わった。
(Bug#57006、Bug#54673)
・ InnoDB ストレージエンジン : REFERENTIAL_CONSTRAINTS.REFERENCED_TABLE_NAME や KEY_COLUMN_USAGE.REFERENCED_TABLE_NAME など特定の INFORMATION_SCHEMA カラム内で値が切り捨てられる可能性があった(Bug#57960)。
・ InnoDB ストレージエンジン : ROW_FORMAT=COMPRESSED または ROW_FORMAT=DYNAMIC で作成された InnoDB テーブルにおいて、 READUNCOMMITTED アイソレーションレベルを使用したクエリを実行する際に、オフページストレージを利用する BLOB などの大きなカラムが同時に挿入された場合、サーバが表明エラーで停止する可能性があった(Bug#57799)。
・ InnoDB ストレージエンジン :WindowsVistaおよびWindows7システム上で、サーバが表明エラーで停止する可能性があった(Bug#57720)。
・ InnoDB ストレージエンジン :Bug#54678のフォローアップ修正。デバッグバージョンのサーバでは、 TRUNCATETABLE が従来同様にクラッシュ(表明エラー)する可能性があった(Bug#57700)。
・ InnoDB ストレージエンジン :高負荷時のサーバで、 InnoDB システムテーブルスペースが大きくなり続ける可能性があった(Bug#57611)。
・ InnoDB ストレージエンジン : InnoDB テーブル内のBLOBカラムのデータを大量に同時更新するとハングが起きる可能性があった(Bug#57579)。
・ InnoDB ストレージエンジン : innodb_stats_on_metadata オプションをオフにすると、 ANALYZETABLE ステートメントが InnoDB テーブルのカーディナリティ統計を更新できない可能性があった(Bug#57252)。
・ InnoDB ストレージエンジン :カラムに大文字と小文字を区別しないインデックスが存在し、カラムの値の大文字が小文字に変更されるか、小文字が大文字に変更された場合、 InnoDB テーブルに対するクエリが間違った値を返す可能性があった(Bug#56680)。
・ InnoDB ストレージエンジン :既存の InnoDB テーブルが、 ALTERTABLE ステートメント中の KEY_BLOCK_SIZE 句によって暗黙的に ROW_FORMAT=COMPRESSED に変更される可能性があった。現在は、 ALTERTABLE ステートメントに ROW_FORMAT=COMPRESSED 句が明示的に指定されている場合のみ、行フォーマットがCOMPRESSEDに変更される。
デフォルトでないその他の有効な ROW_FORMAT パラメータと KEY_BLOCK_SIZE の両方が指定されている場合は、 ROW_FORMAT パラメータが優先される。 KEY_BLOCK_SIZE によって ROW_FORMAT=COMPRESSED が有効にされるのは、 ROW_FORMAT が CREATETABLE ステートメントおよび ALTERTABLE ステートメントのいずれにも指定されていない場合か、 DEFAULT と指定されている場合のみである。 KEY_BLOCK_SIZE 句と ROW_FORMAT 句で矛盾が生じる場合、 innodb_strict_mode がオフであれば KEY_BLOCK_SIZE は無視され、 innodb_strict_mode がオンの場合は、ステートメントによってエラーが生じる(Bug#56632)。
・ InnoDB ストレージエンジン : innodb_strict_mode の設定にかかわらず、 InnoDB テーブルに対する CREATETABLE ステートメントおよび ALTERTABLE ステートメントで KEY_BLOCK_SIZE=0 句が許可される。ゼロ値によって、 KEY_BLOCK_SIZE テーブルパラメータが ROW_FORMAT パラメータに応じて、あらかじめ指定されていなかったようにデフォルト値にリセットされる。ROW_FORMAT=COMPRESSEDの場合、デフォルト値は8である。それ以外の場合は、KEY_BLOCK_SIZEは使用されず、テーブルパラメータと共に保存されることもない。
この修正の結果、 innodb_strict_mode が有効になっている時は ROW_FORMAT=FIXED は許可されない(Bug#56628)。
・ InnoDB ストレージエンジン :外部キーが大量に宣言されている場合、 SHOWCREATESTATEMENT ステートメントの出力が切り捨てられる可能性があった(Bug#56143)。
・ InnoDB ストレージエンジン :外部キー制約に必要なインデックスが設定されていないことが原因で CREATETABLE ステートメントが失敗した場合のメッセージを明確化した(Bug#16290)。
・ パーティショニング :パーティションドテーブル上で(テーブルコピーを含まない)早い ALTERTABLE 操作を行うと、テーブルが不安定な状態になる可能性があった(Bug#57985)。
・ パーティショニング : AUTO_INCREMENT カラムで INSERT...ONDUPLICATEKEYUPDATE column =0 ステートメントを実行すると、デバッグサーバがクラッシュしていた(Bug#57890)。
・ パーティショニング : InnoDB パーティションドテーブルに ALTERTABLE...ADDPRIMARYKEY を発行すると、MySQLサーバがクラッシュする可能性があった(Bug#57778)。
・ レプリケーション :ストアドファンクションを使用する同時実行ステートメントおよびそのストアドファンクションを削除する DROPDATABASE ステートメントによって、ステートメントベースのレプリケーションが失敗した。この問題は、削除されるすべてのストアドファンクションおよびストアドプロシージャに対して、 DROPDATABASE が排他的なメタデータロックを確実に取得するようにすれば解決する(Bug#57663)。
Bug#30977も参照。
・ レプリケーション :トランザクショナルストレージエンジンを使用するテーブルだけを更新するトランザクションの実行中に STOPSLAVE が発行されると、スレーブSQLスレッドは現在のトランザクションを後退復帰してすぐに停止する。 CREATETEMPORARYTABLE ステートメントと DROPTEMPORARYTABLE ステートメントはどちらも後退復帰不可であるにもかかわらず、以前はそのどちらか、または両方を含むトランザクションでも同じ動作が行われていた。テンポラリテーブルはユーザセッション(この場合はレプリケーションユーザ)が終了するまで存在するため、スレーブが停止またはリセットされるまで残る。その後、 STARTSLAVE ステートメントが実行され、トランザクションが再起動されると、作成しようとするテンポラリテーブルはすでに存在する(または削除しようとするテンポラリテーブルは存在しない)というエラーでSQLスレッドが中断する。
この修正によって、実行中のトランザクションに CREATETEMPORARYTABLE ステートメントと DROPTEMPORARYTABLE ステートメントのどちらか、または両方が含まれる場合、SQLスレッドはトランザクションの終了を待機した後、停止するようになった(Bug#56118)。
・ レプリケーション :同じ名前のテンポラリテーブルと非テンポラリテーブルがどちらも存在する場合、その名前を指定した更新は、通常はテンポラリテーブルにのみ適用される。ただし、既存のテンポラリテーブルと同じ名前の非テンポラリテーブルを作成する CREATETABLE...SELECT ステートメントは例外である。 MIXED ログ形式を使用してそのようなステートメントが複製され、それが行ベースのログにとって安全でない場合、更新がテンポラリテーブルに間違って適用されていた。
トランザクショナルストレージエンジンを使用しているテンポラリテーブルがトランザクション中に削除され、その後同じトランザクション中に同じ名前の非テンポラリテーブル内で更新が実行された場合にも、更新が間違って適用されていた(Bug#55478)。
Bug#47899、Bug#55709も参照。
・ レプリケーション : CHANGEMASTERTO を使用してリレーログ設定を変更した場合、I/Oキャッシュがクリアされなかった。そのため、スレーブが無効データをキャッシュから読み取ろうとして、表明を発行して停止した場合、レプリケーションが失敗する可能性があった(Bug#55263)。
・ レプリケーション :異なるエンディアンを使用しているプラットフォーム間で、1バイト以上で表される SET および ENUM カラム(8以上のメンバーを持つ SET カラムおよび256の定数を持つ ENUM カラム)を行ベース形式でレプリケーションすると失敗していた。その原因は、これらのタイプのカラムは内部では整数として表されているにもかかわらず、MySQLが使用する内部関数はそれらを文字列として処理していたことにあった(Bug#52131)。
Bug#53528も参照。
・ レプリケーション :無効なタイプのログイベントを含むバイナリログを読み取ろうとすると、スレーブがクラッシュしていた(Bug#38718)。
・ レプリケーション : mysql.tables_priv テーブルを複製した際に、 Grantor カラムが複製されず、スレーブでは空のままだった(Bug#27606)。
・ サーバ起動時に、 read_only システム変数を設定できなかった(Bug#58669)。
・ MySQL5.1からのアップグレード後に mysql_upgrade が失敗していた(Bug#58514)。
・ VisualStudioExpressを使用し、 -DBUILD_CONFIG=mysql_release という設定でビルドを実行した際に、 signtool.exe が存在していない場合はビルドが失敗していた(Bug#58313)。
・ CMake 2.8.3では、 -DBUILD_CONFIG=mysql_release オプションが機能しなかった(Bug#58272)。
・ Linux上で、 -DBUILD_CONFIG=mysql_release という設定でビルドを実行する際には libaio が必須だが、それが見つからない場合のエラーメッセージがわかりづらかった(Bug#58227)。
・ HAVING 句内で NAME_CONST() を使用するとサーバがクラッシュした(Bug#58199)。
・ BETWEEN は、 DATE および DATETIME カラムにインデックスを使用していなかった(Bug#58190)。
・ パス名を格納するために fn_expand() 内に割り当てられていたメモリがまったく解放されていなかった(Bug#58173)。
・ デバッグビルドにおいて、 CHAR(0) カラムに FLOAT 値を挿入するとサーバがクラッシュする可能性があった(Bug#58137)。
・ ユーザ接続を処理するスレッドの作成に失敗するとサーバがクラッシュする可能性があった(Bug#58080)。
・ 設定中に、 LINK_FLAGS が修正されるとcmake/mysql_version.cmakeの ADD_VERSION_INFO が失敗していた(Bug#58074)。
・ パフォーマンススキーマがバイナリログファイルのI/Oを集計していなかった(I/Oがカウントされていなかった)(Bug#58052)。
・ コンパイルに関するいくつかの問題が修正された(Bug#57992、Bug#57993、Bug#57994、Bug#57995、Bug#57996、Bug#57997、Bug#58057)。
・ 2つの外部キー制約のあるテーブルを作成しても、 INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS テーブルはその内の1つしか表示しなかった(Bug#57904)。
・ 失敗したアイテムが文字セット変換によってラップされた場合、間違ったエラー処理による表明が発行されていた(Bug#57882)。
・ デバッグビルドにおいて、sql/client.cに DBUG_RETURN マクロがない場合に、 mysql がサーバに接続できなかった(Bug#57744)。
・ MySQL5.5.7よりも古いクライアントライブラリを使用しているクライアントが、5.5.7サーバに接続中に mysql_change_user() を実行すると接続が切断されていた(Bug#57689)。
・ MySQL-shared RPMパッケージが、RPM 'Provides' タグ(通常、後方互換性のために使用)で小文字の仮想識別子 'mysql-shared' を提供できなかった(Bug#57596)。
・ 過去のリリースからMySQL5.5.7へアップグレードする際に、 mysql.proxies_priv テーブルが存在しない場合にサーバが終了してしまい、更新が不便だった。現在は、 proxies_priv テーブルが存在しない場合、サーバは空テーブルと同様に扱う。とは言え、サーバの起動後、 mysql_upgrade を実行してテーブルを作成すべきである(Bug#57551)。
・ SHOWPROCESSLIST で、非ASCII文字が適切に表示されなかった(Bug#57306)。
・ NULLで終了しない文字列を UpdateXML() または ExtractValue() に渡すと、サーバが表明を発行して停止する可能性があった(Bug#57279)。
・ サーバがトレースファイルを開けなかった場合、 SETGLOBALdebug によってSolarisがクラッシュする可能性があった(Bug#57274)。
・ デバッグビルドにおいて、文字列を浮動小数点値へと変換している最中に、表明が発行される可能性があった(Bug#57203)。
・ --defaults-fileまたは--defaults-extra-fileオプションの file_name 引数が完全なパス名ではない場合、間違って解釈され、サーバがクラッシュする可能性があった。現在は、 file_name 引数が完全なパス名ではなく相対パス名として与えられた場合、カレントディレクトリを基準として解釈される(Bug#57108)。
・ ストアドルーチンおよび mysql.proc テーブルに対する権限を持たないユーザが、ルーチンの存在を知ることができた(Bug#57061)。
・ IndexMergeアクセスメソッドとテンポラリファイルを使用して実行されるクエリによって、不正確な結果が返される可能性があった(Bug#56862)。
・ 特定のパフォーマンススキーマテーブルを読み取ろうとすると、サーバが memcpy() 内でクラッシュする可能性があった(Bug#56761、Bug#58003)。
・ INFORMATION_SCHEMA.VIEWS にデータを投入する際にビューが適切に開かない場合、解放済みメモリにアクセスした結果、サーバがクラッシュする可能性があった(Bug#56540)。
・ 同一の変数を二重に割り当てた時のメモリの重複に関するValgrind警告が修正された(Bug#56138)。
・ スレーブSQLスレッドが SLEEP() 関数を呼び出すステートメントを実行している最中に、 STOPSLAVE ステートメントが発行されると、両方のステートメントがハングした(Bug#56096)。
・ InnoDB テーブルの OPTIMIZETABLE によって表明が発行される可能性があった(Bug#55930)。
・ トリガによって発行された警告が、そのトリガが正常に完了してもクリアされなかった。現在は、SQL標準に従い、トリガが正常に完了したら警告はクリアされる(Bug#55850)。
・ CMake ビルドにおいて、埋め込みサーバがビルドされている場合に、一部のソースが不必要に二度コンパイルされていた(Bug#55647)。
・ デバッグビルドにおいて、エラーが発生した後に send_eof() メソッドが呼ばれた場合に、表明が発行される可能性があった(Bug#54812)。
・ Booleanコマンドオプションが、オプション値および loose- オプションプリフィックスと共に与えられた場合、エラーが発生した(Bug#54569)。
・ ストアドプロシージャでエラーが発生した場合、異なるデフォルトのデータベースにセッションが残ってしまう可能性があった(Bug#54375)。
・ configure ( configure.pl )の CMake ラッパによって、--with-commentオプションが適切に処理されなかった(Bug#52275)。
・ TIME_TO_SEC() 関数の結果によるグループ化によって、サーバがクラッシュしたり、不正確な結果が生じる可能性があった。 BLOB を返す関数によるグループ化によって、予期しない“Duplicateentry”エラーおよび不正確な結果が生じる可能性があった(Bug#52160)。
・ SHOW ステートメントによって使用される find_files() 関数によって、冗長で不必要なメモリ割り当てが行われる可能性があった(Bug#51208)。
・ Windowsのサンプルオプションファイルに、Linuxにより適した値が含まれていた(Bug#50021)。
・ RENAMETABLE 操作が失敗した場合、 FLUSHTABLESWITHREADLOCK が完了しない可能性があった(Bug#47924)。
・ デリゲートに関連したいくつかの初期化エラー条件に関するエラーメッセージが変更され、問題が発生した領域を特定することが可能になり、さらにユーザにバグレポートの作成を指示するようになった。デリゲートとは、内部データ構造およびアルゴリズムのセットである(Bug#47027)。
・ ファイル名の大文字と小文字を区別しないファイルシステムで lower_case_table_names=2 と設定されている場合、テーブル定義キャッシュの不一致によってサーバがクラッシュする可能性があった(Bug#46941)。
・ GRANT ステートメントのホスト名の大文字/小文字の処理に一貫性がなかった(Bug#36742)。
・ SETNAMESutf8COLLATEutf8_sinhala_ci が機能しなかった(Bug#26474)。
・ utf16_bin は セクション 9.1.14.1 「 UnicodeCharacterSets 」 に記述されているバイト順ではなく、コードポイント順で照合している(MySQL5.5.7.ではバイト順)。