Details
-
Bug
-
Status: Open (View Workflow)
-
Critical
-
Resolution: Unresolved
-
10.11, 11.4, 11.8
Description
Reproducible on 10.11.15 and on bb-10.11-release with MDEV-38246 fix already in the tree.
|
bb-10.11-release 3218602d3100db9ce7a875511a591cddc173cc16 |
[00] 2026-02-02 11:57:27 aria table file ./test/table1_aria_timestamp_key_pk_parts_2#P#p0.MAI is copied successfully.
|
/home/rr/MDEV-38727/bb-10.11-release/bin/mariabackup: Error 176 reading index file `test`.`table1_aria_timestamp_key_pk_parts_2` block 1
|
[00] 2026-02-02 11:57:28 error: aria_read index from ./test/table1_aria_timestamp_key_pk_parts_2#P#p1.MAI failed with error 176
|
[00] 2026-02-02 11:57:28 Skip copying 1 aria log file due to error
|
[00] 2026-02-02 11:57:28 Aria data files backup process is finished with error
|
The test flow seems very simple.
First, one table is created and populated with 1 row:
CREATE TABLE test.table1_aria_timestamp_key_pk_parts_2 (i int, pk timestamp primary key) ENGINE=Aria PARTITION BY key (pk) partitions 2 |
ALTER TABLE test.table1_aria_timestamp_key_pk_parts_2 DISABLE KEYS |
INSERT INTO test.table1_aria_timestamp_key_pk_parts_2 VALUES (5, '2000-01-01 00:00:01') |
ALTER TABLE test.table1_aria_timestamp_key_pk_parts_2 ENABLE KEYS |
Nothing else is done to the table.
After ~10 seconds, a backup is run on the idle server and fails with the error above.
However, not only cannot I convert it to MTR, but even the non-MTR test requires slightly different conditions on different machines (and possibly different builds): for example, on one machine where I tried the above test also fails if I use table name t instead of table1_aria_timestamp_key_pk_parts_2, but on another machine it stops failing if I use t or table1; etc.
So, I'll provide an rr profile instead of a test.
Attachments
Issue Links
- is caused by
-
-
- Closed
-
- relates to
-
-
- Closed
-