|
MySQL 5.5.16 リリースノート (日本語翻訳)
外部認証
・現在、MySQLの商用版には、MySQLサーバで外部認証メソッドを使用してMySQLユーザを認証できる、2つのプラグインが搭載されている。
oPAM(PluggableAuthenticationModules:プラガブル認証モジュール)により、システムで標準インタフェースを使用し各種認証メソッドにアクセスできる。PAM認証プラグインによって、MySQLサーバではPAMの使用でMySQLユーザを認証することが可能になる。
PAMプラグインでは、MySQLサーバによりプラグインに渡される情報(ユーザ名、ホスト名、パスワード、および認証文字列など)、さらにPAMルックアップ(Unixパスワード、またはLDAPディレクトリなど)に対して利用可能なものは何でも使用される。プラグインはPAMに対するユーザ証明書をチェックし、成功か失敗を返す。
PAM認証プラグインは、LinuxおよびMacOSXで検証済みである。
注意事項
PAMプラグインは、クライアントサイドのプラグインで機能するが、クライアントサイドのプラグインは、単純にクリアテキストのパスワードをサーバに送信し、それがPAMに渡される。そのため、設定によってはセキュリティ上の問題になる場合があるが、サーバサイドのPAMライブラリの使用は必要である。パスワードが盗まれる可能性がある場合、問題を回避するために、クライアントはSSLを使用してMySQLサーバに接続する必要がある。詳細は セクション5.5.6.4「TheClear-TextClient-SideAuthenticationPlugin」 を参照。
oMySQLのWindows用ディストリビューションには、MySQLサーバでWindowsのネイティブなサービスを使用してクライアント接続を認証できる認証プラグインが搭載されている。Windowsにログインしたユーザは追加のパスワードを指定しなくても、ユーザ環境の情報を基に、MySQLクライアントプログラムからサーバに接続可能できる。
クライアントとサーバは、認証ハンドシェイクでデータパケットをやり取りする。このやり取りの結果、サーバは、WindowsOSのクライアントの識別を示すセキュリティコンテキストオブジェクトを作成する。この識別には、クライアントアカウントの名前が含まれている。Windows認証プラグインでは、クライアントの識別を使用して、それが特定のアカウントやグループのメンバであるかどうかをチェックする。ネゴシエーションはデフォルトで認証にKerberosを使用し、Kerberosが使えない場合はNTLMを使用する。
Windowsの認証プラグインは、Windows2000Professionalで稼動するものとする。
これらの認証プラグインにより、MySQLサーバでは、MySQL権限テーブル以外に定義されたユーザからの接続を受け入れることができる。これらのプラグインは、MySQLプロキシ-ユーザ機能もサポートしている。各プラグインは、ログインユーザとは異なるユーザ名をMySQLに返すことがあるが、これはプラグインが返すMySQLユーザには外部認証のユーザに必要な権限が定義されていることを意味する。たとえば、joeという名前の外部ユーザが接続して
developer
という名前のMySQLユーザの権限を持つ場合がある。
サーバサイドPAMおよびWindowsの認証プラグインは商用版にのみ搭載されており、MySQLコミュニティ版には搭載されていない。これらプラグインが通信するクライアントサイドのプラグインは、コミュニティ版も含むすべての版に搭載されている。そのため、どのリリースのクライアントでも、サーバサイドのプラグインがロードされたサーバへの接続が許可されている。
これらのプラグインについての詳細は、 セクション5.5.6.2「ThePAMAuthenticationPlugin」 、および セクション5.5.6.3「TheWindowsNativeAuthenticationPlugin」 を参照。MySQLのプラガブル認証の一般的な情報については、 セクション5.5.6「PluggableAuthentication」 を参照。プロキシユーザの詳細は、 セクション5.5.7「ProxyUsers」 を参照。
スレッドプールプラグインに関する注意事項
・MySQLサーバのデフォルトのスレッド処理モデルでは、クライアント接続ごとに1つのスレッドを使用してステートメントを実行する。サーバへ接続してステートメントを実行するクライアントが増えるほど、全体的なパフォーマンスは低下する。MySQLの商用版には、現在それに代わるスレッド処理モデルを導入したスレッドプールプラグインが搭載されている。この処理モデルはオーバヘッドを削減し、パフォーマンスが向上するように設計されている。プラグインに実装されているスレッドプールは、大量のクライアント接続に対するステートメント実行スレッドを効率的に管理して、サーバのパフォーマンスを向上させる。
スレッドプールは、接続ごとに1つのスレッドを採用するモデルにおける、以下のような問題に対処している。
o多すぎるスレッドスタックは、並行実行の作業負荷が高くなりCPUキャッシュをほとんど使用不可能な状態にする。スレッドプールでは、CPUキャッシュのフットプリントを最小限に抑えるために、スレッドスタックの再使用を推進している。
o並行実行するスレッドが多すぎると、コンテキスト切り替えのオーバヘッドが増大する。これはオペレーティングシステムスケジューラでも問題になる。スレッドプールは、MySQLサーバ内の並列性を保てるようにアクティブなスレッドの数を制御する。このときに適用されるのは、サーバによる処理が可能でMySQLが実行中のサーバホストに適したレベルである。
o並列実行するトランザクションの数が多すぎると、リソースの競合が増大する。
InnoDB
では、主要なミューテックスを保持するために費やす時間が増加する。スレッドプールは、並列実行が増えすぎないようにトランザクション開始の時期を制御する。
Windowsの場合、スレッドプールプラグインを使用するためにWindowsVista以降が必要。Linuxの場合、kernel2.6.9以降が必要。
詳細は セクション7.11.6「TheThreadPoolPlugin」 を参照。
機能の追加または変更
・
重要な変更
:
レプリケーション
:
RESETSLAVE
ステートメントが
ALL
キーワードで拡張された。
RESETSLAVEALL
は、
master.info
、
relay-log.info
およびすべてのリレーログファイルの削除に加えて、それ以外に
RESETSLAVE
の実行後にメモリ内に保存されるすべての接続情報も削除する(Bug#11809016)。
・スレッドプールプラグインはサーバの起動時にロードし、実行時にはロードまたはアンロードしないようにする必要がある。現在は、
INSTALLPLUGIN
または
UNINSTALLPLUGIN
ステートメントで、スレッドプールプラグインをロードまたはアンロードしようとするとエラーが発生する。
・一部のプラグインは、サーバの起動時にロードし、実行時にはロードまたはアンロードしないような状況で動作する。プラグインAPIは、現在このようにマーキングしたプラグインをサポートしている。
st_mysql_plugin
構造には
flags
メンバが組み込まれ、該当するフラグのORに設定できる。
PLUGIN_OPT_NO_INSTALL
フラグは、
INSTALLPLUGIN
ステートメントを実行時に指定しても、このプラグインをロードできないことを示す。このフラグは、
--plugin-load
オプションでサーバ起動時にロードする必要があるプラグインに適している。
PLUGIN_OPT_NO_UNINSTALL
フラグは、実行時に
UNINSTALLPLUGIN
ステートメントを指定しても、このプラグインをアンロードできないことを示す。
新規メンバによりインタフェースが変更されたので、プラグインのインタフェースバージョン
MYSQL_PLUGIN_INTERFACE_VERSION
は、
0x0102
から
0x0103
にアップした。新規メンバにアクセスする必要があるプラグインは、バージョン
0x0103
以上を使用するために再コンパイルする必要がある。
・新しいユーティリティ
mysql_plugin
により、MySQL管理者は、どのプラグインをMySQLサーバにロードするかを管理できる。別の手段も搭載されており、サーバ起動時に手動で
--plugin-load
オプションを指定したり、実行時に
INSTALLPLUGIN
および
UNINSTALLPLUGIN
ステートメントを使用することもできる。詳細は
セクション4.4.4「mysql_plugin―ConfigureMySQLServerPlugins」
を参照。
修正されたバグ
・
InnoDB
ストレージエンジン
:この修正により、
InnoDB
テーブルの
VARCHAR(
N
)
カラムの操作パフォーマンスが向上する。ここで
N
は大きな値として宣言されるが、テーブルの実際の文字列値の長さは短い(Bug#12835650)。
・
InnoDB
ストレージエンジン
:使用されていない関数は、論理を明確にするため、小さなトランザクションに関連する内部
InnoDB
コードから削除された(Bug#12626794、Bug#61240)。
・
InnoDB
ストレージエンジン
:
InnoDB
プラグインから削除された「random
read-ahead
」機能を再び使用できる。この機能は特定のワークロードにのみ有用なため、デフォルトではオフになっている。オンにするには、
innodb_random_read_ahead
構成オプションを有効にする。この機能は、場合によりパフォーマンスを向上させたり低下させたりするので、この設定を使用する前に、設定を有効および無効の両方でベンチマークを実行する(Bug#12356373)。
・ 非互換の修正 : 日付関連のアサーションの取り扱いが修正された。しかし、この修正の結果として、いくつかの機能は DATE() 関数に引数が渡されるときに、チェックがより厳格になり、日付部分が0で埋められていないものを拒否するようになった。影響を受ける関数は、 CONVERT_TZ() , DATE_ADD() , DATE_SUB() , DAYOFYEAR() , LAST_DAY() , TIMESTAMPDIFF() , TO_DAYS() , TO_SECONDS() , WEEK() , WEEKDAY() , WEEKOFYEAR() , YEARWEEK() .である。これがGeneralAvailability-statusシリーズ(MySQL5.1と5.5)において日付の取り扱いのふるまいを変えるので、この変更は5.1.62と5.5.21で前の状態に戻された。この修正は、MySQL5.6系で保持される。
・ InnoDB ストレージエンジン : INFORMATION_SCHEMA.TABLES テーブルの中のDATE_LENGTHの列が、圧縮されたInnoDBテーブルのディスク上のテーブルスペースのサイズを正確にレポートするようになった。(Bug#12770537)
・ InnoDB ストレージエンジン : innodb_file_per_table=1 と innodb_file_format=Barracuda の設定により、ページサイズの半分より大きい値の列を挿入し、そしてその列がセカンダリーインデックスを含み、その列の値が更新されたときにクラッシュを引き起こすことができた。(Bug#12637786)
・ InnoDB ストレージエンジン :ロジックをクリアにするために、ミニトランザクションに関するInnoDB内部のコードから使わない関数を削除した。(Bug#12626794,Bug#61240)
・ レプリケーション :破損したテーブルマップイベントの処理を行うと、サーバがクラッシュする可能性があった。これは、Bug#56226で発生する場合と同じで、イベントによって別々のテーブルが同じIDにマップされる場合に、特に発生しやすかった。
現在はサーバによりテーブルマップイベントが適用される前に、そのテーブルが異なる設定でマップされていたかどうかがチェックされる。もし該当する場合には、エラーが発生し、スレーブSQLスレッドは停止する。テーブルが同じ設定でマップされていた場合、あるいはフィルタリングルールに無視されるようにテーブルが設定されている場合、動作は変更しない。イベントはスキップされ、IDはチェックされない(Bug#44360、Bug#11753004)。
Bug#11763509も参照。
・
.frm
または
.TRG
ファイルのみを開いて処理され、テーブルを数多くスキャンする必要があった
INFORMATION_SCHEMA
クエリに対して、メタデータロックサブシステムがオーバヘッドを増やし過ぎていた。たとえば、
SELECTCOUNT(*)FROMINFORMATION_SCHEMA.TRIGGERS
に影響があった(Bug#12828477)。
・MacOSX10.7(Lion)で以下のような警告が表示され、コンパイルが失敗した。
Implicitdeclarationoffunction'pthread_init'
(
Bug#12779790)。
・無効またはコンパイルされていないプロファイリングを使用すると、
set_thd_proc_info()
がファイル名の長さに関して不必要なチェックを実行した(Bug#12756017)。
・Bug#11792200で追加された
DBUG_ASSERT
が、表明の発生に対して過剰だった(Bug#12537160)。
・
CHECKTABLE
および
REPAIRTABLE
は、基礎となるテーブルが欠けている
MERGE
テーブル、または不正なストレージエンジンを使用して問題のルックアップに失敗した。最初の基礎となるテーブルに関してのみ問題が報告されていた(Bug#11754210)。
・
(
5DIV2
)
と(
5.0DIV2
)
が異なる結果(2と3)を生成していた。これは(
5.0DIV2
)
の結果が、切り捨てされずに整数に変換されていたためである。このバグは、MySQL5.0および5.1の動作とは異なる。現在はいずれの式も2を生成する(Bug#61676、Bug#12711164)。
・
lower_case_table_names
の値が1または2で、データベース名に大文字小文字が混在している場合、そのデータベース名が含まれた完全修飾名でストアドファンクションを呼び出すと失敗した(Bug#60347、Bug#11840395)。
・
argc=0
の場合に、埋め込みサーバがクラッシュした(Bug#57931、Bug#12561297)。
・
WHERE
句で決定的なストアドファンクションを使用して
SELECTDISTINCT
を指定すると、誤った結果になる可能性があった(Bug#59736、Bug#11766594)。
・RPMパッケージを使用してアップグレードを行うと、
test
データベースが再作成されていた。これは、このデータベースがすでにDBAにより削除されていた場合は適切ではない(Bug#45415、Bug#11753896)。
・
mysql_affected_rows()
CAPI関数が、重複キー値が存在する
INSERT...ONDUPLICATEKEYUPDATE
ステートメントに対して(2ではなく)3を返していた(Bug#46675、Bug#11754979)。
・
ENGINE
オプションを指定しない
CREATETABLE
は、実行時ではなく解析時にデフォルトエンジンを判別していた。そのため、このステートメントがストアドプログラム内で実行され、その間にデフォルトエンジンが変更されていた場合は不正な結果を導いていた(Bug#50614、Bug#11758414)。