-
-
Notifications
You must be signed in to change notification settings - Fork 579
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ddev start
could check to see if database type matches existing database type
#3923
Comments
After update to version 1.21 i have this problem on every project. I fixed it with complete deletings and new setups. But on one project now i miss a google json file. So is there a easier way to do this Failed to restart nca-sulu: Unable to start project nca-sulu because the configured database type does not match the current actual database. Please change your database type back to and start again, export, delete, and then change configuration and start. To get back to existing type use 'ddev config --database=' and then you might want to try 'ddev debug migrate-database mariadb:10.6', see docs at https://ddev.readthedocs.io/en/latest/users/extend/database_types/ |
Maybe this helps ddev debug get-volume-db-version |
Also replace mariadb and mysql with database: still this issue |
You're in the wrong issue here. The issue is #4129 and you'll find a couple of solutions there, and also in top of the release notes, https://github.com/drud/ddev/releases/tag/v1.21.1 |
This scrip and @rfay on discord helps me https://gist.github.com/rfay/27b12e49ceb1ed1e3959c603401b7010 |
Is there an existing issue for this?
Is your feature request related to a problem? Please describe
When you change the database type in config.yaml, you may or may not be able to start the project. It tries to upgrade if possible, but
mariadb:10.3
tomysql:8.0
orpostgres:14
will never ever work.The previous version is actually stored in /var/lib/mysql/db_mariadb_version.txt, but it's hard to get at that (requires running a container with the volume mounted), so would slow down start.
But the results when somebody does a change are pretty ugly, and they have to do a
ddev logs -s db
to figure out what happened.But ddev could store away the previous version, for example in ~/.ddev/global_config.yaml like it does with
used_host_ports
:Describe the solution you'd like
Above
Describe alternatives you've considered
Mounting the db volume and looking at the file.
Additional context
No response
The text was updated successfully, but these errors were encountered: