The major cases for the --check-if-upgrade-is-needed are:

• MDEV-27606 - debian upgrades, which for historical reasons ran mysql_upgrade to expose new functionality to the user.
• MDEV-25670 Docker Library should run mariadb_upgrade - a very requested user feature that cannot be achieved in all the normal ways of container interaction.

Because of the current implementation the current Debian implementation would look like:

1. Start a temporary server in all the fancy ways to prevent user access, plugin initialization, excessive startup time etc (MDEV-27606 has a more complete list)
2. Run mysql_upgrade --check-if-upgrade-is-needed
3. If this returns true, probably not as already upgrade, run mysql_upgrade --upgrade-system-tables
4. shutdown temporary server
5. start real server with configured options

The container implementation would be largely the same.

The rather complicated idea of MDEV-27167 system variable deferred-networking to resolve early initialization, consistent with https://github.com/MariaDB/mariadb-docker/issues/350#issuecomment-786341072 seemed rather unpopular and I was awaiting the MDEV-27279 implementation to be able to resolve this is a scripted manner, preferably as below:

A more ideal scenario is:

1. (mariadb server is offline as starting point by default)
2. Run mysql_upgrade --check-if-upgrade-is-needed
3. if true; start temporary server; run mysql_upgrade; shutdown temporary server
4. start real server with configured options

The reasons for the mysql_upgrade to connect to the server are:

• to SELECT VERSION
• to obtain the datadir where mysql_upgrade_info can be examined

To obtain these for the purposes of mysql_upgrade --check-if-upgrade-is-needed without connecting to the server:

• mysql_upgrade has a hard baked server version
• datadir can be a mysql_upgrade option

While there is no 100% certainty that the mysql_upgrade version is the same as the mariadbd server version when connected, it always will be in the container (one version per container) and most likely in the Debian installation. Miss-use of mysql_upgrade from different server versions at the check stage can rely on the real upgrade version check to be more thorough.

Even if the --check-if-upgrade-is-need from a 10.2 is run and returns a incorrect result because the server version is 10.1, the version of the server is still checked with the mysql_upgrade is properly run (unless --skip-force is specified).

So lets re-implement mysql_upgrade --check-if-upgrade-is-needed to have a datadir option and run in an offline mode. This will prevent two mariadb server starts on every time systemd/sysv init/container entrypoint starts and account for the common of an upgrade already occurred, knowing there's a small chance of incorrect versions mismatch, and knowing the fall back version check is there.

While this doesn't strictly block MDEV-27606 or MDEV-25670 as the first double start mechanism is implemented, many users will complain if the Debian packaging/container entry-point is implemented the current way.