[MDEV-12108] mariabackup doesn't handle table's DATA DIRECTORY clause - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Affects Version/s: 10.1.22, 10.1.25, 10.2.7
Fix Version/s: 10.1.29, 10.2.11
Component/s: Backup
Labels:
None

Sprint:
10.2.10, 10.1.29

Description

Observed new xtrabackup crash during prepare in bb-10.1-wlad-xtrabackup after recent merge (I have strong consideration that it didn't crash in source code from ~December).

InnoDB: Tablespaces for test/test#P#p2 have been found in two places;

Location 1: SpaceID: 6  LSN: 0  File: ./test/test#P#p2.ibd

Location 2: SpaceID: 6  LSN: 0  File: /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/partitdata/test/test#P#p2.ibd

You must delete one of them.

170222  9:24:34 [ERROR] mysqld got signal 6 ;

...

/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(my_print_stacktrace+0x29)[0x55f6d8034149]

/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(handle_fatal_signal+0x3ad)[0x55f6d7c1cfed]

/lib/x86_64-linux-gnu/libpthread.so.0(+0x11630)[0x7fc71f7e6630]

/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x9f)[0x7fc71dc767ef]

/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fc71dc783ea]

/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(+0x847204)[0x55f6d7eb7204]

/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(+0x8ce1b4)[0x55f6d7f3e1b4]

mysys/stacktrace.c:268(my_print_stacktrace)[0x55f6d7f42d11]

sql/signal_handler.cc:168(handle_fatal_signal)[0x55f6d7f437a4]

log/log0recv.cc:3088(recv_init_crash_recovery())[0x55f6d7f43e9a]

srv/srv0start.cc:2529(innobase_start_or_create_for_mysql())[0x55f6d7fbf3f6]

xtrabackup/xtrabackup.cc:1842(innodb_init())[0x55f6d79d857d]

xtrabackup/xtrabackup.cc:6336(xtrabackup_prepare_func)[0x55f6d79e4ffc]

/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fc71dc613f1]

/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(_start+0x2a)[0x55f6d79f893a]

Please note that indeed .ibd file exists in both places, just it is probably valid situation as one of places is actual original .ibd referenced by .isl inside backup:

$ find ~/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/ | grep p2.i

/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/log/xtrabackup.partition_data_external/mysqld.1/data/test/test#P#p2.isl

/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/backup/test/test#P#p2.ibd

/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/backup/test/test#P#p2.isl

/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/partitdata/test/test#P#p2.ibd

Test case run with :

perl mysql-test-run.pl --mysqld="--partition" partition_data_external.test

$ cat ../mysql-test/suite/xtrabackup/partition_data_external.test

let $targetdir=$MYSQLTEST_VARDIR/backup;

mkdir $targetdir;

mkdir $MYSQLTEST_VARDIR/partitdata;

eval CREATE TABLE test (

  a int(11) DEFAULT NULL

) ENGINE=InnoDB DEFAULT CHARSET=latin1

PARTITION BY RANGE (a)

(PARTITION p0 VALUES LESS THAN (100),

 PARTITION P1 VALUES LESS THAN (200),

 PARTITION p2 VALUES LESS THAN (300)

   DATA DIRECTORY = "$MYSQLTEST_VARDIR/partitdata",

 PARTITION p3 VALUES LESS THAN (400)

   DATA DIRECTORY = "$MYSQLTEST_VARDIR/partitdata",

 PARTITION p4 VALUES LESS THAN MAXVALUE);

INSERT INTO test VALUES (1), (101), (201), (301), (401);

exec $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf  --backup  --target-dir=$targetdir;

exec $XTRABACKUP --prepare --target-dir=$targetdir;

DROP TABLE t;

rmdir $targetdir;

rmdir $MYSQLTEST_VARDIR/partitdata;

Attachments

- Sort By Name
- Sort By Date
- Ascending
- Descending
- Thumbnails
- List
- Download All

mtr.log
29 kB
2017-02-22 08:55

Activity

Ascending order - Click to sort in descending order

Andrii Nikitin (Inactive) created issue - 2017-02-22 08:51

Andrii Nikitin (Inactive) made changes - 2017-02-22 08:52

Field	Original Value	New Value
Description	Observed new xtrabackup crash during prepare in bb-10.1-wlad-xtrabackup after recent merge (I have strong consideration that it didn't crash in source code from ~December). {noformat} InnoDB: Tablespaces for test/test#P#p2 have been found in two places; Location 1: SpaceID: 6 LSN: 0 File: ./test/test#P#p2.ibd Location 2: SpaceID: 6 LSN: 0 File: /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/partitdata/test/test#P#p2.ibd You must delete one of them. 170222 9:24:34 [ERROR] mysqld got signal 6 ; ... /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(my_print_stacktrace+0x29)[0x55f6d8034149] /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(handle_fatal_signal+0x3ad)[0x55f6d7c1cfed] /lib/x86_64-linux-gnu/libpthread.so.0(+0x11630)[0x7fc71f7e6630] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x9f)[0x7fc71dc767ef] /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fc71dc783ea] /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(+0x847204)[0x55f6d7eb7204] /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(+0x8ce1b4)[0x55f6d7f3e1b4] mysys/stacktrace.c:268(my_print_stacktrace)[0x55f6d7f42d11] sql/signal_handler.cc:168(handle_fatal_signal)[0x55f6d7f437a4] log/log0recv.cc:3088(recv_init_crash_recovery())[0x55f6d7f43e9a] srv/srv0start.cc:2529(innobase_start_or_create_for_mysql())[0x55f6d7fbf3f6] xtrabackup/xtrabackup.cc:1842(innodb_init())[0x55f6d79d857d] xtrabackup/xtrabackup.cc:6336(xtrabackup_prepare_func)[0x55f6d79e4ffc] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fc71dc613f1] /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(_start+0x2a)[0x55f6d79f893a] {noformat} Please note that indeed .idb file exists in both places, just it is probably valid situation as one of places is actual original .idb referenced by .isl inside backup: {noformat} $ find ~/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/ \| grep p2.i /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/log/xtrabackup.partition_data_external/mysqld.1/data/test/test#P#p2.isl /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/backup/test/test#P#p2.ibd /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/backup/test/test#P#p2.isl /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/partitdata/test/test#P#p2.ibd {noformat} Test case run with : perl mysql-test-run.pl --mysqld="--partition" partition_data_external.test {noformat} $ cat ../mysql-test/suite/xtrabackup/partition_data_external.test let $targetdir=$MYSQLTEST_VARDIR/backup; mkdir $targetdir; mkdir $MYSQLTEST_VARDIR/partitdata; eval CREATE TABLE test ( a int(11) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1 PARTITION BY RANGE (a) (PARTITION p0 VALUES LESS THAN (100), PARTITION P1 VALUES LESS THAN (200), PARTITION p2 VALUES LESS THAN (300) DATA DIRECTORY = "$MYSQLTEST_VARDIR/partitdata", PARTITION p3 VALUES LESS THAN (400) DATA DIRECTORY = "$MYSQLTEST_VARDIR/partitdata", PARTITION p4 VALUES LESS THAN MAXVALUE); INSERT INTO test VALUES (1), (101), (201), (301), (401); exec $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf --backup --target-dir=$targetdir; exec $XTRABACKUP --prepare --target-dir=$targetdir; DROP TABLE t; rmdir $targetdir; rmdir $MYSQLTEST_VARDIR/partitdata; {noformat}	Observed new xtrabackup crash during prepare in bb-10.1-wlad-xtrabackup after recent merge (I have strong consideration that it didn't crash in source code from ~December). {noformat} InnoDB: Tablespaces for test/test#P#p2 have been found in two places; Location 1: SpaceID: 6 LSN: 0 File: ./test/test#P#p2.ibd Location 2: SpaceID: 6 LSN: 0 File: /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/partitdata/test/test#P#p2.ibd You must delete one of them. 170222 9:24:34 [ERROR] mysqld got signal 6 ; ... /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(my_print_stacktrace+0x29)[0x55f6d8034149] /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(handle_fatal_signal+0x3ad)[0x55f6d7c1cfed] /lib/x86_64-linux-gnu/libpthread.so.0(+0x11630)[0x7fc71f7e6630] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x9f)[0x7fc71dc767ef] /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fc71dc783ea] /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(+0x847204)[0x55f6d7eb7204] /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(+0x8ce1b4)[0x55f6d7f3e1b4] mysys/stacktrace.c:268(my_print_stacktrace)[0x55f6d7f42d11] sql/signal_handler.cc:168(handle_fatal_signal)[0x55f6d7f437a4] log/log0recv.cc:3088(recv_init_crash_recovery())[0x55f6d7f43e9a] srv/srv0start.cc:2529(innobase_start_or_create_for_mysql())[0x55f6d7fbf3f6] xtrabackup/xtrabackup.cc:1842(innodb_init())[0x55f6d79d857d] xtrabackup/xtrabackup.cc:6336(xtrabackup_prepare_func)[0x55f6d79e4ffc] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fc71dc613f1] /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(_start+0x2a)[0x55f6d79f893a] {noformat} Please note that indeed .ibd file exists in both places, just it is probably valid situation as one of places is actual original .ibd referenced by .isl inside backup: {noformat} $ find ~/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/ \| grep p2.i /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/log/xtrabackup.partition_data_external/mysqld.1/data/test/test#P#p2.isl /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/backup/test/test#P#p2.ibd /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/backup/test/test#P#p2.isl /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/partitdata/test/test#P#p2.ibd {noformat} Test case run with : perl mysql-test-run.pl --mysqld="--partition" partition_data_external.test {noformat} $ cat ../mysql-test/suite/xtrabackup/partition_data_external.test let $targetdir=$MYSQLTEST_VARDIR/backup; mkdir $targetdir; mkdir $MYSQLTEST_VARDIR/partitdata; eval CREATE TABLE test ( a int(11) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1 PARTITION BY RANGE (a) (PARTITION p0 VALUES LESS THAN (100), PARTITION P1 VALUES LESS THAN (200), PARTITION p2 VALUES LESS THAN (300) DATA DIRECTORY = "$MYSQLTEST_VARDIR/partitdata", PARTITION p3 VALUES LESS THAN (400) DATA DIRECTORY = "$MYSQLTEST_VARDIR/partitdata", PARTITION p4 VALUES LESS THAN MAXVALUE); INSERT INTO test VALUES (1), (101), (201), (301), (401); exec $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf --backup --target-dir=$targetdir; exec $XTRABACKUP --prepare --target-dir=$targetdir; DROP TABLE t; rmdir $targetdir; rmdir $MYSQLTEST_VARDIR/partitdata; {noformat}

Andrii Nikitin (Inactive) made changes - 2017-02-22 08:53

Description

Observed new xtrabackup crash during prepare in bb-10.1-wlad-xtrabackup after recent merge (I have strong consideration that it didn't crash in source code from ~December).

{noformat}
InnoDB: Tablespaces for test/test#P#p2 have been found in two places;
Location 1: SpaceID: 6 LSN: 0 File: ./test/test#P#p2.ibd
Location 2: SpaceID: 6 LSN: 0 File: /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/partitdata/test/test#P#p2.ibd
You must delete one of them.
170222 9:24:34 [ERROR] mysqld got signal 6 ;
...
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(my_print_stacktrace+0x29)[0x55f6d8034149]
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(handle_fatal_signal+0x3ad)[0x55f6d7c1cfed]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11630)[0x7fc71f7e6630]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x9f)[0x7fc71dc767ef]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fc71dc783ea]
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(+0x847204)[0x55f6d7eb7204]
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(+0x8ce1b4)[0x55f6d7f3e1b4]
mysys/stacktrace.c:268(my_print_stacktrace)[0x55f6d7f42d11]
sql/signal_handler.cc:168(handle_fatal_signal)[0x55f6d7f437a4]
log/log0recv.cc:3088(recv_init_crash_recovery())[0x55f6d7f43e9a]
srv/srv0start.cc:2529(innobase_start_or_create_for_mysql())[0x55f6d7fbf3f6]
xtrabackup/xtrabackup.cc:1842(innodb_init())[0x55f6d79d857d]
xtrabackup/xtrabackup.cc:6336(xtrabackup_prepare_func)[0x55f6d79e4ffc]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fc71dc613f1]
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(_start+0x2a)[0x55f6d79f893a]
{noformat}

Please note that indeed .ibd file exists in both places, just it is probably valid situation as one of places is actual original .ibd referenced by .isl inside backup:

{noformat}
$ find ~/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/ | grep p2.i
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/log/xtrabackup.partition_data_external/mysqld.1/data/test/test#P#p2.isl
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/backup/test/test#P#p2.ibd
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/backup/test/test#P#p2.isl
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/partitdata/test/test#P#p2.ibd
{noformat}

Test case run with : perl mysql-test-run.pl --mysqld="--partition" partition_data_external.test

{noformat}
$ cat ../mysql-test/suite/xtrabackup/partition_data_external.test
let $targetdir=$MYSQLTEST_VARDIR/backup;
mkdir $targetdir;
mkdir $MYSQLTEST_VARDIR/partitdata;
eval CREATE TABLE test (
  a int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
PARTITION BY RANGE (a)
(PARTITION p0 VALUES LESS THAN (100),
PARTITION P1 VALUES LESS THAN (200),
PARTITION p2 VALUES LESS THAN (300)
   DATA DIRECTORY = "$MYSQLTEST_VARDIR/partitdata",
PARTITION p3 VALUES LESS THAN (400)
   DATA DIRECTORY = "$MYSQLTEST_VARDIR/partitdata",
PARTITION p4 VALUES LESS THAN MAXVALUE);
INSERT INTO test VALUES (1), (101), (201), (301), (401);
exec $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf --backup --target-dir=$targetdir;
exec $XTRABACKUP --prepare --target-dir=$targetdir;
DROP TABLE t;
rmdir $targetdir;
rmdir $MYSQLTEST_VARDIR/partitdata;
{noformat}

Observed new xtrabackup crash during prepare in bb-10.1-wlad-xtrabackup after recent merge (I have strong consideration that it didn't crash in source code from ~December).

{noformat}
InnoDB: Tablespaces for test/test#P#p2 have been found in two places;
Location 1: SpaceID: 6 LSN: 0 File: ./test/test#P#p2.ibd
Location 2: SpaceID: 6 LSN: 0 File: /home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/partitdata/test/test#P#p2.ibd
You must delete one of them.
170222 9:24:34 [ERROR] mysqld got signal 6 ;
...
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(my_print_stacktrace+0x29)[0x55f6d8034149]
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(handle_fatal_signal+0x3ad)[0x55f6d7c1cfed]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11630)[0x7fc71f7e6630]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x9f)[0x7fc71dc767ef]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fc71dc783ea]
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(+0x847204)[0x55f6d7eb7204]
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(+0x8ce1b4)[0x55f6d7f3e1b4]
mysys/stacktrace.c:268(my_print_stacktrace)[0x55f6d7f42d11]
sql/signal_handler.cc:168(handle_fatal_signal)[0x55f6d7f437a4]
log/log0recv.cc:3088(recv_init_crash_recovery())[0x55f6d7f43e9a]
srv/srv0start.cc:2529(innobase_start_or_create_for_mysql())[0x55f6d7fbf3f6]
xtrabackup/xtrabackup.cc:1842(innodb_init())[0x55f6d79d857d]
xtrabackup/xtrabackup.cc:6336(xtrabackup_prepare_func)[0x55f6d79e4ffc]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fc71dc613f1]
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/extra/xtrabackup/xtrabackup(_start+0x2a)[0x55f6d79f893a]
{noformat}

Please note that indeed .ibd file exists in both places, just it is probably valid situation as one of places is actual original .ibd referenced by .isl inside backup:

{noformat}
$ find ~/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/ | grep p2.i
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/log/xtrabackup.partition_data_external/mysqld.1/data/test/test#P#p2.isl
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/backup/test/test#P#p2.ibd
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/backup/test/test#P#p2.isl
/home/a/farm/m9-bb-10.1-wlad-xtrabackup/build/mysql-test/var/partitdata/test/test#P#p2.ibd
{noformat}

Test case run with :
{noformat}
perl mysql-test-run.pl --mysqld="--partition" partition_data_external.test
{noformat}

{noformat}
$ cat ../mysql-test/suite/xtrabackup/partition_data_external.test
let $targetdir=$MYSQLTEST_VARDIR/backup;
mkdir $targetdir;
mkdir $MYSQLTEST_VARDIR/partitdata;
eval CREATE TABLE test (
  a int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
PARTITION BY RANGE (a)
(PARTITION p0 VALUES LESS THAN (100),
PARTITION P1 VALUES LESS THAN (200),
PARTITION p2 VALUES LESS THAN (300)
   DATA DIRECTORY = "$MYSQLTEST_VARDIR/partitdata",
PARTITION p3 VALUES LESS THAN (400)
   DATA DIRECTORY = "$MYSQLTEST_VARDIR/partitdata",
PARTITION p4 VALUES LESS THAN MAXVALUE);
INSERT INTO test VALUES (1), (101), (201), (301), (401);
exec $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf --backup --target-dir=$targetdir;
exec $XTRABACKUP --prepare --target-dir=$targetdir;
DROP TABLE t;
rmdir $targetdir;
rmdir $MYSQLTEST_VARDIR/partitdata;
{noformat}

Andrii Nikitin (Inactive) made changes - 2017-02-22 08:55

Attachment

mtr.log [ 43341 ]

Andrii Nikitin (Inactive) made changes - 2017-07-12 20:11

Affects Version/s		10.2.7 [ 22543 ]
Affects Version/s		10.1.25 [ 22542 ]

Andrii Nikitin (Inactive) made changes - 2017-07-12 20:12

Summary

prepare crashes in recv_init_crash_recovery for partition with external DATA DIRECTORY clause

mariabackup doesn't handle table's DATA DIRECTORY clause

Andrii Nikitin (Inactive) made changes - 2017-08-15 14:14

Fix Version/s

10.1 [ 16100 ]

Andrii Nikitin (Inactive) made changes - 2017-08-15 14:14

Fix Version/s

10.2 [ 14601 ]

Vladislav Vaintroub made changes - 2017-09-13 09:40

Assignee

Marko Mäkelä [ marko ]

Vladislav Vaintroub [ wlad ]

Sergei Golubchik made changes - 2017-10-04 14:48

Sprint

10.2.10 [ 183 ]

Sergei Golubchik made changes - 2017-11-01 09:35

Sprint

10.2.10 [ 183 ]

10.2.10, 10.1.29 [ 183, 202 ]

Vladislav Vaintroub made changes - 2017-11-08 09:27

Status

Open [ 1 ]

In Progress [ 3 ]

Marko Mäkelä made changes - 2017-11-08 11:18

issue.field.resolutiondate

2017-11-08 11:18:37.0

2017-11-08 11:18:37.69

Marko Mäkelä made changes - 2017-11-08 11:18

Fix Version/s		10.1.29 [ 22636 ]
Fix Version/s		10.2.11 [ 22634 ]
Fix Version/s	10.2 [ 14601 ]
Fix Version/s	10.1 [ 16100 ]
Resolution		Fixed [ 1 ]
Status	In Progress [ 3 ]	Closed [ 6 ]

Sergei Golubchik made changes - 2021-12-06 21:44

Workflow

MariaDB v3 [ 79710 ]

MariaDB v4 [ 151738 ]

People

Assignee:: Vladislav Vaintroub

Reporter:: Andrii Nikitin (Inactive)

Votes:: 0 Vote for this issue

Watchers:: 3 Start watching this issue

Dates

Created:: 2017-02-22 08:51

Updated:: 2017-11-08 11:21

Resolved:: 2017-11-08 11:18

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server

Details

Description

Attachments

Attachments

Activity

People

Dates

Git Integration