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

Allow write operations to an InnoDB tablespace that is locked with "FLUSH TABLES ... FOR EXPORT"

Details

    Description

      Currently, FLUSH TABLES ... FOR EXPORT takes a read lock on a table, and this prevents any INSERT, UPDATE, or DELETE operations from affecting the table until the lock has been released with UNLOCK TABLES.

      Some users would like to allow INSERT, UPDATE, or DELETE operations to affect a table during the export process. Would it be possible to implement this? Perhaps it could be implemented using the same kind of log used to track changes during a table rebuild with ALTER TABLE ... ALGORITHM=INPLACE? i.e. the log referred to by the innodb_online_alter_log_max_size system variable:

      https://mariadb.com/kb/en/library/innodb-system-variables/#innodb_online_alter_log_max_size

      Attachments

        Issue Links

          is part of

          New Feature - A new feature of the product, which has yet to be developed. MDEV-11658 Simpler, faster IMPORT of InnoDB tables

          • Critical - Crashes, loss of data, severe memory leak.
          • Open
          relates to

          New Feature - A new feature of the product, which has yet to be developed. MDEV-17598 InnoDB index option for per-record transaction ID

          • Major - Major loss of function.
          • Open

          Activity

            marko Marko Mäkelä added a comment -

            I am afraid that it would be very hard to implement this. It could very easily lead to starvation of the FLUSH TABLES…FOR EXPORT operation. By allowing concurrent DML, we would enable the enqueueing of more work for the purge of history. And, if any older read view exists, the progress of purge would be hindered.

            Please refer to the MDEV-11658 section “No instant EXPORT for InnoDB”.

            It could be feasible to implement a ‘copying’ variant of the export operation, which would not only copy the data file in a safe way, but also implement the “Optional offline clean-up step after EXPORT” outlined in MDEV-11658. To perform this efficiently (and to allow concurrent DML operations while we perform the copying), we would probably need MDEV-17598 for the secondary index records.

            marko Marko Mäkelä added a comment - I am afraid that it would be very hard to implement this. It could very easily lead to starvation of the FLUSH TABLES…FOR EXPORT operation. By allowing concurrent DML, we would enable the enqueueing of more work for the purge of history. And, if any older read view exists, the progress of purge would be hindered. Please refer to the MDEV-11658 section “No instant EXPORT for InnoDB”. It could be feasible to implement a ‘copying’ variant of the export operation, which would not only copy the data file in a safe way, but also implement the “Optional offline clean-up step after EXPORT” outlined in MDEV-11658 . To perform this efficiently (and to allow concurrent DML operations while we perform the copying), we would probably need MDEV-17598 for the secondary index records.

            People

              ralf.gebhardt Ralf Gebhardt
              GeoffMontee Geoff Montee (Inactive)
              Votes:
              1 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.