Quick note to mention that I got a number of intermittent test errors on the two PRs I submitted today. I tried to discover the root cause but my knowledge of MySQL and these tests is limited. I did re-run the failed jobs and eventually they all succeeded.

I imagine this is much easier said than done, but I'm sure everyone in the community could benefit from this.

What happened?

The server can accept requests for many backup streams. We have a few servers with 5+ open streams. It appears that https://github.com/aiven/myhoard/blob/f13a8750465a349bff6b68c63bf1a2533e04c7d1/myhoard/controller.py#L1778 might not be quite correct behaviour, as it appears to update streams, but not persist those updates back to controller state, then ask the controller to reload its state.

What did you expect to happen?

In https://github.com/aiven/myhoard/blob/f13a8750465a349bff6b68c63bf1a2533e04c7d1/myhoard/controller.py#L796, we prevent more than two streams from being open, so, that should not be the case. Rather than keep the extra streams that exist around, they should be discarded.

What else do we need to know?

This problem is exacerbated by the lack of an api to delete backups. Because these streams queue up, you can end up hitting your maximum backup count quite easily, which causes even more streams to queue up as they wait for room, snowballing the problem.

i want to know if it will impact the restore data from the basebackup?

What is currently missing?

have not managed to find installation instruction

How could this be improved?

would be good to have installation instruction in the README.md

Is this a feature you would work on yourself?

no

[ ] I plan to open a pull request for this feature