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

Fixing debian to only run the full mysql_upgrade process when necessary



    • Bug
    • Status: Stalled (View Workflow)
    • Major
    • Resolution: Unresolved
    • None
    • 10.5
    • None
    • None


      On Debian, the mariadb_upgrade process is run at every start/reboot of the mariadb-server.

      This is problematic because:

      • most of the time it's not needed;
      • if maria_upgrade has to be run, as in case of a major upgrade, then check and possible fix of tables can take from a few seconds to 20-30 seconds (normally) but potentially much longer if there is was a change in a character collation;
      • If during this time another maria_upgrade is run then it is very likely that mariadb_upgrade will hang because of unexpected conflicts. This is because maria_upgrade was not designed to be run in parallel (should now be fixed by MDEV-27279);
      • If anyone else connects to mysqld/mariadbd during maria_upgrade, bad things can happen as the tables are not up to date for the system. The possible problems are hangs or wrong data from selects or errors from table updates (as the indexes may not be up to date).

      Here are some questions summarized from MDEV-27068:

      • how to integrate this in a many packages upgrade scenario?
      • what is the right moment to run the mariadb_upgrade (post-install script, startup/restart), if needed?
      • should we split system tables upgrade (quick) and the rest of the tables upgrade (can be very long)?
      • is this feasible with systemd directives (man systemd.directives) or should a script handle alone the whole process?
      • what about sysv init?


        Issue Links



              faust Faustin Lammler
              faust Faustin Lammler
              0 Vote for this issue
              7 Start watching this issue



                Git Integration

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