Details
-
New Feature
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
Description
Hi folks,
would it be possible to implement a way to use reflink for mariabackup on filesystems which support it like btrfs and xfs?
The benefit of this woud be that, on systems where the database is installed on a filesystem with reflink-support, the backup could be done within parts of a second without the need of additional space no matter how big the database is (and if the backup-destination is on the same filesystem). On systems where the local backup is only used temporarily until it gets uploaded to a backup-store this is absolutely fine and can save a lot of I/O and time.
You can even use this to "clone" a database e.g. for testing purpouse without the need of additional space (backup a single db and restore it with a different name using cp --reflink during restore)
Attachments
Issue Links
- relates to
-
-
- Open
-
-
MDEV-34850 Unable to create backup with mariabackup: try increasing innodb_log_file_size
-
- Closed
-
- links to
Activity
Sorry, I should have searched before writing the following in MDEV-14992:
There is a Linux system call ioctl(FICLONE) (applicable to XFS, btrfs, bcachefs) as well as macOS fclonefileat() (APFS) and something for the Microsoft Windows ReFS that would allow more efficient copying of files, similar to GNU cp --reflink=auto. I think that we should consider an option to employ that for copying most files. MyRocks backups are probably best served by regular hard links.
For copying the ib_logfile0, I think that memory-mapped I/O (MDEV-34062) is the best option.
Implementation tips from marko regarding implementation in extra/mariabackup:
If we invoked copy_file_range() on the ib_logfile0, we would still have to read and parse that file in --backup. So, it might be better to invoke it for any other file only.
The datasink_struct interface would have to be refactored to allow copy_file_range.
The DS_TYPE_LOCAL would have to be replaced with copy_file_range when it is detected at compilation time.
Maybe also DS_TYPE_STDOUT and a few others could be replaced by that.
Read/write loops e.g. xtrabackup_copy_logfile with a new ds_copy_file_range, if exists, otherwise fallback.