Can't connect to local MySQL server through socket

[ghost]

I’ve just received an error message while trying to connect to my databases through Sequel Pro. I’ve not had this happen before today.

Unable to connect via the socket, or the request timed out.

Double-check that the socket path is correct and that you have the 
necessary privileges, and that the server is running.

MySQL said: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

I’ve been trying to find an answer for the better part of an hour and I can’t find a solution. Worst timing too as I have a deadline on a project tomorrow morning.

Does anyone know what the issue could be? Any suggestions?

Thanks!

[allrude]

Try running valet install with the option --with-mariadb,
I couldn't get it working too, but with MariaDB it works

[ghost]

Maybe I entered the option wrong, but I received this:

The "--with-mariadb" option does not exist.

This is an issue with MySQL directly, not Valet. I’m getting the same error message regarding sockets when I try to connect via the Terminal too.

[allrude]

$ valet install --with-mariadb

[scottzirkel]

Same issue, not sure what happened. I had updated brew, but I didn't see anything related to msyql in the update.

[drbyte]

If the .sock file isn't created, then the service isn't running ... which means either you've not started it or configured it to start, or it's running into problems when trying to start.

Unlikely to be a Valet issue specifically, since Valet doesn't do anything fancy with MySQL/MariaDB.

Probably best to inspect your MySQL error log to understand why MySQL/MariaDB are failing to start.
The log file is probably: /usr/local/var/mysql/(something).err

[ghost]

@drbyte You’re right. Nothing to do with Valet so I’ll close this issue. It’s because of a problem with MySQL 8.0.11. The only solution for me was to roll back to 5.7.

[OZZlE]

My issue was this :S https://www.basezap.com/innodb-check-that-you-do-not-already-have-another-mysqld-process-using-the-same-innodb-data-or-log-files/

solution was to kill all mysql processes (and start them again - it started automatically for me).