Title: Percona XtraDB Cluster Operator Crashes with Nil Pointer Panic on PXCRestore

MySQL & MariaDB Percona Operator for MySQL
1

Percona XtraDB Cluster Operator Crashes with Nil Pointer Panic on PXCRestore

Hi all,

I'm running into a critical issue with the Percona XtraDB Cluster (PXC) Operator version 1.17.0, where the operator crashes with a panic (invalid memory address or nil pointer dereference) when trying to apply a PerconaXtraDBClusterRestore resource to restore from an Azure Blob backup.

❗ Issue Summary

  • The operator (pxcrestore-controller) crashes repeatedly whenever a restore CR is applied.
  • The panic appears to originate from a LabelsRestoreJob(...) function that receives {0x0, 0x0} — suggesting a nil or missing field.

🔧 Environment

  • Operator image: percona/percona-xtradb-cluster-operator:1.17.0
  • Kubernetes version: v1.28+
  • Namespace: percona

📄 CR YAML That Causes Crash

apiVersion: pxc.percona.com/v1
kind: PerconaXtraDBClusterRestore
metadata:
  name: restore1
  namespace: percona
spec:
  pxcCluster: my-db-pxc-db
  backupSource:
    destination: azure://percona-backup/my-db-pxc-db-2025-06-21-02:00:08-full
    azure:
      container: percona-backup
      credentialsSecret: azure-blob-secret

📜 Error Output (Truncated)

panic: runtime error: invalid memory address or nil pointer dereference [recovered]
...
github.com/percona/percona-xtradb-cluster-operator/pkg/naming.LabelsRestoreJob
        /go/src/github.com/percona/percona-xtradb-cluster-operator/pkg/naming/labels.go:106

The operator continues crashing on every reconciliation of the CR, which locks the cluster in a crash loop.

✅ What I’ve Tried

  • Removed backupName to avoid the known error about using both backupName and backupSource.
  • Validated the azure-blob-secret contains the required Azure storage account info.
  • Ensured container and destination fields are correctly set.
  • Tried deleting and recreating the CR — crash still happens.

🛠 Suggested Fixes / Questions

  • Is this a known bug in 1.17.0? If so, is it fixed in 1.18.x or later?
  • Could the operator be missing a nil check for the Azure backup block?
  • What’s the minimum required structure of a restore spec using Azure to avoid this panic?

Any help is appreciated. Let me know if I should post logs, secrets (redacted), or attempt a minimal repro again.

Thanks!
— beery

2

Hi @noops I tried to reproduce this issue but without any results :frowning:
I have used PXCO 1.17.0 and 1.18.0 as well.

STR:

  1. created PXC cluster
  2. use the same restore CR
apiVersion: pxc.percona.com/v1
kind: PerconaXtraDBClusterRestore
metadata:
  name: on-demand-backup-azure-01
spec:
  backupSource:
    azure:
      container: test1
      credentialsSecret: azure-secret
    destination: azure://test1/demand-backup-cloud-2025-06-30-09:59:38-full
  pxcCluster: cluster1
~

It works.