You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
currently only during backup-intervall a backup is taken and stored. But if the pod is terminated there is a time gap between the last backup and the last commited transaction of the database. If then the disk dies, these last commits are lost.
At least in the case of normal pod termination we already get the termination signal. With this there is a chance to do one additional backup.
Downside: termination may take longer.
The text was updated successfully, but these errors were encountered:
Idea makes sense, but I would also see this as an additional feature, which can be turned on or off.
Reasoning: We have a special use case, in which we want two databases in the metal-stack (metal-db and ipam-db) to be in sync. This is why we take backups for those two databases with an identical time schedule. Your proposal works a bit against these "synchronous backup schedules".
currently only during backup-intervall a backup is taken and stored. But if the pod is terminated there is a time gap between the last backup and the last commited transaction of the database. If then the disk dies, these last commits are lost.
At least in the case of normal pod termination we already get the termination signal. With this there is a chance to do one additional backup.
Downside: termination may take longer.
The text was updated successfully, but these errors were encountered: