|
--source include/have_innodb.inc
|
|
CREATE TABLE t1 (pk INT PRIMARY KEY, a YEAR) ENGINE=InnoDB ROW_FORMAT=REDUNDANT;
|
INSERT INTO t1 VALUES (1,2021);
|
UPDATE t1 SET a = NULL;
|
--exec $XTRABACKUP --backup --target-dir=$MYSQLTEST_VARDIR/mbackup_backup --protocol=tcp --port=$MASTER_MYPORT --user=root
|
--exec $XTRABACKUP --prepare --target-dir=$MYSQLTEST_VARDIR/mbackup_backup
|
|
# Cleanup
|
DROP TABLE t1;
|
|
10.5 b3df194e
|
mariabackup: /data/src/10.5/storage/innobase/log/log0recv.cc:493: log_phys_t::apply_status log_phys_t::apply(const buf_block_t&, uint16_t&) const: Assertion `rlen < llen' failed.
|
210214 18:48:09 [ERROR] mysqld got signal 6 ;
|
|
#6 0x00007f45bba53f36 in __GI___assert_fail (assertion=0x55cf22c804d8 "rlen < llen", file=0x55cf22c80040 "/data/src/10.5/storage/innobase/log/log0recv.cc", line=493, function=0x55cf22c801c0 "log_phys_t::apply_status log_phys_t::apply(const buf_block_t&, uint16_t&) const") at assert.c:101
|
#7 0x000055cf224e77ff in log_phys_t::apply (this=0x7f45ade293d0, block=..., last_offset=@0x55cf252daa64: 152) at /data/src/10.5/storage/innobase/log/log0recv.cc:493
|
#8 0x000055cf224de6b8 in recv_recover_page (block=0x7f45adc01ab8, mtr=..., p=Python Exception <class 'AttributeError'> 'NoneType' object has no attribute 'pointer':
|
..., space=0x55cf252c7e08, init=0x55cf252daac0) at /data/src/10.5/storage/innobase/log/log0recv.cc:2330
|
#9 0x000055cf224ea65e in recv_sys_t::recover_low (this=0x55cf23312400 <recv_sys>, page_id=..., p=Python Exception <class 'AttributeError'> 'NoneType' object has no attribute 'pointer':
|
..., mtr=..., b=0x7f45adc01ab8) at /data/src/10.5/storage/innobase/log/log0recv.cc:2577
|
#10 0x000055cf224dfd88 in recv_sys_t::apply (this=0x55cf23312400 <recv_sys>, last_batch=true) at /data/src/10.5/storage/innobase/log/log0recv.cc:2680
|
#11 0x000055cf22624d40 in srv_start (create_new_db=false) at /data/src/10.5/storage/innobase/srv/srv0start.cc:1491
|
#12 0x000055cf2198ed2b in innodb_init () at /data/src/10.5/extra/mariabackup/xtrabackup.cc:2198
|
#13 0x000055cf21999c11 in xtrabackup_prepare_func (argv=0x55cf24d5c998) at /data/src/10.5/extra/mariabackup/xtrabackup.cc:5776
|
#14 0x000055cf2199c5ea in main_low (argv=0x55cf24d5c998) at /data/src/10.5/extra/mariabackup/xtrabackup.cc:6681
|
#15 0x000055cf2199bdfd in main (argc=3, argv=0x7fffaadc3678) at /data/src/10.5/extra/mariabackup/xtrabackup.cc:6473
|
The test case appears to be deterministic, at least for the time being.
Reproducible on 10.5, 10.6.
10.4 does not seem to have this assertion.
No obvious immediate problem on a non-debug build (prepare works, server can start on the prepared datadir, and the table is functonal).
Can also be reproduced with rr. Test case for running with rr (to store mariabackup profiles in addition to the server one, which is done automatically):
--source include/have_innodb.inc
|
|
CREATE TABLE t1 (pk INT PRIMARY KEY, a YEAR) ENGINE=InnoDB ROW_FORMAT=REDUNDANT;
|
INSERT INTO t1 VALUES (1,2021);
|
UPDATE t1 SET a = NULL;
|
--exec rr record --output-trace-dir=$MYSQLTEST_VARDIR/rr.1/rr-mbackup-backup $XTRABACKUP --backup --target-dir=$MYSQLTEST_VARDIR/mbackup_backup --protocol=tcp --port=$MASTER_MYPORT --user=root
|
--exec rr record --output-trace-dir=$MYSQLTEST_VARDIR/rr.1/rr-mbackup-prepare $XTRABACKUP --prepare --target-dir=$MYSQLTEST_VARDIR/mbackup_backup
|
|
# Cleanup
|
DROP TABLE t1;
|
|