More efficient log block checksums
Log block checksums are calculated very inefficiently and introduce
problems for write-intensive workloads.
This BP is to extend page checksums optimization introduced in MySQL 5.6
to log block checksums. That is, implement a new
innodb_
as innodb_
Blueprint information
- Status:
- Complete
- Approver:
- Alexey Kopytov
- Priority:
- Medium
- Drafter:
- Alexey Kopytov
- Direction:
- Approved
- Assignee:
- Alexey Kopytov
- Definition:
- Approved
- Series goal:
- Accepted for 5.6
- Implementation:
- Implemented
- Milestone target:
- 5.6.14-62.0
- Started by
- Alexey Kopytov
- Completed by
- Alexey Kopytov
Whiteboard
Behavior of innodb_
mostly identical to innodb_
applies to log rather than page checksums.
innodb_
written to log blocks instead of calculated checksum values and no
checksum validation will be performed on InnoDB/XtraBackup recovery, or
changed page tracking (if enabled).
innodb_
InnoDB behavior -- a custom and inefficient algorithm is used to
calculate log checksums, but logs created with this option are
compatible with upstream MySQL and earlier Percona Server or XtraBackup
versions that do not support other log checksum algorithms.
innodb_
checksums. Checksums will also benefit from hardware acceleration
provided by recent Intel CPUs.
Normally, XtraDB or XtraBackup will tolerate checksums created with
other algorithms than is currently specified with the
innodb_
when reading the redo log on recovery, the block is considered corrupted
only if no algorithm produces the value matching the checksum stored in
the log block header.
This can be disabled by prepending the value with the 'strict_' suffix,
e.g. 'strict_none', 'strict_crc32' or 'strict_innodb' will only accept
checksums created using the corresponding algorithms, but not the other
ones.
The XtraBackup support is covered by
https:/