mysqldump: Got errno 32 on write: 'all of a sudden' plenty of room still...Drupal 6 installation

Question

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

Answer 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 !!!