I want to deploy a spring boot backend with a mysql database.
I deployed the mysql database as described in this guide: Use a MySQL Database · Fly Docs.
However I’m puzzled about this sentence: “Any app that needs to access the database should set the hostname and username as environment variables, and create a secret for the database password.”
As described in the guide I set this secrets: “fly secrets set MYSQL_PASSWORD=password MYSQL_ROOT_PASSWORD=password”
In my application properties I defined these variables:
In the logging I see this error:
java.sql.SQLException: Access denied for user ‘root’@‘fdaa:3:3513:a7b:16a:88da:6b43:2’ (using password: YES)
Hi… The second half of that sentence is referring exactly to the above fly secrets set invocation, and really it’s just pointing out that you’ll need to do that step at least twice (since the settings aren’t shared): once for the MySQL machine itself and then again (!) for any application that wants to connect to it. (By running that command in the directory that contains the Java application’s fly.toml file, typically, or with the -a knob.) That establishes environment variables MYSQL_PASSWORD (for the non-root user) and MYSQL_ROOT_PASSWORD.
You can check with fly secrets list -a java-app-name.
The other half of the quote is a convention, which your Java properties are an adequate substitute for—if that’s how you prefer to handle such things, .
The database is most likely configured so that you can log in as root only when you’re on localhost. (That’s how the MySQL Docker entrypoints that I’ve seen initialize it by default, anyway.)
Try MYSQL_USER—assuming you had MYSQL_DATABASE, MYSQL_USER, and the secrets all set correctly on first deploy of the MySQL machine.
So, the most orthodox recommendation would be to re-create the MySQL server, with all of those changed to recipe-app related strings (+ unique, strong passwords).
Although I don’t use Spring myself, it seems fairly inevitable that you would need either that or a more complicated intervention elsewhere; search results suggest that something along the following lines might be the path of least resistance…
(Be wary of hyphens versus underscores in identifiers, incidentally, .)
One caveat is that you probably must destroy both the existing MySQL machine and—separately and subsequently—its volume, to be confident that the magic database auto-configuration inside there will go through again.
This part of the process tends to not be as smart about change detection as other parts are. ↩︎
Thanks again for your suggestions and thinking along. Much appreciated.
Of course I did replace the default user and database name, but for reference it is easier to use the default ones
I will retry again soon with your suggestions and will let you know the result