You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 9, 2023. It is now read-only.
I'll try to make a PR for this later when I have some time. As you might have noticed I'm starting to use your tool in production so I'm currently doing a bit of bughunting by usage.
My mysql datadir in production are symlinks. E.g. /var/lib/mysql points to a mountpoint. When using autoxtrabackup --prepare the copy-back step literally moves this symlink to the tmp_dir.
Example:
root@db4:/mnt/backup# ls -ltr
total 8288
drwx------ 2 root root 16384 Dec 13 2017 lost+found
drwxr-xr-x 2 root root 4096 May 9 10:01 et_events
-rwxr-xr-x 1 root root 98 Jun 18 11:49 backup_start.sh
drwxr-xr-x 4 root root 4096 Jun 20 11:33 backups
drwxr-xr-x 3 root root 4096 Jun 26 14:00 archive
lrwxrwxrwx 1 root root 17 Jun 27 15:23 tmp -> /mnt/flash/mysql/
-rw-r--r-- 1 root root 8449837 Jun 27 15:23 autoxtrabackup.log
In /etc/bck.conf :
tmpdir=/mnt/backup/tmp
For me it would also make sense to not-move the datadir before copying back. My datadir is rather large and can better be seen as lost. Would you like me to implement an '--do-not-move-datadir' flag or so? Or a setting in bck.conf ?
Cheers,
Jasper
edit: other part of the symlink problem I just found out: copy-back creates a new dir in /var/lib/mysql. So the restore get written to my / drive. Which isn't a good idea in my case. probably a rm -rf /var/lib/mysql/* would be better instead of removing and recreating this dir.
The text was updated successfully, but these errors were encountered:
edit2: the second problem is 'solved' by changing the datadir (from /var/lib/mysql to my /mnt/whatever/mysql ) in the bck.conf.
But the move to tmp when copying-back should still be optional (enabled by default). Do you agree?
Hi @JasperAlgra,
I was waiting for years to have somebody bughunting this tool and adopting to the needs of production :)
So please continue to find some interesting things.
I agree on this that when copying-back , moving to temp directory can be optional. Currently I can't remember if tmpdir has other usage beside this.
Having option for this is not a good idea, instead please make it optional in config, change code based on this and maybe you can even add some doc info on this 👍
@ShahriyarR yes I am.. was a bit busy with work and now gone for holidays until end of aug. When I've got some spare time in sept I'll have a go at it!
Hi @ShahriyarR,
I'll try to make a PR for this later when I have some time. As you might have noticed I'm starting to use your tool in production so I'm currently doing a bit of bughunting by usage.
My mysql datadir in production are symlinks. E.g. /var/lib/mysql points to a mountpoint. When using
autoxtrabackup --prepare
the copy-back step literally moves this symlink to the tmp_dir.Example:
In /etc/bck.conf :
For me it would also make sense to not-move the datadir before copying back. My datadir is rather large and can better be seen as lost. Would you like me to implement an '--do-not-move-datadir' flag or so? Or a setting in bck.conf ?
Cheers,
Jasper
edit: other part of the symlink problem I just found out: copy-back creates a new dir in /var/lib/mysql. So the restore get written to my / drive. Which isn't a good idea in my case. probably a
rm -rf /var/lib/mysql/*
would be better instead of removing and recreating this dir.The text was updated successfully, but these errors were encountered: