MDEV-34687: Attempt to warn on unexpected binlog file modification
Make an effort to emit a warning if we detect that an outside force has modified the binlog. This warning will not halt binlog writes. We rely on file modification times to detect unexpected writes to the binlog file. This best-effort approach isn't fool-proof because we cannot write to the binlog and get both the prior and current modification times as an atomic operation. There are four cases in which unexpected modification could occur: 1. The time from when the we open the file until the first write. 2. The time between the first and next writes (or between writes k and k+1) 3. The time between the last write and when we close the file. 4. In the case of 0 writes, the time from when we open the file until we close the file. MariaDB writes binlogs with the help of the IO_CACHE, buffering application writes together in memory, then later writing them through to disk. We need to see through the IO_CACHE to know when file modifications occur so that we can compare the last known file modification time to the most recent modification time. However, not every user of IO_CACHE cares for this protection and the overhead of extra stat system calls. To encapsulate this new behavior to binlogs, we add four new callbacks to the IO_CACHE which in the default case do nothing. These new callbacks are triggered on certain file events: file open, pre-write, post-write, and file close. We extend the IO_CACHE with a new type that holds a copy of struct stat, containing the last file modification time, keeping the new field(s) encapsulated away from the original IO_CACHE. In the case of binlogs, we use instances of this new type wherever we previously used IO_CACHE and we set the four new callbacks to invoke the file modification time checks.
Showing
This diff is collapsed.
Please register or sign in to comment