Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 26.8Mb
PDF (A4) - 26.9Mb
HTML Download (TGZ) - 7.1Mb
HTML Download (Zip) - 7.2Mb


B.5.2.9 MySQL サーバーが存在しなくなりました

このセクションでは、関連する「クエリー中にサーバーへの接続が失われました」というエラーについても説明します。

「MySQL サーバーが存在しなくなりました」というエラーのもっとも一般的な原因は、サーバーがタイムアウトして接続が閉じられた場合です。この場合は、通常、次のいずれかのエラーコードを受け取ります (受け取るエラーコードはオペレーティングシステムによって異なります)。

エラーコード 説明
CR_SERVER_GONE_ERROR クライアントはサーバーに問い合わせを送信できませんでした。
CR_SERVER_LOST クライアントはサーバーに書き込むときにエラーを受け取りませんでしたが、問い合わせに対する完全な応答 (または何らかの応答) が得られませんでした。

デフォルトでは、何も発生しなかった場合、サーバーは 8 時間後に接続を閉じます。この時間制限を変更するには、mysqld を起動するときに wait_timeout 変数を設定します。セクション5.1.4「サーバーシステム変数」を参照してください。

スクリプトがある場合、クライアントが自動再接続を行うには、クエリーを再発行する必要があるだけです。これは、クライアントの自動再接続を有効にしている (mysql コマンド行クライアントのデフォルト) ことが前提です。

「MySQL サーバーが存在しなくなりました」というエラーのほかの一般的な原因を次に示します。

  • ユーザー (またはデータベース管理者) が実行中のスレッドを KILL ステートメントまたは mysqladmin kill コマンドを使用して強制終了した。

  • サーバーへの接続を閉じたあとにクエリーを実行しようとした。これはアプリケーションの論理エラーを示しており、修正する必要があります。

  • 別のホスト上で実行されているクライアントアプリケーションに、そのホストから MySQL サーバーに接続するために必要な権限がない。

  • クライアント側で TCP/IP 接続がタイムアウトした。これは、コマンド mysql_options(..., MYSQL_OPT_READ_TIMEOUT,...) または mysql_options(..., MYSQL_OPT_WRITE_TIMEOUT,...) を使用している場合に発生することがあります。この場合は、タイムアウト値を増やすと問題が解決されることがあります。

  • サーバー側でタイムアウトが発生し、クライアントの自動再接続が無効にされている (MYSQL 構造体の reconnect フラグが 0 と等しい)。

  • Windows クライアントを使用していて、コマンドが発行される前にサーバーによって接続がドロップされた (おそらく wait_timeout が期限切れになったため)。

    Windows での問題は、TCP/IP 接続をサーバーに書き込むときに MySQL が OS からエラーを受け取らず、接続から応答を読み取ろうとしたときにエラーを受け取ることです。

    この問題の解決策は、最後のクエリーから長い時間がたっている場合に接続に対して mysql_ping() を実行するか (これは Connector/ODBC が行なっていることです)、mysqld サーバーで wait_timeout に事実上タイムアウトすることがないような高い値を設定することです。

  • 間違ったクエリーまたは長すぎるクエリーをサーバーに送信した場合にも、これらのエラーを受け取ることがあります。mysqld が長すぎるパケットまたは順序が間違っているパケットを受け取ると、クライアントで何らかの問題が発生していると見なして、接続を閉じます。大きなクエリーが必要な場合 (たとえば、大きな BLOB カラムを操作している場合)、クエリーの制限を緩和するには、サーバーの max_allowed_packet 変数 (デフォルト値は 1M バイト) を設定します。クライアント側の最大パケットサイズも増やす必要がある場合もあります。パケットサイズの設定については、セクションB.5.2.10「パケットが大きすぎます」を参照してください。

    多数の行を挿入する INSERT ステートメントまたは REPLACE ステートメントも、これらの種類のエラーの原因となることがあります。これらのステートメントのいずれかは、挿入される行数に関係なくサーバーに単一の要求を送信します。このため、1 つの INSERT または REPLACE で送信される行数を減らすことによって多くの場合エラーを防ぐことができます。

  • また、16M バイト以上のパケットを送信する場合に、クライアントが 4.0.8 より古く、サーバーが 4.0.8 以降であると (またはその逆の場合)、接続を失うことがあります。

  • ホスト名のルックアップが失敗した場合に、このエラーが発生することもあります (たとえば、サーバーまたはネットワークが依存する DNS サーバーが停止した場合)。これは、MySQL が名前解決についてホストシステムに依存しているが、それが動作しているかどうかは知ることができないためです。MySQL が認識している範囲では、この問題はほかのネットワークタイムアウトと区別が付きません。

    --skip-networking オプションを指定して MySQL が起動された場合に、「MySQL サーバーが存在しなくなりました」というエラーが表示されることもあります。

    MySQL のポート (デフォルトは 3306) がファイアウォールによってブロックされていて、MySQL サーバーへのすべての接続が遮断される場合、このエラーの原因となることがある別のネットワークの問題が発生します。

  • アプリケーションで複数の子プロセスがフォークされ、すべての子プロセスが MySQL サーバーへの同じ接続を使用しようとした場合に、このエラーが発生することもあります。これは、各子プロセスが個別の接続を使用することによって防ぐことができます。

  • クエリーの実行中にサーバーが停止するバグが発生した。

MySQL サーバーが停止して再起動されたかどうかを確認するには、mysqladmin version を実行してサーバーの稼働時間を検査します。mysqld がクラッシュして再起動されたためにクライアント接続が切断された場合は、そのクラッシュの原因を見つけることに集中してください。クエリーを再び発行するとサーバーが再び強制終了されるかどうかを確認することから始めます。セクションB.5.4.2「MySQL が繰り返しクラッシュする場合の対処方法」を参照してください。

接続の喪失に関する情報をさらに取得するには、--log-warnings=2 オプションを指定して mysqld を起動します。これにより、一部の切断に関するエラーが hostname.err ファイルに記録されます。セクション5.2.2「エラーログ」 を参照してください。

この問題に関するバグレポートを作成する場合は、次の情報を含めてください。

セクションB.5.2.11「通信エラーおよび中止された接続」およびセクション1.6「質問またはバグをレポートする方法」も参照してください。


User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
  Posted by Mike Kelly on March 17, 2011
I ran into this same error, and as a previous comment noted, and I think bears repeating, was eliminated when I stopped using persistent connections to connect to the MySQL database.
That is, I changed my "PDO::ATTR_PERSISTENT => true" settings to "PDO::ATTR_PERSISTENT => false" and the problem went away.
And there was great rejoicing.
  Posted by MySQL User on May 4, 2011
After I increased my max packet to 2000M, I watched htop when doing the sql import that kept failing and discovered the server went away when I ran out of ram and swap...
  Posted by Chris Calender on May 10, 2011
For those seeing this from PHP scripts, and you've already checked the other items listed above, then ensure your script is calling mysql_free_result when it completes.
  Posted by Jorge Torralba on June 2, 2011
I struggled with this all day. I was uploading two files and then inserting data into the table. The only difference with the files was their size. One would upload just fine and then the database update would take place using a prepared statement. All good. Then I would upload the other larger file which completed uploading but failed to update the database. In the end, what fixed my problem was setting mysqli.reconnect = On in php.ini. My only guess is that the larger file was taking longer to upload thus the db connection was timing out. As a side note, the file was NOT being stored in the db only info about the file.
  Posted by George Liu on August 27, 2011
Just a tip for WHM/Cpanel users experiencing this error it could be related to the WHM cronjob which runs during /scripts/upcp updates which updates WHM/Cpanel versions and checks for version updates to components such as MySQL server http://vbtechsupport.com/433/. Solution is to change when that cronjob is run to not coincide with peak mysql activity time.

  Posted by Radu Onofrei on December 12, 2011
We have found that this problem may occur also because of a bad nameserver, http://matrafox.info/mysql-error-messages-mysql-server-has-gone-away.html or your own cpanel server listed into resolv.conf
  Posted by BOB GALLEY on March 9, 2012
goto include/local
if there is configure.php, delete this file.
  Posted by Pavel Bazanov on June 3, 2013
In my case the problem ("Lost connection to MySQL Server during query") was in a corrupted dump file or in the misbehaving HDDs:

First, I made a dump on the main server and then copied that dump to the replication server. But it seems the replication server had some problems with its HDDs and the dump became corrupted, i.e. MD5 of the original dump file on the main server was different from MD5 of the dump copy on the replication server.
  Posted by Bill Plimpton on August 7, 2013
The key of making it work from command line is not forgetting this part
[mysqld]
max_allowed_packet = 1060M
  Posted by Anna Soseo on October 6, 2014
When you say : If you have a script, you just have to issue the query again for the client to do an automatic reconnection. This assumes that you have automatic reconnection in the client enabled
You can also put automatic reconnection on false to avoid server call. Anna from http://www.howcreateblog.com
Sign Up Login You must be logged in to post a comment.