Vvv: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

Created on 17 May 2016  路  5Comments  路  Source: Varying-Vagrant-Vagrants/VVV

Running Vagrant 1.8.1 on VB 5.0.16

Had to do a hard reboot on OSX now cant connect to mysql on my Vagrant VVV set up. When VVV is running can't connect to any databases or use phpmyadmin - get a #2002 error

VVV log

default: Running: inline script
==> default: stop: Unknown instance:
==> default: start: Job failed to start
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

SSH into Vagrant and ran mysql - I get

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)

Tried vagrant provision and a number of halts and ups but still same issue

If I manually try and restart mysql on the box it fails...

vagrant@vvv:~$ sudo service mysql restart
stop: Unknown instance:
start: Job failed to start

Tried uninstall/reinstall of mysql as mentioned here - but same error applies

Any ways around this?

question

Most helpful comment

What I did was SSH into the vagrant box
vagrant ssh
Viewed the mysql error log
sudo cat /var/log/mysql/error.log

and getting...

vagrant@vvv:~$ sudo more /var/log/mysql/error.log
160516  6:58:26 [Note] Plugin 'FEDERATED' is disabled.
160516  6:58:27 InnoDB: The InnoDB memory heap is disabled
160516  6:58:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160516  6:58:27 InnoDB: Compressed tables use zlib 1.2.8
160516  6:58:27 InnoDB: Using Linux native AIO
160516  6:58:27 InnoDB: Initializing buffer pool, size = 128.0M
160516  6:58:27 InnoDB: Completed initialization of buffer pool
160516  6:58:27 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 25302182000
160516  6:58:28  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 25302231611
160516  6:59:37  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 7
7 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 InnoDB: Probable data corruption on page 18
InnoDB: Original record (compact record)
InnoDB: on that page.
InnoDB: Cannot find the dir slot for record (compact record)
InnoDB: on that page!
160516  6:59:37  InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 5f1573....
...back 1 page
160516  6:58:26 [Note] Plugin 'FEDERATED' is disabled.
160516  6:58:27 InnoDB: The InnoDB memory heap is disabled
160516  6:58:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160516  6:58:27 InnoDB: Compressed tables use zlib 1.2.8
160516  6:58:27 InnoDB: Using Linux native AIO
160516  6:58:27 InnoDB: Initializing buffer pool, size = 128.0M
160516  6:58:27 InnoDB: Completed initialization of buffer pool
160516  6:58:27 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 25302182000
160516  6:58:28  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 25302231611
160516  6:59:37  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 7
7 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 InnoDB: Probable data corruption on page 18
InnoDB: Original record (compact record)
InnoDB: on that page.
InnoDB: Cannot find the dir slot for record (compact record)
InnoDB: on that page!
160516  6:59:37  InnoDB: Page dump in ascii and hex (16384 bytes):

Seems my data is/was corrupted beyond repair - tried following some suggestions here - http://lists.mysql.com/mysql/205511 but to no avail -

Removing any ib* files gets mysql working again

sudo -i
cd /var/lib/mysql
rm -f ib*

But renders all databases empty
Will have to restore the dbs from backups

All 5 comments

What I did was SSH into the vagrant box
vagrant ssh
Viewed the mysql error log
sudo cat /var/log/mysql/error.log

and getting...

vagrant@vvv:~$ sudo more /var/log/mysql/error.log
160516  6:58:26 [Note] Plugin 'FEDERATED' is disabled.
160516  6:58:27 InnoDB: The InnoDB memory heap is disabled
160516  6:58:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160516  6:58:27 InnoDB: Compressed tables use zlib 1.2.8
160516  6:58:27 InnoDB: Using Linux native AIO
160516  6:58:27 InnoDB: Initializing buffer pool, size = 128.0M
160516  6:58:27 InnoDB: Completed initialization of buffer pool
160516  6:58:27 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 25302182000
160516  6:58:28  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 25302231611
160516  6:59:37  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 7
7 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 InnoDB: Probable data corruption on page 18
InnoDB: Original record (compact record)
InnoDB: on that page.
InnoDB: Cannot find the dir slot for record (compact record)
InnoDB: on that page!
160516  6:59:37  InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 5f1573....
...back 1 page
160516  6:58:26 [Note] Plugin 'FEDERATED' is disabled.
160516  6:58:27 InnoDB: The InnoDB memory heap is disabled
160516  6:58:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160516  6:58:27 InnoDB: Compressed tables use zlib 1.2.8
160516  6:58:27 InnoDB: Using Linux native AIO
160516  6:58:27 InnoDB: Initializing buffer pool, size = 128.0M
160516  6:58:27 InnoDB: Completed initialization of buffer pool
160516  6:58:27 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 25302182000
160516  6:58:28  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 25302231611
160516  6:59:37  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36
37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 7
7 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 InnoDB: Probable data corruption on page 18
InnoDB: Original record (compact record)
InnoDB: on that page.
InnoDB: Cannot find the dir slot for record (compact record)
InnoDB: on that page!
160516  6:59:37  InnoDB: Page dump in ascii and hex (16384 bytes):

Seems my data is/was corrupted beyond repair - tried following some suggestions here - http://lists.mysql.com/mysql/205511 but to no avail -

Removing any ib* files gets mysql working again

sudo -i
cd /var/lib/mysql
rm -f ib*

But renders all databases empty
Will have to restore the dbs from backups

Hi @neilgee, thanks for all of the detailed info. I wonder what happened that caused the VM to corrupt the data. 馃槮

I'm going to close this out, but it's a nice set of data for future searchers.

Rather unfortunately, I had a very similar problem and had to remove all the ib files. Provisioning did nothing for me. The mysql log revealed the following:

`170121 1:40:32 [Note] Plugin 'FEDERATED' is disabled.
170121 1:40:32 InnoDB: The InnoDB memory heap is disabled
170121 1:40:32 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170121 1:40:32 InnoDB: Compressed tables use zlib 1.2.3.4
170121 1:40:32 InnoDB: Initializing buffer pool, size = 128.0M
170121 1:40:32 InnoDB: Completed initialization of buffer pool
InnoDB: Error: space header page consists of zero bytes in data file ./ibdata1
170121 1:40:32 InnoDB: Could not open or create data files.
170121 1:40:32 InnoDB: If you tried to add new data files, and it failed here,
170121 1:40:32 InnoDB: you should now edit innodb_data_file_path in my.cnf back
170121 1:40:32 InnoDB: to what it was, and remove the new ibdata files InnoDB created
170121 1:40:32 InnoDB: in this failed attempt. InnoDB only wrote those files full of
170121 1:40:32 InnoDB: zeros, but did not yet use them in any way. But be careful: do not
170121 1:40:32 InnoDB: remove old data files which contain your precious data!
170121 1:40:32 [ERROR] Plugin 'InnoDB' init function returned error.
170121 1:40:32 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
170121 1:40:32 [ERROR] Unknown/unsupported storage engine: InnoDB
170121 1:40:32 [ERROR] Aborting

170121 1:40:32 [Note] /usr/sbin/mysqld: Shutdown complete`

After removing the ib files by @neilgee's suggestion, starting up mysql was no longer an issue. But still, the cause of this is unknown.

@neilgee didn't seem to work for me. I didn't update Vagrant or VB but I did for VVV. After provisioning, it started giving me this issue.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings