Description:
The MySQL Operator creates secrets (eg: {clustername}-privsecrets) with ownerReferences pointing to the InnoDBCluster CR:
When we delete the InnoDBCluster CR using --cascade=foreground:
1. The CR enters the "deletion in progress" state
2. Kubernetes garbage collector deletes all dependent resources (secrets) first
3. The operator's finalizer runs but fails because it still needs the secrets for cleanup operations
4. CR deletion hangs or fails
This is a race condition between the garbage collector and the operator's finalizer.
Expected Behavior
The InnoDBCluster CR should be deleted cleanly without errors. The operator's finalizer should complete successfully before any dependent secrets are removed.
Actual Behavior
The deletion fails with "not found" errors. The operator's finalizer attempts to access secrets (mycluster-privsecrets, mycluster-backup, mycluster-router) that have already been deleted by the Kubernetes garbage collector.
Error message in the operator - "details":{"name":"mycluster-privsecrets","kind":"secrets"},"code":404}
Environment
MySQL Operator Version: Helm chart version 2.2.9
Kubernetes Version: v1.34.3+rke2r1
Platform: RKE2 (on-prem)
How to repeat:
Install MySQL operator and InnoDBCluster CR as per https://dev.mysql.com/doc/mysql-operator/en/mysql-operator-innodbcluster.html
kubectl delete innodbcluster <CR NAME> --cascade=foreground
The deletion hangs or fails with errors like: Error: secrets "mycluster-privsecrets" not found
Check operator logs for actual failure error
Suggested fix:
Operator-owned secrets to handle the secret lifecycle correctly:
* Set ownerReferences to point to the operator deployment instead of the CR
* Secrets persist across the CR lifecycle, and the operator manages deletion explicitly
© 2026, Oracle Corporation and/or its affiliates
Description: The MySQL Operator creates secrets (eg: {clustername}-privsecrets) with ownerReferences pointing to the InnoDBCluster CR: When we delete the InnoDBCluster CR using --cascade=foreground: 1. The CR enters the "deletion in progress" state 2. Kubernetes garbage collector deletes all dependent resources (secrets) first 3. The operator's finalizer runs but fails because it still needs the secrets for cleanup operations 4. CR deletion hangs or fails This is a race condition between the garbage collector and the operator's finalizer. Expected Behavior The InnoDBCluster CR should be deleted cleanly without errors. The operator's finalizer should complete successfully before any dependent secrets are removed. Actual Behavior The deletion fails with "not found" errors. The operator's finalizer attempts to access secrets (mycluster-privsecrets, mycluster-backup, mycluster-router) that have already been deleted by the Kubernetes garbage collector. Error message in the operator - "details":{"name":"mycluster-privsecrets","kind":"secrets"},"code":404} Environment MySQL Operator Version: Helm chart version 2.2.9 Kubernetes Version: v1.34.3+rke2r1 Platform: RKE2 (on-prem) How to repeat: Install MySQL operator and InnoDBCluster CR as per https://dev.mysql.com/doc/mysql-operator/en/mysql-operator-innodbcluster.html kubectl delete innodbcluster <CR NAME> --cascade=foreground The deletion hangs or fails with errors like: Error: secrets "mycluster-privsecrets" not found Check operator logs for actual failure error Suggested fix: Operator-owned secrets to handle the secret lifecycle correctly: * Set ownerReferences to point to the operator deployment instead of the CR * Secrets persist across the CR lifecycle, and the operator manages deletion explicitly