[MDEV-20973] Allow write operations to an InnoDB tablespace that is locked with "FLUSH TABLES ... FOR EXPORT" Created: 2019-11-04 Updated: 2023-11-30 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major |
| Reporter: | Geoff Montee (Inactive) | Assignee: | Ralf Gebhardt |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||
| 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 |
| Comments |
| Comment by Marko Mäkelä [ 2019-11-05 ] |
|
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. |