Originally, InnoDB did not zero-initialize buffer pool blocks that were allocated to a file page. Because of this, unused bytes on data pages could contain any garbage, belonging to the previous contents of the buffer pool block, such as another data page, or a generic memory allocation (BUF_BLOCK_MEMORY, buf_block_alloc(), MEM_HEAP_BUFFER) that is used by the adaptive hash index, crash recovery, record locks.
The page initialization was finally added in MySQL 5.1.48 for all data files. The original author of InnoDB opposed the initialization for many years, because he feared that it might cost some performance.
To make it easier to repurpose unused data fields in the future, we should introduce a flag in FSP_SPACE_FLAGS to indicate that any unused fields in the data file are zero-initialized.
At least since MDEV-11623 in MariaDB 10.1.21, InnoDB is ignoring the useless tablespace flag that was introduced in MySQL 5.6 to indicate that the DATA DIRECTORY attribute was specified when the table was created or rebuilt. Let us repurpose this old flag to indicate that unused data fields have been zero-initialized. (MySQL 5.6 and later always zero-initialized all unused data fields, so it is safe to repurpose this bit. It can never be set on files that were created before MySQL 5.6.)
We must be careful to never set this flag on old data files without first having rewritten all pages. This could be implemented in a conversion tool later.
10.1.patch attempts to implement this. There are a few failing tests.
There also is a downgrade problem. A prerequisite for implementing this should be to ensure that IMPORT TABLESPACE to older versions works.
Marko Mäkelä
added a comment - 10.1.patch attempts to implement this. There are a few failing tests.
There also is a downgrade problem. A prerequisite for implementing this should be to ensure that IMPORT TABLESPACE to older versions works.
After to MDEV-12026 in MariaDB 10.4, data files created with innodb_checksum_algorithm=full_crc32 will be guaranteed to be zero-initialized. The tablespace flag that indicates full_crc32 format is also indicating that the file contains no uninitialized garbage. (We do not support in-place update of old data files (which may contain uninitialized garbage) to the full_crc32 format.)
Marko Mäkelä
added a comment - After to MDEV-12026 in MariaDB 10.4, data files created with innodb_checksum_algorithm=full_crc32 will be guaranteed to be zero-initialized. The tablespace flag that indicates full_crc32 format is also indicating that the file contains no uninitialized garbage. (We do not support in-place update of old data files (which may contain uninitialized garbage) to the full_crc32 format.)
Are pages for tables with ROW_FORMAT=COMPRESSED guaranteed to be zero-initialized if MDEV-18644 is still open?
Geoff Montee (Inactive)
added a comment - I updated the docs here:
https://mariadb.com/kb/en/library/innodb-encryption-troubleshooting/#tablespaces-created-on-mysql-5147-or-earlier
Are pages for tables with ROW_FORMAT=COMPRESSED guaranteed to be zero-initialized if MDEV-18644 is still open?
10.1.patch
attempts to implement this. There are a few failing tests.
There also is a downgrade problem. A prerequisite for implementing this should be to ensure that IMPORT TABLESPACE to older versions works.