Each InnoDB data page contains a 32-bit tablespace identifier (at byte offset 34 from the start of each page) as well as a 32-bit page number (at byte offset 4).

To diagnose something like this, we’d need to see a copy of the first 3 pages of the file:

dd bs=16384 count=3 if=tbl1.ibd of=pages.bin

These pages never contain any user data, only some metadata.

If encryption is involved, it might be that the tablespace ID had not been decrypted correctly. In MariaDB, the first page should never be encrypted even in encrypted .ibd files.

The error message will be output by fil_node_t::read_page0(). If the first page of an InnoDB data file is deemed corrupted, the file cannot be accessed. Without getting a copy of the data, it will be impossible to diagnose this further.

The pages should not contain any application data, only some metadata related to space management within the .ibd file. Here is an except of some page header bytes:

od -Ax -t x1 pages.bin|grep '00[048]0[012]0 '

000000 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff

000010 00 00 00 f6 8b b1 a1 20 00 08 00 00 00 00 00 00

000020 00 00 00 04 bd 7f 00 04 bd 7f 00 00 00 00 00 00

004000 42 52 57 57 00 00 00 01 00 00 00 00 00 00 00 00

004010 00 00 00 ee df af 7c d5 00 05 00 00 00 01 77 f4

004020 91 25 00 00 15 88 31 02 39 c4 3a 41 b4 ba e3 24

008000 00 00 00 01 00 00 00 02 ff ff ff ff ff ff ff ff

008010 00 00 00 f6 8b b1 a1 20 00 03 84 65 1f f6 f2 80

008020 c8 1f 0c fa 72 31 f2 3f 86 90 0d ad 63 a1 a1 0a

I also ran innochecksum on the file. It did not complain about the first page (which is not encrypted), but did complain about the second one because no support for encryption has been implemented in that tool:

Fail: page::1 invalid

Exceeded the maximum allowed checksum mismatch count::1 current::0

The first page looks valid for tablespace 0x4bd7f (310655), but page 1 (change buffer bitmap page) contains the tablespace identifier 0x1588 (5512). For page 2, the tablespace identifier field contains yet something else. I was under the impression that innodb_encrypt_tables would encrypt the tablespace identifier as well, but I may be mistaken about that.

A bug like MDEV-31347 could explain why an unrelated data page was written to the file. Is this reproducible with a recent 10.6 development snapshot?