entrypoint.sh: MySQL's clone plugin support and less restrictive init practice

[nickb937]

When initiating, from a slave, the clone of another server, the command CLONE INSTANCE FROM will restart mysqld on the slave.

The command fails because the Docker image runs mysqld directly rather than through the mysqld_safe wrapper and so the clone_plugin cannot restart mysqld.

The entrypoint.sh script is useful because it pre-initialises the MySQL environment. It is a handy starting point for creating MySQL Group Replication clusters on-the-fly with Kubernetes but it is a little restrictive for use.

Two issues exist:

1. The entrypoint.sh only works for mysqld and not mysqld_safe.
2. There is logic to prevent entrypoint.sh being run from another script. I cannot create a Kubernetes initContainer that runs /entrypoint.sh to initialise the DB environment

My current workaround is to run this sed script in a Kubernetes initContainer to modify entrypoint not to run mysqld upon completion and invert the _is_sourced check, I'm therefore using entrypoint.sh to initialise the environment and leaving process control to the main mysql container in the Pod.

sed -e 's/exec "$@"/###/' -e 's/ _is_sourced;/ false;/' -i /entrypoint.sh 

Suggested fix:
_main():

• support 'init' as an parameter to initialise the DB (as well as existing mysqld). I can therefore run /entrypoint.sh init from an initContainer.
• don't run exec "$@" if "$1" == "init"
• drop the _is_sourced check that wraps the call to _main().

procps is also an additional package dependency to use mysqld_safe

[yosifkit]

The entrypoint.sh only works for mysqld and not mysqld_safe.

We don't support mysqld_safe since it starts mysqld in the background (and a bunch of other stuff) and that is not what we need in the container. We use mysqld directly for simplicity and so that all args to the entrypoint become args to mysqld.

There is logic to prevent entrypoint.sh being run from another script.

This is on purpose. The interface to to the script is to either run it and let it do initialization and start mysql in the foreground (as done by default config of the Dockerfile: ./docker-entrypoint.sh mysqld); or to source it and run whichever functions are required (like #423 (comment)).

The functions not beginning with an underscore are considered the "public" interface of the script when sourcing it and so will be kept as a stable as possible (functionality, names, and arguments will be very unlikely to change). On the flip side, functions beginning with an underscore are "private" and can change at any time.

---

support 'init' as an parameter to initialise the DB (as well as existing mysqld). I can therefore run /entrypoint.sh init from an initContainer.

We've had this type of request multiple times #423, #357, MariaDB/mariadb-docker#192 and the current response is, it is possible with a custom script: #423 (comment).

And this comment:

Instead of adding every possible knob and feature, we settled on docker-library/postgres#496 (and #471). Running "initdb" scripts on every run is the type of customization we built 496 for and is basically the example in my comment.

[yosifkit]

Closing old issue.