Manually increasing the test timeout passes these tests
And the feature:
As this is quite an extensive change MARIADB_AUTO_UPGRADE=1 is
required to opt into the auto upgrade. If may eventually change if
this proves stable and based on user feedback and might change to
on by default.
Per the mysql_upgrade documentation
(https://mariadb.com/kb/en/mysql_upgrade/) we take a backup and leave
this in the datadir. This backup can be disabled with
MARIADB_DISABLE_UPGRADE_BACKUP=1.
The upgrade process requires the entrypoint to start the server
before being available to the use users (for reasons below).
The upgrade will only upgrade-system-tables as highighted in
350, a large set of user database can slow the update process
Because the root password may not be known to the entrypoint
(random or removed users), the temporary server is started in
--skip-grant-tables manner to avoid this contraint.
Background information:
MDEV-27068 showed the dangers of running two mysql_upgrades in
parallel.
MDEV-14622 and MDEV-27107 showed two deadlock cases with myql_upgrade
and the spider engine, and its still unknown if create/drop procedure
or create (udf) function will conflict if started from a user connection
instead of a plugin. As there are a few other user features that
depend on a stable set of system tables, a pre-start upgrade is
performed.
Some small hacks of ensuring the mysql_upgrade_info file is populated
is done in anticipation of upstream features being implementing
including:
With MDEV-27279, mariadb_upgrade added --check-if-upgrade-is-needed
we can test if an upgrade is needed. Unfortunately its not offline
yet (MDEV-27636) and requires the start of the server. As such for now
we do our own version checks based on mysql_upgrade_info.
MDEV-27607: mysql_install_db to install mysql_upgrade_info
should facilitate the avoiding of upgrades been needed on the first
installed. _mariadb_fake_upgrade_info function is anticipated to be
removed and likewise for the || true on mysql_upgrade.
The debian/ubuntu packaging component, MDEV-27068 I hope is going
to leave a set of config parameters for safe upgrades requiring a
small patch like:
Test failures here are timezone timeouts which are fix in the up coming release - https://github.com/MariaDB/server/commit/6b4f0d782c973bd49ad62a67add36d4773852c3a
Manually increasing the test timeout passes these tests
And the feature:
As this is quite an extensive change MARIADB_AUTO_UPGRADE=1 is required to opt into the auto upgrade. If may eventually change if this proves stable and based on user feedback and might change to on by default.
Per the mysql_upgrade documentation (https://mariadb.com/kb/en/mysql_upgrade/) we take a backup and leave this in the datadir. This backup can be disabled with MARIADB_DISABLE_UPGRADE_BACKUP=1.
The upgrade process requires the entrypoint to start the server before being available to the use users (for reasons below).
The upgrade will only upgrade-system-tables as highighted in
350, a large set of user database can slow the update process
by hours. From feedback in (https://jira.mariadb.org/browse/MDEV-27068?focusedCommentId=208660&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-208660) it appears this will rarely if ever be required.
Because the root password may not be known to the entrypoint (random or removed users), the temporary server is started in --skip-grant-tables manner to avoid this contraint.
Background information:
MDEV-27068 showed the dangers of running two mysql_upgrades in parallel.
MDEV-14622 and MDEV-27107 showed two deadlock cases with myql_upgrade and the spider engine, and its still unknown if create/drop procedure or create (udf) function will conflict if started from a user connection instead of a plugin. As there are a few other user features that depend on a stable set of system tables, a pre-start upgrade is performed.
Some small hacks of ensuring the mysql_upgrade_info file is populated is done in anticipation of upstream features being implementing including:
With MDEV-27279, mariadb_upgrade added --check-if-upgrade-is-needed we can test if an upgrade is needed. Unfortunately its not offline yet (MDEV-27636) and requires the start of the server. As such for now we do our own version checks based on mysql_upgrade_info.
MDEV-27607: mysql_install_db to install mysql_upgrade_info should facilitate the avoiding of upgrades been needed on the first installed. _mariadb_fake_upgrade_info function is anticipated to be removed and likewise for the || true on mysql_upgrade.
The debian/ubuntu packaging component, MDEV-27068 I hope is going to leave a set of config parameters for safe upgrades requiring a small patch like:
--- a/docker-entrypoint.sh +++ b/docker-entrypoint.sh @@ -424,6 +424,10 @@ docker_mariadb_upgrade() { return 0 fi mysql_note "Starting temporary server"
Closes #350