Details
-
Task
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
Description
This toplevel ticket captures work related to binlog corruption. Broadly speaking, there appear to be four paths forward, three on the server and one in the client. On the server, we could (1) implement sandboxing for plugins (Andrei's comment "prevent faulty plugins"), (2) prevent binlog corruption from occurring, (3) warn when binlog corruption occurs (e.g. by detecting possible binlog corruption with timestamp checks as described in the ticket). On the client, we can find traces of corruption (some minimum length string of null bytes) enabled a new commandline option.
Attachments
Issue Links
- includes
-
MDEV-34685 Sandbox plugins away from replication mechanics
-
- Open
-
-
MDEV-34686 Prevent binlog corruptions
-
- Open
-
-
MDEV-34687 Warn when binlog corruption occurs
-
- In Review
-
-
MDEV-34688 Client-side binlog corruption detection
-
- Open
-
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).