Database scheme migrations

[m4x1m1l14n]

Hi guys.

Actually I am trying to cope with situation in which I need to apply migrations to existing database scheme in production environment. For example I need to drop PK on table which already contains data. I thought that I simply copy my idempotent migration script into docker entrypoint directory after my database creation scripts and after updating previous image, migrations gets applied somehow magically 😆 Nothing happened of course. Then I checked mariadb docker image entrypoint script and realized scripts are run only in case database is not yet created. Thus scripts in docker entrypoint directory are skipped on image update.

Is there any recommended approach how to do what I want?

Thank you very much ☺️

[grooverdan]

Reasonable idea. Happy to do something similar to /docker-entrypoint-initdb.d. A little help doing investigation on how other entrypoints for database migration schemes work in other scenarios would be appreciated.

[yosifkit]

A little help doing investigation on how other entrypoints for database migration schemes work in other scenarios would be appreciated.

For the postgres and mysql images we explicitly have not directly added an "always run" initdb.d scripts directory. I think https://github.com/docker-library/postgres/issues/1094 has a recent set of links. We instead have recommended that users extend the entypoint script (which is why we made it sourceable, https://github.com/docker-library/postgres/pull/496).

[djjeff80]

For the postgres and mysql images we explicitly have not directly added an "always run" initdb.d scripts directory. I think docker-library/postgres#1094 has a recent set of links. We instead have recommended that users extend the entypoint script (which is why we made it sourceable, docker-library/postgres#496).

Imho initial scripts that run always on docker run or docker compose up/ start would be great.

Maybe by using a command line parameter like the "--init-file" or setting a global env var. Needed functions docker_temp_server_start,docker_temp_server_stop and docker_process_init_files existing yet. It seems, it's just the call at an appropriate place inside the entrypoint script.

Or it should allow running external scripts after mariadbd is up to do some "magic".

[grooverdan]

@djjeff80 can you describe your use case a bit more. (assuming this question was yours).

Loaded question is what is "UP"? healthcheck.sh and few user applications regard a TCP connection as up (but number of option to that script show a variety of options/assumptions and options). To make /docker-entrypoint-initdb.d would imply a pre-up, in which case a shutdown and restart would be required to get back to TCP listening status (an unfortunate server limitation that I'll need a good reasoning to try to resolve).

[NiroDeveloper]

@grooverdan A feature like this would be useful to automatically migrate changes at the users.

Could have also been useful for #508 to generate the healthcheck user. Now we must continue using the mysql@localhost user or reset our production database.

[grooverdan]

@grooverdan A feature like this would be useful to automatically migrate changes at the users.

Could have also been useful for #508 to generate the healthcheck user. Now we must continue using the mysql@localhost user or reset our production database.

Quite right, I should of planned that one better. Creating users and the .my-healthcheck.cnf can be done manually. I'll look at factoring the healthcheck user out to its own function so changes/late additions can be done.

The lack of functionality in other containers is mainly about needing a two server starts every startup. I'd got some prototype design work in the server not to require this (effectively delaying the TCP connection) which can be used for upgrades and this feature. Once that is implemented this can be implemented.