Issues
- Add Option to Limit SST Retry AttemptsK8SPXC-1619ege.gunes
- PITR pod loses connection to DB for 1 node clustersK8SPXC-1608
- pxc-backup is marked successful if upload fails due to incomplete backupK8SPXC-1596Resolved issue: K8SPXC-1596George Kechagias
- PXC-DB Helm Chart regenerates TLS Secrets on upgrade causing issues in clusterK8SPXC-1580Resolved issue: K8SPXC-1580Julio Pasinatto
- spec.backups.pitr.timeoutSeconds have no effectK8SPXC-1549Resolved issue: K8SPXC-1549Julio Pasinatto
- PITR pod crashing with "ERROR: collect binlog files: get GTID sets: get GTID set: scan set: context deadline exceeded" when having large number of binary log filesK8SPXC-1546Resolved issue: K8SPXC-1546Julio Pasinatto
6 of 6
Hi,
When SST fails several times in a row due to a software bug, for example, it can hardly be fixed by itself without intervention.
Meanwhile, SST runs continuously, consuming resources such as network bandwidth and affecting the donor's performance.
The Kubelet's --backoff-max-restart-delay is set to 5 minutes by default, which can be too short between restart attempts. This can lead to repeated SST retries in a short timeframe, potentially impacting cluster performance.
Ideally, nodes should have a configurable limit on SST attempts. After a few failed retries, they could stop requesting SST to avoid putting additional pressure on the cluster.
Thanks!