Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
N/A
-
None
Description
Documentation about innodb_checksum_algorithm is already quite detailed, but still confusing.
It says:
strict_: The strict_ options are the same as the regular options, but InnoDB will halt if it comes across a mix of checksum values.
It doesn't specify what exactly counts as a "mix of checksum values".
For example, currently
- if server was bootstrapped with crc32 and then started with strict_innodb, it causes an error on startup (which is probably the above quote means)
- if server was bootstrapped with full_crc32 and then started with strict_innodb, it starts fine.
Possibly it can be explained by the previous description of full_xx specifics, but it does seem to contradict the part about strict_xx.
Attachments
Issue Links
- relates to
-
MDEV-12026 Support encrypted SPATIAL INDEX
-
- Closed
-
The full_crc32 option was introduced in
MDEV-12026.Any data file that was created while innodb_checksum_algorithm was full_crc32 or strict_full_crc32 will use a single CRC-32C that is computed over the entire page payload. Even if the innodb_checksum_algorithm is modified later, the same checksum will continue to be used. A special flag will be set in the FSP_SPACE_FLAGS in the first data page to indicate the new format of checksum and encryption/page_compressed.
For data files that were not created with full_crc32 or strict_full_crc32, the old rules will apply, and these values will be interpreted as crc32 or strict_crc32, respectively. The strict_ variant means that only the specified type of checksum algorithm will be allowed. The non-strict variant avoids crashes when upgrading from a dataset where innodb_checksum_algorithm=innodb had been used, but it weakens the page checksum, by accepting corrupted pages using a different checksum algorithm.