Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.1(EOL), 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5
-
None
Description
https://github.com/MariaDB/server/blob/395f23a10d44a63732dd69f79fb7372bc5834443/storage/innobase/fil/fil0fil.cc#L2042
This writes bypasses redo log and double buffer and thus allows whose database corruption.
Attachments
Issue Links
- relates to
-
MDEV-11633 Make the InnoDB system tablespace optional
-
- Open
-
Activity
Thanks to this field, it is safe to delete the redo log files are deleted after a clean shutdown, because the new redo log will be initialized based on the contents of the FIL_PAGE_FILE_FLUSH_LSN in the first page of the system tablespace. If we stop updating this field, then we should stop also creating the redo log automatically when data files exist. To allow startup, we would need a special startup option or an external tool to create empty log files as of a specified LSN.
Because of this, it could be too late to remove the writes to the field even in 10.5, which is rather close to feature freeze. But we definitely should consider that in 10.6, because eventually we want to make the system tablespace optional in MDEV-11633.
By design, the write is bypassing the redo log. It would be better to not bypass the doublewrite buffer.
I think that we should remove the function fil_write_flushed_lsn() and related checks in MariaDB 10.5.
I believe that the only purpose of FIL_PAGE_FILE_FLUSH_LSN is to write a message to the server error log when the redo log appears logically empty and its LSN does not correspond to the value of this field. The field is wasting 8 bytes in every data page, even though we only use it in the first page of the system tablespace. In MariaDB 10.1, the field was partly repurposed for encryption, and in MariaDB 10.2 (and MySQL 5.7), for the ‘split sequence number’ of SPATIAL INDEX.