As silly as this sounds, occasionally database servers go down.
If you are using a hosted database service, go to its console and verify that its status is Green. If you have direct access to a command line interface, log in and make sure that it is up and running and accepting queries.
It’s out of the scope of this troubleshooting guide to get your data warehouse server back up. Check with whomever set it up for you!
If you are able to access the server from a bastion host, or another machine, use nc
on Linux (or your operating system’s equivalent) to verify that you can connect to the host on a given port.
The port a data warehouse’s server software is attached to varies, but an example for a default PostgreSQL configuration (which listens on port 5432) would be:
nc -v your-db-host 5432
It’s out of the scope of this troubleshooting guide to change your network configuration. Talk to whomever is responsible for the network your data warehouse is running on.
If you’ve verified that you can connect to the host and port on the data warehouse, the next step is to check your credentials.
Again, connecting to a data warehouse depends on your database server software, but for PostgreSQL, the below uses a command line interface (psql
) to connect to your data warehouse.
psql -h HOSTNAME -p PORT -d DATABASENAME -U DATABASEUSER
If your credentials are incorrect, you should see an error message letting you know if the database name or the user/password are incorrect.
If the database name or the user/password combination are incorrect, ask the person running your data warehouse for correct credentials.
If you see the error message, “Your question took too long,” something in your setup timed out. Depending on the specifics of your deployment, this could be a timeout in:
Fixing this depends on your specific setup. Here are some potentially helpful resources:
Metabase fails to connect to your MySQL server with the error message “Looks like the username or password is incorrect”, but you are sure that the username and password is correct. You may have created the MySQL user with an allowed host other than that which you are connecting from.
For example, if the MySQL server is running in a Docker container, and your metabase
user was created with CREATE USER 'metabase'@'localhost' IDENTIFIED BY 'thepassword';
, the localhost
will be resolved to the Docker container, and not the host machine, causing access to be denied.
You can identify this issue, by looking in the Metabase server logs for the error message Access denied for user 'metabase'@'172.17.0.1' (using password: YES)
. Note the host name 172.17.0.1
(in this case a Docker network IP address), and using password: YES
at the end.
You will see the same error message when attempting to connect to the MySQL server with the command-line client: mysql -h 127.0.0.1 -u metabase -p
Recreate the MySQL user with the correct host name: CREATE USER 'metabase'@'172.17.0.1' IDENTIFIED BY 'thepassword';
. Otherwise, if necessary, a wildcard may be used for the host name: CREATE USER 'metabase'@'%' IDENTIFIED BY 'thepassword';
That user’s permissions will need to be set:
GRANT SELECT ON targetdb.* TO 'metabase'@'172.17.0.1';
FLUSH PRIVILEGES;
Remember to DROP USER 'metabase'@'localhost';
the old user.
Metabase fails to connect to your data warehouse and the Metabase server logs include the error message Connections cannot be acquired from the underlying database!
Navigate to the options for your data warehouse and locate the Additional JDBC Connection Strings option, then add trustServerCertificate=true
as an additional string.