Connection refused for my mysql using laravel

I have this fly.toml for my mysql db config

# fly.toml app configuration file generated for laravelmysql on 2023-06-28T22:22:17+03:00
#
# See https://fly.io/docs/reference/configuration/ for information about how to use this file.
#

app = "laravelmysql"
primary_region = "ams"
kill_timeout = "5s"

[build]
  image = "mysql:8.0.32"

[env]
  MYSQL_DATABASE = "some_db"
  MYSQL_USER = "non_root_user"

[processes]
  app = "--datadir /data/mysql \n  --default-authentication-plugin mysql_native_password \n  --performance-schema=OFF \n  --innodb-buffer-pool-size 64M \n  --port 3306"

[[mounts]]
  source = "mysqldata"
  destination = "/data"

and this is my laravel env I am using

DB_CONNECTION=mysql

DB_HOST=laravelmysql.internal

DB_PORT=3306

DB_DATABASE=some_db

What’s wrong ?

Hi there!

In your Dashboard, can you find the logs for your laravelmysql app and report what you see there?

Alternatively, run fly logs -a laravelmysql to see the latest logs.

There might be an error there showing the mysql instance failed to spin up.

In particular, I’m curious as to why this part has the \n characters in it - does your actual fly.toml have that all on one line, but with \n characters? Or is that just how it was copied/pasted into this forum post?

[processes]
  app = "--datadir /data/mysql \n  --default-authentication-plugin mysql_native_password \n  --performance-schema=OFF \n  --innodb-buffer-pool-size 64M \n  --port 3306"

Note also that the flags --performance-schema=OFF --innodb-buffer-pool-size 64M make MySQL 8 work in small VM’s.

If you’ve scaled the VM’s up in memory, you can remove those 2 flags and make more use of the VM’s memory (in particular --innodb-buffer-pool-size 64M will limit performance if you’ve scaled your MySQL VM up from 256m RAM).

This is my logs from laravelmysql. It’s looks ok, maybe?

Yeah I have scaled the vm and I should remove them. Thanks for the note!

I also got these \n from fly itself, I just copied the content

that DOES look pretty normal, altho I suspect fly.toml should look more like this:

…if it happens to have the \n characters actually literally in there as text (vs having newlines in reality).

But, assuming that’s actually working, it sort of feels like either:

  1. The mysql instance isn’t listening on a network (seems unlikely!)
  2. Somethings up with the networking where laravelmysql.internal isn’t doing its thing

I’m assuming the (Laravel?) application connecting to this database is ALSO hosted on Fly, within the same Fly organization - is that correct?

Yes it is, I can provide additional information

What to check ? I also feel the same, the problem with laravelmysql.internal

Can you SSH into the Laravel instance and double check the connection details? (fly ssh console)

If you head to /var/www/html and start a Tinker session, check the value of config('database') and ensure it shows the hostname you expect for the mysql connection, for example, and then check out the exact error message received back by Laravel as well.

You can also run command printenv to see the environment created to ensure the DB_* ones are set as you’d expect.

I think the url is null which cauzes the problem right,?

I moved the enviroment variables from .env to fly.toml env section and it works, hmmm that was my bad. Can i access the mysql db GUI like Godaddy and Hostinger phpmyadmin? What should I do to get it?

I think the .dockerignore file ignores the .env file when building the application into a docker image for use on fly.io, the presumption being that .env items will either be in fly.toml or set as a secret.

This assumption (presumption) is because the .env you are using locally when first deploying likely has local-dev items in it, not necessarily great for production usage.

So basically: Assume no .env file will be present!

1 Like

Can i access the mysql db GUI like Godaddy and Hostinger phpmyadmin? What should I do to get it?

So, short answer: no

Long answer: You could host an instance of phpmyadmin yourself as a separate app.

What most people are doing is using fly proxy (docs) to create a “tunnel” locally into their fly app.

So you could do something like:

fly proxy -a laravelmysql 33060

Then run a local GUI tool (such as tableplus, navicat, datagrip, dbeaver, or others) to connect to it.

Since the fly proxy opens a tunnel between your local instance and the remote mysql VM (over port 33060), you’d have your GUI tool of choice would connect via hostname / port 127.0.0.1:33060

(that’s outlined in the same docs: Use a MySQL Database · Fly Docs , and here: Laravel and Databases · Fly Docs )