Hi,
I try to make a backup for my MYSQL Server which runs in Windows 10, I’ve installed debian using WSL2 on same machine but I keep getting the same error.
My MySQL version is 5.7.27
and I use this: xtrabackup version 2.4.24 based on MySQL server 5.7.35 Linux (x86_64) (revision id: b4ee263)
and the following is my error:
root@DESKTOP-RU61JK7:/mnt/c/Users/MRC# xtrabackup --backup --datadir=“/mnt/c/mysql/data/” --target-dir=“/mnt/c/backup/” --no-timestamp --parallel=4 --user=backup --password=1234 -H 192.168.1.132
xtrabackup: recognized server arguments: --datadir=/mnt/c/mysql/data/ --parallel=4
xtrabackup: recognized client arguments: --backup=1 --target-dir=/mnt/c/backup/ --user=backup --password=* --host=192.168.1.132
220204 17:47:55 version_check Connecting to MySQL server with DSN ‘dbi:mysql:;mysql_read_default_group=xtrabackup;host=192.168.1.132’ as ‘backup’ (using password: YES).
220204 17:47:55 version_check Connected to MySQL server
220204 17:47:55 version_check Executing a version check against the server…
220204 17:47:55 version_check Done.
220204 17:47:55 Connecting to MySQL server host: 192.168.1.132, user: backup, password: set, port: not set, socket: not set
Using server version 5.7.27
Warning: MySQL variable ‘datadir’ points to nonexistent directory 'C:\mysql\data'
Warning: option ‘datadir’ has different values:
‘/mnt/c/mysql/data/’ in defaults file
'C:\mysql\data' in SHOW VARIABLES
xtrabackup version 2.4.24 based on MySQL server 5.7.35 Linux (x86_64) (revision id: b4ee263)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /mnt/c/mysql/data/
xtrabackup: open files limit requested 0, set to 1024
xtrabackup: using the following InnoDB configuration:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 268435456
InnoDB: Number of pools: 1
220204 17:47:55 >> log scanned up to (5724105)
2022-02-04 17:47:56 0x7f01d8943740 InnoDB: Assertion failure in thread 139645905286976 in file srv0start.cc line 936
InnoDB: Failing assertion: dir
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: MySQL :: MySQL 5.7 Reference Manual :: 14.22.2 Forcing InnoDB Recovery
InnoDB: about forcing recovery.
14:47:56 UTC - xtrabackup got signal 6 ;
This could be because you hit a bug or data is corrupted.
This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong…
stack_bottom = 0 thread_stack 0x10000
xtrabackup(my_print_stacktrace+0x3b)[0x56029e5e9f1b]
xtrabackup(handle_fatal_signal+0x285)[0x56029e2a53f5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7f01d85240c0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7f01d6075fff]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f01d607742a]
xtrabackup(+0x5667e6)[0x56029df667e6]
xtrabackup(_Z25srv_undo_tablespaces_initbbmPm+0x1281)[0x56029e391991]
xtrabackup(_Z22xtrabackup_backup_funcv+0x1866)[0x56029df8dd96]
xtrabackup(main+0xf23)[0x56029df6f693]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f01d60632e1]
xtrabackup(_start+0x2a)[0x56029df841aa]
Unfortunately we don’t support Windows and don’t provide packages for this platform.
My recommendation is that you provision a Linux-only host and try to reproduce your workload, and if you hit the same error we will be in a position to assist you. Best of luck!
Xtrabackup takes backups by copying actual files on disk. You would need to map your datadir into your Linux environment. As Michael said, this is not supported, even though others have accomplished this.
@sodith
In theory it should work, but as other mentioned this is not supported platform, so we do not test it regularly.
First that comes to mind is to make sure you have enough permissions for
both --datadir=“/mnt/c/mysql/data/” --target-dir=“/mnt/c/backup/” directories.
Another thing that caught my attention:
it may happen that xtrabackup is still trying to do something with “C:\mysql\data” which is not accessible from WSL
Yeah I saw those warnings but it looks like xtrabackup just kept continue untill it throws an error, any way to get more details about this failed assertion for dir?
I’m literally using MySQL in the very default way possible, nothing different or special. Thinking of, maybe that is the problem, I should’ve configured some settings maybe
Update: I’ve checked the file on 5.7.27 over here
there is a method call to “fil_set_max_space_id_if_bigger” I’ll check that one out
Hello @sodith,
As it has been said by a couple times above, Windows is not a supported platform. You need to make sure all directories are mounted and permissions are good and path parameters are correct. Good luck!
Hello Matthew,
You say it’s not supported but the only problem left is that percona is taking the data directory from mysql. If I only can provide and skip that phase it will work… The problem is when percona takes that value from mysql server, mysql gives a windows path…
I have also encountered this problem, and finally resolved, hope to be able to help you and other people like us
The innodb_undo_directory variable defines the location of undo tablespace files. If the innodb_undo_directory variable is undefined, undo tablespaces reside in the data directory.
set the innodb_undo_directory = /mnt/c/mysql/data/ in new file named xtrabackup.ini ,the content like this