MySQL サーバーへの接続を試行したときに問題が発生した場合に問題を修正するために実行できる一連のアクションについて、次の項目で説明します。
-
サーバーが実行中であることを確認します。そうでない場合、クライアントは接続できません。たとえば、サーバーに接続しようとして次のいずれかのようなメッセージで失敗した場合、サーバーが実行中でないことが 1 つの原因であることがあります。
shell> mysql ERROR 2003: Can't connect to MySQL server on 'host_name' (111) shell> mysql ERROR 2002: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (111)
-
サーバーは実行しているが、サーバーが待機しているのと異なる TCP/IP ポート、名前付きパイプ、または Unix ソケットファイルを使用して接続しようとしている場合もあります。これを修正するには、クライアントプログラムを呼び出すときに、適切なポート番号を指すように
--port
オプションを指定するか、--socket
で適切な名前付きパイプまたは Unix ソケットファイルを指定します。ソケットファイルがある場所を見つけるには、次のコマンドを使用できます。shell> netstat -ln | grep mysql
サーバーがネットワーク接続を無視するように構成されていないこと、または (リモート側から接続しようとする場合に) サーバーのネットワークインタフェース上でローカル側でのみ待機するように構成されていないことを確認します。サーバーが
--skip-networking
を指定して起動された場合、サーバーは TCP/IP 接続を受け入れません。サーバーが--bind-address=127.0.0.1
を指定して起動された場合、サーバーはローカルのループバックインタフェース上でのみ TCP/IP 接続を待機するためリモート接続を受け入れません。ファイアウォールが MySQL へのアクセスをブロックしていないか確認します。ファイアウォールは、実行中のアプリケーションまたは MySQL によって通信用に使用されるポート番号 (デフォルトは 3306) を基準として構成されることがあります。Linux または Unix の場合、IP テーブル (または同様の機能の) 構成を調べてポートがブロックされていないことを確認します。Windows の場合、ZoneAlarm や Windows XP パーソナルファイアウォールなどのアプリケーションが MySQL ポートをブロックしないようにこれらを構成することが必要な場合があります。
-
付与テーブルが適切にセットアップされており、サーバーがこれをアクセス制御に使用できるようになっていることが必要です。一部の配布タイプ (Windows のバイナリ配布または Linux の RPM 配布など) では、インストールプロセスで、付与テーブルがある
mysql
データベースが初期化されます。これを行わない配布の場合、mysql_install_db プログラムを実行して付与テーブルを手動で初期化する必要があります。詳細については、セクション2.10.1「Unix 類似システムでのインストール後の手順」を参照してください。付与テーブルの初期化が必要かどうかを判別するには、データディレクトリの下にある
mysql
ディレクトリを参照します。(通常、データディレクトリはdata
またはvar
という名前で、MySQL のインストールディレクトリの下にあります。)mysql
データベースディレクトリにuser.MYD
という名前のファイルがあることを確認してください。ない場合、mysql_install_db プログラムを実行します。このプログラムを実行してサーバーを起動したあと、次のコマンドを実行して初期の権限をテストします。shell> mysql -u root test
サーバーはエラーを出さずにユーザーを接続するはずです。
-
新規インストールのあと、サーバーに接続してユーザーおよびユーザーのアクセス権限をセットアップするようにします。
shell> mysql -u root mysql
MySQL
root
ユーザーには最初からパスワードがないため、サーバーはユーザーを接続するはずです。これにはセキュリティー面でのリスクが伴うため、別の MySQL アカウントをセットアップする際は、root
アカウントのパスワードを設定することをお勧めします。初期パスワードの設定手順に関しては、セクション2.10.2「最初の MySQL アカウントのセキュリティー設定」を参照してください。 既存の MySQL インストールを新しいバージョンに更新した場合、mysql_upgrade スクリプトを実行したかどうかを確認します。行なっていない場合は実行します。付与テーブルの構造は、新機能が追加されるときにしばしば変更されるため、アップグレードしたあとは常に、テーブルの構造が最新であることを確認することをお勧めします。その手順は、セクション4.4.7「mysql_upgrade — MySQL テーブルのチェックとアップグレード」を参照してください。
-
クライアントプログラムが接続しようとしたときに次のエラーメッセージを受け取る場合、サーバーはクライアントが生成可能なものよりも新しい形式のパスワードを予期していることを意味します。
shell> mysql Client does not support authentication protocol requested by server; consider upgrading MySQL client
これに対処する方法については、セクション6.1.2.4「MySQL でのパスワードハッシュ」およびセクションB.5.2.4「クライアントは認証プロトコルに対応できません」を参照してください。
-
クライアントプログラムはオプションファイルまたは環境変数に指定された接続パラメータを使用することに留意してください。コマンド行に接続パラメータを指定しないときにクライアントプログラムが間違ったデフォルトの接続パラメータを送信していると思われる場合、該当するオプションファイルおよび環境を確認してください。たとえば、オプションなしでクライアントを実行するときに
Access denied
を受け取る場合、いずれかのオプションファイルで古いパスワードを指定していないか確認してください。--no-defaults
を指定してクライアントプログラムを呼び出すことによって、オプションファイルの使用をクライアントプログラムによって抑制することができます。例:shell> mysqladmin --no-defaults -u root version
クライアントが使用するオプションファイルの一覧は、セクション4.2.6「オプションファイルの使用」にあります。環境変数の一覧は、セクション2.12「環境変数」にあります。
-
次のエラーが出る場合、誤った
root
パスワードを使用していることを示しています。shell> mysqladmin -u root -pxxxx ver Access denied for user 'root'@'localhost' (using password: YES)
パスワードを指定していないのに前述のエラーが発生する場合、いずれかのオプションファイルに間違ったパスワードがリストされていることを意味します。前述の項目で説明したように、
--no-defaults
オプションを試してみてください。パスワードの変更に関する情報は、セクション6.3.5「アカウントパスワードの割り当て」を参照してください。
root
パスワードを紛失したか忘れた場合、セクションB.5.4.1「root のパスワードをリセットする方法」を参照してください。 -
SET PASSWORD
、INSERT
、またはUPDATE
を使用してパスワードを変更する場合、PASSWORD()
関数を使用して、そのパスワードを暗号化する必要があります。これらのステートメントに対してPASSWORD()
関数を使用しないと、パスワードは機能しません。たとえば、次のステートメントはパスワードを割り当てますが、パスワードが暗号化されないため、ユーザーはあとで接続できません。SET PASSWORD FOR 'abe'@'host_name' = 'eagle';
代わりに、パスワードを次のように設定します。
SET PASSWORD FOR 'abe'@'host_name' = PASSWORD('eagle');
CREATE USER
またはGRANT
ステートメントまたは mysqladmin password コマンドを使用してパスワードを指定するときは、PASSWORD()
関数は不要です。これらはいずれもPASSWORD()
を自動的に使用してパスワードを暗号化します。セクション6.3.5「アカウントパスワードの割り当て」およびセクション13.7.1.2「CREATE USER 構文」を参照してください。 -
localhost
はローカルホスト名のシノニムで、ホストを明示的に指定しない場合にクライアントが接続を試行するデフォルトホストでもあります。そのようなシステムで前述の問題を回避するために、
--host=127.0.0.1
オプションを使用して、サーバーホストを明示的に指定することができます。これにより、ローカルの mysqld サーバーへの TCP/IP 接続が作成されます。また、ローカルホストの実際のホスト名を使用する--host
オプションを指定することによって TCP/IP を使用することもできます。この場合、サーバーと同じホスト上でクライアントプログラムを実行していても、ホスト名がサーバーホスト上のuser
テーブル行に指定されていなければなりません。 Access denied
というエラーメッセージは、ログインしようとしているユーザー名、接続を試行しているクライアントホスト、およびパスワードを使用したかどうかを通知します。通常では、エラーメッセージ内で指定されたホスト名およびユーザー名に正確に一致する 1 つの行をuser
テーブル内に持つようにします。たとえば、using password: NO
というメッセージを含むエラーメッセージを受け取る場合、パスワードなしでログインしようとしたことを意味します。-
mysql -u
を使用してデータベースに接続しようとしたときにuser_name
Access denied
エラーを受け取った場合、user
テーブルにおそらく問題があります。これをチェックするには、mysql -u root mysql
を実行し、次の SQL ステートメントを発行します。SELECT * FROM user;
この結果には、クライアントのホスト名および使用中の MySQL ユーザー名に一致する
Host
およびUser
カラムを持つ行が含まれているはずです。 -
MySQL サーバーを実行しているホストではないホストから接続しようとして次のエラーが発生する場合、クライアントホストと一致する
Host
値を持つ行がuser
テーブルにないということを意味しています。Host ... is not allowed to connect to this MySQL server
これは、接続しようとするときに使用するクライアントホスト名およびユーザー名の組み合わせに対するアカウントをセットアップすることによって修正できます。
接続元のマシンの IP アドレスまたはホスト名がわからない場合、
Host
カラム値が'%'
の行をuser
テーブル内に作成するようにします。そして、そのクライアントマシンから接続しようとしたあとで、SELECT USER()
クエリーを使用して、実際にどのように接続したかを確認します。そのあと、user
テーブル行の'%'
を、ログに表示されている実際のホスト名に変更します。そうしない場合、特定のユーザー名について任意のホストからの接続が可能になるため、システムはセキュアでない状態のままになります。Linux では、このエラーが発生する可能性がある別の理由として、使用中のバージョンとは異なるバージョンの
glibc
ライブラリでコンパイルされたバイナリ MySQL バージョンを使用しているということがあります。この場合、オペレーティングシステムまたはglibc
をアップグレードするか、MySQL のソース配布バージョンをダウンロードして自分でコンパイルします。ソース RPM のコンパイルおよびインストールは通常簡単であるため、これは大きな問題ではありません。 -
接続しようとしたときにホスト名を指定したが、ホスト名が非表示または IP アドレスとなっているエラーメッセージを受け取った場合、MySQL サーバーはクライアントホストの IP アドレスを名前に解決しようとしたときにエラーを受け取ったことを意味します。
shell> mysqladmin -u root -pxxxx -h some_hostname ver Access denied for user 'root'@'' (using password: YES)
root
として接続しようとして次のエラーを受け取った場合、User
カラム値が'root'
の行がuser
テーブルになく、mysqld がクライアントに対してホスト名を解決できないことを意味します。Access denied for user ''@'unknown'
これらのエラーは DNS の問題を示しています。これを修正するには、mysqladmin flush-hosts を実行して内部 DNS ホストキャッシュをリセットします。セクション8.11.5.2「DNS ルックアップの最適化とホストキャッシュ」を参照してください。
いくつかの永続的な解決策を次に示します。
DNS サーバーの問題を判別して修正します。
MySQL 付与テーブルにホスト名の代わりに IP アドレスを指定します。
クライアントマシン名に対するエントリを、Unix の場合は
/etc/hosts
に、Windows の場合は\windows\hosts
に配置します。mysqld を
--skip-name-resolve
オプションで起動します。mysqld を
--skip-host-cache
オプションで起動します。Unix で、サーバーとクライアントを同じマシンで実行している場合、
localhost
に接続します。localhost
への Unix 接続は、TCP/IP ではなく Unix ソケットファイルを使用します。Windows で、サーバーとクライアントを同じマシンで実行していて、サーバーが名前付きパイプ接続をサポートしている場合、ホスト名
.
(ピリオド) に接続します。.
への接続には、TCP/IP ではなく名前付きパイプが使用されます。
mysql -u root test
は動作するが、mysql -h
がyour_hostname
-u root testAccess denied
になる場合 (ここで、your_hostname
はローカルホストの実際のホスト名)、ホスト名に対する正しい名前がuser
テーブル内にない可能性があります。このときよくある問題として、user
テーブル行のHost
値は、修飾されていないホスト名を指定しているが、システムの名前解決ルーチンは完全修飾ドメイン名を返すということ (またはその逆) があります。たとえば、user
テーブルにホスト'pluto'
のエントリがあるが、DNS が MySQL に対してホスト名が'pluto.example.com'
であると指示する場合、エントリは無効になります。ホストの IP アドレスをHost
カラム値として格納するエントリをuser
テーブルに追加してみてください。(または、'pluto.%'
などのワイルドカードを含むHost
値を持つエントリをuser
テーブルに追加することもできます。ただし、「%
」で終わるHost
値を使用することは安全でないため推奨されません。)mysql -u
が動作するが、user_name
testmysql -u
が動作しない場合、user_name
other_db
other_db
という名前のデータベースについて、特定のユーザーにアクセス権限を付与していません。mysql -u
をサーバーホスト上で実行したときに動作するが、user_name
mysql -h
をリモートクライアントホスト上で実行したときに動作しない場合、特定のユーザー名についてリモートホストからサーバーへのアクセスを有効にしていません。host_name
-uuser_name
Access denied
を受け取る理由がわからない場合、ワイルドカードを含むHost
値を持つすべてのエントリ ('%'
または'_'
文字を含むエントリ) をuser
テーブルから削除します。非常によくある間違いは、Host
='%'
およびUser
='
という新しいエントリを挿入して、これにより、ユーザーは同じマシンから接続するようsome_user
'localhost
に指定できると思い込むことです。これが機能しない理由は、デフォルト権限に、Host
='localhost'
およびUser
=''
というエントリを含むためです。このエントリには、'%'
よりもさらに具体的な'localhost'
というHost
値があるため、localhost
から接続するときは新しいエントリよりもこちらが優先して使用されます。正しい手順としては、Host
='localhost'
およびUser
='
という第 2 のエントリを挿入するか、some_user
'Host
='localhost'
およびUser
=''
のエントリを削除します。このエントリを削除したら、FLUSH PRIVILEGES
ステートメントを発行して、付与テーブルのリロードを必ず行なってください。セクション6.2.4「アクセス制御、ステージ 1: 接続の検証」も参照してください。MySQL サーバーに接続できるが、
SELECT ... INTO OUTFILE
またはLOAD DATA INFILE
ステートメントを発行するたびにAccess denied
メッセージを受け取る場合、user
テーブル内のエントリでFILE
権限が有効になっていません。付与テーブルを直接 (たとえば、
INSERT
、UPDATE
、またはDELETE
ステートメントを使用して) 変更し、変更が無視されたように思われる場合、サーバーに権限テーブルをリロードさせるためにFLUSH PRIVILEGES
ステートメントまたは mysqladmin flush-privileges コマンドを実行する必要があることを覚えておいてください。そうしない場合、サーバーが次回再起動するまで変更の影響はありません。root
パスワードをUPDATE
ステートメントで変更したあと、権限をフラッシュするまで新規パスワードを指定する必要はありません。これは、パスワードが変更されたことがサーバーにまだ認識されないためです。セッションの最中に権限が変更されたと思われる場合、MySQL 管理者によって権限が変更された可能性があります。付与テーブルのリロードは、新しいクライアント接続に影響しますが、セクション6.2.6「権限変更が有効化される時期」に示すように既存の接続にも影響します。
Perl、PHP、Python、または ODBC プログラムとのアクセスに問題がある場合、
mysql -u
またはuser_name
db_name
mysql -u
を使用してサーバーに接続してみてください。mysql クライアントを使用して接続できる場合、問題はアクセス権限ではなくプログラムにあります。(user_name
-pyour_pass
db_name
-p
とパスワードの間にスペースはありません。--password=
構文を使用してパスワードを指定することもできます。your_pass
-p
または--password
オプションを使用してパスワード値を指定しない場合、MySQL はパスワードを要求します。)テスト目的で、
--skip-grant-tables
オプションを指定して mysqld サーバーを起動します。これにより、MySQL 付与テーブルを変更でき、SHOW GRANTS
ステートメントを使用して、変更による望ましい影響があるかどうかを確認することができます。変更に満足したら、mysqladmin flush-privileges を実行して、権限をリロードするよう mysqld サーバーに指示します。これにより、サーバーを停止して再起動することなく新しい付与テーブルの内容の使用を開始することができます。すべてが失敗する場合、mysqld サーバーをデバッグオプション (
--debug=d,general,query
など) で起動します。これによって、発行された各コマンドに関する情報のほかに、試行された接続についてのホストおよびユーザー情報が出力されます。セクション24.4.3「DBUG パッケージ」を参照してください。MySQL 付与テーブルに関して何かほかの問題があって、メーリングリストに問題を投稿する必要があると思われる場合、MySQL 付与テーブルのダンプを常に提供してください。mysqldump mysql コマンドでテーブルをダンプできます。バグレポートを提出するには、セクション1.6「質問またはバグをレポートする方法」の説明を参照してください。mysqldump を実行するには
--skip-grant-tables
を指定して mysqld を再起動することが必要な場合もあります。