Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5
-
None
-
Linux, x86_64
Description
On executing of
mariabackup --move-back --target-dir=.
|
mariabackup deletes the current sourcefile after an "No space left on device" error before exiting. Only the incomplete target file is still available.
[01] 2021-03-22 16:33:28 Moving ./interactive@002dcreator_log/campaign__event#P#future.ibd to /var/lib/mysql/interactive@002dcreator_log/campaign__event#P#future.ibd
|
[01] 2021-03-22 16:33:28 Copying ./interactive@002dcreator_log/campaign__event#P#future.ibd to /var/lib/mysql/interactive@002dcreator_log/campaign__event#P#future.ibd
|
mariabackup: Error writing file '/var/lib/mysql/interactive@002dcreator_log/campaign__event#P#future.ibd' (errno: 28 "No space left on device")
|
[01] 2021-03-22 16:43:08 Error: copy_file() failed.
|
[01] 2021-03-22 16:43:08 Removing ./interactive@002dcreator_log/campaign__event#P#future.ibd
|
After this the prepared backup is useless as at least one file is missing/incomplete.
mariabackup should delete the incomplete target file instead and allow a re-run of the process to complete the restore.
Also mariabackup should try to use a native filesystem move if on same filesystem instead of a copy/delete cycle to reduce required disk space during the restore step and the option --move-back.
Attachments
Activity
Hi @Vladislav Vaintroub, it was just a guess as mariabackup always writes a cycle of
- Moving FileA to FileATarget
- Copying FileA to FileATarget
- Removing FileA
into the output. Also it requires several minutes in the copied example to copy the file. The prepared source file has approx 400GB and there were 120GB free on the device. So i have expected a real copy of the file as the source for the error (as written to the log). A rename() shouldn't require any additional space and also should happen in near to no time as just some directory informations are rewritten not the data itself. I don't know if it is relevant that i use BTRFS.
In the meantime i have replaced the disk in my development system so i have enough space to hold the prepared and the restored database for testing purposes.
o.friedrich, I'm wondering what made you think that move-back is not optimized to move within the same filesystem.
According to my reading of source code it is. If you think it was not, can you provide strace output of mariabackup, apparently interesting is the rename() system call.