Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-30755

slow shutdown on uninstall

Details

    Description

      InnoDB implements various levels of "fast shutdown", from the slowest when all logs are applied to data, to the crash-like, which causes a full recovery run on the next start.

      The default is 1, "fast". But this works best if the server of exactly the same version is used for the next start.

      On upgrades the slow shutdown is the safest. Redo log format used to change between versions in the past and it has happened that after the upgrade the server was not able to start (or, worse, corrupted the data).

      In fact, it's generally safer to use a slow shutdown when the server is uninstalled. RPM/DEB before-uninstall (preun, prerm) scriptlet should always use the slowest and safest shutdown method.

      Implementation ideas:

      • set global @@innodb_fast_shutdown=0
      • SHUTDOWN SLOW
      • SIGTERM for normal shutdown, SIGQUIT for slow (and SIGKILL for fast )

      Attachments

        Issue Links

          is duplicated by

          New Feature - A new feature of the product, which has yet to be developed. MDEV-33364 pre-uninstall scriptlets should use slow innodb shutdown for upgrades

          • Major - Major loss of function.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-23755 safety for upgrades (innodb) and packaging

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            danblack Daniel Black added a comment -

            Contradicting advice: MDEV-23755

            danblack Daniel Black added a comment - Contradicting advice: MDEV-23755
            greenman Ian Gilfillan added a comment -

            Our documentation is unclear here. We used to state innodb_fast_shutdown=0 as a requirement when upgrading, but this was removed on marko's suggestion (MDEV-23755). monty has added the suggestion that fast_shutdown=0 is 'recommended' back in the docs in one location, but overall the docs don't now give a clear guideline to users. Basically, we currently state 1 is OK, but recommended is 0, which I wouldn't know what to do with.

            greenman Ian Gilfillan added a comment - Our documentation is unclear here. We used to state innodb_fast_shutdown=0 as a requirement when upgrading, but this was removed on marko 's suggestion ( MDEV-23755 ). monty has added the suggestion that fast_shutdown=0 is 'recommended' back in the docs in one location, but overall the docs don't now give a clear guideline to users. Basically, we currently state 1 is OK, but recommended is 0, which I wouldn't know what to do with.
            marko Marko Mäkelä added a comment -

            For some time, it was somewhat unclear whether it is safe to upgrade to MariaDB Server 10.3 from earlier versions after a normal shutdown. It was possible to get into trouble by playing with innodb_force_recovery=3 (MDEV-13269). Finally, in MDEV-15912 a check for that was implemented: InnoDB would refuse to start if it recovers any incomplete transactions that contain nonempty insert undo logs.

            Recently, there were some upgrade issues related to MDEV-29694, which could be worked around by executing a slow shutdown. These bugs have been fixed.

            I do not think that we should generally recommend innodb_fast_shutdown=0. In the past, a support customer got data corruption due to MDEV-29905 (in combination with MDEV-29984 or MDEV-30009).

            marko Marko Mäkelä added a comment - For some time, it was somewhat unclear whether it is safe to upgrade to MariaDB Server 10.3 from earlier versions after a normal shutdown. It was possible to get into trouble by playing with innodb_force_recovery=3 ( MDEV-13269 ). Finally, in MDEV-15912 a check for that was implemented: InnoDB would refuse to start if it recovers any incomplete transactions that contain nonempty insert undo logs. Recently, there were some upgrade issues related to MDEV-29694 , which could be worked around by executing a slow shutdown. These bugs have been fixed. I do not think that we should generally recommend innodb_fast_shutdown=0 . In the past, a support customer got data corruption due to MDEV-29905 (in combination with MDEV-29984 or MDEV-30009 ).
            marko Marko Mäkelä added a comment -

            If the motivation is to save space in the data directory, then it could make sense to execute the following before shutting down InnoDB:

            SET GLOBAL innodb_undo_log_truncate=ON, innodb_max_purge_lag_wait=0, innodb_log_file_size=4194304;

            You would not want to shrink the ib_logfile0 to its minimum size if there are any further writes to do, because it would cause excessive amount of page flushing.

            marko Marko Mäkelä added a comment - If the motivation is to save space in the data directory, then it could make sense to execute the following before shutting down InnoDB: SET GLOBAL innodb_undo_log_truncate= ON , innodb_max_purge_lag_wait=0, innodb_log_file_size=4194304; You would not want to shrink the ib_logfile0 to its minimum size if there are any further writes to do, because it would cause excessive amount of page flushing.

            People

              Unassigned Unassigned
              serg Sergei Golubchik
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.