12

開発サーバーで、ほぼ 1 年間使用してきたのと同じスクリプトを実行しようとしましたが、最後に : mysqldump: Got errno 32 on write が発生しました

先週、IT システム管理者が仮想サーバーをバックアップの数日前に復元したところ、すべて正常に機能しました。

Drupal のインストールに問題はなく、ライブ サーバー (開発サーバーの複製) にも問題はありません...同じボックスに約 30 台ほどの仮想サーバーがあり、IT システム管理者はかなりの数のリソースを割り当てています。

開発者で df -h を使用して得られるものは次のとおりです。

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        18G  6.1G   12G  36% /
udev           1000M  4.0K 1000M   1% /dev
tmpfs           403M  228K  403M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none           1007M     0 1007M   0% /run/shm
/dev/sdb1       100G  8.1G   87G   9% /data
xxxx@dev1:~$

コマンドラインでスクリプトを実行した後の基本的な出力：

エラー 1005 (HY000) 行 5416: テーブル 'content_type_ses_job_postings' を作成できません (errno: 28) mysqldump: 書き込みで errno 32 を取得しました エラー 2003 (HY000): '198.xx.xx の MySQL サーバーに接続できません。 xx' (111) LDAP サーバーの IP が更新されました。

最後に、すべてが機能している場合でもMySQLサーバーに接続しないことに注意してERROR 2003ください。これは発生しないはずですが、データベースのバックアップ、保存、および「保持」データベースへのインポートなどのユーザーの問題だと思いますコンテンツを更新するときに切り替えるので、おそらくそれが何かですが、それは特定の問題ではありません.

スペースに関連している場合error 32、スペースの問題はどこにある可能性がありますか? アクセス許可に関連している場合、アクセス許可の問題はどのフォルダーにありますか? ただし、どのように、または何が動的にアクセス許可を変更したのかはわかりません...前に述べたように、これらのスクリプトを約 8 か月間問題なく実行していますか?

開発サーバーの基本

  • MySQL 5.5.24
  • Ubuntu0.12.04.1
  • PHP5.3
4

1 に答える 1

20

奇妙に思える

[root@*****]# perror 28
OS error code  28:  No space left on device
[root@*****]# perror 32
OS error code  32:  Broken pipe

mysqldump はランダムな場所で壊れ続けているため、これはスペースに関連しており、ディスクがいっぱいの状態ではないため、より深いレイヤーである MySQL パケットに問題があると思われます。MySQL パケットとは何ですか?

本の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_pa​​cket が与えられたデータの負荷に対して小さすぎる場合に特に当てはまります。

これについては以前に書きました : MySQL サーバーが消えて、大きなダンプのインポートが妨げられました

次のように、mysqldump の max_allowed_pa​​cket を上げてみてください。1G

mysqldump --max-allowed-packet=1073741824 ...

そしてmysqldumpを試してください。

これでうまくいかない場合は、次のようにします。

これを my.cnf に追加しました

[mysqld]
max_allowed_packet = 1G

次に、MySQL にログインし、root@localhostこれを実行します。

mysql> SET GLOBAL max_allowed_packet = 1024 * 1024 * 1024;

そしてmysqldumpを試してください。

試してみる ！！！

于 2013-07-08T19:52:33.997 に答える