Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.1(EOL)
-
None
Description
Outdated notes from zulip chat with marko;
Regarding package upgrades:
- upgrade from 10.2 or earlier should use innodb_fast_shutdown=0 (or better, SET GLOBAL innodb_max_purge_lag_wait=0, implemented in
MDEV-16952) to avoid hittingMDEV-15912to implement in rpm/deb packaging scripts.
Update by marko:
MDEV-15912 was fixed by refusing to start up InnoDB in case the pre-10.3 format undo logs are not empty. It turns out that a clean shutdown (innodb_fast_shutdown=1) always guaranteed this; in some upgrade tests we had to jump through hoops to end up with nonempty undo logs and empty redo log. With MariaDB (thanks to MDEV-12289) there should never have been a need to issue a slow shutdown (innodb_fast_shutdown=0) before upgrading.
Attachments
Issue Links
- relates to
-
MDEV-23321 debian upgrade shouldn't start previously stopped services
-
- Open
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Open
-
-
MDEV-33364 pre-uninstall scriptlets should use slow innodb shutdown for upgrades
-
- Closed
-
Activity
danblack, I hope that you can review our upgrade scripts that they correspond to what I suggested here and in MDEV-25793.
I think that it would be nice to ensure that ‘failure is an option’. First, if the server hangs on shutdown, or if some incompatible option (such as innodb_force_recovery) was in effect, maybe the upgrade script should abort just there. Ultimately, it is the upgraded server’s duty to perform further consistency checks and refuse startup if appropriate.
Should the upgraded server fail to start up, then I think that manual intervention by the system administrator will be needed: For example, install an old version of the server again and try to perform a proper shutdown. I do not think that we should attempt to implement rollback to an older version.
Note illuusio that among the 17 comments in this issue there is a prototype in https://jira.mariadb.org/browse/MDEV-23755?focusedCommentId=188808&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-188808 - you don't need to start from scratch on this one.
otto As commented in Pull and reading what 'innodb_max_purge_lag_wait' should do I'm favor to believe that it's not actually needed as it but then if it doesn't make problem worse then extra care problems like this is not bad thing.
It should be enough to wait clean shutdown with mariadb-admin or does it just sigkill process?
Just reading comments and is there good way to hit this problem. Create database on 10.2 (or below) with client write to it then kill it when there is load and then upgrade to 10.3 and try to start?
MDEV-15912is now fixed, and InnoDB will refuse to start up if the data directory is from an earlier version than MariaDB 10.3 that had not been shut down in a clean fashion. Hence, we now should have a reliable post-upgrade check that will prevent bad things from happening. But we still need a pre-upgrade check for smooth upgrades from 10.2 or earlier. I genuinely do not know if this needs to be addressed by packaging, or whether documenting this should be enough. Maybe the current scripts in (say) Debian are adequate for the masses who might be running a mostly idle instance of MariaDB. Those who are hosting valuable data should think twice before blindly executing something like sudo apt dist-upgrade.