Details
-
Bug
-
Status: Open (View Workflow)
-
Critical
-
Resolution: Unresolved
-
11.4, 11.8, 12.3, 13.0, 13.1
Description
A table created with ENGINE=DuckDB is empty after a mariadb-backup round trip. The restored server still carries the table definition, so SHOW CREATE TABLE works, but every read of the table ends in a DuckDB catalog error. A full backup and a full plus incremental backup both show it.
The DuckDB engine keeps every table in one database file, duckdb.db, in the data directory root, with its write-ahead log beside it in duckdb.db.wal. mariadb-backup copies data directory root files by name prefix. BackupStages::stage_block_commit() in extra/mariabackup/xtrabackup.cc copies aws-kms-key and mariadb_upgrade_info, and ibx_copy_incremental_over_full() in extra/mariabackup/backup_copy.cc copies those two plus aria_log. Neither list carries duckdb.db, and no other part of mariadb-backup names it, so the file never reaches the backup. The restored server opens a new, empty DuckDB database in its place.
The DuckDB handlerton does not implement the prepare_for_backup and end_backup hooks. The server calls these through ha_prepare_for_backup() and ha_end_backup() at the start and at the end of a backup, which is how an engine brings its own files to a consistent state for the copy. DuckDB implements neither, so its database file stays open for writes for the duration of the backup.
MTR Testcase:
--disable_query_log
|
--disable_result_log
|
--disable_abort_on_error
|
INSTALL SONAME 'ha_duckdb'; |
--enable_abort_on_error
|
--enable_result_log
|
--enable_query_log
|
if (`SELECT COUNT(*) = 0 FROM information_schema.engines WHERE engine = 'DuckDB' AND support IN ('YES','DEFAULT','ENABLED')`) |
{
|
--skip Test requires engine DuckDB. |
}
|
|
|
CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 INT) ENGINE=DuckDB; |
INSERT INTO t1 VALUES (1,1),(2,2),(3,3); |
|
|
--let $targetdir=$MYSQLTEST_VARDIR/tmp/backup
|
--let $incdir=$MYSQLTEST_VARDIR/tmp/backup_inc
|
|
|
--disable_result_log
|
--exec $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf --backup --target-dir=$targetdir
|
--enable_result_log
|
|
|
INSERT INTO t1 VALUES (4,4),(5,5); |
|
|
--disable_result_log
|
--exec $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf --backup --target-dir=$incdir --incremental-basedir=$targetdir
|
--exec $XTRABACKUP --prepare --target-dir=$targetdir
|
--exec $XTRABACKUP --prepare --target-dir=$targetdir --incremental-dir=$incdir
|
--enable_result_log
|
|
|
--perl
|
my $dir= $ENV{'MYSQLTEST_VARDIR'} . "/tmp/backup"; |
die "The DuckDB database file is not in the backup. mariadb-backup did not copy duckdb.db out of the data directory.\n" unless -f "$dir/duckdb.db"; |
EOF
|
|
|
--let $_datadir= `SELECT @@datadir`
|
--source include/shutdown_mysqld.inc
|
--rmdir $_datadir
|
--exec $XTRABACKUP --defaults-file=$MYSQLTEST_VARDIR/my.cnf --copy-back --datadir=$_datadir --target-dir=$targetdir
|
--source include/start_mysqld.inc
|
|
|
--let $total= `SELECT IFNULL(SUM(c2),-1) FROM t1`
|
if ($total != 15) { |
--die The DuckDB table is not readable after the backup round trip. The rows written before the backup are gone. |
}
|
|
|
DROP TABLE t1; |
UNINSTALL SONAME 'ha_duckdb'; |
--rmdir $targetdir
|
--rmdir $incdir
|
The test fails at the first check, because duckdb.db is not in the backup directory:
|
CS 13.1.0 da18481158c81ca94689702073c3e04aad85a6a3 (Optimized, Clang 22.1.8-20260622) Build 18/08/2026 |
CURRENT_TEST: main.test_claude
|
The DuckDB database file is not in the backup. mariadb-backup did not copy duckdb.db out of the data directory.
|
mysqltest: At line 31: command "perl" failed with error: 2 my_errno: 0 errno: 0
|
Leads to, on a server started on the prepared backup:
|
CS 13.1.0 da18481158c81ca94689702073c3e04aad85a6a3 (Optimized, Clang 22.1.8-20260622) Build 18/08/2026 |
SHOW CREATE TABLE t1;
|
Table Create Table
|
t1 CREATE TABLE `t1` (
|
`c1` int(11) NOT NULL,
|
`c2` int(11) DEFAULT NULL,
|
PRIMARY KEY (`c1`)
|
) ENGINE=DUCKDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_uca1400_ai_ci
|
|
|
SELECT * FROM t1;
|
ERROR 1296 (HY000) at line 1: Got error 122 'Catalog Error: Table with name t1 does not exist!
|
Did you mean "pg_tables"?
|
|
|
LINE 1: SELECT * FROM t1
|
^' from DuckDB
|
|
Bug Detection Matrix |
Rel o/d Build Commit Affected
|
CS 10.11 dbg 180826 8f00e6caca633c783140db86d3a48a96de67cf38 No
|
CS 10.11 opt 180826 8f00e6caca633c783140db86d3a48a96de67cf38 No
|
CS 11.4 dbg 180826 1a052f27e374fc9b4cb5b1fd098cf10f0e1381cc Yes
|
CS 11.4 opt 180826 1a052f27e374fc9b4cb5b1fd098cf10f0e1381cc Yes
|
CS 11.8 dbg 180826 d26f9ab217a7fcf9d4eccc62c01020ff275ff42e Yes
|
CS 11.8 opt 180826 d26f9ab217a7fcf9d4eccc62c01020ff275ff42e Yes
|
CS 12.3 dbg 180826 add63991988734383c5e942de2a19c6c45f511f7 Yes
|
CS 12.3 opt 180826 add63991988734383c5e942de2a19c6c45f511f7 Yes
|
CS 13.0 dbg 180826 a848493c6fe031f23606144420c1ca1e467cbd81 Yes
|
CS 13.0 opt 180826 a848493c6fe031f23606144420c1ca1e467cbd81 Yes
|
CS 13.1 dbg 180826 da18481158c81ca94689702073c3e04aad85a6a3 Yes
|
CS 13.1 opt 180826 da18481158c81ca94689702073c3e04aad85a6a3 Yes
|
ES 10.6 dbg 180826 fcecb2620f25965723d640decede7c018bcb1dcc No
|
ES 10.6 opt 180826 fcecb2620f25965723d640decede7c018bcb1dcc No
|
ES 11.4 dbg 180826 3b34189bfe675c18c4ced3ef531d016ea74c76f4 No
|
ES 11.4 opt 180826 3b34189bfe675c18c4ced3ef531d016ea74c76f4 No
|
ES 11.8 dbg 180826 4694e931d10fecf733c34f83ea2146d31b708eb3 No
|
ES 11.8 opt 180826 4694e931d10fecf733c34f83ea2146d31b708eb3 No
|
ES 12.3 dbg 180826 f513f503feacabfb219d4a6f965b5f72b86d4db0 No
|
ES 12.3 opt 180826 f513f503feacabfb219d4a6f965b5f72b86d4db0 No
|
Attachments
Issue Links
- blocks
-
MDEV-40015 Transition DuckDB engine to gamma
-
- Open
-
- relates to
-
MDEV-39234 DuckDB as a storage engine
-
- Closed
-
-
-
- Stalled
-
