web-dev-qa-db-ja.com

MySQLサーバーが大規模なダンプのインポートを妨害しなくなった

Mac上のローカルmysqlに大きなSQLダンプ（2GB）をインポートしようとしています。過去にこれを行うことができました（私はMAMPを使用していました）が、現在、行7758でエラー2006（HY000）を受け取ります：ダンプをインポートしようとするたびに、MySQLサーバーが消えてしまいました。データベースにはinnodbテーブルが含まれています。

My-innodb-heavy-4G.cnfファイルをmy.cnfにコピーして、これらの設定が役立つかどうかを確認しましたが、うまくいきませんでした。

何を調整するかについてのアイデアはありますか？

ここから「Mac OS Xバージョン10.6（x86、64ビット）、DMGアーカイブ」を使用しています： http://dev.mysql.com/downloads/mysql/

mysqlinnodbdumpmac-os-x
14
naxoc

MySQL接続のサイレントキラーの1つはMySQLパケットです。 MySQLレプリケーションのI/Oスレッドでさえ、これによって被害を受ける可能性があります。

MySQL Documentation によれば

  • 正しくないか大きすぎるクエリをサーバーに送信した場合にも、これらのエラーが発生する可能性があります。 mysqldが受信したパケットが大きすぎるか、順序が乱れている場合、mysqldはクライアントで問題が発生したと見なし、接続を閉じます。大きなクエリが必要な場合（たとえば、大きなBLOB列で作業している場合）は、サーバーのmax_allowed_pa​​cket変数（デフォルト値は1MB）を設定して、クエリの制限を増やすことができます。また、クライアントエンドの最大パケットサイズを増やす必要がある場合もあります。パケットサイズの設定の詳細については、 セクションC.5.2.10「パケットが大きすぎる」 を参照してください。

  • 非常に多くの行を挿入するINSERTまたはREPLACEステートメントも、この種のエラーを引き起こす可能性があります。これらのステートメントのいずれかが、挿入される行の数に関係なく、サーバーに単一の要求を送信します。したがって、INSERTまたはREPLACEごとに送信される行数を減らすことで、エラーを回避できることがよくあります。

少なくとも、mysqldumpを実行したマシンとロードするマシンの両方のパケットサイズが同じであることを確認する必要があります。

あなたが取ることができる2つの（2）アプローチがあるかもしれません：

APPROACH＃1：--skip-extended-insert を使用してmysqldumpを実行します

これにより、MySQLパケットが複数のBLOB、TEXTフィールドで溢れることがなくなります。これにより、SQL INSERTが一度に1つずつ実行されます。主な欠点は

  1. mysqldumpがはるかに大きい
  2. このようなダンプのリロードには、はるかに長い時間がかかります。

APPROACH＃2： max_allowed_pa​​cketを増やします

これはMySQLを再起動するだけなので、これは推奨されるアプローチです。 MySQLパケットが何であるかを理解することで、これを明確にすることができます。

「MySQLの内部構造について」の99ページ（ISBN 0-596-00957-7） によると、これはそれを説明する1〜3の段落です。

MySQLネットワーク通信コードは、クエリが常に適度に短いため、1つのチャンクでサーバーに送信および処理できることを前提に記述されています。これは、MySQLではパケットと呼ばれます。用語。サーバーは、パケットを格納するための一時バッファにメモリを割り当て、完全に収まるように要求します。このアーキテクチャでは、サーバーがメモリ不足になるのを防ぐための予防策が必要です。このオプションを使用すると、パケットのサイズに上限が設けられます。

このオプションに関連するコードは、 sql/net_serv.cc にあります。 my_net_read（）を確認してから、 my_real_read（）の呼び出しに従い、 net_reallocに特に注意してください（）。

この変数は、多くの文字列関数の結果の長さも制限します。詳細については、 sql/field.cc およびsql/intem_strfunc.ccを参照してください。

この説明を踏まえると、一括INSERTを実行すると、MySQLパケットのロード/アンロードがかなり速くなります。これは、max_allowed_pa​​cketが小さすぎて、指定されたデータの負荷が来ないときに特に当てはまります。

[〜＃〜]結論[〜＃〜]

MySQLのほとんどのインストールでは、通常これを256Mまたは512Mに設定します。データのロードで「MySQLがなくなった」というエラーが発生した場合は、より大きな値で実験する必要があります。

15
RolandoMySQLDBA

他の提案で成功しなかった人は、BigDump PHP staggered MySQL dump importer script 。

これは、大きなデータベースダンプをMySQLにインポートするための回避策です。これを使用して、大規模なMySQLダンプをローカル開発環境にインポートしました（この場合はMAMPを使用しています）。

2
Marcus Barnes

タイムアウトになるまでにどれくらいかかりますか？最初のステップは wait_timeout および interactive_timeout インポートに十分な大きさであることを確認するための設定：

SHOW VARIABLES LIKE '%_timeout';
SET SESSION wait_timeout=28800;

デフォルトは8時間（28800）なので、これは問題にならない可能性があります。この問題の他の兆候は here にあります。目立つのはこれです：

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

最初に権限を確認し、次に潜在的な問題のリストを確認します。

2
Derek Downey

それは「正しい」ことではないかもしれませんが、うまくいくかもしれません（完了しますよね？）：

大きなダンプを複数のファイルに分割し、一度に1つずつ順番に実行してみてください。私のアプローチは、それを半分に分けてテストすることです。次に、それぞれの半分を半分に分けて再テストします。

RAM箱に入っている量がこれに何らかの影響を与える可能性がある場合、MySQLはダンプ全体をメモリにロードしますか？わからない...しかし、2 GBのRAMで、OSや他のアプリの実行に使用されている場合、これは可能性があります問題。

2
Day Davis Waterbury

うん、通常はwait_timeoutとmax_allowed_pa​​cketsで遊んでいるので、エラーメッセージを回避することもできます。

2
p4guru