MySQL 8.0 リファレンスマニュアル MySQL NDB Cluster 8.0 を含む
このページは機械翻訳したものです。
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 rootAccess 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
='
を使用して 2 行目を挿入するか、some_user
'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
を使用してサーバーに接続してみてください。 mysql クライアントを使用して接続できる場合、問題はアクセス権限ではなくプログラムにあります。 (user_name
-ppassword
db_name
-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 を再起動することが必要な場合もあります。