[MDEV-32953] main.rpl_mysqldump_slave Fails with "Master binlog wasn't deleted" Assertion Created: 2023-12-05 Updated: 2023-12-12 Resolved: 2023-12-07 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Replication, Tests |
| Affects Version/s: | 10.4 |
| Fix Version/s: | 10.4.33, 10.5.24, 10.6.17, 10.11.7, 11.0.5, 11.1.4, 11.2.3 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Brandon Nesterenko | Assignee: | Brandon Nesterenko |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Description |
|
After
The problem is that --delete-master-logs immediately purges logs after flushing, and the active binlog dump thread can still be using the old log when the purge executes, disallowing the file from being deleted. That is because there is validation logic in the purge code to ensure that nobody is actively using that log before it deletes it:
If a user is using mysqldump --delete-master-logs with active binlog dump thread connections, they can run into this with their workaround options being |
| Comments |
| Comment by Yuchen Pei [ 2023-12-07 ] |
|
Looks pretty frequent now, failing at 5 builders at say 13dd787530863954fcd17fbaf83d46e7170667f6. Shall we raise the prio to critical? |
| Comment by Brandon Nesterenko [ 2023-12-07 ] |
|
Hi Andrei! This is ready for review: PR 2900 The underlying cause of the test failure may need additional discussion, as I'm not sure if it is a bug or a feature. But the proposed fix in PR 2900 at least institutes a work-around in the test in the mean-time. |
| Comment by Brandon Nesterenko [ 2023-12-07 ] |
|
Fixed and pushed into 10.4 as 9be7e03f70e |