Details
-
Task
-
Status: In Review (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
Description
Explore, and choose one for implementing, several ideas around detecting binlog corruption on the server and warning about it. See comments from MDEV-32662, which are copied here for convenience.
"Another idea would be to incorporate the last modified timestamp of the binary logs to find if someone unexpected has tampered with the binary log file. That is, within mariadbd, we would cache the time that we last wrote to the binary log file. Then, before writing an ever, we would compare our last cached timestamp against that which the file-system reports. If the file system reports a last modified date that is after the timestamp when we last wrote an event, we'd know it has been tampered with (and possibly corrupted). Then, we could write a warning to the error log with the file system's reported last modified date, which could be used to cross-reference other logs on the server to see what was happening at that time (e.g. system logs, other mariadbd logs, etc)."
"To explore the fs timestamp more, remembering by MYSQL_BIN_LOG object the last modification timestamp could be done always. Later then an error read from the current binlog occurs, MYSQL_BIN_LOG::last_modified_ts would be compared against the FileSystem's version. A mismatch would obviously indicate the fact of a illegal writer at the FS::last_modified_ts."
Attachments
Issue Links
- is part of
-
MDEV-32662 Capture corrupted binlog events
- Open