Mac上のローカルmysqlに大きなSQLダンプ（2GB）をインポートしようとしています。過去にこれを行うことができました（私はMAMPを使用していました）が、今では行7758でERROR 2006（HY000）を受け取ります：ダンプをインポートしようとするたびにMySQLサーバーがなくなっています。データベースにはinnodbテーブルが含まれます。
my-innodb-heavy-4G.cnfファイルをmy.cnfにコピーして、これらの設定が役立つかどうかを確認しましたが、うまくいきませんでした。
何を微調整するかについてのアイデアはありますか？
ここから「Mac OS X ver。10.6（x86、64ビット）、DMG Archive」を使用しています：http : //dev.mysql.com/downloads/mysql/
回答:
MySQL Connectionsのサイレントキラーの1つはMySQLパケットです。これにより、MySQLレプリケーションのI / Oスレッドも被害を受ける可能性があります。
MySQLドキュメントによると
間違っているか大きすぎるクエリをサーバーに送信した場合にも、これらのエラーが発生する可能性があります。mysqldが受信したパケットが大きすぎるか、順序が乱れている場合、クライアントで何らかの問題が発生したと見なし、接続を閉じます。大きなクエリが必要な場合（たとえば、大きなBLOB列を使用している場合）、サーバーのmax_allowed_packet変数（デフォルト値は1MB）を設定して、クエリの制限を増やすことができます。クライアント側で最大パケットサイズを増やす必要がある場合もあります。パケットサイズの設定に関する詳細は、セクションC.5.2.10「パケットが大きすぎます」に記載されています。
非常に多くの行を挿入するINSERTまたはREPLACEステートメントも、この種のエラーを引き起こす可能性があります。これらのステートメントのいずれかは、挿入される行の数に関係なく、サーバーに単一の要求を送信します。したがって、INSERTまたはREPLACEごとに送信される行の数を減らすことにより、多くの場合エラーを回避できます。
少なくとも、mysqldumpしたマシンとロードしているマシンの両方のパケットサイズが同じであることを確認する必要があります。
次の2つのアプローチがあります。
アプローチ＃1：--skip-extended-insertを使用してmysqldumpを実行します
これにより、MySQLパケットが複数のBLOB、TEXTフィールドであふれないようにします。これにより、SQL INSERTは一度に1つずつ実行されます。主な欠点は
アプローチ＃2：max_allowed_packetを増やす
これは、mysqlを再起動するだけなので、これが推奨される方法です。MySQLパケットが何であるかを理解すると、これが明らかになる場合があります。
「MySQL内部構造の理解」（ISBN 0-596-00957-7）の99ページによると、これを説明するパラグラフ1〜3があります。
MySQLネットワーク通信コードは、クエリは常に合理的に短いため、MySQL用語ではパケットと呼ばれる1つのチャンクでサーバーに送信および処理できるという仮定の下で作成されました。サーバーは、パケットを格納するための一時バッファにメモリを割り当て、完全に収まるのに十分な量を要求します。このアーキテクチャでは、サーバーのメモリ不足を回避するための予防措置が必要です。このオプションでは、パケットサイズの上限を設定しています。
このオプションに関連する重要なコードは sql / net_serv.ccにあります。my_net_read（）を見て、my_real_read（）の呼び出しに従い、net_realloc（）に特に注意を払って ください。
この変数は、多くの文字列関数の結果の長さも制限します。詳細については、sql / field.ccおよび sql / intem_strfunc.ccを参照してください。
この説明から、バルクINSERTを作成すると、MySQLパケットのロード/アンロードがかなり速くなります。これは、max_allowed_packetが与えられたデータの負荷に対して小さすぎる場合に特に当てはまります。
結論
MySQLのほとんどのインストールでは、通常これを256Mまたは512Mに設定します。データのロード時に「MySQLがなくなった」というエラーが発生した場合は、より大きな値で実験する必要があります。
タイムアウトする前にこれはどのくらい実行されますか？最初のステップはwait_timeout、interactive_timeout設定をチェックして、インポートに十分な大きさであることを確認することです。
SHOW VARIABLES LIKE '%_timeout';
SET SESSION wait_timeout=28800;デフォルトは8時間（28800）であるため、問題ではない可能性があります。ここでこの問題の他のしるしを見つけることができます。際立っているのはこれです：
別のホストで実行されているクライアントアプリケーションには、そのホストからMySQLサーバーに接続するために必要な特権がありません。
最初に権限を確認してから、潜在的な問題のリストを確認してください。
それは「正しい」ことではないかもしれませんが、うまくいくかもしれません（完了しましたか？）：
大きなダンプを複数のファイルに分割し、順番に1つずつ実行してみてください。私のアプローチは、それを半分に分割してテストすることです。次に、各半分を半分に分割し、再テストします。
あなたがあなたの箱に持っているRAMの量がこれと何か関係があるかもしれないならば、私はいくらか興味があります。MySQLは実行するときにダンプ全体をメモリにロードしますか？わからない...しかし、RAMが2GBしかなく、その一部がOSや他のアプリの実行に使用されている場合、これが問題になるかもしれません。
他の提案で成功していない人は、BigDump PHPスタッガードMySQLダンプインポータースクリプトを検討することを検討するかもしれません。
これは、大規模なデータベースダンプをMySQLにインポートするための回避策です。大規模なMySQLダンプをローカル開発環境にインポートするために正常に使用しました（この場合はMAMPを使用しています）。
max_allowed_packet900Mに設定しようと しましたが、私は使用していました--skip-extended-insert（そしてあなたは正しいです-それは巨大なdbダンプを作ります）が、それでも失敗します。おそらく回避できるので、ダンプ内の特定の行を疑っています。しかし、それはまだ奇妙です-ダンプは私のCentOSサーバーにうまくインポートできます。