wsrep_sst_xtrabackup-v2 does not support innodb_data_home_dir

innodb_data_home_dir=/innodbdata

160906 16:03:31 innobackupex: Starting the backup operation

IMPORTANT: Please check that the backup run completes successfully.

           At the end of a successful backup run innobackupex

           prints "completed OK!".

160906 16:03:31 Connecting to MySQL server host: localhost, user: backup, password: set, port: 0, socket: /var/lib/mysql/mysql.sock

Using server version 10.1.16-MariaDB

innobackupex version 2.3.3 based on MySQL server 5.6.24 Linux (x86_64) (revision id: 525ca7d)

xtrabackup: uses posix_fadvise().

xtrabackup: cd to /var/lib/mysql/

xtrabackup: open files limit requested 0, set to 16364

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 = 50331648

160906 16:03:31 >> log scanned up to (44011183)

2016-09-06 16:03:31 7f48af035740  InnoDB: Operating system error number 2 in a file operation.

InnoDB: The error means the system cannot find the path specified.

InnoDB: File ./ibdata1: 'open' returned OS error 71. Cannot continue operation

2016-09-06 16:03:31 7f48af035740  InnoDB: Assertion failure in thread 139950150604608 in file os0file.cc line 658

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: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html

InnoDB: about forcing recovery.

20:03:31 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.

We will try our best to scrape up some info that will hopefully help

diagnose the problem, but since we have already crashed,

something is definitely wrong and this may 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

innobackupex(my_print_stacktrace+0x2e) [0x96c7be]

innobackupex(handle_fatal_signal+0x262) [0x84cbc2]

/lib64/libpthread.so.0(+0xf100) [0x7f48aec17100]

/lib64/libc.so.6(gsignal+0x37) [0x7f48ad3815f7]

/lib64/libc.so.6(abort+0x148) [0x7f48ad382ce8]

innobackupex(os_file_create_func(char const*, unsigned long, unsigned long, unsigned long, unsigned long*)+0x46c) [0x6a386c]

innobackupex(open_or_create_data_files(unsigned long*, unsigned long*, unsigned long*, unsigned long*)+0x3b2) [0x706b52]

innobackupex() [0x59464c]

innobackupex(xtrabackup_backup_func()+0x9a4) [0x599cc4]

innobackupex(main+0x9a2) [0x57dd92]

/lib64/libc.so.6(__libc_start_main+0xf5) [0x7f48ad36db15]

innobackupex() [0x591bfd]

Please report a bug at https://bugs.launchpad.net/percona-xtrabackup