Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL)
-
Reproduced on Windows 10 and Windows Server 2016
Description
I have found a critical bug in Aria (Page storage format) where tables are wiped if someone runs a repair command with the USE_FRM flag.
REPAIR TABLE X USE_FRM
This bug only exists for databases that use an encryption plugin. In our case we use a file encryption plugin, however it is likely this bug affects all types of encryption plugin.
Disabling the encryption plugin or changing the storage format to Dynamic will prevent the USE_FRM from wiping the table.
However, since we require Data Encryption at Rest, we have to use encryption and Page storage format.
To reproduce, set up a Windows VM with MariaDB 10.5.13 (or later) installed.
Load on a file-based encryption plugin (or any other encryption plugin).
Then create a database and some tables and add data.
Finally, run a repair table command with the additional flag USE_FRM.
Now disconnect and reconnect to the Database and you will see all data has been removed.
A proposed dirty fix could be the following:
If table type is Aria and Storage Format is Page and encryption is enabled, then ignore USE_FRM flag if its passed in.
Attachments
Activity
We just had a power cut at one of our sites.
Before the power cut the system was functioning correctly.
After the power cut, the database "tigersys" had been wiped.
I believe this is related to auto crash recovery built into Aria when
using encryption plugins.
Please see attached mariadb err log (zipped up).
Thanks for the report. Reproducible as described.
--source suite/encryption/include/have_file_key_management_plugin.inc
|
|
|
set global aria_encrypt_tables=1; |
|
|
create table t (a int) engine=Aria row_format=PAGE; |
insert into t values (1),(2); |
repair table t use_frm; |
select * from t; |
|
|
# Cleanup
|
drop table t; |
set global aria_encrypt_tables= default; |
|
10.3 02e85aea |
repair table t use_frm; |
Table Op Msg_type Msg_text |
test.t repair info Wrong CRC on datapage at 1 |
test.t repair status OK
|
select * from t; |
a
|
drop table t; |
There are two issues here.
- REPAIR ... USE_FRM destroys encrypted Aria tables. This is not a bug as such, documentation says "For use only when the index file is missing or its header corrupted". This is because REPAIR ... USE_FRM completely discards and destroys the index file. Vital encryption information is stored in the Aria index file header, and when it's destroyed the table becomes unreadable. We'll try to add some guard rails here though.
- Data loss after a power failure. It is a different issue, auto crash recovery never resorts to USE_FRM.
There also seems to be the same issue with auto-recovery when using encryption. Is it possible auto-recovery also uses USE_FRM ? If so, this might need fixing/tweaking so that USE_FRM isn't used.