Mysqldump: Got errno 32 wrote: "suddenly" a lot of space is still ... Installing Drupal 6

Question

On the dev server, I tried to run the same script that I had been using for almost a year, and at the end I got: mysqldump: Got errno 32 on write

Last week, the IT administrator just rebuilt the virtual server a few days before the backup, and it all worked.

The Drupal installation is fine, and the live server is fine (duplicate of the dev server) ... we have about 30 virtual servers in one window, and the SysAdmin IT server has allocated a lot of resources.

Here is what I get from df -h to 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 main output after running my script on the command line:

ERROR 1005 (HY000) on line 5416: cannot create table 'content_type_ses_job_postings' (errno: 28) mysqldump: Got errno 32 on write ERROR 2003 (HY000): cannot connect to MySQL server on '198.xx.xx.xx' (111 ) Updated IP address of LDAP server.

Please note that I received the latest ERROR 2003 saying that I’m not connecting to the MySQL server, even if everything works, although this should not happen, I think there is more problem with the user like backing up, saving, and then importing to "hold "db, which I then switch to updating the content, maybe something, but it was never a problem.

If error 32 is related to space, where could there be a space problem? If it is related to permissions, in which folder would there be a problem with permissions? However, I don’t know how or what could dynamically change permissions anywhere, like ... I already said, I ran these scripts for about 8 months without problems?

Dev Server Basics

• 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 mysqldump continues to crash in arbitrary places, it is associated with space and does not have full disk state, I would suspect a problem at a deeper level: the MySQL package. What is a MySQL package?

According to page 99 of the book

here are paragraphs 1-3 explaining this:

The MySQL network communication code was written under the assumption that requests are always quite short, and therefore can be sent and processed by the server in one piece, which is called a package in MySQL terminology. The server allocates memory to store the temporary packet buffer, and it asks for a completely suitable one. This architecture requires caution to avoid running out of memory on the server --- a cap on the packet size that this option executes.

The code of interest in relation to this parameter is in SQL / net_serv.cc . Take a look at my_net_read () , then follow the call to my_real_read () and pay special attention to net_realloc () .

This variable also limits the length of the result of many string functons. See sql / field.cc and sql / intem_strfunc.cc .

Given this explanation, executing bulk INSERTs will load / unload the MySQL package quite quickly. This is especially true when max_allowed_packet is too small for a given load of data coming into it.

I wrote about this before: MySQL server is gone, preventing the import of large dumps

Try raising max_allowed_packet for mysqldump to 1G as follows:

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

and try mysqldump.

If not, do the following:

Added this to my.cnf

 [mysqld] max_allowed_packet = 1G 

Then log into MySQL as root@localhost and run this

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

and try mysqldump.

Give it a try !!!