Recently, my Homebrew MySQL setup started failing when trying to start up. When I run mysql.server start, I get the following error:
$ mysql.server start
Starting MySQL
.. ERROR! The server quit without updating PID file (/opt/homebrew/var/mysql/MacBookPro.pid).
Here are the logs from /opt/homebrew/var/mysql/${computer_name}.err:
2025-01-01T22:08:13.6NZ mysqld_safe Logging to '/opt/homebrew/var/mysql/MacBookPro.err'.
2025-01-01T22:08:13.6NZ mysqld_safe Starting mysqld daemon with databases from /opt/homebrew/var/mysql
2025-01-01T22:08:13.378645Z 0 [System] [MY-015015] [Server] MySQL Server - start.
2025-01-01T22:08:13.521513Z 0 [System] [MY-010116] [Server] /opt/homebrew/opt/mysql/bin/mysqld (mysqld 9.0.1) starting as process 40612
2025-01-01T22:08:13.522727Z 0 [Warning] [MY-010159] [Server] Setting lower_case_table_names=2 because file system for /opt/homebrew/var/mysql/ is case insensitive
2025-01-01T22:08:13.536732Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2025-01-01T22:08:13.583485Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2025-01-01T22:08:13.716166Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2025-01-01T22:08:13.716195Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2025-01-01T22:08:13.719572Z 0 [ERROR] [MY-000067] [Server] unknown variable 'default_authentication_plugin=mysql_native_password'.
2025-01-01T22:08:13.720023Z 0 [ERROR] [MY-010119] [Server] Aborting
2025-01-01T22:08:14.884732Z 0 [System] [MY-010910] [Server] /opt/homebrew/opt/mysql/bin/mysqld: Shutdown complete (mysqld 9.0.1) Homebrew.
2025-01-01T22:08:14.884778Z 0 [System] [MY-015016] [Server] MySQL Server - end.
2025-01-01T22:08:14.6NZ mysqld_safe mysqld from pid file /opt/homebrew/var/mysql/MacBookPro.pid ended
What is interesting is the following line, which seems it might be the issue:
2025-01-01T22:08:13.719572Z 0 [ERROR] [MY-000067] [Server] unknown variable 'default_authentication_plugin=mysql_native_password'.
Here is my.cnf:
# Default Homebrew MySQL server config
[mysqld]
default_authentication_plugin= mysql_native_password
# Only allow connections from localhost
bind-address = 127.0.0.1
mysqlx-bind-address = 127.0.0.1
Another data point is that if I run mysql.server stop, I get this error:
$ mysql.server stop
ERROR! MySQL server PID file could not be found!
Here is my MySQL version:
$ mysql --version
mysql Ver 9.0.1 for macos15.1 on arm64 (Homebrew)
I am running macOS Sequoia 15.2 on an M1 MacBook Pro.
There are a number of similar posts, but none of them seem to help. I would also rather not delete my database and start over if possible.
Does anyone know what might be causing this and how to fix it? Could this be MySQL 9 not supporting default_authentication_plugin=mysql_native_password?
I ran into something similar on my own setup. The key is that your version of MySQL doesn’t recognize the default_authentication_plugin=mysql_native_password line in my.cnf. MySQL 8 used that parameter, but in MySQL 9, it seems to have changed or been removed.
The easiest way to fix this is to open up /opt/homebrew/etc/my.cnf (or wherever your my.cnf lives), remove or comment out the default_authentication_plugin line, then try starting MySQL again. You could also explicitly set it to whatever plugin is officially supported by MySQL 9 (caching_sha2_password is the typical default now), but a quick test is to just comment out that line and see if MySQL starts up cleanly.
If that doesn’t work, make sure you’re using the same version of MySQL across the board—Homebrew can occasionally leave remnants of older MySQL installs. It might help to do something like:
brew update && brew upgrade
brew unlink mysql && brew link mysql
Then ensure the symlinks are set for the right version. If MySQL still refuses to start, you could try moving your data directory (the /opt/homebrew/var/mysql folder) out of the way temporarily, letting MySQL re-initialize a new data directory, then bringing your data back. But more often than not, simply removing or updating the default_authentication_plugin line fixes the crash-on-startup issue.