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

Extend the RQG infrastructure for backup testing

Details

    • Task
    • Status: Stalled (View Workflow)
    • Minor
    • Resolution: Unresolved
    • None
    • Tests
    • None

    Description

      MDEV-16809 Allow full redo logging for ALTER TABLE
      MDEV-16791 mariabackup : allow consistent backup, in presence of concurrent DDL,
                            also without --lock-ddl-per-table
      point to the need to have sufficient corresponding test.
      MTR based tests could be only used for some basic coverage.
      Whereas exemplary tests are easy written and recommended to have this way cannot be
      used as main method for providing sufficient functional coverage.
      a) Developing sufficient MTR tests for mariabackup with concurrent DDL is quite costly because the amount of relevant DDL is huge.
      b) Even if a) would be cheap than running these tests frequent like as members of the
          regression tests would require too much elapsed runtime and resources (assume CPU)
      Given the fact that we already have some crowd of RQG tests checking roughly all kinds of concurrent DDL it seems to be recommended to do the following with RQG:
      - the server is under serious load by arbitrary DDL (existing YY grammars)
      - run parallel in a loop
        1. Hot backup of data of running server 1
        2. Prepare the data backed up for restore + restore to other place than server 1
        3. Start some additional server 2 on that data
        4. Run check table in server 2
        5. If no trouble during 4. shutdown of server 2 + destroy his data + run next loop round.
            If trouble terminate the test. 
      It is not 100% clear if the loop should be implemented as
      - periodic reporter (management of the server 2 might be complicated)
      - feature of the RQG runner 
      

      Attachments

        Activity

          I think it should be a reporter. There is an old reporter CloneSlaveXtrabackup, possibly it has some code or at least ideas for re-using; but of course the reporter for MariaBackup must be implemented based on the "native" server startup, not MTR-v1 as many old RQG reporters.

          Starting additional server inside a reporter is in fact fairly easy, basically you already have the server "structure", you just clone it, change the port/socket and maybe a few other instance-specific values and launch startServer as usual.

          elenst Elena Stepanova added a comment - I think it should be a reporter. There is an old reporter CloneSlaveXtrabackup, possibly it has some code or at least ideas for re-using; but of course the reporter for MariaBackup must be implemented based on the "native" server startup, not MTR-v1 as many old RQG reporters. Starting additional server inside a reporter is in fact fairly easy, basically you already have the server "structure", you just clone it, change the port/socket and maybe a few other instance-specific values and launch startServer as usual.

          Thank you for the hints. The old reporter CloneSlaveXtrabackup is indeed quite useful.

          mleich Matthias Leich added a comment - Thank you for the hints. The old reporter CloneSlaveXtrabackup is indeed quite useful.

          People

            mleich Matthias Leich
            mleich Matthias Leich
            Votes:
            0 Vote for this issue
            Watchers:
            3 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.