Thank you for confirming my analysis.
Compared to innodb_doublewrite=0 and reading the recently written page identifiers from the redo log (starting from a recent or the latest checkpoint), the reduced innodb_doublewrite=2 mode could have the benefit that it might be able to record a larger number of recently written pages, especially if the most recent workload involves writing a few pages over and over, so that the redo log would only contain the few page identifiers of the busy pages.
There is another corruption mode, of which I have some anecdotal evidence: spontaneous corruption of data that was not accessed (read or written) for a long time. As far as I understand, neither the reduced doublewrite buffer nor the redo logs would help there.
I believe that before introducing the new innodb_doublewrite=2 mode, we should spend more effort on improving the corruption handling of InnoDB.
Thank you for confirming my analysis.
Compared to innodb_doublewrite=0 and reading the recently written page identifiers from the redo log (starting from a recent or the latest checkpoint), the reduced innodb_doublewrite=2 mode could have the benefit that it might be able to record a larger number of recently written pages, especially if the most recent workload involves writing a few pages over and over, so that the redo log would only contain the few page identifiers of the busy pages.
There is another corruption mode, of which I have some anecdotal evidence: spontaneous corruption of data that was not accessed (read or written) for a long time. As far as I understand, neither the reduced doublewrite buffer nor the redo logs would help there.
I believe that before introducing the new innodb_doublewrite=2 mode, we should spend more effort on improving the corruption handling of InnoDB.