pingcap / pingcap/tidb-operator

BackupSchedule: Log backups are also included in the deletion targets of `spec.maxBackups`

Open
#6,320 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
1.3k
Forks
540
Avg merge
3d 2h
Merged PRs (30d)
18

Description

Question

What version of Kubernetes are you using?
v8.5.1

What version of TiDB Operator are you using?
v1.6.1

What did you do?

  • spec.backupTemplate
  • spec.logBackupTemplate
  • spec.maxBackups

Using backupSchedule, we integrated the management of scheduled snapshot backups and log backups.
Set maxBackups to 3.

What did you expect to see?

Log backups should not be subject to deletion by maxBackups and should continue.

What did you see instead?

The log backup CR is deleted during the third snapshot backup.

It is considered that the reason is that the deletion targets of maxBackups are not distinguished between snapshot backups and log backups. Is it expected behavior that log backups are included in the deletion targets of maxBackups?

https://github.com/pingcap/tidb-operator/blob/v1.6.1/pkg/backup/backupschedule/backup_schedule_manager.go#L675-L705

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with pkg/backup/backupschedule/backup_schedule_manager.go at lines 675-705, where maxBackups deletion targets are selected. Trace how snapshot and log backup resources are collected, then verify the intended behavior for both resource types. Done means log backup CRs are not deleted by the snapshot backup limit while snapshot cleanup still works.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes
Domain
devops, infrastructure
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.