This repository was archived by the owner on Jun 6, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 52
cleanupTempfiles.minutes - default value #61
Copy link
Copy link
Open
Description
Hello,
We just did a test how the Pod will handle multiple restarts during backups.
- At some point there maybe snapshot creation started and interrupted
- As a result we may have a temporary backup file, which was not finished
drwxr-xr-x. 1 root root 56 Jan 4 11:04 .. -rw-r--r--. 1 root root 20547669028 Jan 4 10:02 dump.rdb -rw-r--r--. 1 root root 5188599808 Jan 4 11:03 temp-1-3.rdb -rw-r--r--. 1 root root 1432674655 Jan 4 10:46 temp-1-9.rdb -rw-r--r--. 1 root root 1078273848 Jan 4 10:46 temp-2086607563.1.rdb -rw-r--r--. 1 root root 0 Jan 4 11:06 temp-2088105784.1.rdb - At the next start KeyDB will load the data and then start to sync from the Master
- After the sync it will perform a new backup
- This backup can be interrupted and as a result we may have one more temp file.
Doing this in a loop, we may running out of disk space. It is for sure a corner case.
Current value for the cleanupTempfiles.minutes is 60 minutes and it will not delete all precedent crashes happened just some minutes ago.
What is the main reason to have such a big value?
For Bitnami Redis Chart we use the following
master:
preExecCmds: "rm -rf /data/temp*.*"So, we will delete all temporary files right before the Redis start.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels