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

Upgrade testing between major versions in MTR

Details

    • Task
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Fixed
    • 10.5.4
    • Tests
    • None

    Description

      It would be good to ensure in MTR that mysql_upgrade works from any recent version of MariaDB.

      The task would be to add an upgrade tests to MTR that checks that one can run mysql_upgrade on any version of MariaDB, starting from 5.5, to the current version.
      For example, MariaDB 10.5, should run upgrade test on mysql database tables that comes from
      5.5, 10.0, 10.1, 10.2, 10.3 and 10.4.

      The main focus here is to ensure that mysql_upgrade works, not that database on disk format is compatible (it should be, but that is another problem not covered by this task).

      One suggestion of how to do this is having in the mtr suite, mysqldump's of all the previous versions of the mysql database and check that one can run mysql_upgrade on all of these.

      Attachments

        Activity

          This would be great. Currently when it is missing I have had to build my own Salsa-CI pipelines to ensure upgrades work:
          https://salsa.debian.org/mariadb-team/mariadb-server/pipelines/125324

          Naturally my pipelines also cover the Debian packaging scripts, but having in MTR coverage for the mysql_upgrade itself across all the situations would be great and help fix issues at the root when they appear.

          It would also be nice if there was testing from MySQL 5.5, 5.6 and 5.7 upgrades.

          otto Otto Kekäläinen added a comment - This would be great. Currently when it is missing I have had to build my own Salsa-CI pipelines to ensure upgrades work: https://salsa.debian.org/mariadb-team/mariadb-server/pipelines/125324 Naturally my pipelines also cover the Debian packaging scripts, but having in MTR coverage for the mysql_upgrade itself across all the situations would be great and help fix issues at the root when they appear. It would also be nice if there was testing from MySQL 5.5, 5.6 and 5.7 upgrades.

          otto, this task has absolutely nothing to do with packaging.

          elenst Elena Stepanova added a comment - otto , this task has absolutely nothing to do with packaging.

          Yes, I know this was not about packaging, I was just saying it would be very useful to have something like this and my supportive motivations for it.

          This does tangent packaging however, since when current mtr/buildbot does not cover this at the moment, issues in mysql_upgrade surface at a very late stage when I do packaing updates and bump into mysql_upgrade or other upgrade issues.

          For example https://github.com/MariaDB/server/commit/c1bdf62452139e9310d3234266802748ba4c74b8 is not a change in packaging but I ended up doing it because I noticed it while doing packaging and it had not been noted before.

          otto Otto Kekäläinen added a comment - Yes, I know this was not about packaging, I was just saying it would be very useful to have something like this and my supportive motivations for it. This does tangent packaging however, since when current mtr/buildbot does not cover this at the moment, issues in mysql_upgrade surface at a very late stage when I do packaing updates and bump into mysql_upgrade or other upgrade issues. For example https://github.com/MariaDB/server/commit/c1bdf62452139e9310d3234266802748ba4c74b8 is not a change in packaging but I ended up doing it because I noticed it while doing packaging and it had not been noted before.

          Dumps were pre-created with 5.5.68, 10.0.38, 10.1.45, 10.2.32, 10.3.23, 10.4.13 versions (latest released as of now), by bootstrapping the binary tarball and then running mysqldump mysql.
          On 10.4, before running mysqldump the local user (automatically created upon bootstrap) was dropped, and password authentication was added to the local root (for MTR convenience and to make the dump usable for Windows).

          The test logic was added to main.mysql_upgrade after the end of4 tests. For each of 5.5, 10.[0-4] dump, it

          • stores the current contents of mysql database;
          • loads a pre-created dump from a previous version;
          • runs mysql_upgrade;
          • checks that mysql.user is accessible and returns some data;
          • checks that mysql_upgrade_info was created;
          • restores the earlier preserved contents of mysql schema.

          It masks one expected warning in the error log, related to InnoDB stat tables. Unexpected ones will be discovered upon MTR's post-testcase check.

          Additionally the logic contains a workaround for MDEV-22127 which is still open at the moment. As suggested to users in the comments, it runs

          DROP TABLE IF EXISTS `mysql`.`global_priv`;
          DROP VIEW IF EXISTS `mysql`.`user`;
          

          It can be removed later conditionally for 10.1+ when the bug is fixed and dumps can be re-created.

          elenst Elena Stepanova added a comment - Dumps were pre-created with 5.5.68, 10.0.38, 10.1.45, 10.2.32, 10.3.23, 10.4.13 versions (latest released as of now), by bootstrapping the binary tarball and then running mysqldump mysql . On 10.4, before running mysqldump the local user (automatically created upon bootstrap) was dropped, and password authentication was added to the local root (for MTR convenience and to make the dump usable for Windows). The test logic was added to main.mysql_upgrade after the end of4 tests. For each of 5.5, 10. [0-4] dump, it stores the current contents of mysql database; loads a pre-created dump from a previous version; runs mysql_upgrade ; checks that mysql.user is accessible and returns some data; checks that mysql_upgrade_info was created; restores the earlier preserved contents of mysql schema. It masks one expected warning in the error log, related to InnoDB stat tables. Unexpected ones will be discovered upon MTR's post-testcase check. Additionally the logic contains a workaround for MDEV-22127 which is still open at the moment. As suggested to users in the comments, it runs DROP TABLE IF EXISTS `mysql`.`global_priv`; DROP VIEW IF EXISTS `mysql`.` user `; It can be removed later conditionally for 10.1+ when the bug is fixed and dumps can be re-created.

          People

            elenst Elena Stepanova
            monty Michael Widenius
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

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