このページは機械翻訳したものです。

6.2.21 MySQL への接続の問題のトラブルシューティング

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 ファイアウォールなどのアプリケーションを、MySQL ポートをブロックしないように構成する必要がある場合があります。

• 付与テーブルが適切にセットアップされており、サーバーがこれをアクセス制御に使用できるようになっていることが必要です。 一部の配布タイプ (Windows でのバイナリ配布、Linux での RPM および DEB 配布など) では、インストールプロセスによって、付与テーブルを含む mysql システムデータベースを含む MySQL データディレクトリが初期化されます。 これを行わない配布の場合は、データディレクトリを手動で初期化する必要があります。 詳細は、セクション2.10「インストール後のセットアップとテスト」を参照してください。

  付与テーブルの初期化が必要かどうかを判別するには、データディレクトリの下にある mysql ディレクトリを参照します。 (通常、データディレクトリは data または var という名前で、MySQL のインストールディレクトリの下にあります。) mysql データベースディレクトリに user.MYD という名前のファイルがあることを確認してください。 そうでない場合は、データディレクトリを初期化します。 これを行ってサーバーを起動すると、サーバーに接続できるようになります。

• 新規インストールの後、パスワードを使用せずに root としてサーバーにログオンしようとすると、次のエラーメッセージが表示されることがあります。

  shell> mysql -u root 
  ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

  これは、インストール時に root パスワードがすでに割り当てられており、指定する必要があることを意味します。 パスワードが割り当てられている様々な方法、およびパスワードの検索方法については、セクション2.10.4「初期 MySQL アカウントの保護」 を参照してください。 root パスワードをリセットする必要がある場合は、セクションB.3.3.2「root のパスワードをリセットする方法」 の手順を参照してください。 パスワードを検出またはリセットした後、--password (または -p) オプションを使用して root として再度ログオンします:

  shell> mysql -u root -p
  Enter password:

  ただし、mysqld --initialize-insecure を使用して MySQL を初期化した場合、サーバーはパスワードを使用せずに root として接続できます (詳細は セクション2.10.1「データディレクトリの初期化」 を参照)。 これはセキュリティ上のリスクであるため、root アカウントのパスワードを設定する必要があります。手順は、セクション2.10.4「初期 MySQL アカウントの保護」 を参照してください。

• 既存の MySQL インストールを新しいバージョンに更新した場合、MySQL のアップグレード手順を実行しましたか。 行なっていない場合は実行します。 付与テーブルの構造は、新機能が追加されるときにしばしば変更されるため、アップグレードしたあとは常に、テーブルの構造が最新であることを確認することをお勧めします。 その手順は、セクション2.11「MySQL のアップグレード」を参照してください。

• クライアントプログラムが接続しようとしたときに次のエラーメッセージを受け取る場合、サーバーはクライアントが生成可能なものよりも新しい形式のパスワードを予期していることを意味します。

  shell> mysql
  Client does not support authentication protocol requested
  by server; consider upgrading MySQL client

• クライアントプログラムは、オプションファイルまたは環境変数で指定された接続パラメータを使用することに注意してください。 コマンド行に接続パラメータを指定しないときにクライアントプログラムが間違ったデフォルトの接続パラメータを送信していると思われる場合、該当するオプションファイルおよび環境を確認してください。 たとえば、オプションなしでクライアントを実行するときに Access denied を受け取る場合、いずれかのオプションファイルで古いパスワードを指定していないか確認してください。

  --no-defaults を指定してクライアントプログラムを呼び出すことによって、オプションファイルの使用をクライアントプログラムによって抑制することができます。 例:

  shell> mysqladmin --no-defaults -u root version

  クライアントが使用するオプションファイルの一覧は、セクション4.2.2.2「オプションファイルの使用」にあります。 環境変数の一覧は、セクション4.9「環境変数」にあります。

• 次のエラーが出る場合、誤った root パスワードを使用していることを示しています。

  shell> mysqladmin -u root -pxxxx ver
  Access denied for user 'root'@'localhost' (using password: YES)

  パスワードを指定していないのに前述のエラーが発生する場合、いずれかのオプションファイルに間違ったパスワードがリストされていることを意味します。 前述の項目で説明したように、--no-defaults オプションを試してみてください。

  パスワードの変更に関する情報は、セクション6.2.14「アカウントパスワードの割り当て」を参照してください。

  root パスワードを紛失したか忘れた場合、セクションB.3.3.2「root のパスワードをリセットする方法」を参照してください。

• 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 ホストキャッシュをリセットします。 セクション5.1.12.3「DNS ルックアップとホストキャッシュ」を参照してください。

  いくつかの永続的な解決策を次に示します。

  • DNS サーバーの問題を判別して修正します。

  • MySQL 付与テーブルにホスト名の代わりに IP アドレスを指定します。

  • クライアントマシン名に対するエントリを、Unix の場合は /etc/hosts に、Windows の場合は \windows\hosts に配置します。

  • skip_name_resolve システム変数を有効にして mysqld を起動します。

  • mysqld を --skip-host-cache オプションで起動します。

  • Unix で、サーバーとクライアントを同じマシンで実行している場合、localhost に接続します。 localhost への接続の場合、MySQL プログラムは、クライアントが TCP/IP 接続を確立するための接続パラメータが指定されていないかぎり、Unix ソケットファイルを使用してローカルサーバーへの接続を試みます。 詳細は、セクション4.2.4「コマンドオプションを使用した MySQL Server への接続」を参照してください。

  • Windows で、サーバーとクライアントを同じマシンで実行していて、サーバーが名前付きパイプ接続をサポートしている場合、ホスト名 . (ピリオド) に接続します。 . への接続には、TCP/IP ではなく名前付きパイプが使用されます。

• mysql -u root は動作するが、mysql -h your_hostname -u root によって Access denied (your_hostname はローカルホストの実際のホスト名) が生成される場合、user テーブルにホストの正しい名前がない可能性があります。 このときよくある問題として、user テーブル行の Host 値は、修飾されていないホスト名を指定しているが、システムの名前解決ルーチンは完全修飾ドメイン名を返すということ (またはその逆) があります。 たとえば、user テーブルにホスト'pluto'を含む行があり、ホスト名が'pluto.example.com'であることを DNS が MySQL に通知した場合、その行は機能しません。 ホストの IP アドレスを Host カラム値として含む行を user テーブルに追加してみます。 (または、ワイルドカードを含む Host 値 ('pluto.%'など) を使用して、user テーブルに行を追加できます。 ただし、%で終わる Host 値を使用することは安全でないため推奨されません。)

• mysql -u user_name は動作するが、mysql -u user_name some_db は動作しない場合、some_db という名前のデータベースに対する特定のユーザーへのアクセス権を付与していません。

• mysql -u user_name をサーバーホスト上で実行したときに動作するが、mysql -h host_name -u user_name をリモートクライアントホスト上で実行したときに動作しない場合、特定のユーザー名についてリモートホストからサーバーへのアクセスを有効にしていません。

• Access denied を取得する理由がわからない場合は、ワイルドカード ('%'または'_'文字を含む行) を含む Host 値を持つすべての行を user テーブルから削除します。 非常に一般的なエラーは、Host = '%'および User = 'some_user'を使用して新しい行を挿入することです。これにより、localhost を指定して同じマシンから接続できると考えられます。 これが機能しない理由は、デフォルトの権限に Host = 'localhost'および User = ''の行が含まれているためです。 その行には'%'よりも具体的な Host 値'localhost'があるため、localhost から接続するときに新しい行よりも優先して使用されます。 正しい手順は、Host = 'localhost'および User='some_user'を使用して 2 行目を挿入するか、Host = 'localhost'および User = ''を使用して行を削除することです。 行を削除した後は、必ず FLUSH PRIVILEGES ステートメントを発行して付与テーブルをリロードしてください。 セクション6.2.6「アクセス制御、ステージ 1: 接続の検証」も参照してください。

• MySQL サーバーに接続できても、SELECT ... INTO OUTFILE または LOAD DATA ステートメントを発行するたびに Access denied メッセージが表示される場合、user テーブルの行で FILE 権限が有効になっていません。

• 付与テーブルを直接 (たとえば、INSERT、UPDATE、または DELETE ステートメントを使用して) 変更し、変更が無視されたように思われる場合、サーバーに権限テーブルをリロードさせるために FLUSH PRIVILEGES ステートメントまたは mysqladmin flush-privileges コマンドを実行する必要があることを覚えておいてください。 そうしない場合、サーバーが次回再起動するまで変更の影響はありません。 UPDATE ステートメントを使用して root のパスワードを変更した後は、権限をフラッシュするまで新しいパスワードを指定する必要はありません。これは、パスワードを変更するまでサーバーが認識しないためです。

• セッションの最中に権限が変更されたと思われる場合、MySQL 管理者によって権限が変更された可能性があります。 付与テーブルのリロードは、新しいクライアント接続に影響しますが、セクション6.2.13「権限変更が有効化される時期」に示すように既存の接続にも影響します。

• Perl、PHP、Python または ODBC プログラムでアクセスの問題が発生した場合は、mysql -u user_name db_name または mysql -u user_name -ppassword db_name を使用してサーバーに接続してみてください。 mysql クライアントを使用して接続できる場合、問題はアクセス権限ではなくプログラムにあります。 (-p とパスワードの間に空白はありません。--password=password 構文を使用してパスワードを指定することもできます。 -p または --password オプションを使用してパスワード値を指定しない場合、MySQL はパスワードを要求します。)

• テスト目的で、--skip-grant-tables オプションを指定して mysqld サーバーを起動します。 これにより、MySQL 付与テーブルを変更でき、SHOW GRANTS ステートメントを使用して、変更による望ましい影響があるかどうかを確認することができます。 変更に満足したら、mysqladmin flush-privileges を実行して、権限をリロードするよう mysqld サーバーに指示します。 これにより、サーバーを停止して再起動することなく新しい付与テーブルの内容の使用を開始することができます。

• すべてが失敗する場合、mysqld サーバーをデバッグオプション (--debug=d,general,query など) で起動します。 これによって、発行された各コマンドに関する情報のほかに、試行された接続についてのホストおよびユーザー情報が出力されます。 セクション5.9.4「DBUG パッケージ」を参照してください。

• MySQL 付与テーブルにその他の問題があり、MySQL Community Slack で確認する場合は、常に MySQL 付与テーブルのダンプを提供してください。 mysqldump mysql コマンドでテーブルをダンプできます。 バグレポートを提出するには、セクション1.6「質問またはバグをレポートする方法」の説明を参照してください。 mysqldump を実行するには --skip-grant-tables を指定して mysqld を再起動することが必要な場合もあります。