问题
On the dev server, I tried to run the same script I've been using for almost a year and at the end got the : mysqldump: Got errno 32 on write
Last week, the IT sysadmin just restored the virtual server to a few days before backup and it all worked.
The Drupal install is fine and the live server is fine (a duplicate of the dev server)...we have about 30 or so virtual servers all on the same box and the IT SysAdmin has allocated quite a few resources.
Here's what I get with df -h on the dev:
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:~$
and the basic output after running my script in the command line:
ERROR 1005 (HY000) at line 5416: Can't create table 'content_type_ses_job_postings' (errno: 28) mysqldump: Got errno 32 on write ERROR 2003 (HY000): Can't connect to MySQL server on '198.xx.xx.xx' (111) LDAP server IP updated.
Note that I get that last ERROR 2003 about not connecting to the MySQL server even when it all works so though that shouldn't happen, I think that's more of the user problem as the databases backup, save, and then import to the 'holding' db which I then switch to when updating content so perhaps that's something, but it's never been a specific problem.
If error 32 is related to space, where could the space problem be? If it's related to permissions, which folder would the permissions problem be on? However, I don't know how or what could have dynamically changed the permissions anywhere as...I stated before, I've been running these scripts for about 8 months with no problem?
The basics of the dev server
- MySQL 5.5.24
- Ubuntu0.12.04.1
- PHP 5.3
回答1:
Seems strange
[root@*****]# perror 28
OS error code 28: No space left on device
[root@*****]# perror 32
OS error code 32: Broken pipe
Since the mysqldump keeps breaking at random places, it is space-related, and no disk full condition, I would suspect the problem at a deeper layer : the MySQL Packet. What is a MySQL Packet?
According to the page 99 of the Book
here are paragraphs 1-3 explaining it:
MySQL network communication code was written under the assumption that queries are always reasonably short, and therefore can be sent to and processed by the server in one chunk, which is called a packet in MySQL terminology. The server allocates the memory for a temporary buffer to store the packet, and it requests enough to fit it entirely. This architecture requires a precaution to avoid having the server run out of memory---a cap on the size of the packet, which this option accomplishes.
The code of interest in relation to this option is found in sql/net_serv.cc. Take a look at my_net_read(), then follow the call to my_real_read() and pay particular attention to net_realloc().
This variable also limits the length of a result of many string functons. See sql/field.cc and sql/intem_strfunc.cc for details.
Given this explanation, making bulk INSERTs will load/unload a MySQL Packet rather quickly. This is especially true when max_allowed_packet is too small for the given load of data coming at it.
I wrote about this before : MySQL server has gone away obstructing import of large dumps
Try raising max_allowed_packet for the mysqldump to 1G as follows:
mysqldump --max-allowed-packet=1073741824 ...
and try the mysqldump.
If this does not do it, then do this:
Added this to my.cnf
[mysqld]
max_allowed_packet = 1G
Then, login to MySQL as root@localhost and run this
mysql> SET GLOBAL max_allowed_packet = 1024 * 1024 * 1024;
and try the mysqldump.
Give it a Try !!!
来源：https://stackoverflow.com/questions/17533323/mysqldump-got-errno-32-on-write-all-of-a-sudden-plenty-of-room-still-drupa