Xtrabackup: This target seems to be not prepared yet

MySQL & MariaDB Percona XtraBackup
1

Hello,

When i try to run prepare backup with xtrabackup i’m getting the below error. Any clue on this issue?

xtrabackup version 8.0.25-17 based on MySQL server 8.0.25 Linux (x86_64) (revision id: d27028b)
xtrabackup: cd to /backup1/mysql-a22-pxc-db/WEEKLY/W-33/D-1/
xtrabackup: This target seems to be not prepared yet.
Number of pools: 1

Thanks

1 Like
2

Hi @AnandaKumar_Kench , this message means you are running --prepare on a target-dir that has not been prepred yet (eg.: a full backup).
This is not an error message it’s an info, and it is the correct message you want to see while preparing a full backup.

Are you getting any errors after this?

1 Like
3

Hi @Marcelo_Altmann,

It just hangs after this “xtrabackup: This target seems to be not prepared yet.”
I don’t see any error message. Any clue to debug this pls?

Thanks

1 Like
4

Hi @AnandaKumar_Kench ,

Please run your --prepare with strace:

strace -f -s8192 -ttt -o/tmp/backup.trace xtrabackup --prepare ...

Please note there is no space after output parameter -o/tmp/backup.trace.
Then please attach /tmp/backup.trace here.

1 Like
5

@Marcelo_Altmann
backup.xtrace.txt (95.4 KB)

PFA the trace.

1 Like
6 
1629204432.087728 write(2, "Number of pools: 1\n", 19) = 19
61    1629204432.087818 stat("#clone/#status_in_progress", 0x7fff1955d3a0) = -1 ENOENT (No such file or directory)
61    1629204432.087878 openat(AT_FDCWD, "#clone/#status_error", O_RDONLY) = -1 ENOENT (No such file or directory)
61    1629204432.087954 openat(AT_FDCWD, "#clone/#replace_files", O_RDONLY) = -1 ENOENT (No such file or directory)
61    1629204432.088018 openat(AT_FDCWD, "#clone/#old_files", O_RDONLY) = -1 ENOENT (No such file or directory)
61    1629204432.088081 openat(AT_FDCWD, "#clone/#old_files", O_RDONLY) = -1 ENOENT (No such file or directory)
61    1629204432.088182 openat(AT_FDCWD, "#clone/#replace_files", O_RDONLY) = -1 ENOENT (No such file or directory)
61    1629204432.088282 openat(AT_FDCWD, "#clone/#new_files", O_RDONLY) = -1 ENOENT (No such file or directory)
61    1629204432.088426 mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f00a94a9000
61    1629204432.088552 openat(AT_FDCWD, "./xtrabackup_logfile", O_RDWR) = 3
61    1629204432.088847 fcntl(3, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}

Your backup is opening xtrabackup_logfile (redo log of backup).

Can you please leave the trace running for a few more minutes after this point and attach here again?

1 Like
7

It is not progressing further, it is stuck at this stage.

1 Like
8

It is not generating any more traces. Kindly suggest further action.

Thanks,

1 Like
9

This issue seems like you have other process locking your xtrabackup_logfile since fcntl did not return (we are missing the = return code in the end of this system call. Are you trying to prepare a target dir located on a NFS share?

1 Like
10

Yes, the backup is on NFS share. I saw other article on xtrabackup using NFS, they recommend mount NFS client with SYNC option. But in my case the database is running in K8s as stateful set. NFS volume is attached to the container using PV/PVC. We cant add any mount option to PV/PVC. Any alternate pls?

1 Like
11

Hi @Marcelo_Altmann,

I tried preparing the backup on NFS server itself, but i’m getting the below error. Attached is trace.

xtrabackup: Error: xtrabackup_init_temp_log() failed

Processing: backup.xtrace…
backup.xtrace.txt (95.4 KB)

Thanks

1 Like
12

seems like you sent the same trace as before:

backup.xtrace.txt - the one from yesterday.
backup.xtrace\ (1).txt - the one from today.

marceloaltmann@Marcelos-MacBook-Pro.local:~/Downloads$ md5 backup.xtrace.txt
MD5 (backup.xtrace.txt) = 0908adbf29de5bd47b47f6ecdf4c7aba
marceloaltmann@Marcelos-MacBook-Pro.local:~/Downloads$ md5 backup.xtrace\ \(1\).txt
MD5 (backup.xtrace (1).txt) = 0908adbf29de5bd47b47f6ecdf4c7aba
1 Like
13

Sorry, my bad. Here is the correct one.

backup.trace.txt (102.5 KB)

Thanks

1 Like
14

Xtrabackup cannot find a valid checkpoint by reading the redo log header.
Originally, you mentioned you took the backup using xtrabackup 8.0, but now seems you are using an old version 2.3 to restore it:

34273 1629349354.886755 write(2, "xtrabackup version 2.3.10 based on MySQL server 5.6.24 Linux (x86_64) (revision id: bd0d4403f36)\n", 97) = 97

Those versions are not compatible and it can explain what you are seeing:

34273 1629349354.887230 open("./xtrabackup_logfile", O_RDWR) = 3
34273 1629349354.887304 lseek(3, 0, SEEK_END) = 2560
34273 1629349354.887419 pread64(3, "\0\0\0\4\0\0\0\0\0\0\0\0\1\261\252\0xtrabkup 210819  4:43:38\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\233C\376\301\0\0\0\0\0\0\0X\0\0\0\0\1\272\216\260\0\0\0\0\1\272v\260\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\34e\5r\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0Y\0\0\0\0\1\272\221\26\0\0\0\0\1\272y\26\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\371\0L\245", 2048, 0) = 2048
34273 1629349354.887517 write(2, "xtrabackup: No valid checkpoint found.\n", 39) = 39
34273 1629349354.887593 close(3)        = 0
34273 1629349354.887704 write(2, "xtrabackup: Error: xtrabackup_init_temp_log() failed.\n", 54) = 54
34273 1629349354.888118 exit_group(1)   = ?

It doesn’t understand the 8.0 redo log format and cannot find the first checkpoint.

1 Like
15

Thank you so much. I had not noticed the version difference. The backup prepare works fine now.

Is there any workaround if i have to run prepare on DB server where NFS volume is mounted as PV/PVC. I tried exporting with SYNC on NFS server side, but it did not help. Appreciate you could provide some solutions.

1 Like